Successfully reported this slideshow.
Your SlideShare is downloading.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

0

Share

RBA - Provision QoS

Material docente de la asignatura Redes de Banda Ancha de la ETSE Telecomunicaciones Vigo - Tema Provisión de QoS en Internet

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

RBA - Provision QoS

  1. 1. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.1. Exposición do problema
  2. 2. Tipos de tráfico Atendendo basicamente aos requisitos QoS, podemos distinguir: Tráfico elástico: Flexible en canto a requisitos de BW, adáptanse ás condiciones da rede. Son bastante tolerantes a retardos, pero non a perdas Corresponde ás aplicacións de datos tradicionais que usan tipicamente TCP e, polo tanto, os seus mecanismos reactivos de control de conxestión Dous tipos de aplicacións: • Transferencia masiva: FTP, aplicacións P2P, etc. • Transaccionais (moitas preguntas e respostas relativamente curtas): Web, acceso a BBDD, etc. Tráfico inelástico (ou de tempo real): Pouco flexibles en canto a requisitos de BW, necesitando un mínimo para traballar axeitadamente. Son relativamente tolerantes a perdas pero moi pouco a retardos Corresponde a aplicacións de tempo real, tipicamente multimedia, que usan UDP e técnicas de de disimulo ou FEC para paliar as perdas Dous tipos de aplicacións: • Interactivas (retardo ida-volta crítico, entre 200-400 ms.): Son as conversacionais (VoIP, videoconferencia) e algúns xogos en rede (de acción, ou tipo Doom) • Streaming de audio e/ou vídeo (retardo ida-volta menos crítico): O fluxo multimedia só viaxa dende un servidor a un cliente
  3. 3. Exposición do problema O modelo de servizo extremo a extremo ofrecido por IP é best-effort (BE) os paquetes IP son indistinguibles uns doutros e reciben o mesmo trato por parte da rede Aplicacións tradicionais de Internet (Web, FTP, e-mail, Telnet) son orientados a datos, é dicir, tolerantes a retardos, pero non a perdas (tráfico elástico) ⇒ Servicio BE de IP xunto coa fiabilidade extremo a extremo de TCP resulta axeitado Sen embargo, as novas aplicacións multimedia son de tempo real, é dicir, tolerantes a perdas pero non a retardos (os datos posúen un prazo de entrega) ⇒ Necesidade de garantías sobre o servizo, que se traduce na necesidade de distinguir os paquetes e darlles tratamentos diferenciados
  4. 4. Limitacións do best-effort Retardo extremo a extremo Especialmente crítico en aplicacións interactivas Retardos > 400 ms. poden danar a interactividade da conversación seriamente, polo que normalmente implican descartes no receptor Variación do retardo (jitter) Datos multimedia son xerados a tasa constante e deben ser reproducidos coa mesma tasa constante ⇒ Necesidade de eliminar o jitter introducindo un retardo artificial (búfer), fixo ou adaptativo, Compromiso entre o tamaño de búfer de recepción, que incrementa o retardo, e a tasa de paquetes fora de prazo
  5. 5. Escenario aplicación multimedia r mostras ou tramas/sg. TC Desempaquetador TD r mostras ou tramas/sg. Decodificador Codificador Empaquetador TREDE TB Búfer REDE recepción Tplayout(0) = T’0 = T0 + TC + TREDE + TB + TD T’i = T’i-1 + 1/r
  6. 6. Limitacións do best-effort Perdas A vantaxe do tráfico multimedia é a súa tolerancia ás perdas (tasas < 2% poden pasar inadvertidas) Estas perdas poderían eliminarse con TCP, pero A estratexia de retransmisión implica retardos que son habitualmente inaceptables O control de conxestión en TCP implica reducción da tasa de emisión tras perdas só é aceptable para tráfico elástico Por isto, emprégase UDP (SSC no fiable) Aínda con todo, no caso de perdas elevadas úsanse distintas técnicas, non excluíntes, que permiten elevar o límite permisible de perdas na rede incluso ata o 20%, dependendo da codificación: FEC (redundancia) Interleaving para paliar efectos de ráfagas de perdas. Incrementa o retardo. Ocultación de perdas (Loss concealing) no receptor: Repetición, interpolación e predicción.
  7. 7. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.2. O contrato de servizo e os principios da provisión de QoS
  8. 8. Provisión de QoS Unha arquitectura de provisión de QoS permite distinguir paquetes e tratalos de xeito distinto Obxectivo da provisión de QoS dar soporte a servizos que posúan necesidades específicas: Ancho de banda Retardo extremo a extremo Jitter Perdas A provisión de QoS permitirá despregar sobre Internet novas aplicacións e oportunidades de negocio
  9. 9. O contrato: os acordos TCA e SLA A provisión de QoS implica o establecemento dun contrato entre un usuario (final ou ISP) e a rede, que inclúe un acordo sobre o patrón de tráfico Traffic Conditioning Agreement (TCA) un acordo sobre a QoS que recibirá do usuario Service Level Agreement (SLA) O incumplimento do TCA por parte do usuario supón unha rotura de contrato e libera ao operador da súa obriga de cumprir o SLA
  10. 10. Principios da provisión de QoS I. Para cada fluxo, as fontes declaran o seu patrón de tráfico e os requisitos de QoS II. A clasificación e marcado permiten a un router distinguir paquetes III. As fontes deben conformar (shape) ou regular o seu patrón de tráfico ao declarado e a rede ten que monitorizar (police) o seu cumprimento IV. As clases de tráfico deben illarse para evitar interferencias nas QoS, pero isto debe facerse mediante un uso o máis eficiente posible dos recursos da rede (BW e búferes) ⇒ Mecanismos de planificación/asignación de recursos V. Necesítase un mecanismo de control de admisión: Admitir ou rexeitar un fluxo se a QoS solicitada non pode ser satisfeita sen comprometer a doutros fluxos xa aceptados.
  11. 11. Diagrama de bloques funcional A provisión de QoS nos routers dunha rede IP consta das seguintes fases: No acceso á rede: Distinción de paquetes: • Clasificación: Agrupar paquetes segundo algún criterio ou regra • Marcado: Código na cabeceira que identifica un fluxo ou clase • Monitorización de tráfico: medición e marcado adicional No núcleo da rede: Tratamento diferenciado para cumprir SLA: • planificación de recursos: búfer e BW Na saída da rede: Regulación de tráfico para cumprir TCA Clasificación Marcado Monitorización Router IP de paquetes de paquetes de tráfico Regulación de tráfico Active Queue Planificación Management BW (AQM)
  12. 12. Regulación de Tráfico (Traffic Shaping) Quero cumprir Eu vixío que se co TCA, polo tanto regularei o meu cumpre o TCA tráfico Regulador Datos Datos regulados reais Rede A regulación (conformación) do tráfico é realizada polo usuario para asegurar que o tráfico inxectado á rede é conforme ao patrón declarado no SLA A regulación é un mecanismo activo que altera (suaviza) o tráfico introducido Empréganse reguladores de tipo Leaky Bucket (cubo con goteo)
  13. 13. Leaky Bucket No caso máis simple, o tráfico dun fluxo Tráfico sen almacénase nun búfer regular (bucket) de tamaño C bytes, Descarte se do que se extrae a tasa bucket cheo constante ρ bytes/seg. Cando o bucket se enche, o Bucket con exceso de tráfico é capacidade para C bytes descartado ¿Inconveniente? Pode servir para regular Tráfico Tasa cte. fluxos de tasa constante, pero conformado ρ bytes/sg. (regulado) non serve claramente para os de tasa variable
  14. 14. Token Bucket (I) Tasa cte. ρ testigos/sg. Bucket con Descarta testigos capacidade para se bucket cheo C testigos Paquete de lonxitude L bytes Espera por Elimina L testigos L testigos Rede Tasa máxima R bytes/sg. Para permitir maior flexibilidade para o tráfico de tasa variable, emprégase un regulador lixeiramente distinto, denominado Token Bucket, que regula a tasa media ρ, permitindo ráfagas de tamaño C Cada paquete debe obter do bucket tantos testigos como a súa lonxitude (en bytes) para poder ser transmitido Os testigos son xerados a unha tasa constante ρ testigos/seg. e acumúlanse no bucket hasta un máximo de C testigos
  15. 15. celdas/sg. Token Bucket (e II) R Afórranse A C = TMÁX.(R-ρ ) A = min (C, ρ.T) testigos ρ TMÁX.ρ t TMÁX T Bucket cheo A mellora aportada por Token Bucket é que permite “aforrar” testigos, cando a tasa de tráfico está por debaixo de ρ, para poder ser usados cando esta tasa se atope por riba EXERCICIO: Calcular a duración máxima dunha ráfaga a tasa de pico R TMÁX = C/(R - ρ)
  16. 16. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.3. Regulación e Monitorización (Shaping and Policing)
  17. 17. Patróns de tráfico Os patróns de tráfico no TCA son declarados mediante especificacións Token Bucket(ρ, C), empregando os seguintes parámetros: para as tasas (ρ ): • CIR (Comitted Information Rate): Tasa sostible garantizada a longo prazo • PIR (Peak Information Rate): Tasa de pico para os tamaños de bucket (C ): • PBS/CBS/EBS (Peak/Comitted/Excess Burst Size)
  18. 18. Regulación conToken Bucket Para regular un fluxo de tasa constante, emprégase un TB(PIR, PBS). Tipicamente, PBS posuirá un valor pequeno. Nos fluxos de tasa variable sempre se regula a tasa CIR e o tamaño máximo das ráfagas (en bytes). Tipicamente hai dúas opcións: Na máis habitual tamén se regula a tasa PIR, mediante dous reguladores TB en serie: • Un para regular a PIR TB(PIR, PBS) • Outro, a continuación, para regular a CIR TB(CIR, CBS) • O tamaño máximo da ráfaga (en bytes) viría dado por TMÁX x PIR = CBS x PIR / (PIR - CIR) Cando a tasa PIR non é relevante, adóitase empregar dous límites para o tamaño de ráfaga, un brando (CBS) e outro estricto (CBS+EBS)
  19. 19. Monitorización (Policing) Marcadores No acceso á rede, debe verificarse se se cumple o TCA, función que se denomina monitorización ou vixilancia (policing). A monitorización dun fluxo implica realizar medidas para verificar a súa conformidade co TCA En función das medidas e a conformidade co TCA, asígnaselles aos paquetes unha marca adicional, tipicamente denominadas cores. Por isto, fálase habitualmente de marcadores ou algoritmos de marcado, pero debe distinguirse do marcado resultante da clasificación Comezouse usando 2 cores (verde/vermella) para distinguir o tráfico conforme do non conforme, pero hoxe é moito máis habitual o uso adicional dunha terceira cor (amarela) que ofrece unha maior flexibilidade en canto ao tratamento posterior: Habitualmente o tráfico claramente non conforme (vermello) é descartado En cambio, o tráfico non conforme “por pouco” (amarelo), tipicamente é: • Conformado, é dicir, retardado para que cumpra o TCA • Marcado cunha prioridade inferior ao conforme (verde)
  20. 20. Monitorización (Policing) Marcadores Este usuario non está cumprindo o contrato. ¿Cal debe ser a multa? Prioridade • DEIXAR PASAR, RETARDAR • MARCAR BAIXA PRIORIDADE Monitorización • DESCARTAR C 0 H 0 B H A H B L A H Paquete Prioridade baixa: En caso de conxestión, a descartado rede pode descartar máis tarde os paquetes C marcados de baixa prioridade Dado que o patrón de tráfico se especifica segundo o Token Bucket co que é regulado este, parece lóxico que a monitorización e marcaxe na rede se base no mesmo Token Bucket
  21. 21. Marcadores Token-Bucket: srTCM O marcador de tipoToken-Bucket máis simple é o GCRA usado en ATM, que marca VERMELLO os paquetes que non atopasen testigos no bucket equivalente, e VERDE en caso contrario. O algoritmo single rate Three Color Marker (srTCM - RFC 2697) usa dous buckets C e E, ambos con tasa CIR, e capacidades CBS e EBS (Excess Burst Size), de forma que E só empeza a encherse de testigos cando C está xa cheo: Inicialmente ambos buckets están cheos Se un paquete atopa suficientes testigos no bucket C, cólleos e márcase VERDE, se non • se hai suficientes testigos no bucket E, cólleos e márcase AMARELO, se non • o paquete márcase VERMELLO, pero non colle ningún testigo. srTCM é útil cando, ademáis da tasa CIR, a lonxitude da ráfaga, e non a PIR, é relevante ao servizo.
  22. 22. Marcadores Token-Bucket: trTCM Cando se desexa monitorizar ambas tasas, CIR e PIR, úsase o marcador two rate TCM (trTCM - RFC 2698) Empréganse dous buckets, P e C, con tasas PIR e CIR, e capacidades PBS e CBS, respectivamente: Un paquete que non atope suficientes testigos no bucket P márcase VERMELLO, sen tomar testigo algún. Se houbese suficientes en P collería estes, e nese caso: • Se non houbese suficientes testigos no bucket C, marcaríase como AMARELO, sen coller testigos de C • Se houbese suficientes testigos no bucket C, colleríaos e marcaríase como VERDE
  23. 23. Marcador TSW-TCM Para reducir a probabilidade de descartar unha ráfaga de múltiples paquetes dunha mesma ventá de envío TCP, como pode ocorrer cos marcadores de tipo TB, propúxose un marcador baseado nunha función de marcado probabilística Este é o marcador TSW-TCM (RFC 2859), que usa un estimador da tasa media sobre o tráfico recibido nunha ventá temporal (Time-Sliding Window - TSW) Coa chegada de cada paquete, estímase a tasa media R e, segundo o seu valor, asígnase a cor ao paquete: Se R ≤ CIR Paquete VERDE Se CIR < R ≤ PIR PA = (R – CIR) / R • Paquete AMARELO con probabilidade PA (crecente con R) • Paquete VERDE con probabilidade 1-PA Se R > PIR PR = (R–PIR)/R y PA = (PIR–CIR)/R • Paquete VERMELLO con probabilidade PR (crecente con R) • Paquete AMARELO con probabilidade PA (decrecente con R) • Paquete VERDE con probabilidade 1-(PR + PA) Importantes traballos de investigación recomendan que o tamaño da ventá para un fluxo TCP sexa igual ao RTT (Round Trip Time) do fluxo. No caso de agregación de fluxos, TCP ou UDP, un valor de 1 seg. parece axeitado.
  24. 24. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.4. Illamento de clases de tráfico: Planificación de búfer
  25. 25. Planificación de búfer (AQM) Os mecanismos de planificación de búfer reciben tamén o nome de mecanismos de xestión activa de cola (Active Queue Management - AQM) En ausencia dun mecanismo AQM nun router IP, todos os paquetes que chegan a un búfer cheo son descartados de xeito indiscriminado, mecanismo que se denomina tail drop Sincronización global en TCP Solución: descarte no indiscriminado Téñense propostos diversos mecanismos de xestión de cola baseados en prioridades/clases: PBS (Partial Buffer Sharing): Un nodo con memoria B bytes e N umbrais 0 < B1 < B2 <... < BN = B descartará o tráfico da clase i se a memoria ocupada é superior a Bi bytes PushOut: As celdas de maior prioridade expulsan ás de menor prioridade cando o búfer se enche
  26. 26. O algoritmo RED O mecanismo AQM máis amplamente usado é RED (Random Early Drop), baseado en Descarte aleatorio de paquetes (para evitar a sincronización global en TCP) Tras detección adiantada da conxestión (unha vez superado un límite do tamaño medio da cola) Funcionamento: Á chegada dun paquete estímase o tamaño medio Q da cola de saída Qi+1 = Qi*a + q*(1 – a) Se Q < minth Funcionamento normal: Almacenamento do paquete Se minth ≤ Q < maxth Evitar conxestión: O paquete descártase cunha probabilidade crecente linealmente con Q: Pdrop=Pmax*(Q – minth)/(maxth–minth) Se Q ≥ maxth Conxestión: Descártase o paquete O comportamento de RED ven determinado polo conxunto de parámetros (minth, maxth, Pmax). Recoméndase que maxth sexa dous ou tres veces minth. Valores típicos de Pmax atópanse entre 0.01 e 0.2
  27. 27. RED con varios niveis de precedencia (prioridade) de descarte Unha variante moi usada é RIO (RED IN/OUT), que usa RED con dous niveis de precedencia de descarte, é dicir, dous conxuntos de parámetros: un para os paquetes dentro do perfil (IN) outro para os paquetes fora do perfil de tráfico OUT (maxOUT < minIN ). No cálculo de QIN só se contabilizan os paquetes IN, mentres no cálculo de QOUT contabilízanse todos (IN e OUT) Do mesmo xeito, pódense usar tres conxuntos de parámetros (3 niveis de precedencia) cando temos un marcador de tres cores
  28. 28. Explicit Congestion Notification – ECN O mecanismo de control de conxestión actualmente usado por TCP, baseado no control do fluxo, ten dous serios inconvenientes: Adoece do problema da sincronización global A indicación de conxestión é xerada localmente (sen participar a rede) e de forma implícita (tras non recibir ACKs) Na actualidade estase empezando a usar o mecanismo ECN, baseado igualmente no control do fluxo, pero onde a notificación sexa xerada pola rede (os routers IP) e sexa unha indicación explícita da conxestión. Un mecanismo similar úsase en ATM co bit EFCI. En ECN, os routers IP usan o mesmo mecanismo de detección adiantada da conxestión de RED. A diferencia radica en que cando RED descartaría un paquete, en ECN reenviase igualmente pero notifícase a conxestión á fonte TCP de forma explícita.
  29. 29. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.5. Illamento de clases de tráfico: Planificación de BW
  30. 30. Planificación de BW: GPS Estes mecanismos de planificación úsanse para decidir cal será o próximo paquete a enviar sobre un enlace dado. FIFO e PQ (Priority Queueing) non garanten BW mínimo nin equidade na súa asignación ⇒ Disciplinas basadas en GPS (Generalized Processor Sharing) Dadas N colas con pesos wi para un enlace de capacidade C, GPS reparte este BW entre todas as colas non baleiras de forma proporcional ao peso, de xeito que en cada instante a tasa de servizo para unha cola non baleira i é Ri = C . (wi /∑k non baleira wk) e garantindo a cada cola un BW mínimo proporcional ó peso GPS é un algoritmo ideal, imposible de implementar, dado que asume que o servidor pode atender simultaneamente todas as colas non baleiras (a una tasa de servizo Ri) e que o tráfico é fluído, cando nun sistema realista só se pode atender unha cola cada vez (a tasa máxima C) e o tráfico consta de paquetes de lonxitude variable.
  31. 31. WFQ (Weighted Fair Queueing) Todas as aproximacións prácticas de GPS propostas fan uso dun reparto circular WFQ é a aproximación de GPS máis amplamente usada Sen entrar nos seus detalles, cabe dicir que WFQ presenta pequenas diferencias de funcionamento fronte a GPS, favorecendo tipicamente ás colas con maior peso Poden aniñarse 2 niveis de WFQ CBQ (Class-Based Queueing) Considéranse clases de tráfico e úsase un WFQ entre clases. Cada clase i posee un peso Wi Dentro de cada clase distínguense colas ou fluxos. Cada cola k da clase i ten un peso relativo wik (tipicamente son iguais e o ancho de banda de cada clase repártese equitativamente entre os fluxos activos) O peso absoluto dunha cola ou fluxo individual é Wik = Wi x wik
  32. 32. TB e GPS (WFQ): Retardo acotado Suposicións caso ideal: Fluxo fluído regulado con Token Bucket(C, ρ) que atravesa N Bucket routers Todos os routers usan GPS e garanten a este fluxo un BW R>ρ Peor caso: bucket cheo Retardo máximo no primeiro router = C/R Seguintes routers: Dado que a tasa de saída (R) é sempre maior que a de entrada (ρ) Retardo = 0 Retardo máx. extremo a extremo TMAX ≤ C/R Caso real: WFQ e un fluxo con paquetes de tamaño máx. m (M na rede), H saltos e Rk capacidade en cada enlace k [Parekh 92]: C ( H − 1)m H M TMAX ≤ + +∑ R R k =1 Rk
  33. 33. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.5. Arquitecturas de provisión de QoS: IntServ
  34. 34. Servicios integrados (IntServ) IntServ é unha arquitectura proposta para Internet no seo de IETF, co obxectivo de dar garantías QoS a sesións de aplicación individuais (fluxos), baseándose en: Reserva de recursos Control de admisión Procedemento: Un fluxo declara o seu TCA e SLA, enviándoos a cada router atravesado mediante RSVP RSVP [Zhang 93; RFC 2205] é o protocolo de sinalización usado en IntServ para permitir ás aplicacións establecer e liberar reservas de recursos en Internet (tipicamente BW), de xeito similar a como se fai nas redes clásicas orientadas a conexión Cada router verifica se dispón de recursos suficientes, reservándoos en caso afirmativo e rexeitando a sesión correspondente ao fluxo en caso negativo.
  35. 35. IntServ : Clases de servizo A arquitectura IntServ define dúas clases de servizo básicas: Servizo garantido [RFC 2212]: Para aplicacións de tempo real que necesitan garantías cuantitativas firmes de QoS Servizo de carga controlada [RFC 2211]: Para aplicacións elásticas, incluso de tempo real, como as que deseñaron para a Internet actual, que son relativamente tolerantes a retardos pero moi sensitivas á conxestión. O servizo é cualitativamente “bo” (perdas e retardos baixos) pero non se dan garantías cuantitativas.
  36. 36. Reparto de recursos en IntServ Best Effort Caudal → Carga controlada Garantido Tempo →
  37. 37. Inconvenientes de IntServ Escalabilidade: A reserva de recursos mediante RSVP e o mantemento do estado de cada fluxo que atravesa un router resulta moi pouco eficiente se o número de fluxos é moi elevado (máis de 250.000 nun troncal) Flexibilidade: IntServ non permite definir clases de servizo cualitativamente distintas (p. ex., a clase A recibiría un trato preferente sobre a B) que, entre outras vantaxes, permitiría que a tarificación resultase moito máis sinxela e intuitiva que a realizada en base a requisitos cuantitativos.
  38. 38. Problema de escalabilidad de RSVP Estes routers han de manter información sobre moitos fluxos e por tanto moita información de estado ‘Core’ de Internet
  39. 39. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.6. Arquitecturas de provisión de QoS: DiffServ
  40. 40. Servicios diferenciados (DiffServ) DiffServ DiffServ [RFC 2475] resolve os problemas de IntServ fixando o número de posibles categorías de servizo, sendo por tanto independente do número de fluxos ou usuarios; e de complexidade constante Así, en vez de distinguir fluxos individuais, en DiffServ clasifícanse os paquetes en clases á entrada da rede (dominio), onde se marcan axeitadamente. Posteriormente, os routers tratan cada paquete segundo a súa clase ofrecendo servizo diferenciado por clase (comportamento agregado) DiffServ basease só no marcado de paquetes. Non hai reserva de recursos por fluxo, non hai protocolo de sinalización, non hai información de estado nos routers (atópase contida nos paquetes) Aínda que as garantías QoS non son tan severas como en IntServ, en moitos casos considéranse suficientes
  41. 41. DiffServ: A fronteira Os nodos fronteira son os que supoñen a entrada/saída a/de un dominio DS e, por tanto, son os que se interconectan con outros dominios e cos hosts Aínda que son funcionalmente moi similares, adoitase distinguir entre os routers periféricos ou de acceso (que dan servicio aos clientes finais) e os fronteira (que interconectan dominios) Nos routers fronteira, os paquetes IP son clasificados e marcados no octeto DS [RFC 2474]. A clasificación nun router fronteira faise en base a certos campos da súa cabeceira: dirs. IP, portos, protocolo, etiqueta de fluxo (IPv6), campo DS, interface de entrada, etc. Clasificación y marcado basado en clases. Dos tipos de marcado: Marcado interclase: paquetes de clases diferentes son marcados de xeito diferente Marcado intraclase: en dúas ou tres cores, segundo o nivel de conformidade co patrón acordado DiffServ só facilita a arquitectura marco para a provisión de QoS DiffServ non especifica cómo se fai a clasificación ou o marcado, nen que accións se deben tomar en caso de incumplimiento do patrón de tráfico (conformación, descarte, ...)
  42. 42. Campo DS (RFC 2474) Campo DS DSCP ECN DSCP: Differentiated Services CodePoint. Seis bits que indican o tratamento que debe recibir o paquete nos routers ECN: Campo reservado para o mecanismo ECN de control de conxestión O campo DS, con igual lonxitude e formato que en IPv4, colócase en IPv6 sustituíndo ao campo prioridade (de 4 bits) e aos catro primeros bits do campo ‘etiqueta de fluxo’ que se reduce de 24 a 20 bits
  43. 43. Aparición do campo DS en IPv4 e IPv6 IPv4 Antes Precedencia D T R C X IPv4 e IPv6 Agora DSCP ECN IPv6 Prioridade Etiq. de Fluxo (1-4) Antes Os tres primeros bits interprétanse En DiffServ os tres primeiros bits (ccc) indican a clase, e os dous seguintes (dd) úsanse para o como prioridade en tódolos casos por marcado intraclase (as cores) compatibilidade con moitos routers
  44. 44. DiffServ: O núcleo (core) Os routers DS interiores a un dominio tratan aos paquetes salto a salto e só en base á súa clase. É o que se denomina Per-Hop Behavior (PHB) Un PHB é unha descrición do comportamento de envío externamente observable (medible) nun nodo DS, aplicado a unha clase en particular Un router non DS aplicará o mesmo PHB (é dicir, best-effort) a todo o tráfico (clase única) DiffServ distingue claramente entre o PHB e a súa implementación: mentres se manteña o criterio de diferencia de prestacións observable, DiffServ permite implementar calquer mecanismo de asignación de recursos para logralo O grupo de traballo DiffServ en IETF definiu dous PHBs: Expedited Forwarding (EF) [RFC 2598] Assured Forwarding (AF) [RFC 2597]
  45. 45. DiffServ: EF PHB O PHB Expedited Forwarding (EF) [RFC 2598] ofrece un SLA que, basicamente, garante un BW mínimo O valor DSCP é “101110” EF está pensado para aplicacións que Requiran retardos, perdas e/ou jitter moi baixos (colas moi pequenas), de forma equivalente a un servicio VBR-rt de ATM. Tamén recibe o nome de “servicio Premium”. Non se dan garantías cuantitativas para tasa de perdas, retardo ou jitter Requiran una tasa de pico garantida. Dende o punto de vista das aplicacións, trátase dunha especie de conexión punto a punto ou “liña virtual alugada”
  46. 46. DiffServ -Assured Service O PHB Assured Forwarding (AF) está baseado no assured service (AS) Características principais do AS: “Asegúrase” que o tráfico conforme ao perfil contratado para un fluxo será entregado sen perdas con probabilidade moi alta, aínda en caso de conxestión O perfil pode incumprirse, pero coa comprensión de que o tráfico en exceso non será entregado con una probabilidade tan alta Garántese a entrega ordenada dentro de cada fluxo, independentemente de que os paquetes sexan conformes ou no
  47. 47. DiffServ: AF PHB O PHB Assured Forwarding (AF) [RFC 2597] permite ofrecer distintos niveis de “garantía de entrega” ou de calidade relativa: O AF-PHB ofrece ata 4 niveis de servizo AS (clases) sen fixar garantías (non hai SLA) Asegúrase un trato diferenciado entre clases, pero non se garanten BWs, retardos, etc. Non obstante, o ISP pode ofrecer a contratación de distintos BWs por clase Cada router debe garantir que o nivel de servizo ofrecido a cada clase sexa sempre superior ao dunha clase de menor prioridade Dentro de cada clase, os paquetes poden clasificarse á vez en ata tres categorías de preferencia de descarte (dependendo do marcado na fronteira), que recibirán tratamento diferenciado segundo outros tantos mecanismos de tipo RED
  48. 48. Codepoints do Servizo AF (RFC2597) Menor probabilidade Maior probabilidade de descarte de descarte Hoxe en día tamén se Precedencia de descarte empregan ‘dd’ servizos BE Clase (clase ‘000’) Baixa ’11’ Media ’10’ Alta ’01’ con prioridade ‘ccc’ (indicada polos Maior prioridade AF4 AF43 AF42 AF41 bits ‘dd’) ‘100’ 10011 10010 10001 AF3 AF33 AF32 AF31 O DSCP ‘011’ 01111 01110 01101 ‘000000’ correspondería AF2 AF23 AF22 AF21 ó servizo Best ‘010’ 01011 01010 01001 Effort sen AF1 AF13 AF12 AF11 prioridade de sempre ‘001’ 00111 00110 00101 Menor prioridade BE BE3 BE2 BE1 ‘000’ 00011 00010 00001
  49. 49. Tipos de servizo en DiffServ Equivalencia en Servizo Características ATM • É o que da máis garantías. Equivale a unha liña dedicada EF-PHB ou • Garante Caudal Tasa de perdas, retardo e jitter baixos CBR e VBR-rt Premium • DSCP = 101110 • Asegura un trato preferente, pero sen fixar garantías (non hai SLA) AF-PHB • Defínense catro clases e en cada unha 3 niveis de descarte VBR-nrt de paquetes BE • Sen garantías, pero con trato preferente frente a ‘best- effort sen prioridade’ ABR con prioridade BE • Sen garantías, obtén só os recursos sobrantes UBR sen prioridade
  50. 50. Reparto de recursos en DiffServ BE sin prioridade BE con prioridade Caudal → AF-PHB EF-PHB o Premium Tempo →
  51. 51. DiffServ: Implementación A implementación máis habitual usa PQ entre PHBs e WFQ entre as clases AF Dentro de EF-PFB, é habitual usar WFQ entre os distintos fluxos para garantir BW individualmente Para garantir certo BW ao servizo BE, podería introducirse tamén BE no reparto WFQ como se fose unha clase AF adicional de menor prioridade (AF0) se non se desexa considerar servizo BE con prioridade, podería usarse a clase AF menos prioritaria e con maior probabilidade de descarte, é dicir a AF11, para o tráfico BE
  52. 52. Cola ‘EF’ Cola ‘AF 4’ PQ Cola ‘AF 3’ WFQ Cola ‘AF 2’ Liña de saída WFQ/ Cola ‘AF 1’ PQ Cola ‘BE’
  53. 53. RFCs Diffserv RFC 2430 (10/1998): A Provider Architecture for DiffServ and Traffic Eng. RFC 2474 (12/1998): Definition of the DS field in the IPv4 and IPv6 Headers RFC 2475 (12/1998): An Architecture for Differentiated Service RFC 2597 (6/1999): Servicio Expedited Forwarding RFC 2598 (6/1999): Servicio Assured Forwarding RFC 2638 (7/1999): A Two-bit DiffServ Architecture for the Internet RFC 2963 (10/2000): A Rate Adaptive Shaper for Differentiated Services RFC 2983 (10/2000) Differentiated Services and Tunnels RFC 3086 (4/2001): Def. of DiffServ Per Domain Behaviors & Rules for Spec. RFC 3270 (5/2002): MPLS Support of DiffServ RFC 3287 (7/2002): Remote Monitoring MIB Extensions for DiffServ RFC 3289 (5/2002): Management Information Base for the DiffServ Architect.
  54. 54. Situación actual Aínda que IntServ foi desenvolvido con anterioridade, DiffServ estendeuse máis DiffServ permite agregar fluxos o modelo é escalable Moitos fabricantes de routers implementan versións eficientes de DiffServ, pero non de IntServ, debido ao elevado costo que supón a implementación HW das funcións de mantemento da información de estado Actualmente, moitos ISP implementan DiffServ Problema Provisión de QoS extremo a extremo
  55. 55. Problema de DiffServ Provisión QoS extremo a extremo Os detalles de como cada router trata o campo DSCP son arbitrarios, e resulta difícil predicir o comportamento extremo a extremo. Isto é máis complicado se un paquete atravesa dous ou máis dominios DiffServ para acadar o seu destino Dende un punto de vista comercial, isto supón un inconveniente fundamental, xa que resulta imposible vender distintas clases de servizo extremo a extremo ós clientes finais (un paquete AF4 nun ISP pode ser tratado como AF2 noutro) Os ISPs poderían resolver este problema forzando a implantación de SLAs normalizados entre as redes, pero non están pola labor de engadir complexidade adicional ós seus xa complexos SLAs e acordos de intercambio de tráfico IP
  56. 56. Combinación de RSVP e DiffServ RSVP RSVP DiffServ RSVP RSVP Na periferia da rede o uso de RSVP non plantexa problemas e pode ser necesaria a reserva estricta de recursos Neste caso, o router DS fronteira ‘traducirá’ a petición ao servizo DiffServ máis parecido.
  57. 57. Redes de Banda Ancha Curso 2009/10 Tema 3 Provisión de calidade de servizo (QoS) 3.7. Provisión de QoS en ATM
  58. 58. Servizo CBR (Constant Bit Rate) Capacidade do enlace CBR • • • PCR/CDVT CTD, CDV, CLR CBR CBR é unha emulación de circuítos, é dicir, resérvase de forma estática un caudal PCR para cada CV, que se desperdicia de non ser usada É un servizo deseñado para aplicacións de tempo real de tasa constante (tipicamente, voz sen comprimir) As conexións ATM son monitorizadas mediante GCRA (Generic Cell rate Algorithm), que equivale a un marcador TB de dúas cores e tasa única. No caso de CBR úsase para monitorizar o PCR, sendo tipicamente descartadas as celdas vermellas
  59. 59. Servizo VBR (Variable Bit Rate) Capacidade no Capacidade aproveitada do enlace VBR • • • VBR • CBR • • CBR Garántese un caudal sostible SCR, permitíndose ráfagas de duración MBS a tasa máxima PCR A pesar de reservar a capacidade SCR, a diferencia de CBR, se non é usada queda libre para outros fluxos VBR ou de menor prioridade. Dúas variantes: VBR-rt (real time): Para tráfico de tempo real (típicamente, vídeo) ⇒ QoS caracterizada por retardo máx. e jitter VBR-nrt (no real time): Para tráfico elástico con caudal e tasa de perdas garantidos As conexións VBR son monitorizadas mediante dous GCRA en serie: un para PCR (celdas vermellas son descartadas) e outro a continuación para SCR e MBS (celdas vermellas son marcadas con CLP=1)
  60. 60. Servizo ABR (Available Bit Rate) Capacidade Tráfico ABR elástico do enlace con garantías VBR ABR CBR VBR ABR CBR (PCR, MCR) A realimentación da rede evita a conxestión e a perda de celdas Deseñado para tráfico elástico, lixeiramente sensible a perdas, ao que se lle garante un caudal mínimo Mediante control de conxestión reactivo (realimentación), as conexións ABR varían o seu caudal entre un mínimo (MCR) e un máximo (PCR), o que permite manter unha tasa de perdas baixa Aínda que ABR vai enchendo os ocos que deixa VBR, por razóns de dimensionado, só se emprega o caudal por riba do SCR total reservado Nas conexións ABR podería monitorizarse a tasa MCR, de xeito que as celdas vermellas serían marcadas con CLP=1
  61. 61. Servizo UBR (Unspecified Bit Rate) Capacidade excedente Capacidade utilizada por UBR do enlace VBR UBR CBR VBR UBR CBR Celdas descartadas en caso de conxestión UBR intenta aproveitar o BW que poida deixar VBR e ABR (tamén a porción do SCR reservado non usado) Non hai garantías Non está sometido a control de conxestión Equivale a un servicio best-effort, resultando axeitado para tráfico IP sin necesidad de garantías QoS. En caso de conxestión, é o primeiro tráfico en ser descartado
  62. 62. Categorías de Servizo ATM Servicio Best Calidade de Garantido Effort Servicio CBR VBR-rt VBR-nrt ABR UBR
  63. 63. Suscrición dun enlace A suma ABR MCR + VBR SCR + CBR PCR correspondente ás reservas de BW que se deben realizar sobre un enlace recibe comunmente o nombre de “suscrición do enlace” Unha regra de dimensionado habitualmente usada polos operadores consiste en manter a suscrición dos seus enlaces por debaixo do 50% Non obstante, dado que hai moitas fontes VBR (ADSL, principalmente) que non consumen o seu SCR reservado, podería existir “sobresuscrición” para este tipo de tráfico sen incumplir os SLAs na práctica BWVBR ≤ Σi SCRi
  64. 64. Exemplo de servizo VBR-nrt: ADSL A normativa legal (CMT 31/3/2004) establece as seguintes modalidades ADSL, basadas na categoría VBR-nrt de ATM. As celdas non conformes con PCR descártanse e as non conformes con SCR son marcadas con CLP=1

    Be the first to comment

    Login to see the comments

Material docente de la asignatura Redes de Banda Ancha de la ETSE Telecomunicaciones Vigo - Tema Provisión de QoS en Internet

Views

Total views

935

On Slideshare

0

From embeds

0

Number of embeds

21

Actions

Downloads

0

Shares

0

Comments

0

Likes

0

×