Операторский уровень linux — carrier grade linux

Предпосылки создания Ethernet операторского класса (CGE)

Описывая сети Ethernet операторского класса, нужно прежде всего указать на предпосылки, которые привели к созданию CGE (ниже будем использовать сокращение CGE – Carrier Grade Ethernet, а не CE – Carrier Ethernet, чтобы не путать с сокращениями CE для терминов типа Customer Edge, Customer Equipment, см. ).

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

Протокол Ethernet был достаточно прост и легко масштабировался для работы на скоростях в сотни и десятки тысячи раз выше исходной (достаточно вспомнить ряд рабочих скоростей Ethernet за последние 40 лет: 0,01–0,1–1–10–100 Гбит/с) и был одинаково хорошо адаптирован к этим новым скоростям. Например, новые возможности во временной области, добавленные к стандарту IEEE 802.3 Ethernet для поддержки передачи потоков аудио-видео (AV) данных по ЛС (см. IEEE 802.1 Audio Video Bridging ), оказались удобными для приложений, чувствительным к временным задержкам, таким, например, как протокол точного времени IEEE 1588.

Кроме постоянного роста скорости, все больше ЛС-пользователей присоединялись к различным глобальным сетям связи (ГлС), используя интерфейсы Ethernet, или к устройствам, которые имели мостовые переходы в эти сети (например, к цифровой абонентской линии – DSL), или реализовали беспроводную связь между ними. Более того, пользователи, знакомые с такими возможностями сетей Ethernet, могли расширить их для сложных сетей со многими узлами. Необходимость в использовании таких сетей росла, так как они включали много таких сервисов, которые обрабатывались раньше только в ЛС или при наличии специальных соединений, к ним относились, прежде всего, видеосервисы и резервное копирование.

Отраслевые стандарты

Несколько отраслевых стандартов имеют решающее значение для успеха коммуникационных серверов, в том числе:

AdvancedTCA

В Передовая архитектура телекоммуникационных вычислений (ATCA) представляет собой серию Группа производителей промышленных компьютеров PCI (PICMG ) спецификации, предназначенные для удовлетворения требований к оборудованию связи операторского класса. Эта серия спецификаций включает последние тенденции в технологиях высокоскоростных соединений, процессоры нового поколения и повышенную надежность, управляемость и удобство обслуживания.

AdvancedMC

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

Эта спецификация PICMG обеспечивает основу для непосредственного комбинирования модулей AdvancedMC без необходимости использования AdvancedTCA или специального носителя. предназначена для оборудования меньшего размера, такого как беспроводные базовые станции, радиомодули Wi-Fi и WiMAX, а также шлюзы доступа VoIP, где ключевыми требованиями являются небольшой физический размер, низкая начальная стоимость и масштабируемость.

Операционная система Linux

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

HPI и AIS

Эти Форум доступности услуг (SA Forum) спецификации определяют стандартные интерфейсы для управления телекоммуникационной платформой и программного обеспечения высокой доступности.

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

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

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

Инфраструктурные элементы системы

Базовая станция DIB-500
  • Поддержка до 8 несущих;
  • Полноценный режим автономной работы (Fallback);
  • Поддержка функции коммутации;
  • Удаленный мониторинг модулей и компонентов БС;
  • Конфигурируемые входы и выходы внешней аварийной сигнализации;
  • Поддержка различных конфигураций антенно-фидерной системы;
  • Модульный дизайн, компактность и энергоэффективность.
Базовая станция DIB-R5
  • Поддержка расширенных сервисов передачи данных (TEDS);
  • Возможность разнесенного приема по 3-м направлениям
  • Поддержка до 8 несущих;
  • Полноценный режим автономной работы (Fallback);
  • Поддержка функции коммутации;
  • Поддержка «горячего» резервирования модулей
  • Система обнаружения помех
  • Удаленный мониторинг модулей и компонентов БС;
  • Конфигурируемые входы и выходы внешней аварийной сигнализации;
  • Поддержка различных конфигураций антенно-фидерной системы;
  • Модульный дизайн, компактность и энергоэффективность.
