Pgina 1

Red Grupo de Trabajo G. Camarillo Peticin de Comentarios: 3524 A. Monrad Categora: Normas Track Ericsson 04 2003 Mapeo de flujos de medios de Flujos de reserva de recursos Condicin de este Memo Este documento especifica un protocolo de normas de Internet para la Comunidad de Internet, y solicita debate y sugerencias para mejoras. Por favor refirase a la edicin actual de la Internet " Normas Oficiales de Protocolo "(STD 1) para la normalizacin de estado y la situacin de este protocolo. La distribucin de este memo es ilimitada. Aviso de Copyright Copyright (C) The Internet Society (2003). Todos los Derechos Reservados. Abstracto Este documento define una extensin de la descripcin de sesin Protocol (SDP) Agrupacin marco. Se permite solicitar un grupo de flujos de medios para ser asignada a una reserva de un solo flujo de recursos. La sintaxis SDP necesario se define, as como una "semntica" nuevos atributo llamado Flow Reserva Individual (SRF). Tabla de contenidos 1. Introduccin ........................................ 2 Terminologa 1,1 .................................... 2 2. Semntica SRF ....................................... 2 3. Declaracin de Aplicabilidad ............................. 3 4. Ejemplos ............................................ 3 5. Consideraciones IANA ................................. 4 6. Consideraciones de seguridad ............................. 4 7. Agradecimientos .................................... 4 8. Referencias Normativas ................................ 5 9. Referencias informativas .............................. 5 10. De los autores Direcciones .................................. 5 11. Declaracin de derechos de autor ............................ 6 Camarillo y Monrad Normas Track [Page 1]
Page 2

RFC 3524 Asignacin de medios de comunicacin arroyos para reserva de recursos Flujos de abril 2003 1. Introduccin Protocolos de reserva de recursos asignar recursos de red para concreto flujos de paquetes IP. Cuando un router recibe un paquete IP, se aplica

un filtro con el fin de asignar el paquete a la que pertenece el flujo. La router proporciona el paquete IP con la Calidad de Servicio (QoS) correspondiente a su flujo. Routers utilizan tpicamente la fuente y el direcciones de destino IP y nmeros de puerto para filtrar paquetes. Sesiones multimedia suelen contener flujos de medios mltiples (por ejemplo, un flujo de audio y un flujo de vdeo). Con el fin de proporcionar una QoS para sesin multimedia es necesario asignar todos los flujos de medios a los flujos de recursos reserva. Esta asignacin se puede realizar en diferentes maneras. Dos formas posibles para mapear todos los flujos de medios a un flujo de recursos nica reserva o para mapear todos los medios individuales corriente para un flujo de reserva de recursos diferentes. Algunas aplicaciones requieren que el primer tipo de mapeo se realiza mientras otro aplicaciones requieren que estos ltimos. Es incluso posible que una mezcla de ambas asignaciones se requiere para una sesin de medios de comunicacin en particular. Para ejemplo, una sesin multimedia con tres flujos de medios puede requerir que dos de ellas se reducen a una sola reserva de flujo, mientras que el flujo de medios tercero utiliza un flujo segunda reserva. Este documento define el SDP [1] sintaxis necesaria para expresar cmo los medios de comunicacin corrientes deben asignarse a los flujos de reserva. Para este propsito, usamos el marco agrupacin SDP [2], y defina una nueva "semntica" atributo llamado Flow Reserva Individual (SRF). 1,1 Terminologa En este documento, las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBER", "NO", "DEBE", "NO DEBE", "recomendada", "MAYO", y "OPCIONAL" se han de interpretar como se describe en el BCP 14, RFC 2119 [3] y Indicar los niveles de exigencia para indicar compatible SIP implementaciones. 2. SRF semntica Definimos una nueva "semntica" atributo dentro de la agrupacin SDP marco [2]: Flujo de Reserva Individual (SRF). Lneas de medios agrupados utilizando la semntica SRF DEBE ser asignada a la mismo recurso flujo reserva. Medios lneas que no pertenecen a un determinado grupo SRF no deben asignarse al flujo de reserva utilizado para ese grupo de SRF. Normas Camarillo y Monrad Track [Page 2]
Pgina 3

RFC 3524 Asignacin de medios de comunicacin arroyos para reserva de recursos Flujos de abril 2003

Tenga en cuenta que un grupo de SRF puede consistir en una sola lnea de medios. En que caso, despus de la definicin anterior, que la lnea de medios se asignarn en el flujo de una reserva. Ese flujo reserva transportar trfico desde la lnea de medios, y no de otras lneas de comunicacin. 3. Declaracin de Aplicabilidad La forma en que funciona la reserva de recursos en algunos casos se hace innecesario utilizar el mecanismo descrito en este documento. Algunos protocolos de reserva de recursos permitir a la entidad la generacin de la SDP descripcin de sesin para asignar los recursos en ambas direcciones (es decir, sendrecv) para la sesin. En este caso, el generador de la descripcin de la sesin puede elegir cualquier asignacin especial de los medios de comunicacin fluye reserva y caudales. El mecanismo descrito en este documento es til cuando el control remoto Parte necesita estar involucrado en la reserva de recursos. 4. Ejemplos Para este ejemplo, hemos optado por utilizar SIP [4] para el transporte de SDP sesiones y RSVP [5] para establecer los flujos de reserva. Sin embargo, otro protocolos o mecanismos podran utilizarse en su lugar sin afectar a la SDP sintaxis. Un agente de usuario recibe un INVITE SIP con el SDP a continuacin: v=0 o = 289083124 289083124 Laura EN IP4 one.example.com t=00 C = EN IP4 192.0.0.1 un grupo =: SRF 1 2 m = audio 30000 RTP / AVP 0 un mid =: 1 m = video 30002 RTP / AVP 31 un mid =: 2 Este agente de usuario utiliza RSVP para realizar la reserva de recursos. Desde ambas corrientes de los medios son parte de un grupo de SRF, el agente de usuario establecer una sesin RSVP nico. Una sesin RSVP se define por la triple: (DestAddress, ProtocolId [, DstPort]). La Tabla 1 muestra el parmetros utilizados para establecer la sesin RSVP. Si el agente mismo usuario recibe una descripcin de la sesin SDP con el flujos de medios mismos, pero sin el grupo de lnea, sera libre para mapa de las dos corrientes de los medios de comunicacin en dos sesiones RSVP diferentes.

