Разработка новой информационной системы с использованием технологии клиент-сервер и биллинговой системы

Выбор клиент-серверной архитектуры.

Как правило компьютеры и программы, входящие в состав информационной системы, не являются равноправными. Некоторые из них владеют ресурсами (файловая система, процессор, принтер, база данных и т. д.), другие имеют возможность обращаться к этим ресурсам. Компьютер (или программу), управляющий ресурсом, называют сервером этого ресурса (файл-сервер, сервер базы данных, вычислительный сервер…). Клиент и сервер какого-либо ресурса могут находится как на одном компьютере, так и на различных компьютерах, связанных сетью.

В рамках многоуровневого представления вычислительных систем можно выделить три группы функций, ориентированных на решение различных подзадач:

• 1. функции ввода и отображения данных (обеспечивают взаимодействие с пользователем);
• 2. прикладные функции, характерные для данной предметной области;
• 3. функции управления ресурсами (файловой системой, базой даных и т. д.)

Выполнение этих функций в основном обеспечивается программными средствами, которые можно представить в виде взаимосвязанных компонентов, которые показаны на рисунке.

• · компонент представления — отвечает за пользовательский интерфейс;
• · прикладной компонент — реализует алгоритм решения конкретной задачи;
• · компонент управления — ресурсом обеспечивает доступ к необходимым ресурсам.

Автономная система (компьютер, не подключенный к сети) представляет все эти компоненты как на различных уровнях (ОС, служебное ПО и утилиты, прикладное ПО), так и на уровне приложений (не характерно для современных программ). Так же и сеть — она представляет все эти компоненты, но, в общем случае, распределенные между узлами. Задача сводится к обеспечению сетевого взаимодействия между этими компонентами.

Архитектура «клиент-сервер» определяет общие принципы организации взаимодействия в сети, где имеются серверы, узлы-поставщики некоторых специфичных функций (сервисов) и клиенты, потребители этих функций.

Практические реализации такой архитектуры называются клиент-серверными технологиями. Каждая технология определяет собственные или использует имеющиеся правила взаимодейстия между клиентом и сервером, которые называются протоколом обмена (протоколом взаимодействия).

Рассмотрим подробнее двухзвенную архитектуру. В любой сети, построенной на современных сетевых технологиях, присутствуют элементы клиент-серверного взаимодействия, чаще всего на основе двухзвенной архитектуры. Двухзвенной (two-tier, 2-tier) она называется из-за необходимости распределения трех базовых компонентов между двумя узлами (клиентом и сервером).

Рисунок Двухзвенная клиент-серверная архитектура.

Двухзвенная архитектура используется в клиент-серверных системах, где сервер отвечает на клиентские запросы напрямую и в полном объеме, при этом используя только собственные ресурсы. Т. е. сервер не вызывает сторонние сетевые приложения и не обращается к сторонним ресурсам для выполнения какой-либо части запроса.

Расположение компонентов на стороне клиента или сервера определяет следующие основные модели их взаимодействия в рамках двухзвенной архитектуры:

• · сервер терминалов — распределенное представление данных;
• · файл-сервер — доступ к удаленной базе данных и файловым ресурсам;
• · сервер БД — удаленное представление данных;
• · сервер приложений — удаленное приложение.

Исторически первой появилась модель распределенного представления данных (модель сервер терминалов). Она реализовывалась на универсальной ЭВМ (мэйнфрейме), выступавшей в роли сервера, с подключенными к ней алфавитно-цифровыми терминалами. Пользователи выполняли ввод данных с клавиатуры терминала, которые затем передавались на мэйнфрейм и там выполнялась их обработка, включая формирование «картинки» с результатами. Эта «картинка» и возвращалась пользователю на экран терминала.

С появлением персональных компьютеров и локальных сетей, была реализована модель файлового сервера, представлявшего доступ файловым ресурсам, в том числе и к удаленной базе данных. В этом случае выделенный узел сети является файловым сервером, на котором размещены файлы базы данных. На клиентах выполняются приложения, в которых совмещены компонент представления и прикладной компонент (СУБД и прикладная программа), использующие подключенную удаленную базу как локальный файл. Протоколы обмена при этом представляют набор низкоуровневых вызовов операций файловой системы.

Такая модель показала свою неэффективность ввиду того, что при активной работе с таблицами БД возникает большая нагрузка на сеть. Частичным решением является поддержка тиражирования (репликации) таблиц и запросов. В этом случае, например при изменении данных, обновляется не вся таблица, а только модифицированная ее часть.