Сервер приложений IP Node (IPN)
  • Централизованная коммутация голосовых вызовов и данных (для централизованных систем);
  • Построен на аппаратной части серверов операторского класса (COTS)
  • Сервер системы управления сетью;
  • Сервер приложений для диспетчеризации, записи переговоров и т.д.
  • Предоставление интерфейсов для выхода во внешние сети связи (ТфОП, корпоративные АТС, сети пакетной передачи данных и т.д.) 

Особенности версий OpenStack и Linux операторского класса

  • функциями single-root input/output virtualization (SR-IOV) и PCI-passthrough;
  • поддержкой NUMA node affinity и CPU core pinning;
  • назначением виртуальным машинам больших страниц памяти;
  • масштабированием vCPU;
  • планировщиком на основе производительности сети (network performance-based scheduling);
  • планировщиком с учетом типа CPU и узла NUMA.
  • оркестрацию виртуальных сетей для функций VNF;
  • изоляцию «жильцов» с помощью виртуальных локальных сетей (VLAN) и расширяемых VLAN (VXLAN) провайдера;
  • функциональность распределенной виртуальной маршрутизации virtual routing (DVR);
  • функциональность безопасности и политики QoS;
  • механизм плагинов Modular Layer 2 (ML2) для программирования и управления AVS,;
  • возможность посылать пакеты с тегами VLAN к/от VNF.
  • управление жизненным циклом композитных приложений («Stack»)
  • способность определять набор ресурсов (например, VM, сети, тома Cinder, базы данных Swift) которые образуют сложные приложения
  • определения на базе файлов и шаблонов
  • поддержка для команд управления жизненным циклом, например, start, modif и stop
  • VM instance bootstrapping/конфигурирование с помощью механизмов cloud-initiative и cloud-formation
  • автоматическое масштабирование приложений
  • интеграция security groups
  • улучшенное удобство использования шаблонов
  • улучшенное удобство использования Heat в Horizon

Как узнать, есть ли у моего оператора меня в CG-NAT или у меня есть публичный IP

Мы можем узнать, предоставил ли нам наш оператор общедоступный IP-адрес или, тем не менее, он поставил нас за CG-NAT с помощью нескольких методов, которые мы собираемся подробно объяснить. Любой из методов, которым мы собираемся научить вас дальше, скажет нам, есть ли у нас общедоступный IP-адрес или, тем не менее, наш оператор поместил нас в CG-NAT. Кроме того, мы могли бы без проблем использовать один или несколько методов одновременно, чтобы точно проверить, есть ли у нас публичный IP-адрес в нашем доме или его нет.

Просмотр IP-адреса WAN на маршрутизаторе

Первое, что нам нужно сделать, это получить доступ к нашему домашнему маршрутизатору, настроенному вами или предоставленному оператором Интернета. Вы должны получить доступ через шлюз по умолчанию, обычно вы получаете доступ через http://192.168.1.1 or http://192.168.0.1 , затем вы входите в систему под своим именем пользователя и паролем (по умолчанию это обычно пользователь «Admin» и пароль «admin»).

На экране состояния маршрутизатора появится раздел с надписью » WAN IP-адрес «,» WAN IP ”Или подобное, то есть мы должны посмотреть, какой IP-адрес получает WAN-интерфейс Интернет-маршрутизатора. На следующем снимке экрана вы можете увидеть соединение Digi с использованием CG-NAT, как это видно в разделе «IP-адрес».

