III GESTIÓN DE CONTABILIDAD

La gestión de contabilidad se refiere a la colección de los datos sobre el consumo de un recurso para los propósitos del análisis de la capacidad y de tendencia, de la asignación de costos, de la revisión, y de facturación. Puesto que los usos de la contabilidad no tienen requisitos uniformes de la seguridad y de la confiabilidad, no es posible idear un solo protocolo de la contabilidad y fijado de los servicios de seguridad que resolverán todas las necesidades. Así la meta de la gestión de contabilidad es proporcionar un sistema de las herramientas que se pueden utilizar para resolver los requisitos de cada uso.

3.2 Arquitectura

La arquitectura de la gestión de contabilidad implica interacciones entre los dispositivos de la red, los servidores de la contabilidad, y los servidores de la facturación. El dispositivo de la red recoge datos del consumo del recurso. Esta información entonces se transfiere a un servidor de la contabilidad. Esto se logra típicamente vía un protocolo de la contabilidad, aunque es también posible que los dispositivos generen sus propios registros de sesión. El servidor de la contabilidad entonces procesa los datos contables recibidos del dispositivo de la red. Esto que procesa puede incluir la suma de la información de contabilidad del proceso en gestión, de la eliminación de datos duplicados, o de la generación de los registros de la sesión.

Una de las funciones del servidor de contabilidad es distinguir entre los acontecimientos inter e intradominio de la contabilidad y encaminarlos apropiadamente. Para los registros de la sesión que contienen un Identificador del Acceso de Red (NAI, Network Access Identifier), la distinción puede ser hecha examinando la porción del dominio del NAI. Si la porción del dominio está ausente o corresponde al dominio local, después el registro de la sesión le trata como acontecimiento de la contabilidad del intradominio. Si no, se trata como acontecimiento de la contabilidad del interdominio. Los acontecimientos de la contabilidad del intradominio se encaminan típicamente al servidor local de la facturación, mientras que los acontecimientos de la contabilidad del interdominio serán encaminados a los servidores de la contabilidad que funcionan dentro de otros dominios administrativos. Mientras que no se requiera que los formatos de registro de la sesión usados en contabilidad inter y del intradominio sean iguales, esto es deseable, puesto que elimina las traducciones que serían requeridas de otra manera.

3.3 ¿Por qué las Características de la Contabilidad son Importantes?

La inversión en el equipo necesario para obtener el ancho de banda tiene un valor real y necesita ser recuperado. La meta de los proveedores de servicio (los encargados de proveer los recursos necesarios para el funcionamiento de la red), es desplegar y mantener la cantidad de equipo necesaria para resolver los objetivos que deban cumplirse con el uso de la red. Los pequeños errores en este proceso pueden conducir a las grandes pérdidas económicas.

La información exacta del uso de la red es vital para que los administradores de la red. Los proveedores de servicio que tienen la visión competa del uso de la red estarán siempre en ventaja cuando se tiene que asignar ancho de banda existente y al planear las expansiones a futuro. Un plan de contabilidad eficiente que les provea de esta información de la red es una de las metas. La facturación basada en el uso se puede entender como quizás la mejor manera de alcanzar la meta a beneficio del cliente y de los costos del proveedor de servicio. Sin embargo, cuando se considera la expansión de la red, el proveedor de servicio se podría preguntar cosas como: ¿Cuáles aplicaciones consumen el mayor ancho de banda? ¿Cuándo hay épocas de picos de tráfico? ¿Necesito agregar mayor capacidad a la red o puedo implementar políticas de red para mejorar su desempeño? La gestión de contabilidad tiene la habilidad de colectar esta información y contabilizarla para darle al proveedor de servicio mayor entendimiento de cómo esta siendo usada la red.

3.4 Protocolos de Contabilidad de Flujo

3.4.1 NETFLOW

La Tecnología de Netflow de CISCO proporciona eficientemente la base de medición para aplicaciones tales como:

	Estadísticas de tráfico de red.
	Facturación del uso de la red.
	Planeación de la red.
	Monitoreo de red.

Netflow captura la clasificación o la preferencia del tráfico asociado a cada flujo, permitiendo realizar diferentes cargos basándose en QoS.

Existen dos herramientas en Cisco para el análisis de flujo.

	Neflow Collector.
	Netflow Analyzer.

