Calidad de Servicio en aplicaciones multimedia sobre redes de ...
Calidad de Servicio en aplicaciones multimedia sobre redes de ...
Calidad de Servicio en aplicaciones multimedia sobre redes de ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Aunque <strong>en</strong> el estudio que <strong>en</strong> este docum<strong>en</strong>to sepres<strong>en</strong>ta no estén incluidas, la arquitecturaPacketCable soporta más funciones extremoextremo,a<strong>de</strong>más <strong>de</strong> la provisión <strong>de</strong> <strong>Calidad</strong> <strong>de</strong><strong>Servicio</strong>, <strong>en</strong>tre las cuales se <strong>en</strong>cu<strong>en</strong>tran, laseguridad [4], facturación y otras funciones <strong>de</strong>gestión <strong>de</strong> la red.Junto a estas especificaciones <strong>de</strong> PacketCableque <strong>de</strong>fin<strong>en</strong> una arquitectura a nivel IP, esnecesario t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta también el medio <strong>en</strong> elque nos <strong>en</strong>contramos, una red <strong>de</strong> cable, <strong>en</strong>don<strong>de</strong> el <strong>en</strong>lace upstream es un mediocompartido (con un sistema <strong>de</strong> acceso al medioTDMA y con tasa <strong>de</strong> transmisión máxima <strong>de</strong>10Mbps). Esto se traduce <strong>en</strong> la necesidad <strong>de</strong>mecanismos <strong>de</strong> provisión <strong>de</strong> QoS <strong>de</strong>ntro <strong>de</strong> lared <strong>de</strong> cable misma para permitir nuevosservicios a nuevos cli<strong>en</strong>tes sin disminuir lacalidad <strong>de</strong> los ya exist<strong>en</strong>tes. De la <strong>de</strong>finición <strong>de</strong>las características <strong>de</strong> QoS, así como <strong>de</strong> otrasfuncionalida<strong>de</strong>s, <strong>en</strong> la red <strong>de</strong> acceso <strong>de</strong> cable seocupan las especificaciones DOCSIS 1.1 (DataOver Cable Service Interface Specifications)[5]. Y por tanto, hay que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta laexist<strong>en</strong>cia <strong>de</strong> una integración <strong>en</strong>tre losprotocolos a nivel IP <strong>de</strong>finidos por PacketCablecon la capa <strong>de</strong> <strong>en</strong>lace (DOCSIS).Así, DOCSIS provee cinco tipos <strong>de</strong> servicio <strong>en</strong>el upstream (s<strong>en</strong>tido cable mo<strong>de</strong>m- CMTS ocabecera <strong>de</strong> cable):- Unsolicited Grant Service (UGS).- Real-Time Polling Service (rtPS).- Unsolicited Grant Service with ActivityDetection (UGS-AD).- Non-Real Time Polling ServiceFigura 1. Mo<strong>de</strong>lo <strong>de</strong> arquitectura <strong>de</strong>PacketCable <strong>en</strong> OPNET.- MTA (Multimedia Terminal Adapter ,equipo <strong>de</strong> usuario)- CM (Cable Mo<strong>de</strong>m, mó<strong>de</strong>m cable <strong>en</strong> elusuario)- CMTS (Cable Mo<strong>de</strong>m TeminationSystem, cabecera <strong>de</strong> cable)- CMS (Call Managem<strong>en</strong>t Server, gestor<strong>de</strong> acceso <strong>de</strong> usuarios)Estos compon<strong>en</strong>tes <strong>de</strong> red han sido diseñados apartir <strong>de</strong> elem<strong>en</strong>tos disponibles <strong>en</strong> OPNET, sinembargo, han t<strong>en</strong>ido que ser modificadosprincipalm<strong>en</strong>te para introducir laimplem<strong>en</strong>tación <strong>de</strong> los protocolos necesariospara proveer QoS y que no estabanimplem<strong>en</strong>tados <strong>en</strong> la herrami<strong>en</strong>ta <strong>de</strong> simulación.Estos protocolos que se han implem<strong>en</strong>tado <strong>en</strong> laherrami<strong>en</strong>ta OPNET para mo<strong>de</strong>lar laarquitectura <strong>de</strong> PacketCable <strong>de</strong>sempeñan unaserie <strong>de</strong> funcionalida<strong>de</strong>s <strong>en</strong> la red:(nrtPS). - autorización <strong>de</strong> los usuarios- Best Effort Service (BE).- autorización <strong>de</strong> los recursos que <strong>de</strong>mandan- reserva <strong>de</strong> los recursos- activación <strong>de</strong> los recursosPor ello <strong>en</strong> este docum<strong>en</strong>to también se pres<strong>en</strong>tala evaluación <strong>de</strong> algunos <strong>de</strong> estos tipos <strong>de</strong>servicio <strong>en</strong> la herrami<strong>en</strong>ta <strong>de</strong> simulaciónOPNET.CMSPDP3. Descripción <strong>de</strong>l trabajo.COPS DQoSPara abordar el estudio <strong>de</strong> la arquitecturaPacketCable se ha mo<strong>de</strong>lado la misma <strong>de</strong>ntro <strong>de</strong>la herrami<strong>en</strong>ta <strong>de</strong> simulación OPNET. En dichomo<strong>de</strong>lo se i<strong>de</strong>ntifican los compon<strong>en</strong>tes <strong>de</strong> redbásicos <strong>de</strong> las especificacionesPacketCable/IPCableCom (Figura 1), que son:CMTSPEPFigura 2. Jerarquía CMTS-CMS, a través <strong>de</strong>lprotocolo COPS.Esta arquitectura ti<strong>en</strong>e una jerarquía, basada <strong>en</strong>el protocolo COPS [6] (figura 2), porque estasfuncionalida<strong>de</strong>s <strong>de</strong>b<strong>en</strong> ser <strong>de</strong>sempeñadas porsus compon<strong>en</strong>tes sigui<strong>en</strong>do una cierta secu<strong>en</strong>cia2
para llegar a proveer calidad <strong>de</strong> servicio. Enprimer lugar se hace una autorización <strong>de</strong> losusuarios (esta función la <strong>de</strong>sempeña el CMS(Call Manager Server)), elem<strong>en</strong>to que gestionalas difer<strong>en</strong>tes <strong>aplicaciones</strong>. Una vez que unusuario ha sido autorizado, se <strong>de</strong>b<strong>en</strong> autorizarlos recursos que <strong>de</strong>manda, es <strong>de</strong>cir, comprobarque no <strong>de</strong>manda más cantidad <strong>de</strong> recursos <strong>de</strong> losque ti<strong>en</strong>e <strong>en</strong> su SLA (<strong>de</strong> lo cual también ti<strong>en</strong>econtrol el CMS). Es <strong>de</strong>cir, el CMS realiza unagestión a alto nivel. El sigui<strong>en</strong>te paso (sigui<strong>en</strong>t<strong>en</strong>ivel <strong>en</strong> la jerarquía) es comprobar que existanrecursos sufici<strong>en</strong>tes <strong>en</strong> la red <strong>de</strong> cable paraproveer la QoS que <strong>de</strong>manda el cli<strong>en</strong>te (<strong>de</strong> locual ti<strong>en</strong>e el control el CMTS, porque es qui<strong>en</strong>ti<strong>en</strong>e el conocimi<strong>en</strong>to <strong>de</strong> los recursos que sonempleados y los que quedan libres <strong>en</strong> cadamom<strong>en</strong>to). Con este mo<strong>de</strong>lo jerárquico, sialguna <strong>de</strong> estas autorizaciones no essatisfactoria hace que no se continúe con elestablecimi<strong>en</strong>to <strong>de</strong> la comunicación, y por tantono se llegaría a autorizar o a reservar recursos.De esta forma, la comunicación se corta <strong>en</strong>cuanto se sabe que no hay posibilidad <strong>de</strong>ejecutarla con las garantías solicitadas y no semalgastan los recursos.Una vez que la autorización <strong>de</strong> los recursos hasido satisfactoria, los cli<strong>en</strong>tes <strong>de</strong> lacomunicación pue<strong>de</strong>n reservar los recursos <strong>en</strong> lared <strong>de</strong> cable para po<strong>de</strong>r transmitir con losparámetros <strong>de</strong> QoS <strong>de</strong>mandados <strong>en</strong> el inicio <strong>de</strong>lestablecimi<strong>en</strong>to <strong>de</strong> la comunicación. Estapetición <strong>de</strong> reserva por parte <strong>de</strong> los cli<strong>en</strong>tes esefectuada al CMTS, que como ya se ha dicho, esel elem<strong>en</strong>to que ti<strong>en</strong>e el control <strong>de</strong> los recursosexist<strong>en</strong>tes y disponibles para su utilización. Deesta forma, si exist<strong>en</strong> los recursos <strong>de</strong>mandados,se los reserva al cli<strong>en</strong>te. A<strong>de</strong>más también secontrola que no se <strong>de</strong>man<strong>de</strong>n <strong>en</strong> la reserva másrecursos <strong>de</strong> los que fueron autorizados <strong>en</strong> laetapa <strong>de</strong> autorización, <strong>de</strong> lo cual también ti<strong>en</strong>eun control el CMTS. Es <strong>de</strong>cir, el CMTS realizauna gestión <strong>de</strong> los recursos físicam<strong>en</strong>te <strong>de</strong>ntro<strong>de</strong> la jerarquía.- COPS PacketCable (basado <strong>en</strong> el protocoloCOPS estándar, [6]): se ocupa <strong>de</strong> laautorización <strong>de</strong> los usuarios, así como <strong>de</strong> laautorización <strong>de</strong> los recursos <strong>en</strong> la red.- RSVP+ (basado <strong>en</strong> el protocolo RSVPestándar, [7]): se ocupa <strong>de</strong> la reserva y <strong>de</strong> laactivación <strong>de</strong> los recursos.- Protocolo <strong>de</strong> señalización <strong>de</strong> aplicación(basado <strong>en</strong> el protocolo NCS estándar, [8]):es necesario para que se inicie elmecanismo <strong>de</strong> autorización, así como el <strong>de</strong>la reserva.4. Resultados.Las simulaciones <strong>en</strong> OPNET realizadas ti<strong>en</strong><strong>en</strong>dos objetivos difer<strong>en</strong>tes, por una parte, sepret<strong>en</strong><strong>de</strong> testear el uso <strong>de</strong> la arquitectura <strong>de</strong>PacketCable para extraer conclusiones <strong>sobre</strong> la<strong>Calidad</strong> <strong>de</strong> <strong>Servicio</strong> disp<strong>en</strong>sada. Y por otraparte, se han realizado simulaciones para ver elpropio comportami<strong>en</strong>to <strong>de</strong> una red <strong>de</strong> cableDOCSIS, así como los resultados que ofrec<strong>en</strong>los difer<strong>en</strong>tes tipos <strong>de</strong> servicio <strong>en</strong> el upstreamque son ofrecidos por ella misma a nivel <strong>de</strong> capafísica.4.1. Configuración arquitecturaPacketCable.Se han realizado simulaciones <strong>de</strong> la arquitectura<strong>en</strong> OPNET (Figura 1) creada con el objetivo <strong>de</strong>comprobar el establecimi<strong>en</strong>to <strong>de</strong> la señalizacióna<strong>de</strong>cuada, acor<strong>de</strong> con la <strong>de</strong>scrita <strong>en</strong> la figura 3.Así como para comprobar el comportami<strong>en</strong>toobt<strong>en</strong>ido por una aplicación que <strong>de</strong>ba serautorizada, y para la que se realic<strong>en</strong> reservas <strong>de</strong>recursos a través <strong>de</strong> RSVP+ y se hagan cumplircon el planificador WFQ (Weighted FairQueueing). Y todo ello comparándolo con elcomportami<strong>en</strong>to <strong>de</strong> una aplicación que no haganingún tipo <strong>de</strong> petición <strong>de</strong> QoS.Finalm<strong>en</strong>te, <strong>en</strong> el mo<strong>de</strong>lo <strong>de</strong> PacketCable existeuna última etapa, que es la <strong>de</strong> la activación <strong>de</strong>los recursos. Esta etapa ti<strong>en</strong>e su razón porquelos recursos han sido reservados por el CMTS,pero hasta que el cli<strong>en</strong>te no los activa no tomaposesión <strong>de</strong> ellos. Esto hace posible que <strong>en</strong>tre lareserva y la activación pueda ser posible queotros cli<strong>en</strong>tes hagan uso <strong>de</strong> los recursos <strong>de</strong> lared, permiti<strong>en</strong>do hacer un uso más efici<strong>en</strong>te <strong>de</strong>los limitados recursos.Las funcionalida<strong>de</strong>s son resueltas por lossigui<strong>en</strong>tes protocolos:3
MTAo CMTSsocketcli<strong>en</strong>t_op<strong>en</strong>cli<strong>en</strong>t_acceptcli<strong>en</strong>t_requestCMSMTAdprotocolo RSVP ni el RSVP+. Por tanto, sólo sevan a hacer reservas y activaciones <strong>de</strong> losrecursos <strong>en</strong> la sección <strong>de</strong> red don<strong>de</strong> se haconfigurado el protocolo RSVP+.ncs_initgate_setgate_set_ackncs_initncs_init4.2. Conclusiones arquitectura PacketCable.ncs_init_ackrsvp_pathrsvp_resvrsvp_commitrsvp_commit_ackrsvp_tearrsvp_tear_ackncs_finishgate_setgate_set_ackgate_op<strong>en</strong>gate_op<strong>en</strong>start communicationgate_closefinish communicationncs_init_ackrsvp_pathrsvp_resvrsvp_commitrsvp_commit_ackncs_finishEl tiempo total que pasa <strong>de</strong>s<strong>de</strong> que la aplicacióninicia su autorización (<strong>en</strong>vío <strong>de</strong>l m<strong>en</strong>saje Ncs-Init) hasta que recibe el m<strong>en</strong>saje RSVP+Commit-Ack (significa que los recursos han sidoactivados) es <strong>de</strong> 0,2347 segundos. Este tiempoes el que <strong>de</strong>be transcurrir hasta que la aplicaciónrealm<strong>en</strong>te recibe la calidad <strong>de</strong> servicio que se leasignó (cuyo cumplimi<strong>en</strong>to es misión <strong>de</strong>lplanificador WFQ).Figura 3. Señalización.En particular las simulaciones realizadas hant<strong>en</strong>ido una duración <strong>de</strong> 300 segundos y se hanconfigurado dos <strong>aplicaciones</strong> <strong>de</strong> VoIP (Voiceover IP). Los parámetros son:(1) una aplicación <strong>de</strong> VoIP con RSVP+ yNCS habilitados:- norma G.723.1 que implica una tasa <strong>de</strong>transmisión <strong>de</strong> 5,3Kbps.- la longitud <strong>de</strong> los sil<strong>en</strong>cios sigue unadistribución expon<strong>en</strong>cial <strong>de</strong> media 0,65segundos.- Tipo <strong>de</strong> servicio Interactive Voice.- RSVP parameters activados- Señalización NCS.- La aplicación se establece <strong>en</strong>tre loselem<strong>en</strong>tos <strong>de</strong>l esc<strong>en</strong>ario MTA y <strong>de</strong>stination.(2) una aplicación <strong>de</strong> VoIP sin RSVP+ niNCS habilitados:- norma G.711 que implica una tasa <strong>de</strong>transmisión <strong>de</strong> 64Kbps- la longitud <strong>de</strong> los sil<strong>en</strong>cios sigue unadistribución expon<strong>en</strong>cial <strong>de</strong> media 0,65segundos.- Tipo <strong>de</strong> servicio Interactive Voice.- RSVP parameters no activados.- Sin ningún tipo <strong>de</strong> señalización.- Esta aplicación se establece <strong>en</strong>tre elelem<strong>en</strong>to llamado Embed<strong>de</strong>d_MTA y<strong>de</strong>stination_no_RSVP.En este esc<strong>en</strong>ario sólo soportan dos nodos elprotocolo RSVP+: el MTA y el CMTS <strong>en</strong> suinterfaz con el medio compartido. Esto esporque es <strong>en</strong>tre estos elem<strong>en</strong>tos <strong>en</strong> don<strong>de</strong> se<strong>de</strong>be establecer la reserva <strong>de</strong> recursos <strong>en</strong> unesc<strong>en</strong>ario <strong>de</strong> cable PacketCable. El resto <strong>de</strong>elem<strong>en</strong>tos <strong>de</strong> la arquitectura no soportan ni elTabla 1. Resultados <strong>de</strong> <strong>de</strong>lay <strong>de</strong> las<strong>aplicaciones</strong>.Aplicación Delay Jitter <strong>de</strong>lay DesviaciónVoz conRSVP+Voz sinRSVP+estándar0,0126 5,4728E-5 1,4696E-50,6033 1,6576 0,4511En la tabla 1 se pres<strong>en</strong>tan los resultados <strong>en</strong>cuanto al comportami<strong>en</strong>to <strong>de</strong> las <strong>aplicaciones</strong><strong>sobre</strong> el esc<strong>en</strong>ario. Para ello se pres<strong>en</strong>ta el <strong>de</strong>layo retardo extremo-extremo, el jitter <strong>de</strong>lay y la<strong>de</strong>sviación estándar <strong>de</strong>l <strong>de</strong>lay.At<strong>en</strong>di<strong>en</strong>do a estos resultados <strong>de</strong> la tabla 1, laaplicación <strong>de</strong> voz con RSVP+ ti<strong>en</strong>e mejorcomportami<strong>en</strong>to que la <strong>de</strong> voz sin RSVP+ <strong>en</strong>cuanto a <strong>de</strong>lay, jitter <strong>de</strong>lay, así como <strong>de</strong>sviciónestándar <strong>de</strong>l <strong>de</strong>lay.Por tanto, se ha comprobado que la aplicación ala que se le reservan y activan los recursos qu<strong>en</strong>ecesita para su ejecución obti<strong>en</strong>e unos valores<strong>de</strong> <strong>de</strong>lay, jitter <strong>de</strong>lay, y <strong>de</strong>sviación estándar <strong>de</strong>l<strong>de</strong>lay mucho mejores que una que no disfruta<strong>de</strong>l mo<strong>de</strong>lo PacketCable. Es <strong>de</strong>cir, se haconseguido proporcionar a esta aplicación ciertonivel <strong>de</strong> <strong>Calidad</strong> <strong>de</strong> <strong>Servicio</strong> gracias al mo<strong>de</strong>locontrolado IntServ [2] que provee OPNET.Este mo<strong>de</strong>lo es implem<strong>en</strong>tado <strong>en</strong> OPNETgracias al planificador <strong>de</strong> paquetes WFQ que seha configurado <strong>en</strong> los nodos <strong>de</strong> la arquitectura,<strong>en</strong> especial <strong>en</strong> el CMTS. Este permite asegurarun <strong>de</strong>terminado comportami<strong>en</strong>to a los flujos <strong>de</strong>datos.4.3. DOCSIS, tipos <strong>de</strong> servicio <strong>en</strong> elupstream, configuración.4
El mo<strong>de</strong>lo <strong>de</strong> DOCSIS 1.1 provee 5 tipos <strong>de</strong>servicios, que ya se han m<strong>en</strong>cionadoanteriorm<strong>en</strong>te. En OPNET sólo es posiblerealizar simulaciones <strong>de</strong> los tipos UGS y BE,por ello sólo se han podido estudiar estos dostipos <strong>de</strong> servicios.Los mini-slots <strong>en</strong> los que está dividido el <strong>en</strong>laceupstream <strong>de</strong>l cable pue<strong>de</strong>n ser empleados comoasignaciones para los usuarios para po<strong>de</strong>rtransmitir información, como slots <strong>de</strong>competición, para que otras estaciones nuevasse puedan unir al medio y como <strong>de</strong> control. Yexist<strong>en</strong> unos m<strong>en</strong>sajes llamados MAP (<strong>en</strong>viadospor el <strong>en</strong>lace dowstream), mediante los cuales,el CMTS realiza las asignaciones <strong>de</strong> mini-slots alos difer<strong>en</strong>tes usuarios y <strong>de</strong>fine los mini-slots <strong>de</strong>control (no son asignaciones para latransmisión <strong>de</strong> usuarios) a través <strong>de</strong> elem<strong>en</strong>tos<strong>de</strong> información.Cada elem<strong>en</strong>to <strong>de</strong> información repres<strong>en</strong>ta untipo <strong>de</strong> mini-slot. Así, los posibles tipos <strong>de</strong>elem<strong>en</strong>tos <strong>de</strong> información que pue<strong>de</strong> transportarun m<strong>en</strong>saje MAP son: Request (petición),Request/data (petición con piggybacking), Shortgrant (asignación), Long grant (asignación),P<strong>en</strong>ding (asignación), Initial maint<strong>en</strong>ance(aparec<strong>en</strong> cada mucho tiempo), Stationmaint<strong>en</strong>ance (aparec<strong>en</strong> cada mucho tiempo).Los tipos <strong>de</strong> elem<strong>en</strong>tos <strong>de</strong> información másimportantes son los <strong>de</strong> petición (con los que se<strong>de</strong>fin<strong>en</strong> los mini-slots que se <strong>de</strong>dicarán <strong>en</strong> latrama TDMA para la competición <strong>de</strong> todos losusuarios, que emplearán para <strong>de</strong>mandar minislotspara po<strong>de</strong>r transmitir su información). Ypor otra parte, los <strong>de</strong> asignación, es <strong>de</strong>cir, losmini-slots asignados para la transmisión a cadausuario.- Frecu<strong>en</strong>cia c<strong>en</strong>tral: 8MHz- Bytes por mini-slot: 4También se <strong>de</strong>b<strong>en</strong> configurar una serie <strong>de</strong>parámetros relacionados con los m<strong>en</strong>sajes MAP,que se pue<strong>de</strong>n ver a continuación:- tiempo <strong>en</strong>tre MAPs: se <strong>de</strong>fine <strong>en</strong> cadasimulación- Grant Interval: se <strong>de</strong>fine <strong>en</strong> cada simulación- número <strong>de</strong> mini-slots para hacer peticiones(<strong>de</strong> competición): 16- tamaño límite <strong>de</strong> bytes que pue<strong>de</strong>n ser<strong>en</strong>viados <strong>en</strong> los elem<strong>en</strong>tos <strong>de</strong> informaciónreducidos: 128 bytes- tamaño límite <strong>de</strong> bytes que pue<strong>de</strong>n ser<strong>en</strong>viados <strong>en</strong> los elem<strong>en</strong>tos <strong>de</strong> informacióngran<strong>de</strong>s: 1000 bytes- Mini-slots <strong>de</strong> mant<strong>en</strong>imi<strong>en</strong>to inicial: 4mini-slots/segundo- Mini-slots <strong>de</strong> mant<strong>en</strong>imi<strong>en</strong>to <strong>de</strong> la estación:2 mini-slots/segundoPor otra parte, se <strong>de</strong>b<strong>en</strong> pres<strong>en</strong>tar los difer<strong>en</strong>testipos <strong>de</strong> servicio que han sido objeto <strong>de</strong> estudio:UGS y BE.El tipo <strong>de</strong> servicio UGS se caracteriza poreliminar el overhead y la lat<strong>en</strong>cia queintroduc<strong>en</strong> las peticiones <strong>de</strong> los CMs para po<strong>de</strong>rtransmitir, porque el CMTS hace asignacionesperiódicas <strong>de</strong> forma que asegura o reserva un<strong>de</strong>terminado ancho <strong>de</strong> banda <strong>en</strong> el upstreampara cada cable mo<strong>de</strong>m que ti<strong>en</strong>e configuradoeste tipo <strong>de</strong> servicio. En cambio, para el tipoBest-Effort (BE) no se disp<strong>en</strong>san asignacionesperiódicas, sino que <strong>de</strong>be emplear los mini-slots<strong>de</strong> competición para solicitar al CMTS que leasigne mini-slots <strong>en</strong> el sigui<strong>en</strong>te MAP, y asípo<strong>de</strong>r transmitir.Los parámetros <strong>de</strong> configuración para cada<strong>en</strong>lace, y los valores particulares que se hanempleado <strong>en</strong> las simulaciones son lossigui<strong>en</strong>tes:Estos tipos <strong>de</strong> servicio también pose<strong>en</strong> unosparámetros que <strong>de</strong>b<strong>en</strong> ser configurados. Éstosson:(1) Best-Effort (BE):(1) Downstream (s<strong>en</strong>tido CMTS-CM):- i<strong>de</strong>ntificador <strong>de</strong> canal <strong>sobre</strong> el que se- modulación: 64QAMquiere transmitir = 0,- tasa datos: 27Mbps - parámetros DOCSIS 1.1- ancho <strong>de</strong> banda <strong>de</strong>l canal: 6MHz - fragm<strong>en</strong>tación habilitada (sólo es- Frecu<strong>en</strong>cia c<strong>en</strong>tral: 500MHzconfigurable <strong>en</strong> DOCSIS 1.1)- Lat<strong>en</strong>cia <strong>en</strong>trelazador: profundidad <strong>de</strong><strong>en</strong>trelazado: 32 e increm<strong>en</strong>to :4(2) Unsolicited Grant (UGS):(2) Upstream (s<strong>en</strong>tido CM-CMTS): - i<strong>de</strong>ntificador <strong>de</strong> canal <strong>sobre</strong> el que sequiere transmitir = 0- modulación para un canal: QPSK - versión DOCSIS 1.1- tasa máxima <strong>de</strong>l <strong>en</strong>lace: 640Kbps - Grant Size para cada CM- ancho <strong>de</strong> banda <strong>de</strong>l canal: 800KHz“configurable <strong>en</strong> cada simulación”=5
- Nominal Grant Interval : “configurable<strong>en</strong> cada simulación”- Fragm<strong>en</strong>tación no habilitada (no esposible habilitarla <strong>en</strong> estaimplem<strong>en</strong>tación <strong>de</strong> OPNET).Hay que hacer una serie <strong>de</strong> consi<strong>de</strong>raciones paraconfigurar los parámetros Nominal GrantInterval y Grant Size para el servicio UGS:- El Nominal Grant Interval <strong>de</strong>be seralgo superior al tiempo <strong>en</strong>tre MAPs.Este tiempo <strong>en</strong>tre MAPs <strong>de</strong>fine latrama básica <strong>en</strong> tiempo <strong>de</strong>l TDMA- El Grant Size vi<strong>en</strong>e dado <strong>en</strong> g<strong>en</strong>eralpor [eq.1].Grant Size = tamaño <strong>de</strong>l paquete g<strong>en</strong>erado porel cli<strong>en</strong>te + cabecera IP[eq.1]Se pue<strong>de</strong> calcular el número <strong>de</strong> mini-slotsdisponibles <strong>en</strong>tre dos m<strong>en</strong>sajes MAPs, es <strong>de</strong>cir,el número <strong>de</strong> mini-slots <strong>de</strong> la trama TDMA através <strong>de</strong> la sigui<strong>en</strong>te fórmula [eq.2].tasa <strong>en</strong>lace x intervalo <strong>en</strong>tre MAPs [eq.2]nº mini - slots =8 (bits/byte)x(bytes/mini - slot)Pero no todos estos mini-slots pue<strong>de</strong>n serempleados por los usuarios para transmitir; losque realm<strong>en</strong>te se pue<strong>de</strong>n emplear para este tipo<strong>de</strong> servicio resultan <strong>de</strong> restarle a [eq.2] elnúmero <strong>de</strong> mini-slots <strong>de</strong> competiciónconfigurados <strong>en</strong> el upstream.nºmini-slots disponibles =tasa <strong>en</strong>lace x intervalo<strong>en</strong>tre MAPs8 (bits/byte)x(bytes/mini -slot)– 16 (competición)(1) para un tamaño <strong>de</strong> paquete DOCSIS (antes<strong>de</strong> añadir el código <strong>de</strong> corrección) inferiora 66 bytes:- Preamble l<strong>en</strong>gth: 48 bits- FEC Error Correction: 10 bytes- FEC Co<strong>de</strong>word L<strong>en</strong>gth: 75 bytes- Guard time: 40 bits- Last Co<strong>de</strong>word Mo<strong>de</strong>: Fixe-l<strong>en</strong>gth(2) Para un tamaño <strong>de</strong> paquete superior a 66bytes:- Preamble l<strong>en</strong>gth: 56 bits- FEC Error Correction: 16 bytes- FEC Co<strong>de</strong>word L<strong>en</strong>gth: 226 bytes- Guard time: 40 bits- Last Co<strong>de</strong>word Mo<strong>de</strong>: Fixe-l<strong>en</strong>gthPara calcular el tamaño <strong>de</strong>l paquete DOCSISfinal se ti<strong>en</strong>e que efectuar los sigui<strong>en</strong>tescálculos:Nº palabras código: tamaño <strong>de</strong>l paquete sincorrección <strong>de</strong> errores/(FEC Co<strong>de</strong> Word L<strong>en</strong>gth-FEC Parity)El tamaño final <strong>de</strong>l paquete es: número <strong>de</strong>palabras x DEC Co<strong>de</strong> Word + (Preamble +Guard Time)/8[eq.5]Se han realizado múltiples simulaciones condifer<strong>en</strong>te número <strong>de</strong> usuarios, difer<strong>en</strong>tescombinaciones <strong>de</strong> tipos <strong>de</strong> servicios, y <strong>de</strong>configuraciones <strong>de</strong> los mismos. Pero elesc<strong>en</strong>ario <strong>de</strong> simulación más g<strong>en</strong>eral <strong>sobre</strong> elque se han efectuado simulaciones es el <strong>de</strong> lafigura 4.[eq.3]También es importante t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta eltamaño <strong>de</strong> los paquetes DOCSIS para calcular elnúmero <strong>de</strong> mini-slots necesarios para <strong>en</strong>viar unpaquetes DOCSIS. Este cálculo se realiza con lafórmula [eq.4].Nºmini-slots para paquete = tamaño paqueteDOCSIS /(nºbytes/mini-slot)[eq.4]Para calcular el tamaño <strong>de</strong>l paquete DOCSIS esnecesario conocer: el tamaño <strong>de</strong> las cabecerasque son añadidas a los paquetes creados por elcli<strong>en</strong>te (20 bytes <strong>de</strong> cabecera IP y 26 bytes <strong>de</strong>cabecera DOCSIS) y los bytes añadidos por elcódigo <strong>de</strong> corrección <strong>de</strong> errores que poseeDOCSIS. Los parámetros <strong>de</strong>l código <strong>de</strong>corrección <strong>de</strong> errores son:Figura 4. Esc<strong>en</strong>ario <strong>de</strong> simulación DOCSIS.Se van a <strong>de</strong>tallar los parámetros particulares <strong>de</strong>una prueba, sin embargo, no se va a dar unainformación tan exhaustiva <strong>de</strong>l resto <strong>de</strong> pruebas6
ealizadas para no increm<strong>en</strong>tar <strong>en</strong> excesivo lalongitud <strong>de</strong> este artículo. Simplem<strong>en</strong>te seexpondrán las conclusiones g<strong>en</strong>erales obt<strong>en</strong>idas<strong>de</strong> todas las simulaciones.until _ map =nºmin i − slotsocupadosDatosEnMAP)Parámetros:nºmin i − slotsDisponiblesParaDatosEnMAP- Tiempo <strong>en</strong>tre MAPs: 0,02 segundos- Nº mini-slots por MAP, <strong>de</strong> [eq.2] : 400 [eq.7] es la utilización <strong>de</strong> la trama TDMA, <strong>en</strong> %- Nº mini-slots disponibles por MAP, <strong>de</strong>[f.3]: 384tasa _ g<strong>en</strong> =- Tasa total <strong>de</strong>l <strong>en</strong>lace uspstream:paqueteDOCSIS(bytes)*8(bits/byte)640Kbps∑- Tasa disponible <strong>de</strong>l <strong>en</strong>lace upstream,nº cli<strong>en</strong>tes intervalo_g<strong>en</strong>eración_paquetes<strong>de</strong> [eq.6]: 614.400bps[eq.8][eq.7]tasa_util =[f.3]*4( bytes/ minislot)*8(bits/byte)intervalo−MAPs[eq.6]La fórmula [eq.6] especifica la tasa <strong>de</strong>transfer<strong>en</strong>cia máxima que es posible obt<strong>en</strong>er <strong>en</strong>el <strong>en</strong>lace upstream, <strong>de</strong>bido a que no es posibleemplear toda la trama TDMA para transmitirinformación útil.Los parámetros <strong>de</strong> los usuarios son los <strong>de</strong> latabla 2:Tabla 2. Tasa <strong>de</strong> g<strong>en</strong>eración <strong>de</strong> cli<strong>en</strong>tes ytipos <strong>de</strong> servicio.Tasa g<strong>en</strong>eración <strong>de</strong>paquetes IP(bytes/seg)Cli<strong>en</strong>tes1, 2,3Cli<strong>en</strong>te4Cli<strong>en</strong>te5393 /0,03(109.800bps)39 /0,03(10.400bps)39 /0,03(10.400bps)Tipo <strong>de</strong>servicioNominalIntervalGrant(seg)GrantSize(bytes)CM [1]UGS 0,03 393UGS 0,03 39BE _ _Según los parámetros configurados <strong>en</strong> loscli<strong>en</strong>tes se pue<strong>de</strong> calcular el número <strong>de</strong> minislotsnecesarios para transmitir, la utilizaciónmáxima <strong>de</strong> un intervalo <strong>en</strong>tre MAPs y el total <strong>de</strong>tasa g<strong>en</strong>erada por todos los cli<strong>en</strong>tes, así como lautilización <strong>de</strong>l <strong>en</strong>lace. Para ello consultar tabla3.Tabla 3. Parámetros <strong>de</strong> los cli<strong>en</strong>tes.Cli<strong>en</strong>tes[5] [4] [7] [8] [9] [10]1, 2, 3 464 1164 86 225 86 22100 418.133,3 68,165,33[eq.8] es la tasa <strong>de</strong> g<strong>en</strong>eración <strong>de</strong> paquetesDOCSIS, <strong>en</strong> bits/segutil _ upstream _ <strong>de</strong>l _ disponible =tasa _ g<strong>en</strong>erada _ cli<strong>en</strong>tes ( bps ) x100 [eq.9]tasa _ util _ upstream ( bps )[eq.9] es la utilización <strong>de</strong>l upstream, <strong>de</strong>ntro <strong>de</strong>lefectivo para po<strong>de</strong>r transmitir datos.util _ upstream _ total =tasa _ g<strong>en</strong>erada _ cli<strong>en</strong>tes(bps)x100tasa _ total _ upstream(640bps)[eq.10][eq.10] es la utilización <strong>de</strong>l upstream <strong>en</strong> total,incluidos los mini-slots <strong>de</strong> competiciónEn este esc<strong>en</strong>ario se completaban el número <strong>de</strong>mini-slots disponibles pero sólo <strong>en</strong> ciertosmom<strong>en</strong>tos, luego no se g<strong>en</strong>eraba una tasa <strong>de</strong>información superior a la capacidad útil <strong>de</strong>l<strong>en</strong>lace.4.4. DOCSIS, conclusionesLos resultados particulares para la prueba<strong>de</strong>scrita con <strong>de</strong>talle son los que a continuaciónse pres<strong>en</strong>tan.Tabla 4. Retardos <strong>de</strong> espera <strong>en</strong> cola <strong>en</strong> losCMs.Retardo<strong>en</strong> cola<strong>de</strong>lCM_1(seg)Retardo<strong>en</strong> cola<strong>de</strong>l CM_2(seg)Retardo<strong>en</strong> cola<strong>de</strong>l CM_3(seg)Retardo<strong>en</strong> cola<strong>de</strong>l CM_4(seg)Retardo<strong>en</strong> cola<strong>de</strong>l CM_5(seg)0,0226 0,0063 0,0121 0,01813 0,09578El retardo (tabla 4) que se obti<strong>en</strong>e <strong>en</strong> la cola <strong>de</strong>lCM_5 (que ti<strong>en</strong>e un tipo <strong>de</strong> servicio Best-Effort) es el tiempo que transcurre hasta queconsigue que se le asign<strong>en</strong> mini-slots. Estetiempo es <strong>de</strong>bido <strong>en</strong> parte al tiempo <strong>en</strong>tre MAPs(tiempo <strong>en</strong>tre posibles peticiones) y a que7
cuando realiza una petición es posible que elCMTS no t<strong>en</strong>ga recursos sufici<strong>en</strong>tes para él <strong>en</strong>ese mom<strong>en</strong>to; <strong>en</strong> este caso <strong>de</strong>be quedar <strong>en</strong>espera hasta que el CMTS t<strong>en</strong>ga mini-slotsdisponibles para su petición. Por tanto, lospaquetes irán acumulando retardo hasta quepuedan ser transmitidos.Sin embargo, para el tipo <strong>de</strong> servicio UGS, elCMTS asigna periódicam<strong>en</strong>te los mini-slots qu<strong>en</strong>ecesitan, por eso si llega una petición <strong>de</strong> Best-Effort cuando ya han sido asignados los recursosa los flujos UGS y no quedan sufici<strong>en</strong>tes para lapetición Best-Effort, se queda <strong>en</strong> espera.El retardo que obti<strong>en</strong><strong>en</strong> estas transmisiones bajoun tipo <strong>de</strong> servicio UGS es <strong>de</strong>bido a la suma <strong>de</strong>ltiempo <strong>de</strong> transmisión por el <strong>en</strong>lace DOCSIS <strong>de</strong>un paquete g<strong>en</strong>erado por el cli<strong>en</strong>te (0,001segundos para los paquetes <strong>de</strong>l CM_4 y 0,0058segundos para los paquetes <strong>de</strong> los CM 1, 2 Y 3)más el tiempo <strong>de</strong> espera <strong>en</strong> cola correspondi<strong>en</strong>te<strong>en</strong> cada caso. Este es difer<strong>en</strong>te para cada CM<strong>de</strong>bido a que <strong>de</strong>p<strong>en</strong><strong>de</strong> <strong>de</strong>l or<strong>de</strong>n <strong>en</strong> el que elCMTS asigna los mini-slots a los CMs para eltipo <strong>de</strong> servicio UGS, como se pue<strong>de</strong> ver <strong>en</strong> losdatos <strong>de</strong> la tabla 4.Vi<strong>en</strong>do los tiempos <strong>de</strong> espera <strong>en</strong> cola <strong>de</strong> losCMs se pue<strong>de</strong> <strong>de</strong>cir <strong>en</strong> qué or<strong>de</strong>n son asignadoslos mini-slots a los CMs:(1) CM_3(2) CM_4(3) CM_2(4) CM_1Tabla 5. Delay medio <strong>de</strong> las transmisiones.upDelaymedio0,029 0,01275EnlaceTransmisión 1Transmisión 2Transmisión3Transmisión4Transmisión50,01855 0,01935 0,097Y <strong>en</strong> cuanto a los resultados <strong>de</strong> retardo mediopara cada transmisión (tabla 5), se pue<strong>de</strong>observar que la comunicación <strong>de</strong> la transmisión5 (<strong>en</strong>tre cli<strong>en</strong>te_5 y <strong>de</strong>stino_5), que ti<strong>en</strong>e un tipo<strong>de</strong> servicio Best-Effort asociado, g<strong>en</strong>era unacomunicación con mayor <strong>de</strong>lay medio, si locomparamos con el <strong>de</strong> las otras comunicaciones.Esto no es sorpr<strong>en</strong><strong>de</strong>nte, sino que era algoesperable si se recuerdan los resultados <strong>de</strong>retardo <strong>en</strong> colas <strong>de</strong> los CMs.Otras conclusiones g<strong>en</strong>erales que se pue<strong>de</strong>nobt<strong>en</strong>er <strong>de</strong> todas las simulaciones efectuadasson:- El retardo que experim<strong>en</strong>tan lospaquetes que se transmit<strong>en</strong> <strong>en</strong> elupstream <strong>de</strong>p<strong>en</strong><strong>de</strong> <strong>de</strong>l tiempo <strong>en</strong>treMAPs que se estipule. Si este tiempoes pequeño, el retardo será m<strong>en</strong>or<strong>de</strong>bido a que los CMs podrán efectuarpeticiones (<strong>en</strong> el caso <strong>de</strong> tipo <strong>de</strong>servicio BE) cada m<strong>en</strong>or tiempo ypodrán transmitir datos cada m<strong>en</strong>ortiempo, reduci<strong>en</strong>do el tiempo que<strong>de</strong>b<strong>en</strong> esperar <strong>en</strong> sus colas esos datos.- Es necesario que la fragm<strong>en</strong>tación estéhabilitada si se quiere transmitir unpaquete que no cabe <strong>en</strong> un intervalo <strong>de</strong>MAP. Esta fragm<strong>en</strong>tación sólo estáimplem<strong>en</strong>tada <strong>en</strong> la versión DOCSIS1.1 y sólo es posible seleccionarla <strong>en</strong>OPNET para el tipo <strong>de</strong> servicio Best-Effort. Por tanto, no es posibletransmitir paquetes que t<strong>en</strong>gan unaduración superior a la <strong>de</strong> un intervalo<strong>de</strong> MAP para un tipo <strong>de</strong> servicio UGS,porque no se van a po<strong>de</strong>r fragm<strong>en</strong>tar.- Se ha podido observar que la carga quesupon<strong>en</strong> las cabeceras IP y DOCSIS(cabecera y corrección <strong>de</strong> errores) esmuy elevada, si<strong>en</strong>do muy pequeño elporc<strong>en</strong>taje <strong>de</strong> información útil que setransmite. De esta forma se gana <strong>en</strong>inmunidad fr<strong>en</strong>te a ruido, aunque se<strong>de</strong>sperdicia parte <strong>de</strong> la capacidad <strong>de</strong>l<strong>en</strong>lace para transmisión <strong>de</strong> informaciónútil.- Se ha podido comparar elcomportami<strong>en</strong>to <strong>de</strong>l servicio Best-Effort fr<strong>en</strong>te al UGS, y como era <strong>de</strong>esperar, el retardo obt<strong>en</strong>ido para elservicio UGS ha sido inferior que elobt<strong>en</strong>ido para el servicio Best-Effort.Esto se <strong>de</strong>be a que el tipo <strong>de</strong> servicioBest-Effort no da garantías <strong>de</strong> QoS,porque sólo se le permite transmitircuando hay recursos libres y el CMTSse los asigna previa petición por parte<strong>de</strong>l CM. Sin embargo, <strong>en</strong> el servicioUGS esto no es necesario ya que elCMTS asigna periódicam<strong>en</strong>te minislots,según la configuración inicial <strong>de</strong>lCM, para que pueda transmitir. Esto setraduce <strong>en</strong> un m<strong>en</strong>or tiempo <strong>de</strong> espera<strong>en</strong> cola para los paquetes que recib<strong>en</strong>un tipo <strong>de</strong> servicio UGS.- El retardo que percib<strong>en</strong> los paquetesbajo un tipo <strong>de</strong> servicio UGS <strong>en</strong> elupstream <strong>de</strong>p<strong>en</strong><strong>de</strong> básicam<strong>en</strong>te <strong>de</strong>ltiempo <strong>de</strong> transmisión <strong>de</strong> los paquetesy <strong>de</strong>l tiempo que <strong>de</strong>be esperar cadapaquete para <strong>en</strong>contrar sus mini-slots,pero siempre <strong>de</strong>ntro <strong>de</strong>l mismointervalo <strong>de</strong> MAP.8
- A<strong>de</strong>más para el tipo UGS se ha podidocomprobar que <strong>en</strong> cada CM, el tiempo<strong>de</strong> espera es difer<strong>en</strong>te (<strong>en</strong> una situación<strong>en</strong> la que a todos los CMs llegan lospaquetes <strong>en</strong> los mismos instantes <strong>de</strong>tiempo), <strong>de</strong>bido a que <strong>de</strong>p<strong>en</strong><strong>de</strong> <strong>de</strong>lor<strong>de</strong>n <strong>en</strong> el que el CMTS emita lasasignaciones <strong>de</strong> los mini-slots <strong>en</strong> cadaMAP.- Cuando el <strong>en</strong>lace upstream se<strong>en</strong>cu<strong>en</strong>tra saturado, se produce unincrem<strong>en</strong>to <strong>de</strong>l retardo <strong>en</strong> lastransmisiones, incluso por parte <strong>de</strong>aquellas que ti<strong>en</strong><strong>en</strong> un tipo <strong>de</strong> servicioUGS. Sin embargo, no es unincrem<strong>en</strong>to sustancial y se manti<strong>en</strong>e<strong>de</strong>ntro <strong>de</strong> unos márg<strong>en</strong>es, porque estetipo <strong>de</strong> servicio <strong>de</strong>be garantizar unascaracterísticas <strong>de</strong> QoS.- Se ha podido observar que cuandoexist<strong>en</strong> varios CMs con un tipo <strong>de</strong>servicio Best-Effort, <strong>de</strong>b<strong>en</strong> competirpor realizar sus peticiones <strong>sobre</strong> losmismos mini-slots. Por ello <strong>en</strong> muchasocasiones ti<strong>en</strong><strong>en</strong> lugar colisiones,produciéndose <strong>de</strong> esta forma unincrem<strong>en</strong>to <strong>en</strong> el tiempo <strong>de</strong> espera <strong>en</strong>cola.- La transmisión <strong>sobre</strong> el <strong>en</strong>lacedownstream obti<strong>en</strong>e un m<strong>en</strong>or retardoque para el upstream <strong>de</strong>bido a que ti<strong>en</strong>euna mayor tasa <strong>de</strong> transmisión(27Mbps) y a<strong>de</strong>más no ti<strong>en</strong>e técnica <strong>de</strong>acceso TDMA, luego no hay tiempos<strong>de</strong> espera producidos por la forma <strong>de</strong> latrama TDMA.5. Conclusiones y líneas futuras.Este estudio <strong>de</strong> la arquitectura PacketCable hasido el punto <strong>de</strong> partida para g<strong>en</strong>eralizar su usoa una arquitectura heterogénea. De esta forma,se han as<strong>en</strong>tado las bases para crear unaarquitectura jerárquica que sea capaz <strong>de</strong>asegurar que las <strong>aplicaciones</strong> <strong>multimedia</strong> que<strong>sobre</strong> ella se <strong>de</strong>sarroll<strong>en</strong> reciban una calidad <strong>de</strong>servicio, y todo ello que se pueda realizar conin<strong>de</strong>p<strong>en</strong><strong>de</strong>ncia <strong>de</strong> qué red <strong>de</strong> acceso o redtroncal se t<strong>en</strong>ga a disposición.La arquitectura heterogénea <strong>en</strong> la que se estátrabajando actualm<strong>en</strong>te (<strong>de</strong>ntro <strong>de</strong>l proyectoQUAR2) compr<strong>en</strong><strong>de</strong> la integración <strong>de</strong> red <strong>de</strong>acceso <strong>de</strong> cable, xDSL e incluso <strong>de</strong> re<strong>de</strong>s <strong>de</strong>acceso EPON. Y para asegurar la calidad <strong>de</strong>servicio se está estableci<strong>en</strong>do una señalizaciónbasada <strong>en</strong> la <strong>de</strong> la figura 3, con alguna salvedad.La primera difer<strong>en</strong>cia es que se int<strong>en</strong>taráintroducir SIP como protocolo <strong>de</strong> señalización<strong>de</strong> aplicación puesto que es el más empleadohoy <strong>en</strong> día <strong>en</strong> <strong>aplicaciones</strong> <strong>multimedia</strong>.Por otra parte, hay que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta que unared <strong>de</strong> acceso <strong>de</strong> cable es muy difer<strong>en</strong>te <strong>de</strong> unalínea xDSL. En una red <strong>de</strong> cable hay que haceruna reserva <strong>de</strong> recursos incluso <strong>de</strong>ntro <strong>de</strong> ellamisma porque el <strong>en</strong>lace upstream es un mediocompartido, luego se hac<strong>en</strong> necesarias laautorización y reserva <strong>de</strong> recursos <strong>en</strong> el CMTS.Sin embargo, <strong>en</strong> la red xDSL cada usuario ti<strong>en</strong>eun ancho <strong>de</strong> banda para él, luego no ti<strong>en</strong>e quecompetir con otros usuarios por el medio y portanto se hace innecesaria una reservaequival<strong>en</strong>te a la <strong>de</strong> cable <strong>en</strong> el router fronteraxDSL.T<strong>en</strong>i<strong>en</strong>do muy <strong>en</strong> cu<strong>en</strong>ta sus difer<strong>en</strong>cias perotambién int<strong>en</strong>tando llegar a una arquitecturag<strong>en</strong>érica basada <strong>en</strong> la <strong>de</strong> PacketCable se estándirigi<strong>en</strong>do los esfuerzos <strong>de</strong>l proyecto QUAR2.Refer<strong>en</strong>cias.[1] http://projects.celticinitiative.org/QUAR2/<strong>de</strong>scription.htm[2] Z.Wang, “Internet QoS: Architectures andMechanisms for Quality of Service, MorganKaufmann Publishers, 2001.[3] Dynamic QoS PacketCable 1.0 spec. I02 00-08 DVB 01-04, ITU-T J.163, ETSI TS 101 909-5[4] Security PacketCable 1.0 spec. I01 99-12DVB 01-04, ITU-T draft J.170 ETSI TS 101909-11[5] DOCSIS 1.1 RFI spec.I05 00-07, ITU-TJ.112 Annex B (part) ETSI ES 201 488 v1.1.1[6] RFC 2748, The COPS (Common Op<strong>en</strong>Policy Service) Protocol[7] RFC 2205, Resource ReSerVation Protocol(RSVP). Version 1 Functional Specification.[8] NCS PacketCable 1.0 spec. I02, Diciembre19999