Чтобы узнать, является ли наш IP-адрес общедоступным или находится в CG-NAT, это так же просто, как знать, находится ли этот IP-адрес, который указывает маршрутизатор, в диапазоне CG-NAT или он не имеет к нему никакого отношения. Если IP-адрес находится в подсети 100.64.0.0/10, то есть в диапазоне от 100.64.0.1 до 100.127.255.254, то мы можем гарантировать, что мы находимся в CG-NAT, потому что этот диапазон принадлежит этой технологии и зарезервирован.

Сравните WAN IP-адрес маршрутизатора с общедоступным IP-адресом, полученным в Интернете.

Еще один очень полезный способ узнать, находится ли наш IP-адрес в CG-NAT или у нас есть общедоступный IP-адрес, — это сравнить «IP-адрес WAN», который отображается в нашем маршрутизаторе, с общедоступным IP-адресом, который мы можем получить через такие веб-сайты, как Что такое IP . Если IP-адрес, указанный на этом веб-сайте, в точности совпадает с IP-адресом, указанным в WAN IP-адресе нашего маршрутизатора, то мы можем гарантировать, что оператор предоставил нам общедоступный IP-адрес и мы не находимся в CG-NAT.

Этот метод, чтобы узнать, находимся ли мы в CG-NAT или нет, является одним из самых простых, поскольку нам нужно будет только сравнить два IP-адреса, без необходимости знать, находится ли он в диапазоне CG-NAT 100.64.0.0/ 10 как у нас. объяснено выше.

Сделайте traceroute или tracert для нашего общедоступного IP

If вы заходите на веб-страницу «Какой у меня IP» и Интернет сообщает вам, что ваш общедоступный IP-адрес — 150.150.150.150, вы открываете командную строку в Windows (Клавиша Windows, введите в поисковике «cmd» и нажмите Enter), и вы положите:

Если трассировка имеет 1 одиночный переход, это означает, что у вас есть публичный IP-адрес, если у него 2 перехода, это означает, что вы находитесь в CG-NAT. Причина этого в том, что для достижения общедоступного IP-адреса один из переходов будет в домашнем маршрутизаторе, а другой переход (второй) будет в маршрутизаторе CGN нашего оператора.

  • Если у нас есть скачок, мы можем гарантировать, что IP-адрес является общедоступным и он есть у маршрутизатора.
  • Если у нас есть два прыжка, мы можем убедиться, что находимся в CG-NAT

Мы надеемся, что с помощью этих шагов вы сможете легко и быстро узнать, используем ли мы общедоступную IP-адресацию или, наоборот, вы находитесь под CG-NAT.

Передача Ethernet по сети SONET/SDH

Звено Ethernet «точка-точка» можно оптимально передать по сети SONET/SDH, сформировав контейнер с помощью трех процедур: VCAT (процедуры виртуальной конкатенации – ITU-T G.707), LCAS (схемы динамической настройки звена связи – ITU-T G.7042) – для создания блока, умещающегося в контейнере SDH, и процедуры GFP (общей процедуры фреймирования кадров – ITU-T G.7041), см. подробнее в . Это позволяет, кроме прочего, воспользоваться преимуществами развитого менеджмента и возможностью восстановления трафика (после отказа), характерными для SDH, которые позволяют обеспечить высокую доступность сети и ее устойчивость к отказам.

Сеть магистрального транспорта провайдера (PBT, 802.1Q-2011 или 802.1Qay-2009)

Что такое магистральный транспорт провайдера?

Это транспорт, который ассоциируется:

  • с простой технологией туннельной проводки Ethernet, работающей со звеньями связи типа «точка-точка»;
  • с тем, что туннели могут быть спроектированы с учетом разнесенности, отказоустойчивости и распределения нагрузки;
  • с возможностью доставки трафика из «конца-в-конец» с определенным качеством сервиса (QoS);
  • с возможностью обеспечить гарантированную (уровня SDH) производительность и SLA;
  • с тем, что предлагает (как SDH) 50 мс восстановление в случае отказа.