Netflow Collector - Cisco: Los siguientes puntos son parte de las estadísticas:

	Dirección fuente y destino
	Dirección del siguiente salto
	Número de las interfaces de entrada y salida.
	Número de paquetes
	Número de bytes.
	Puerto fuente y destino
	Protocolo
	Tipo de servicio (ToS)
	AS fuente y destino

Netflow Analyzer - Cisco: Herramienta utilizada para desplegar y analizar la información colectada por el Netflow Collector. La información puede ser presentada en:

	Tablas
	Gráficas
	Listas numeradas
	Listas no numeradas

3.4.2 LFAP (Light-weight Flow Accounting Protocol)

LFAP (Protocolo de Contabilidad de Flujo Liviano) es un protocolo de contabilidad que fue desarrollado por Riverstone para resolver las necesidades de la contabilidad del flujo de los proveedores de servicio. El protocolo es particularmente valioso para recopilar la información de flujos de las capas 3 (Red) y 4 (Transporte). Los datos contables para las redes de la capa 2 (Enlace de datos) se pueden también recoger usando LFAP mientras el dispositivo está funcionando en modo que tiende un puente sobre de la capa 4 (Transporte).

En la práctica LFAP es excepcional. A través de la plataforma de Riverstone, el flujo y los datos del tráfico es considerado por el hardware, más que por el software, de modo que la contabilidad no afecta el funcionamiento del sistema. Periódicamente, el enrutador recopilará los datos del flujo y enviará la información a un servidor de la contabilidad usando el protocolo de LFAP. El intervalo del tiempo en el cual los datos del flujo se envían al servidor de la contabilidad es configurable a no menos de cada cinco minutos.

El protocolo trabaja conjuntamente con los enrutadores basados en hardware de Riverstone para capturar datos del tráfico confiablemente de modo que los encargados de red puedan recoger los datos contables del flujo y transmitir los datos sobre un protocolo confiable.

Una ventaja dominante de las capacidades de la contabilidad del tráfico del hardware de Riverstone es que la característica de la contabilidad no afecta funcionamiento del sistema.

3.4.3 Ventajas sobre de LFAP sobre NETFLOW

NetFlow es un protocolo básico de contabilidad desarrollado por Cisco Systems para ayudar a administradores de la red a obtener una mejor comprensión del tipo de tráfico en sus redes. En ausencia de una solución mejor a esta, muchos vendedores del equipo han implementado NetFlow para recoger y para transmitir los datos contables del flujo del switch o enruteador. Desafortunadamente, NetFlow nunca fue diseñado para las demandas de redes modernas, y no se aprovecha de las capacidades de los enrutadores basados en hardware de hoy en día.

Hay varias ventajas de LFAP sobre NetFlow. En general, LFAP es el protocolo confiable que no afecta funcionamiento del sistema, mientras que NetFlow no es fiable y en la operación afecta el funcionamiento del enrutador, de tal modo distorsiona el funcionamiento de la red que se supone debe medir. Las ventajas más sobresalientes son las siguientes:

Basado en TCP VS Basado en UDP: LFAP es intrínsecamente más confiable que otros protocolos de contabilidad puesto que es TCP basado en la capa de transporte. El dato contable del flujo se envía de el enrutador al servidor de contabilidad y la entrega de los datos se confirma usando capacidades de TCP. Un protocolo de la contabilidad que utiliza UDP no garantiza la entrega. Sin un mecanismo confiable del transporte, las aplicaciones del paquete y su confiabilidad se puede decir que son los recorridos de los datos contables de tráfico del elemento de la red al colector de datos.

Flujo de datos en tiempo real: LFAP es diseñado para entregar flujo de datos en tiempo real, incluso en medio de un flujo. El protocolo LFAP especifica que el enrutador establece un archivo flujo de trafico una vez que comienza. A medida que el flujo continua, el enrutador recopilará los datos incrementados en el flujo de trafico y transmitirá esos datos al servidor de contabilidad.

Otros protocolos, por otro lado, esperan hasta que el flujo ha expirado y entonces envía todos los datos del flujo de tráfico al servidor de contabilidad.

Sobre fallas en servidores de contabilidad: La implementación actual de Riverstone permite la configuración de arriba de dos servidores de fallas. Cuando el enrutador es configurado para enviar datos LFAP a un servidor de contabilidad, un servidor primario es establecido. Dos servidores de respaldo adicionales pueden incluso ser especificados. En el momento en el que el primer servidor falle, el enrutador automáticamente reconocerá la falla y mandara los datos del tráfico al servidor de respaldo.