Camarillo y Monrad Normas Track [Page 3]

Page 4

RFC 3524 Asignacin de medios de comunicacin arroyos para reserva de recursos Flujos de abril 2003 Nmero de Sesin DestAddress ProtocolId DstPort ________________________________________________ 1 192.0.0.1 UDP cualquier Tabla 1: Parmetros necesarios para establecer el perodo de sesiones RSVP 5. Consideraciones IANA IANA ha registrado la siguiente nueva "semntica" de atributos para el SDP marco agrupacin [2]. Se ha registrado en el SDP parmetros de registro (http://www.iana.org/assignments/sdp-parameters) bajo Semntica para el "grupo" atributo SDP: Semntica Token Referencia --------------------------------Flujo Reserva Individual SRF [RFC3524] 6. Consideraciones de seguridad Un atacante aadiendo lneas de grupo utilizando la semntica SRF a un SDP descripcin de la sesin podra obligar a un agente de usuario para establecer una mayor o un menor nmero de reserva de recursos fluye de lo necesario. Esta podra consumir recursos adicionales en el punto final o degradar la calidad de servicio para una sesin en particular. As, se RECOMIENDA proteccin de la integridad que se aplica a las descripciones de la sesin SDP. Para descripciones de las sesiones realizadas en SIP, S / MIME es la eleccin natural proporcionar tal extremo a extremo proteccin de integridad, como se describe en RFC 3261 [4]. Otras aplicaciones pueden utilizar una forma diferente de integridad proteccin. 7. Agradecimientos Jonathan Rosenberg proporcionaron comentarios tiles acerca de la aplicabilidad del mecanismo descrito en este documento. Camarillo y Monrad Normas Track [Page 4]
Page 5

RFC 3524 Asignacin de medios de comunicacin arroyos para reserva de recursos Flujos de abril 2003 8. Referencias Normativas [1] Handley, M. y V. Jacobson, "SDP: Descripcin de la sesin

Protocolo ", RFC 2327, de abril de 1998. [2] Camarillo, G., Eriksson, G., Holler, J. y H. Schulzrinne, "Agrupacin de Lneas de medios en el Protocolo de Descripcin de Sesin (SDP) ", diciembre de 2002. [3] Bradner, S., "Palabras clave para su uso en RFC para indicar requisito niveles ", BCP 14, RFC 2119, marzo de 1997. 9. Referencias informativas [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. y E. Primaria, "SIP: Session Initiation Protocol ", RFC 3261, junio de 2002. [5] Braden, R., Zhang, L., Berson, S. Herzog, S. y S. Jamin, "Protocolo de reserva de recursos (RSVP) - Versin 1 funcional Specification ", RFC 2205, septiembre de 1997. 10. De los autores Direcciones Gonzalo Camarillo Ericsson Laboratorio de Investigacin Avanzada de sealizacin. FIN-02420 Jorvas Finlandia EMail: Gonzalo.Camarillo @ ericsson.com Atle Monrad Ericsson N-4898 Grimstad Noruega EMail: atle.monrad @ ericsson.com Camarillo y Monrad Normas Track [Page 5]
Pgina 6

RFC 3524 Asignacin de medios de comunicacin arroyos para reserva de recursos Flujos de abril 2003 11. Declaracin de derechos de autor Copyright (C) The Internet Society (2003). Todos los Derechos Reservados. Este documento y sus traducciones puede ser copiado y facilitado a otros, y las obras derivadas que comentar o de otra manera explicarlo O asistencia para su ejecucin podrn ser preparados, copiados, publicados y distribuy, en todo o en parte, sin restriccin de ningn especie, siempre que el aviso de copyright anterior y este prrafo son incluido en todas esas copias y trabajos derivados. Sin embargo, este documento por s mismo no puede ser modificada en cualquier forma, como por ejemplo eliminando la nota de copyright o referencias a la Sociedad Internet o de otro tipo

Organizaciones de Internet, excepto cuando sea necesario para el propsito de desarrollo de estndares de Internet, en cuyo caso los procedimientos para copyrights definidos en el proceso de normalizacin de Internet debe ser seguido, o como sea necesario traducirla a otros idiomas distintos Ingls. Los limitados permisos concedidos anteriormente son perpetuos y no sern revocados por la Internet Society ni sus sucesores o cesionarios. Este documento y la informacin contenida en este documento se proporciona en un "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING GRUPO DE TRABAJO NIEGA TODAS LAS GARANTAS, EXPRESAS O IMPLCITAS, INCLUYENDO PERO NO LIMITADO A CUALQUIER GARANTA DE QUE EL USO DE LA INFORMACIN Contenida en ella no vulnere cualquier derecho o cualquier Las garantas implcitas de COMERCIALIZACIN O IDONEIDAD PARA UN PROPSITO PARTICULAR. Acuse de recibo La financiacin de la funcin del Editor RFC es actualmente el Internet Society.