Итак, PBT может дать решение для простого и эффективного проектирования трафика, а именно:

  • дать возможность (с помощью OSS), используя вариации IEEE 802.1ah, осуществить соединение операторов с сетями Ethernet топологии E-line (рис. 5.1);
  • выключить специфические мостовые функции, протоколы и ситуации, такие как:
  1. функции бродкастинга и мультикастинга,
  2. функцию обучения системы на MAC-уровне,
  3. возможность использования протокола STP (остовного покрывающего дерева),
  4. ситуацию «флудинга» – наводнения, вызванного массовыми рассылками опросных пакетов в ЛС;

дает возможность управления форвардингом таблиц в плоскость менеджмента, а следовательно, и допускает управление поведением форвардинга с помощью, например, конструкции типа if <> than <> e
se: если «VLAN ID существует» и «адрес DA существует», то «форвардинг», в противном случае «выход».

Ethernet операторского класса первого поколения (CE/CGE-1)

Рассмотрим более подробно процесс становления сети CE/CGE первого поколения.

Известно, что Ethernet занимал третий (сетевой) уровень модели взаимодействия открытых систем (МВОС/OSI). Сегодня первые три уровня (с учетом нового и промежуточных уровней) превратились в шесть :

  • уровень 3 – сетевой – I P, Ethernet;
  • уровень 2,5 – MPLS;
  • уровень 2 – звена передачи – ATM, FR, Ethernet;
  • уровень 1,5 – GFP, LCAS, VCAT;
  • уровень 1 – физический – SDH;
  • уровень 0 – фотонный – WDM.

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

  • уровень 3 – сетевой – IP;
  • уровень 2 – звена передачи – Ethernet (PBB, PBT);
  • уровень 0 – фотонный – WDM.

Обзор Решения

PCRF Сервер – программная платформа операторского класса, предназначенная для создания конвергентных решений по управлению политиками и принятию решений по применению политик в режиме реального времени. Платформа интегрируется в основные функциональные области сети оператора: B/OSS, область базовых элементов сети (core network), область контент-приложений.

PCRF Сервер включает в себя реализацию PCRF (Policy and Charging Rules Function), основанную на стандартах 3GPP, и представляет собой «out of box»-решение для провижионига, управления и назначения таких политик, как управление QoS (Quality of Service), управление полосой пропускания, политик, учитывающих поведение абонента, а также политик доступа к дополнительным услугам в сетях 2G/3G и LTE.

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

PCRF Сервер также предлагает исключительную гибкость при интеграции с различным оборудованием сети и B/OSS системами при помощи стандартных (например, специфицированных в 3GPP) или нестандартных интерфейсов/протоколов.

PCRF Сервер дает возможность быстро создавать и внедрять новые политики или продукты, позволяя оператору предоставлять абонентам инновационные и уникальные услуги/приложения.

PCRF Сервер состоит из следующих подсистем:

  • PCRF Engine
  • Репозиторий
  • Подсистема управления
  • Подсистема доступа к SPR
  • Балансировщики трафика (Load Balancers)
  • Studio, графический интерфейс пользователя.

PCRF Engine – это основной модуль, который обрабатывает запросы политик от элементов сети или B/OSS систем в режиме реального времени. Основными компонентами являются: Diameter-based 3GPP Gx Connector, Diameter-based 3GPP Rx Connector, Diameter-based 3GPP Sy Connector, Policy and Charging Rules Server, Policy Decision Platform, Subscriber Profile Cache и Subscription Management Service.

Репозиторий хранит все бизнес-правила, технические и конфигурационные параметры, используемые в PCRF Engine, подсистеме управления, балансировщиках и Studio. Это обязательный компонент PCRF Сервера.

Подсистема управления – это централизованный узел, предназначенный для мониторинга и управления всеми компонентами PCRF Сервера. Это базовый компонент PCRF Сервера, выполняющий функции OA&M.

Подсистема доступа к SPR предоставляет API (Web сервисы) для управления данными об абонентах и подписках во внутреннем SPR (Subscriber Profile Repository).