3.5 Aplicaciones de Datos de LFAP

Hay dos aplicaciones principales para los datos contables del flujo. La primera está para el análisis del uso de la red: el estudio y el entendimiento de cómo los usuarios están utilizando la red. La segunda está para la facturación basada en uso.

3.5.1 Análisis del Uso de la Red

La clave para maximizar el beneficio del proveedor de servicio es entender exactamente cómo se esta utilizando la red realmente. Hoy, los abastecedores de servicio se hacen frente con frecuencia con el aumento de demandas de ancho de banda de clientes individuales sin un aumento correspondiente en rédito.

La situación pone a consideración la expansión que solo el análisis de la red puede facilitar, y tal vez una mayor tendencia a la facturación basada en uso.

3.5.2 La facturación Basada en Uso

Conduce un modelo claro y lucrativo del rédito. En vez de cargar a todos los clientes una tarifa estable, este sistema permite los proveedores de servicio que carguen a sus clientes que use más los recursos, que ganen el rédito adicional.

3.6 Componentes

Figura 3.1 Contabilidad de Flujo.

Connection Control Entity (CCE): El rol del CCE (Entidad de Control de Conexión) es el de admitir y seguir flujos e interactuar con el FAS par grabar estadísticas de estos flujos. El CCE debe ser capaz de ser configurado para la contabilidad de flujos, tales como la prevención de cobrar dos veces.

Flow Accounting Server (FAS): El FAS (Servidor de Contabilidad de Flujos) usa el protocolo LFAP para obtener información de flujos provenientes del CCE. Los datos capturados.

Flow Messages: Mensajes de flujo, son información que sirven para comunicar el CCE con el FAS. En ellos se envían los campos con los comandos requeridos para la negociación del protocolo y transmisión de flujos.

3.7 Mensajes de Flujo (Flow Messages)

La inicialización de flujos entre el CCE (Call Control Entity) y el FAS (Flow Accounting Servirse) siempre se origina en el switch. Es entonces, el switch es el punto donde la conectividad se origina. El CCE debe tener alcance IP y una dirección IP para el FAS que debe estar previamente configurada en el switch CCE. El CCE establece la conectividad TCP usando el número de puerto registrado 3145. Cuando un puerto TCP es abierto por el CCE éste manda un VR como petición para la conexión usando la versión especifica del protocolo. El FAS responde con un VRA y el estado de éxito, si es que la versión es soportada. Una vez que la versión del protocolo es establecida, el FAS envía un AR con permiso para que la conversación continúe (p.e. el FAS hace una revisión de seguridad).

Como se muestra en la figura 3.2, los mensajes FAR (Flow Accounting Request) están siendo enviados al CCE (Call Control Entity) del switch al FAS (Flow Accounting Service). Estos mensajes son enviados cuando el switch da de alta un flujo. El mensaje contiene información específica relacionada con el flujo, como el identificador de flujo, origen/destino y calidad de la información sobre el flujo.

Figura 3.2 Mensajes entre el CCE y el FAS.

Periódicamente durante el transcurso del flujo y cuando ocurre un cambio en el estado del flujo, el switch CCE envía un mensaje de actualización de flujo (FUN, Flow Update Notification) al FAS. El mensaje FUN contiene la contabilidad (p.e. bytes recibidos y enviados) y otra información del flujo

3.7.1 Formato de Mensajes

LFAP define seis mensajes: “Flow Accounting Request”, Flow Update Notification”, “Administrative Request”, “Administrative Request Acknowledge”, “Versión Request”, “Versión Request Acknowledge” (FAR, FUN, AR, ARA, VR, VRA respectivamente).

Los mensajes FAR son enviados por el CCE hacia el FAR. Los mensajes FUN se originan en switch y los mensajes AR son enviados por una de las entidades (FAS o CCE) y son reconocidos por mensajes ARA. El formato general de mensajes para todos los mensajes de LFAP para la versión 4 es el siguiente.

Figura 3.3 Formato de mensajes de LFAP

STATUS: El campo del estado sirve como estado en el mensaje total. Los valores que el estado puede asumir son:

SUCESS = 1

VERSION = 2 Usado por el FAS para indicar que no soporta la versión de LFAP usado por el CCE.