С появлением специализированных СУБД появилась возможность реализации другой модели доступа к удаленной базе данных — модели сервера баз данных. В этом случае ядро СУБД функционирует на сервере, прикладная программа на клиенте, а протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса «клиент-сервер». Однако, сетевой трафик остается достаточно высоким, кроме того, по прежнему невозможно удовлетворительное администрирование приложений, поскольку в одной программе совмещаются различные функции.

С разработкой и внедрением на уровне серверов баз данных механизма хранимых процедур появилась концепция активного сервера БД. В этом случае часть функций прикладного компонента реализованы в виде хранимых процедур, выполняемых на стороне сервера. Остальная прикладная логика выполняется на клиентской стороне. Протокол взаимодействия — соответствующий диалект языка SQL.

Преимущества такого подхода очевидны:

• · возможно централизованное администрирование прикладных функций;
• · снижение стоимости владения системой (TOC, total cost of ownership) за счет аренды сервера, а не его покупки;
• · значительное снижение сетевого трафика (т.к. передаются не SQL-запросы, а вызовы хранимых процедур).

Основной недостаток — ограниченность средств разработки хранимых процедур по сравнению с языками высокого уровня.

Реализация прикладного компонента на стороне сервера представляет следующую модель — сервер приложений. Перенос функций прикладного компонента на сервер снижает требования к конфигурации клиентов и упрощает администрирование, но представляет повышенные требования к производительности, безопасности и надежности сервера.

В настоящее время намечается тенденция возврата к тому, с чего начиналась клиент-серверная архитектура — к централизации вычислений на основе модели терминал-сервера. В современной реинкарнации терминалы отличаются от своих алфавитно-цифровых предков тем, что имея минимум программных и аппаратных средств, представляют мультимедийные возможности (в т.ч. графический пользовательский интерфейс). Работу терминалов обеспечивает высокопроизводительный сервер, куда вынесено все, вплоть до виртуальных драйверов устройств, включая драйверы видеоподсистемы.

Еще одна тенденция в клиент-серверных технологиях связана с все большим использованием распределенных вычислений. Они реализуются на основе модели сервера приложений, где сетевое приложение разделено на две и более частей, каждая из которых может выполняться на отдельном компьютере. Выделенные части приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее согласованном формате. В этом случае двухзвенная клиент-серверная архитектура становится трехзвенной (three-tier, 3-tier). Как правило, третьим звеном в трехзвенной архитектуре становится сервер приложений, т. е. компоненты распределяются как показано на рисунке.

• 1. Представление данных — на стороне клиента.
• 2. Прикладной компонент — на выделенном сервере приложений (как вариант, выполняющем функции промежуточного ПО).
• 3. Управление ресурсами — на сервере БД, который и представляет запрашиваемые данные.

Рисунок Многозвенная (N-tier) клиент-серверная архитектура

Трехзвенная архитектура может быть расширена до многозвенной (N-tier, Multi-tier) путем выделения дополнительных серверов, каждый из которых будет представлять собственные сервисы и пользоваться услугами прочих серверов разного уровня.

Из выше сказанного сравним архитектуры. Двухзвенная архитектура проще, так как все запросы обслуживаются одним сервером, но именно из-за этого она менее надежна и предъявляет повышенные требования к производительности сервера.

Трехзвенная архитектура сложнее, но благодаря тому, что функции распределены между серверами второго и третьего уровня, эта архитектура представляет:

• 1. Высокую степень гибкости и масштабируемости.
• 2. Высокую безопасность (т.к. защиту можно определить для каждого сервиса или уровня).
• 3. Высокую производительность (т.к. задачи распределены между серверами).

Архитектура клиент-сервер применяется в большом числе сетевых технологий, используемых для доступа к различным сетевым сервисам. Кратко рассмотрим некоторые типы таких сервисов (и серверов).

Web-серверы. Изначально представляли доступ к гипертекстовым документам по протоколу HTTP (Huper Text Transfer Protocol). Сейчас поддерживают расширенные возможности, в частности работу с бинарными файлами (изображения, мультимедиа и т. п.).

Серверы приложений. Предназначены для централизованного решения прикладных задач в некоторой предметной области. Для этого пользователи имеют право запускать серверные программы на исполнение. Использование серверов приложений позволяет снизить требования к конфигурации клиентов и упрощает общее управление сетью.

Серверы баз данных. Серверы баз данных используются для обработки пользовательских запросов на языке SQL. При этом СУБД находится на сервере, к которому и подключаются клиентские приложения.

Файл-серверы. Файл-сервер хранит информацию в виде файлов и представляет пользователям доступ к ней. Как правило файл-сервер обеспечивает и определенный уровень защиты от несанкционированного доступа.

Прокси-сервер. Во-первых, действует как посредник, помогая пользователям получить информацию из Интернета и при этом обеспечивая защиту сети. Во-вторых, сохраняет часто запрашиваемую информацию в кэш-памяти на локальном диске, быстро доставляя ее пользователям без повторного обращения к Интернету.

Файрволы (брандмауэры). Межсетевые экраны, анализирующие и фильтрующие проходящий сетевой трафик, с целью обеспечения безопасности сети.

Почтовые серверы. Представляют услуги по отправке и получению электронных почтовых сообщений.

Серверы удаленного доступа (RAS). Эти системы обеспечивают связь с сетью по коммутируемым линиям. Удаленный сотрудник может использовать ресурсы корпоративной ЛВС, подключившись к ней с помощью обычного модема.

Это лишь несколько типов из всего многообразия клиент-серверных технологий, используемых как в локальных, так и в глобальных сетях.

Для доступа к тем или иным сетевым сервисам используются клиенты, возможности которых характеризуются понятием «толщины». Оно определяет конфигурацию оборудования и программное обеспечение, имеющиеся у клиента. Рассмотрим возможные граничные значения:

«Тонкий» клиент. Этот термин определяет клиента, вычислительных ресурсов которого достаточно лишь для запуска необходимого сетевого приложения через web-интерфейс. Пользовательский интерфейс такого приложения формируется средствами статического HTML (выполнение JavaScript не предусматривается), вся прикладная логика выполняется на сервере.

Для работы тонкого клиента достаточно лишь обеспечить возможность запуска web-браузера, в окне которого и осуществляются все действия. По этой причине web-браузер часто называют «универсальным клиентом» .

«Толстый» клиент. Таковым является рабочая станция или персональный компьютер, работающие под управлением собственной дисковой операционной системы и имеющие необходимый набор программного обеспечения. К сетевым серверам «толстые» клиенты обращаются в основном за дополнительными услугами (например, доступ к web-серверу или корпоративной базе данных).

Так же под «толстым» клиентом подразумевается и клиентское сетевое приложение, запущенное под управлением локальной ОС. Такое приложение совмещает компонент представления данных (графический пользовательский интерфейс ОС) и прикладной компонент (вычислительные мощности клиентского компьютера).

СПД на предприятии должна представлять собой интегрированную информационную систему (ИИС). Под ИИС подразумевается комплекс программно-аппаратных устройств и коммуникаций связи, обеспечивающий сотрудников предприятия единой информационной сетью и доступом к сети IP «ТТК».

Компонентами ИИС являются:

• — Структурированная кабельная система (СКС);
• — Волоконно-оптические линия связи (ВОЛС);
• — Локальная вычислительная сеть (ЛВС).

ИИС должна состоять из семи узлов, один из которых является центральным узлом сети. Центральный узел находится на первом этаже здания администрации предприятия. Остальные узлы располагаются так:

• — Терминал 1 — Терминал 7 — узел № 1;
• — Терминал 8 — Терминал 11 — узел № 2;
• — Терминал 12, Терминал 13 — узел № 3;
• — Терминал 14 — Терминал 17 — узел № 4;
• — Главный терминал — узел № 5;
• — Складской терминал — узел № 6;

Выбор биллинговой системы.

Биллинговая система — программный комплекс, осуществляющий учет объема потребляемых абонентами услуг, расчет и списание денежных средств в соответствии с тарифами компании.

Задачи, которые стоят перед биллинговой системой следующие:

• · сбор информации о потребляемых услугах (аккаунтинг)
• · аутентификация и авторизация абонентов
• · контроль денежных средств на счетах абонентов и списание средств в соответствии c действующей тарифной сеткой
• · пополнение счетов абонентов
• · внесение изменений в тарифы
• · предоставление статистики по операциям (клиентская и операторская части).

Кстати, не стоит путать аутентификацию и авторизацию — это разные понятия. Так, аутентификация — процедура идентификации пользователя (обычно сводящаяся к проверке указываемых им данных на совпадение с хранящимися в системе). Авторизация — процесс принятия решения о правомерности доступа пользователя к какому-то конкретному ресурсу (например, к файлу на диске или к определенной услуге связи).

Рисунок Структура биллинговой системы поставщика услуг.

• · коллекторы информации о потребленных услугах
• · система аутентификации абонентов
• · ядро (бизнес-логика)
• · многоуровневая БД
• · модуль авторизации
• · модуль анализа типов трафика (локальный, пиринговый, etc)
• · модуль разграничения доступа
• · модуль статистики
• · административный интерфейс для ручного управления абонентами
• · интерфейс управления счетами абонентов и тарифами для отдела продаж

Основной принцип проектирования системы — строгая модульность, которая в последствии позволит легко модернизировать отдельные компоненты системы в зависимости от меняющихся задач бизнеса.

Услуги могут быть разными (например — VPN-доступ, dial-up пул, обычный неинкапсулированный трафик, Proxy, VoIP, etc), надо обеспечить доставку ядру системы в единообразном виде информации о том, какой тип услуги, какой абонент, в каком объеме и в какое время потребил.

Многоуровневая БД нужна для того, чтобы не работать все время с массивами максимально детальной информации, так как это значительно может снизить быстродействие всей системы.

Можно выделить 3 уровня:

• 1. максимально детализированная информация без какой-либо обработки
• 2. классифицированная и первично агрегированная информация
• 3. оперативная информация

База первого уровня может понадобиться для разрешения спорных моментов с клиентами. Важно сохранять ее в исходном виде, т.к. возможно будет необходимо постфактум произвести перерасчет выставленных к оплате счетов с учетом скорректированных тарифов или, например, уточненных границ сетей, по которым делится трафик.

Не для каждого сервиса можно получить детализированную информацию о соединениях, но к этому надо стремиться. По крайней мере, при подсчете трафика через Web Proxy это решается автоматически, использование NetFlows тоже позволяет делать полную детализацию. Минусом является значительный объем, требующийся для хранения всех этих данных. Однако, т.к. эта информация нужна не очень часто, ее более логично хранить в виде обычных файлов, а не в базе — это уменьшит нагрузку на сервер БД и является более компактным способом хранения.

База второго уровня компактнее, чем первая, поэтому ее можно хранить за более продолжительный период времени. Например, после классификации трафика можно не хранить информацию о локальном трафике, если за него не взимается плата. Также с большой долей вероятности можно считать одним соединением несколько соединений с одним и тем же хостом, произошедшие в приблизительно одно.

Оперативная информация — наиболее грубая по отношению к остальным двум базам, но зато операции с ней можно совершать очень быстро, что позволяет сократить время реакции системы, которое будет обсуждаться ниже. На основе этой базы осуществляется принятие решений о предоставлении или прекращении предоставления услуг конкретному клиенту.

На предприятии установим биллинговую систему UTM 5.

Базовая лицензия на UTM 5 открывает полноценный доступ к основному функционалу биллинговой системы. Это тарификация наиболее востребованных услуг, основные инструменты учета трафика, все необходимые отчеты. Базовая лицензия не накладывает никаких ограничений по количеству абонентов или объемам тарифицируемого трафика.

Лицензия на базовый модуль позволяет производить тарификацию:

• · Разовых услуг;
• · Периодических услуг;
• · Трафика.

Предоставляемые инструменты:

• · Интерфейс администратора (основное средство управления биллинговой системой);
• · Интерфейс пользователя (отчетность для абонента и управление собственной учетной записью);
• · UTM 5 Tray (пользовательская мультиплатформенная утилита для управления доступом в интернет).

Интерфейс администратора позволяет создавать тарифные планы, заводить услуги, выставлять счета. Платежи могут быть зарегистрированы в системе администратором вручную, или самими пользователями, через предоплаченные карты.

Формирование документов происходит на основании шаблонов (договора, счета, приходно-кассовые ордера, счета-фактуры, и т. д.). Отчеты формируются по стандартным формам (по трафику, списаниям, услугам, платежам, блокировкам и другим параметрам).

Биллинговая система UTM 5 способна управлять оборудованием и сторонним программным обеспечением (брэндмауэры, коммутаторы, прокси-серверы и т. д.) при наступлении определенных событий. К примеру, при нулевом балансе ограничить доступ абонента к интернету непосредственно на коммутаторе.

Поддерживаемые версии программного обеспечения:

• · Аппаратная платформа: x86
• · Операционная система: Windows 2003 Server
• · СУБД: mysql 5.0.x

А теперь более подробно рассмотрим интерфейс администратора биллинговой системы UTM 5.

Список пользователей отображается постранично; интерфейс для выбора настроек отображения (числа пользователей на странице и номера страницы) расположен в нижней части списка. Количество пользователей на странице сохраняется при выходе из программы.

На рисунке показано как в UTM 5 выглядит список пользователей.

Рисунок Список пользователей.

Окно добавления пользователя подразделяется на следующие страницы:

• * Основные параметры — логин, наименование, пароль и параметр Работать по предоплате. Имеется возможность сгенерировать случайный пароль, который автоматически подставляется в поля Пароль и Подтверждение, а также показывается явно в поле Сгенерированный пароль.
• * Дополнительные параметры — паспортные данные и банковские параметры, а также дополнительно заведённые параметры пользователя.
• * Контакты — персональные данные (адрес, телефон, e-mail) контактного лица.
• * Другое — прочие параметры, ассоциированные с данным пользователем (адрес и порт удалённого коммутатора; закреплённая валюта пользователя).

В группе страниц Пользователь в окне свойств пользователя страница Основные параметры показана на рисунке 2.2.2.3.

Рисунок Окно свойств пользователя.

Создание новой учетной записи клиента осуществляется при помощи диалогового окна добавления пользователя. Обязательной информацией является логин пользователя. При создании новой учётной записи пароль генерируется автоматически, но есть возможность его изменения. Одновременно с учётной записью для пользователя заводится основной лицевой счёт.

Рисунок 2.2.2.4. Окно добавления пользователя.

Чтобы внести платёж на счёт пользователя необходимо:

• 1. На левой панели в группе страниц Пользователи и группы откройте пункт Пользователи. Откроется страница со списком зарегистрированных пользователей.
• 2. Выберите нужного пользователя в списке и нажмите Внести платеж. Откроется окно параметров платежа.
• 3. Если у пользователя несколько лицевых счетов, выберите нужный счёт из выпадающего списка.
• 4. Выберите из списка валюту платежа.
• 5. Введите сумму платежа.
• 6. Введите дату платежа или оставьте значение по умолчанию (текущую дату).
• 7. Введите дату истечения платежа или оставьте значение по умолчанию (не истекает).
• 8. Введите произвольные комментарии для администратора и для пользователя.
• 9. Выберите из списка метод платежа.
• 10. Если платёж производится согласно внешнему платёжному документу, введите номер этого документа.
• 11. Если платёж производится по счёту, зарегистрированному в системе, выберите номер этого счёта.
• 12. Нажмите ОК, чтобы произвести платёж.

Для создания правила firewall необходимо:

• 1. На левой панели в группе страниц Настройки открыть пункт Правила firewall. Откроется страница со списком зарегистрированных правил.
• 2. Нажмите Добавить. Откроется окно Правило firewall.
• 3. Введите комментарий в поле Комментарий, чтобы легко отличать данное правило от других в общем списке.
• 4. В выпадающем списке Брандмауэр выберите брандмауэр, на котором должна выполняться команда, или позицию Любой для выполнения команды на всех брандмауэрах, подключённых в момент выполнения.
• 5. В группе параметров Выполнять для либо поставьте флажок Все пользователи, либо задайте одно или более из следующих условий для определения области применимости:

Идентификатор пользователя в поле ID пользователя;

Группу в выпадающем списке Имя группы;

Тарифный план в выпадающем списке Название тарифа.

Если задано более одного условия, по умолчанию учитывается их объединение. При надобности отметьте флажок Совпадают все параметры, чтобы учитывать пересечение условий.

• 6. В группе Выполнять при выберите инициирующее событие или несколько событий, при наступлении которых должно срабатывать данное правило, пользуясь выпадающим списком всех возможных событий и кнопками Добавить и Удалить.
• 7. В поле Правило firewall введите шаблон команды. При необходимости используйте переменные для построения шаблонов команд. Переменные заменяются своими значениями непосредственно при выполнении команды. Набор допустимых переменных зависит от выбранных инициирующих событий. При использовании неприменимых переменных выдаётся предупреждение.
• 8. Нажмите ОК, чтобы завершить создание правила.

На рисунке показан пример списка правил firewall.

Интерфейс настройки свойств правил firewall показан на рисунке.

Рисунок Окно «Правила firewall».

Чтобы создать тарифный план необходимо нажать кнопку Добавить.

Кнопка Добавить открывает окно создания тарифного плана со следующими полями ввода:

• · Название тарифа — обязательный параметр.
• · Срок завершения действия — дата окончания действия тарифного плана и списаний за него (необязательный параметр).
• · Обнулять баланс в конце расч. периода — установка данного параметра приводит к обнулению баланса лицевого счета, привязанного к тарифной связке этого тарифного плана, при закрытии расчетного периода.

Кнопка Редактировать открывает окно свойств тарифного плана, в котором имеются следующие поля ввода:

• · Идентификатор тарифа — присваивается автоматически.
• · Название тарифа — обязательный параметр.
• · Создан, Изменен — дата создания и дата последнего изменения тарифного плана.
• · Создал, Изменил — логин пользователя, создавшего или последним изменившего тарифный план.
• · Срок завершения действия — дата окончания действия тарифного плана и списаний за него (необязательный параметр).
• · Обнулять баланс в конце расч. периода — установка данного параметра приводит к обнулению баланса лицевого счета, привязанного к тарифной связке этого тарифного плана, при закрытии расчетного периода.
• · Услуги — список услуг, входящих в тарифный план.

Для включения новой услуги в тарифный план необходимо нажать кнопку Добавить. Будет отображен список всех существующих в системе шаблонов услуг.

На рисунке показан интерфейс редактирования тарифа.

Рисунок Редактирование тарифного плана.

Технические требования к ВОЛС

• · Волоконно-оптическая линия связи должна соответствовать международному стандарту на кабельные разводки International Standard ISO/IEC 11 801.
• · Волоконно-оптическая линия связи должна обеспечивать поддержку протоколов передачи функционирующих на скоростях до 100 Мбит.
• · ВОЛС должна соединять центральный узел КОР, находящийся по адресу Высоцкого, 50, и узел доступа к сети «ТТК», находящийся по адресу Малышева, 122.
• · ВОЛС не должна взаимодействовать с другими коммуникациями, такими как вентиляция, теплосеть, водопровод, канализация и т. п. При проектировании трасс ВОЛС необходимо учитывать коммутации силовых электрических сетей, сетей освещения здания, вентиляции и др.
• · Кабели и коммутационные устройства должны быть промаркированы.
• · ВОЛС должна иметь 100% резерв волокон в кабелях.
• · ВОЛС должна иметь 50% избыточности кроссового оборудования для дальнейшего расширения системы в помещениях основных служб.

Текущие и перспективные технические требования к СКС

• · СКС должна соответствовать международному стандарту на кабельные разводки International Standard ISO/IEC 11 801.
• · СКС должна быть рассчитана на подключение слаботочных устройств общей емкостью до 120 портов (портом следует считать модульное окончание для разъема типа RJ-45).
• · СКС должна обеспечивать поддержку следующих протоколов передачи:
  • — 10 BaseT, 100 BaseT, ISDN;
  • — Fast Ethernet, ATM, видеоконференции — приложения, функционирующие на частотах до 100 МГц при использовании медных носителей.
• · СКС должна иметь один центр коммутации. Центр коммутации располагается на первом этаже административного здания в специальном помещении, а также предусматривать достаточную емкость для будущего расширения.
• · СКС должна быть выполнена с применением топологии «звезда» — от кроссового оборудования к каждому порту отдельная линия. Горизонтальная (абонентская) кабельная разводка должна быть выполнена кабелем FTP не ниже категории 5.
• · СКС не должна взаимодействовать с каналами скрытой проводки для прокладки кабелей других коммуникаций, таких как вентиляция, теплосеть, водопровод, канализация и т. п. При проектировании трасс СКС необходимо учитывать коммутации силовых электрических сетей, сетей освещения здания, вентиляции и др.
• · Кабели и коммутационные устройства СКС должны быть промаркированы. Следует предусмотреть необходимое оборудование и запас материалов для изменения маркировки при эксплуатации сети.
• · Увеличение количества портов для расширения системы на 15%.
• · СКС должна иметь 20% избыточности кроссового оборудования для дальнейшего расширения системы в помещениях основных служб.

Текущие и перспективные технические требования к активному оборудованию ЛВС

• · Активное оборудование должно соответствовать международным стандартам:
  • — Протокол построения основного дерева IEEE 802.1D;
  • — Поддержка протоколов VLAN.
• · Активное оборудование должно поддерживать виртуальные группы на базе сетевых протоколов (IP, IPX), MAC — адресов и объединение в группы по административному принципу.
• · Активное оборудование должно поддерживать следующие технологии: агрегирование портов, коммутацию уровня 3, FAST IP, IGMP snooping.
• · Активное оборудование должно обеспечивать передачу с использованием протоколов Ethernet и Fast Ethernet.
• · Активное оборудование должно иметь встроенные функции по защите от широковещательного трафика, фильтрации.