Балансировщики трафика (Load Balancers) – это ключевой компонент в распределенном деплойменте системы. Балансировщики трафика обеспечивают балансировку запросов на уровне протокола DIAMETER.

Studio – пользовательский Web-интерфейс. Предназначен для создания/редактирования политик и продуктов. Operations and Maintenance Console (OMC) также интегрирована в Studio и предназначена для выполнения OA&M функций.

Приложения

Система управления сетью NMS-500

  • Удобный и интуитивно понятный интерфейс управления
  • Гибкие возможности управления функциями, сетевыми элементами и абонентами
  • Масштабируемая модульная структура
  • Максимальная доступность и безопасность данных
  • Простота подключения и мониторинга внешних компонентов системы
  • Контроль доступа к системе управления сетью для обеспечения безопасности
  • Многоязычный графический пользовательский интерфейс

Терминал диспетчера DWS

  • Голосовые вызовы:
    • Поддержка дуплексного вызова, полудуплексного вызова, группового вызова, вызова по всей сети и вызова «соединенных» групп
    • Поддержка перевода и удержания вызова, позднего входа и экстренного вызова
    • Выполнение вызова несколькими способами: через список контактов, историю вызовов и т.д.
    • Детальная информация о вызовах
    • Поддержка различных способов оповещения о вызове
    • Поддержка двух звуковых карт: одна для осуществления вызова, вторая для прослушивания текущих вызовов
    • Фоновый мониторинг позволяет диспетчеру прослушивать окружающую обстановку вокруг абонентского терминала.
  • Текстовые сообщения:
  • Мониторинг абонентских терминалов
  • Управление записью переговоров
  • Голосовые вызовы во внешние сети
  • Управление списком контактов
    • Автоматическая синхронизация данных с инфраструктурой сети
    • Поддержка различных методов поиска контактов: по категории, имени или индивидуальному идентификатору абонента
    • Быстрый доступ к подробной информации об абоненте
    • Управление динамическими группами и соединением групп
    • Управление мониторингом: позволяет выбрать диспетчеру отслеживаемую группу
  • Сервис автоматического определения местоположения подвижного объекта:
    • Работа с ГИС
    • Определение и отображение местоположения абонентского терминала
    • Работа с геозонами
  • Поддержка внешних устройств: дисплей с технологией «touch screen», микрофон с тангентой и т.д.

Цифровая система записи и воспроизведения переговоров

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

Сервер системы записи и воспроизведения переговоров
Функционал:
  • запись переговоров абонентов по всей сети;
  • запись коротких сообщений;
  • анализ записанных данных.

 
Основные преимущества:

  • система записи базируется на IP технологии;
  • архитектура «Веб-браузер/Сервер»;
  • поддержка технологии «горячего» резервирования;
  • многоуровневый контроль доступа к системе;
  • конструктив сервера позволяет его монтировать в стандартную 19” стойку;
  • гибкая конфигурация системы.
Система воспроизведения переговоров
Функционал:
  • воспроизведение и скачивание записанных файлов;
  • возможность сортировки и поиска данных по различным параметрам. 

Основные преимущества:

  • в качестве клиентского терминала используется обычный ПК, оснащенный сетевым интерфейсом;
  • не требуется установка дополнительного программного обеспечения: работа с системой осуществляется через веб-браузер.
 

Сервисы типа E-Аccess

Этот новый тип сервиса определен в спецификации MEF 33 (см. рис. 26), он упрощает и стандартизует взаимосвязь сервисов типа E-Access, допуская оптовые покупки и продажи сервисов Ethernet, а также доставку несетевых сервисов. Это ключевой момент для локальной, региональной и глобальной адаптации сервисов Ethernet операторского класса.

Сервис реализует схемы EPL- и EVPL-доступа и имеет некоторые особенности.