Reserved: Esta reservado para futuras expansiones y debe estar en Cero para esta versión.

Message ID: Es usado para asociarlos con cada mensaje original con el que este corresponde y debe ser único para la combinación del remitente y el respondedor mientras el mensaje original esta pendiente.

Message Lenght: excluye a 8 octetos del encabezado del mensaje.

Information Elements (IE): Contiene en si la información del mensaje, y puede contener distintos tipos de mensajes internos dentro de este campo, como lo muestra la tabla 2.

Los campos IE consisten en 2 octetos para el tipo (TYPE), 2 octetos para el tamaño (LENGTH) y un valor (VALUE) variable para los sub-campos. Todos los IE’s son múltiplos de 4 octetos en tamaño, alineados a la izquierda y rellenados con ceros si es necesario. (Figura 3.4)

Figura 3.4 Formato de básico de IE’s

Número de tipo (TYPE)	Nombre del IE
1	Flow ID
2	Source Ardes
3	Destination Ardes
4	Flow Qualifier
5	Time
6	Type of Service
7	Source CCE Adress
8	Client Data
9	Command Code
11	Failure Code
12	Flow Identifier Prefix
13	Flow State
14	Byte Count
15	Byte Count
16	Packet Count
17	Packet Count
18	Protocol Identifier
19	Source Port
20	Source Port
21	Source Port
22	Multiple Record
23	Source and Destination AS
24	Ingress port
25	Egress port

Tabla 3.1 Lista de tipos y nombre de mensajes de IE.

3.7.2 Tipos de Mensajes

Los mensajes soportados por el protocolo LFAP son enviados 6 mensajes son manejados según la figura 3.2. La descripción de cada uno de ellos se explica en la tabla 3.

Código	Número	Nombre	Descripción/Uso
VR	1	Version Request	Usado para enviar una petición de conexión enviando la versión soportada (enviado por el CCE).
VRA	2	Version Request Acknowledge	Usado para responder a la petición de conexión, avisando si la versión utilizada esta soportada (por el FAS).
FAR	3	Flow Accounting Request	Indica que un nuevo flujo se ha creado y la información de éste.
FUN	4	Flow Update Notification	Contiene la información la contabilidad del flujo anteriormente creado en el FAR. Actualización del flujo.
AR	5	Administrative Request	Utilizado para ejecutar peticiones o comandos.
ARA	6	Administrative Request Acknowledge	Utilizado para responder que un mensaje AR ha sido recibido.

Tabla 3.2 Opcodes (código de mensaje) y respectivo valor numérico.

3.7.3 Descripción de IE’s de los Mensajes de LFAP

Mensaje FAR
Flow ID	Identificador único (único para la entidad de reporte de actualización).
Source Address	Dirección IP origen del flujo.
Destination Address	Dirección IP destino del flujo.
Time	Tiempo del switch de la petición de contabilidad (reloj interno del switch).
Source CCE Address	Dirección del CCE que registra los flujos.
Protocol Identifier	Identificador del protocolo usado.
Source Port	Puerto origen del flujo.
Type of Service	ToS IP, Tipo de servicio del IP.
Flow Qualifier	Prioridad de la conexión y el intervalo de chequeo.
Sourse and Destination AS	Un números de AS de el IP origen y destino.
Ingress Port	Índice del puerto de entrada (Switch).
Egress Port	Índice del puerto de salida (Switch).
Client Data	Datos del cliente aplicados a esta petición.

Tabla 3.3 Elementos de Información de los Mensajes FAR

Para un mensaje FAR los IE’s obligatorios son: Flow ID, Source Ardes, Destination Address y Time. El resto, son opcionales.

Mensaje FUN
Time	Tiempo de la notificación en el switch
Flow ID	Identificador para el flujo.
Flow State	Estado del flujo a la hora de la notificación.
Byte Count	Octetos enviados o recibidos por este flujo.
Packet Count	Paquetes enviados o recibidos por este flujo.

Tabla 3.4 Elementos de Información de los Mensajes FUN

Para un mensaje FUN, los IE’s obligatorios son: Flow ID, Time. Los opcionales son Flow State, Byte Count y Packet Count.

Mensaje AR
Command	Comando.
Flow ID	Identificador de flujo.
FAS IP Address	Dirección IP del FAS.

Tabla 3.5 Elementos de Información de los Mensajes AR

Obligatorio: Command.

Opcional: Flow ID, FAS IP Address.

Mensaje ARA
Flow ID	Si FAS pidió estadística sobre un flujo desconocido.
Failure Code	Para el identificador de flujo mencionado.
Flow Identifier Prefix	Si el ARA es la respuesta a un comando del CCE a RETURN_FLOW_PREFIX.

Tabla 3.6 Elementos de Información de los Mensajes ARA

Los mensajes ARA son enviados por el FAS o el CCE como respuesta para un mensaje AR recibido por un CCE o FAS respectivamente.

Mensaje VR

Tabla 3.7 Elementos de Información de los Mensajes VR

Los mensajes VR no contienen IE’s. Son usados por el CCE para hacer la petición de sesión con el FAS bajo una específica versión del protocolo LFAP.

Mensaje VRA

Tabla 3.8 Elementos de Información de los Mensajes VRA

Los mensajes VRA no contienen IE’s. El ID del mensaje es copiado del mensaje VR. Si el FAS soporta la versión, incluso copia la versión del mensaje VR al mensaje VRA. A este punto, la negociación del protocolo esta completa y la conversación toma inicio. Si el FAS no soporta la versión enviada en el mensaje VR, este pone su versión más alta en la cabecera del mensaje y pone en el campo STATUS la VERSION, indicando un error en la versión.

3.8 Establecimiento de la Sesión

El establecimiento de la sesión ocurre en dos fases. En la primera fase la versión del protocolo es establecida. En la segunda fase, el FAS permite o rechaza la conexión. El FAS puede negar la conexión por varias razones. Por ejemplo, el CCE puede no estar autorizado para conectarse a este FAS.

3.8.1 Negociación del Protocolo

En esta fase el FAS y el CCE negocian la versión del el protocolo LFAP a ser usado. El CCE inicializa el proceso enviando un mensaje VR con el valor más alto de la versión que soporta en el encabezado del mensaje. Si el FAS soporta la versión, este le responderá un VRA con la misma versión y el estado de éxito. Por ejemplo, un CCE puede hacer la petición con una versión 3 y el FAS soporta las versiones 3, 4 y 5. En este caso el FAS responderá con un mensaje VRA con la versión 3 en el encabezado y el estado de éxito. Si el FAS no soporta la versión este enviara un mensaje VRA con la versión más alta que este soporta y el estado con el valor de la versión. En este punto el CCE puede entonces desconectarse e intentar otro FAS. O, si el CCE soporta la versión indicada por el FAS, el CCE puede enviar un mensaje VR con la versión indicada, si el CCE soporta la versión 5 y 6, este enviara un mensaje VR al FAS con la versión 6. Si el FAS soporta las versiones 3, 4 y 5, este responderá con un mensaje VRA con la versión 5 y el estado con la versión que no soporto, (indicando que este no soporta la versión 6). El CCE puede entonces enviar otro mensaje VR, esta vez con la versión 5.

3.8.2 Establecimiento de la Conexión

La secuencia normal de eventos cuando un CCE y un FAS tratan de establecer una conversación es la siguiente:

El CCE abre un socket TCP.

	El CCE envía un mensaje VR con la versión designada del protocolo..
	El FAS envía la respuesta VRA con la versión designada.
	Asumiendo que los dos están de acuerdo, el CCE entonces envía un AR con la lista de FASS y el FAS debe responder con un ARA.
	Entonces el FAS envía un AR con la opción de “Conexión Aceptada”.
	El CCE envía una respuesta ARA.

Desde este punto el orden no es garantizado.

	El CCE envía mensajes AR con el mensaje de “Regreso de Prefijo de Flujo” si es necesario.
	El CCE envía FAR’s/FUN’s (etc.).

3.9 Slate-1.1 Una aplicación para LFAP

Es una aplicación creada por Cabletron (Creador de enrutadores con soporte del protocolo LFAP) que proporciona un interfaz para el switch u otro dispositivo de entidad de control de conexión (CCE) para conectarse con un servidor de contabilidad del flujo (FAS). El código de este programa LFAP esta escrito en lenguaje de C permitiendo al código ser utilizado en un sin numero de plataformas. Este programa se encarga de la administración del protocolo LFAP para la codificación y descodificación de los mensajes manejados por este protocolo.

Regresar al Indice