• Для сервиса Access EPL (см. рис. 27):

  1. Реализует первый сервис оптовых продаж в рамках использования интерфейсов UNI-ENNI.
  2. Организуется на базе использования портов на интерфейсах UNI.
  3. Может формировать часть сервиса EP-LAN.

•Для сервиса Access EVPL (см. рис. 28):

  1. Реализует сервис оптовых продаж в рамках использования интерфейсов UNI-ENNI;
  2. Реализует сервис, в котором приложение или устройство может проверить, работает ли оно автономно или в рамках VLAN (с интерфейсом UNI).
  3. Может формировать часть сервиса EVP-LAN.

Сервисы доступа MEF с возможностью реализации оптовых продаж адресуют крупномасштабные, дорогие, требующие временных затрат сервисы Ethernet операторского класса. Это существенно облегчает для новых провайдеров выход на рынок услуг. Кроме того, сервисы E-Access ускоряют доставку несетевых сервисов.

Будучи ключевыми для утверждения сервисов локальных, региональных и глобальных сетей CE, они имеют следующие особенности:

  • оба сервиса имеют 1 ENNI и 1 UNI и следуют определению сервиса доступа типа «точка-точка» (P2P) Ethernet;
  • сервис доступа EPL поддерживает 1 сервис доступа на 1 UNI;
  • сервис доступа EVPL поддерживает много сервисов доступа на 1 UNI.

Примечания: Retail Service Provider – «розничный» сервис-провайдер, обычно имеет коммерческие отношения с конечным пользователем и коммерческие контракты с сервис-провайдером доступа (ASP). Однако в 90% случаев сервис-провайдеры играют обе роли в одно и то же время. Термины: виртуальное соединение оператора (OVC) или оператор (Operator) не следует использовать в маркетинговых презентациях документов MEF.

Атрибуты

Открытые

  • На основе отраслевых открытых стандартов
  • Широкая мультивендорная экосистема
  • Совместимость с отраслевыми сертификатами
  • Доступность инструментов, облегчающих разработку и интеграцию приложений с использованием стандартизованных интерфейсов
  • Множество конкурентоспособных вариантов для стандартных модулей

Гибкость

  • Разработаны для простого включения добавленная стоимость для конкретного приложения на всех уровнях решения
  • Может быть быстро перепрофилирована по мере необходимости для защиты t инвестиции клиентов
  • Многоуровневая масштабируемая архитектура лезвий
  • Удовлетворяет потребности многих отраслей, помимо телекоммуникаций, таких как медицинская визуализация, оборона и аэрокосмическая промышленность

операторского класса

Предназначен для Долговечность поставки
Поддержка расширенного жизненного цикла (>10 лет)

Высокая доступность (>5NINES)

Возможность обновления и обновления «без прерывания работы»
Жесткая возможность реального времени для обеспечения качества обслуживания критически важного трафика
Соответствует правилам построения сети

Ограничения операторов

Из сказанного следует, что операторы глобальных (ГлС/WAN) и региональных/городских (MAN) сетей сталкивались с необходимостью обеспечить три потребности:

  1. Получение для своих пользователей сервисов Ethernet.
  2. Использование преимуществ технологии Ethernet по стоимости и объему предоставляемых услуг.
  3. Замену не-Ethernet-технологий на конкурентные Ethernet-технологии, которые имели бы достаточную емкость сети для хранения контента, резервного копирования и реализации видео высокой четкости, а также гарантировали особенности (надежность передачи и малую задержку), необходимые для поддержки этих сервисов.

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

Следовательно, операторы должны были расширять свои сервисы достаточно консервативно, обращая особое внимание на обеспечение качества сервиса (QoS)

Рейтинг
( Пока оценок нет )
Editor
Editor/ автор статьи

Давно интересуюсь темой. Мне нравится писать о том, в чём разбираюсь.

Понравилась статья? Поделиться с друзьями:
Работатека
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: