По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Работа SR (Segment Routing) в MPLS и SR в IPv6 аналогична во всех отношениях, за исключением того, как передается и обрабатывается стек меток. Заголовки SR в IPv6 переносятся в поле метки потока, показанном на рисунке 8. В реализации IPv6 SR стек меток SR переносится в заголовке маршрутизации заголовка пакета IPv6. Информация в этом заголовке предназначена специально для предоставления информации об узлах, через которые "этот пакет" должен проходить при маршрутизации по сети, поэтому он служит той же цели, что и стек меток SR. В случае реализации SR IPv6 каждая метка имеет длину 128 бит, поэтому в качестве SID можно использовать некоторый локальный IPv6-адрес. Один интересный момент заключается в том, что спецификации IPv6 указывают, что заголовок IPv6 не должен изменяться маршрутизатором при обработке пакета (более подробную информацию см. В RFC8200). Вместо того, чтобы выталкивать (pop), проталкивать (push) и менять местами метки, SR IPv6 полагается на то, что каждый узел на пути имеет указатель на текущую метку в обрабатываемом стеке. Метки маршрутизации сегментов сигнализации SR технически является механизмом маршрутизации источника, потому что источник выбирает путь через сеть-хотя маршрутизация источника в SR может быть гораздо более свободной, чем традиционная маршрутизация источника. Для каждой метки в стеке существует два возможных способа обработки пакета узлом вдоль пути: Метка содержит подробные инструкции о том, как пакет должен обрабатываться на этом устройстве: POP или CONTINUE сегмента (метки) и обработать пакет соответствующим образом. Метка не содержит явных инструкций о том, как пакет должен обрабатываться на этом устройстве: использовать информацию о локальной маршрутизации для пересылки пакета и CONTINUE сегмента. Ни в том, ни в другом случае узел обработки не должен знать обо всем пути для коммутации пакета: он либо просто следует по указанному пути метки, либо обрабатывает пакет на основе чисто локальной информации. Благодаря этой парадигме передача сигналов SR проста. Необходимы два типа сигнализации. Локальный узел, префикс и SID смежности, назначенные узлу в сети, должны быть объявлены каждым узлом в сети. Эта передача сигналов в основном осуществляется в протоколов маршрутизации. Например, протокол от промежуточной системы к промежуточной системе (IS-IS) расширен черновым вариантом расширений (Intermediate System to Intermediate System- IS-IS) для Segment Routing1 для переноса SID префиксов с использованием значения длины подтипа (sub-TLV), как показано на рисунке 9. Также для стандартизации предлагаются расширения к другим протоколам маршрутизации и уровня управления. Поскольку расчет пути в SR основан на источнике, нет необходимости переносить путь в протоколе распределенной маршрутизации. Единственная реальная необходимость - предоставить каждому узлу в сети информацию, необходимую для переноса информации об узле SR, префиксе и смежности. В случае, когда пути SR вычисляются централизованным устройством или контроллером, должен быть способ объявить путь метки, который будет использоваться для достижения определенного назначения. Были предложены расширения для Border Gateway Protocol (BGP) в политике маршрутизации объявленных сегментов в BGP,2 и в протоколе Path Computation Element Protocol (PCEP) в расширениях PCEP для Segment Routing.3 Эти два вида объявления отделены друг от друга, поскольку единственным узлом в сети, который должен либо вычислить, либо наложить список сегментов, является головной узел туннеля или точка, где трафик входит в путь сегмента.
img
Прочитайте материал про реактивное и упреждающее распределение достижимости в сетях. Есть много случаев, когда более эффективно или в соответствии с конкретными ограничениями политики для плоскости управления изучать информацию о достижимости и топологии с другой плоскости управления, а не с помощью механизмов, описанных до этого момента в этой серии статей. Вот некоторые примеры: Две организации должны соединить свои сети, но ни одна из них не хочет позволить другой контролировать политику и работу своих плоскостей управления; Крупная организация состоит из множества бизнес-единиц, каждая из которых имеет возможность управлять собственной внутренней сетью в зависимости от местных условий и требований приложений. Организация должна каким-то образом позволить двум плоскостям управления взаимодействовать при переходе от одной к другой. Причины, по которым одна плоскость управления может получать информацию о доступности от другой, почти безграничны. Учитывая это требование, многие сетевые устройства позволяют операторам перераспределять информацию между плоскостями управления. При перераспределении достижимости возникают две проблемы, связанные с плоскостью управления: как обрабатывать метрики и как предотвращать петли маршрутизации. Примечание. Перераспределение можно рассматривать как экспорт маршрутов из одного протокола в другой. На самом деле импорт/экспорт и перераспределение часто используются для обозначения одного и того же, либо разными поставщиками, либо даже в разных ситуациях одним и тем же поставщиком. Перераспределение и метрики Взаимосвязь между свойствами связи, политиками и метриками определяются каждым протоколом плоскости управления независимо от других протоколов. Фактически, более описательная или более полезная метрическая система - это то, что иногда привлекает операторов к определенному протоколу плоскости управления. На рисунке 12 показаны два участка сети, в которых работают две разные управляющие плоскости, каждая из которых использует свой метод расчета метрик связей. Протоколы X и Y в этой сети были настроены с использованием двух разных систем для назначения показателей. При развертывании протокола X администратор разделил 1000 на скорость соединения в гигабитах. При развертывании протокола Y администратор создал "таблицу показателей" на основе наилучшего предположения о каналах с самой высокой и самой низкой скоростью, которые они могут иметь в течение следующих 10-15 лет, и назначил метрики для различных скоростей каналов в этой таблице. Результат, как показывает рисунок, несовместимые показатели: 10G каналы в протоколе X имеют метрику 100, в то время как в протоколе Y они имеют метрику 20. 100G-каналы как в протоколе X, так и в протоколе Y имеют метрику 10. Предполагая, что более низкая метрика предпочтительна, если метрики добавлены, канал [B, C, F] будет считаться более желательным путем, чем канал [B, D, G]. Однако, если учитывать пропускную способность, оба канала будут считаться одинаково желательными. Если между этими двумя протоколами настроено перераспределение, как следует обрабатывать эти метрики? Есть три общих решения этой проблемы. Администратор может назначить метрику в каждой точке перераспределения, которая передается как часть внутренней метрики протокола. Например, администратор может назначить метрику 5 для пункта назначения E на маршрутизаторе C при перераспределении из протокола X в Y. Этот пункт назначения, E, вводится в протокол Y с метрикой 5 маршрутизатором C. На маршрутизаторе F метрика для E будет от 25 для C. В G стоимость достижения E будет 35 по пути [F, C]. Желательность использования любой конкретной точки выхода для любого конкретного пункта назначения выбирается оператором при назначении этих ручных метрик. Метрика "другого" протокола может быть принята как часть внутренней метрики протокола. Это не работает в случае, когда один протокол имеет более широкий диапазон доступных метрик, чем другой. Например, если протокол Y имеет максимальную метрику 63, метрики 10G из протокола X будут "выше максимума"; ситуация, которая вряд ли будет оптимальной. При отсутствии такого ограничения маршрутизатор C внедрит маршрут к E со стоимостью 100 в протокол Y. Стоимость достижения E на маршрутизаторе F составит 110; стоимость в G будет от 130 до [F, C]. Примечание. Здесь вы можете увидеть компромисс между состоянием плоскости управления и оптимальным использованием сети, это еще один пример компромисса сложности при проектировании реальных протоколов. Перенос внешней метрики в отдельное поле добавляет состояние плоскости управления, но позволяет более оптимально управлять трафиком через сеть. Назначение или использование внешней метрики снижает состояние плоскости управления, но за счет возможности оптимизации потока трафика. Внешняя метрика может быть перенесена в отдельное поле, поэтому каждое сетевое устройство может отдельно определять лучший путь к каждому внешнему адресату. Это третье решение является наиболее широко используемым, поскольку оно обеспечивает наилучшую возможность управления трафиком между двумя сетями. В этом решении C вводит достижимость для E с внешней стоимостью 100. В F есть две метрики в объявлении, описывающие достижимость для E; внутренняя метрика для достижения точки перераспределения (или выхода) - 20, а метрика для достижения точки E во внешней сети - 100. В G внутренняя метрика для достижения точки выхода - 30, а внешняя метрика - 100. Как реализация будет использовать оба этих показателя? Следует ли протоколу выбирать ближайшую точку выхода или, скорее, самую низкую внутреннюю метрику? Это позволит оптимизировать использование локальной сети и потенциально деоптимизировать использование сетевых ресурсов во внешней сети. Должен ли протокол выбирать точку выхода, ближайшую к внешнему назначению, или, скорее, самую низкую внешнюю метрику? Это позволит оптимизировать сетевые ресурсы во внешней сети, потенциально за счет деоптимизации использования сетевых ресурсов в локальной сети. Или протоколу следует попытаться каким-то образом объединить эти две метрики, чтобы максимально оптимизировать использование ресурсов в обеих сетях? Некоторые протоколы предпочитают всегда оптимизировать локальные или внешние ресурсы, в то время как другие предоставляют операторам возможность конфигурации. Например, протокол может позволять переносить внешние метрики в виде метрик разных типов, при этом один тип считается большим, чем любая внутренняя метрика (следовательно, сначала предпочтение отдается самой низкой внутренней метрике и использование внешней метрики в качестве средства разрешения конфликтов), а другой тип - это когда внутренние и внешние метрики считаются эквивалентными (следовательно, добавляются внутренние и внешние метрики для принятия решения о пути). Перераспределение и петли маршрутизации В приведенном выше обсуждении вы могли заметить, что места назначения, перераспределенные с одного протокола на другой, всегда выглядят так, как будто они подключены к перераспределяющему маршрутизатору. По сути, перераспределение действует как форма резюмирования (что означает, что удаляется информация о топологии, а не информация о достижимости), как описано ранее в этой серии статей. Хотя этот момент не является критическим для показателей перераспределения, важно учитывать способность плоскости управления выбирать оптимальный путь. В некоторых конкретных случаях деоптимизация может привести к тому, что плоскость управления не сможет выбрать пути без петель. Рисунок 13 демонстрирует это. Чтобы построить петлю маршрутизации в этой сети: Маршрут к хосту A перераспределяется от протокола X к Y с вручную настроенной метрикой 1. Маршрутизатор E предпочитает маршрут через C с общей метрикой (внутренней и внешней) 2. Маршрутизатор D предпочитает маршрут через E с общей метрикой 3. Маршрутизатор D перераспределяет маршрут к хосту A в протокол X с существующей метрикой 3. Маршрутизатор B имеет два маршрута к A: один со стоимостью 10 (напрямую) и один с метрикой от 4 до D. Маршрутизатор B выбирает путь через D, создавая петлю маршрутизации. И так далее (цикл будет продолжаться, пока каждый протокол не достигнет своей максимальной метрики). Этот пример немного растянут для создания цикла маршрутизации в тривиальной сети, но все циклы маршрутизации, вызванные перераспределением, схожи по своей структуре. В этом примере важно, что была потеряна не только топологическая информация (маршрут к A был суммирован, что, с точки зрения E, было непосредственно связано с C), но и метрическая информация (исходный маршрут со стоимостью 11 перераспределяется в протокол Y со стоимостью 1 в C). Существует ряд общих механизмов, используемых для предотвращения формирования этой петли маршрутизации. Протокол маршрутизации всегда может предпочесть внутренние маршруты внешним. В этом случае, если B всегда предпочитает внутренний маршрут A внешнему пути через D, петля маршрутизации не образуется. Многие протоколы маршрутизации будут использовать предпочтение упорядочивания при установке маршрутов в локальную таблицу маршрутизации (или базу информации о маршрутизации, RIB), чтобы всегда отдавать предпочтение внутренним маршрутам над внешними. Причина этого предпочтения состоит в том, чтобы предотвратить образование петель маршрутизации этого типа. Фильтры можно настроить так, чтобы отдельные пункты назначения не перераспределялись дважды. В этой сети маршрутизатор D может быть настроен для предотвращения перераспределения любого внешнего маршрута, полученного в протоколе Y, в протокол X. В ситуации, когда есть только два протокола (или сети) с перераспределенной между ними информацией плоскости управления, это может быть простым решением. В случаях, когда фильтры необходимо настраивать для каждого пункта назначения, управление фильтрами может стать трудоемким. Ошибки в настройке этих фильтров могут либо привести к тому, что некоторые пункты назначения станут недоступными (маршрутизация черных дыр), либо приведет к образованию петли, потенциально вызывающей сбой в плоскости управления. Маршруты могут быть помечены при перераспределении, а затем отфильтрованы на основе этих тегов в других точках перераспределения. Например, когда маршрут к A перераспределяется в протокол Y в C, маршрут может быть административно помечен некоторым номером, например, 100, чтобы маршрут можно было легко идентифицировать. На маршрутизаторе D можно настроить фильтр для блокировки любого маршрута, помеченного тегом 100, предотвращая образование петли маршрутизации. Многие протоколы позволяют маршруту нести административный тег (иногда называемый сообществом или другим подобным именем), а затем фильтровать маршруты на основе этого тега.
img
Разработка классов модели контакт-центра Для правильного управления количеством операторов контакт-центра надо понимать, по какому принципу он работает. Для этого разработана имитационная модель, отображающая структуру контакт-центра. Для распределения поступающих запросов в контакт-центр, создаем класс (Gen_ab_pоtоk), который генерирует временные интервалы между вxодящими запросами. Создаем нейронную сеть, которая будет предсказывать по обучающей выборке временные интервалы для будущиx вxодныx запросов, это второй класс (FlоwRNN). Для управления количеством операторов нейронная сеть должна заранее предсказывать необxодимое количество операторов для работы контакт-центра без потерь в обслуживании. Для этого необxодимо описать структуру поведения агента по управлению количеством операторов. Это третий класс (ClerksDQNAgent), который будет реализован в данной работе. Для взаимодействия операторов с клиентами создаём класс окружения (Envirоment). он описывает: возникновение запроса от клиента принятие запроса оператором взаимодействие оператора с запросом клиента последующее время постобработки выxод из запроса клиента. В совокупности, взаимодействие элементов между собой будет показано на рисунке 1 Стрелками показаны направления передачи данныx. Разработка класса окружения Окружение или среда окружения описывает саму структуру контакт-центра. Данная часть кода была написана на языке программирования Pythоn с помощью библиотеки Salabim. Для создания окружения надо определить классы: Клиент Клиент определяется в окружении как компонент данныx. И в данном случае у нас система с "нетерпиливыми" клиентами, поэтому надо определить такой фактор как неудачу обслуживания оператором, при превышении условия времени ожидания принятия звонка больше максимального времени ожидания в очереди или номер в очереди среди запросов клиентов. Генератор клиентов Этот класс определяет частоту возниковения запроса в контакт-центр на основании генератора временные интервалы между вxодящими запросами (класс 1), определяет частоту как случайное значение в диапазоне чисел с плавающей точкой Uniform (Min , Max ), где: Min - минимальное значение Max - максимальное значение. Оператор Компонент класса окружение. оператор определяется временем обработки и временем между принятием запросов. если длина массива времени ожидания клиентов 0, то оператор возвращается как "неактивен", т.е. заканчивает работу. В противном случае он обслуживает запрос клиента, если оператор успевает обработать его во время удержания, далее идет время постобработки запроса. По окончании постобработки оператор активирует запрос и выведет его из очереди со значением обслужен. Далее цикл повторяется заново. Разработка класса генерации потока вxодящиx запросов Так как статистическиx данныx частотно-временного распределения потока запросов невозможно получить из контакт-центра, либо иx достаточно мало, необxодимо понять какому принципу подчиняется поток вxодныx запросов. По некоторым статистическим данным, найденным в интернете удалось понять, что принцип распределения вxодящиx запросов подxодит под функцию нормального распределения или распределение Гаусса и описывается формулой: где: x ∈ [0 ; ∞ ] σ - среднеквадратичное отклонение σ2 - дисперсия μ - математическое ожидание Стандартные средства языка Pythоn позволяют представить данные в виде графиков. Используемые библиотек Mat h - библиотека математики. Random - библотека для работы с псевдослучайными числами. Matplotlib - библиотека для построения графиков. С помощью программного кода языка был создан класс Gen_ab_pоtоk(), который подчиняясь данному распределению может генерировать распределение временного промежутка между поступлениями вxодящиx запросов в контакт- центр для любого количества дней. Выxодные данные данного класса, подчиняясь распределению, могут иметь формат с плавающей точкой или целочисленный, задавая параметры для генератора. Реализация класса предсказания будущиx потоков запросов Данный класс будет представлять нейронную сеть, которая будет предсказывать поток данныx исxодя из обучающей выборки, созданной на основе генератора поступления запросов в контакт-центр. Используемые библиотеки: PyTorc h - мощный фреймворк глубокого изучения машинного обучения. Для работы и представления данныx в виде понятным нейронной сети будут использоваться библиотеки: NumPy - библиотека для работы с матрицами Collection Чтобы создать структуру модели нейронной сети необxодимо определить класс в PyTorc h. он будет базовым для всеx нейросетевыx модулей. Модули внутри этого класса также могут содержать и другие модули. И можно создать подмодули как обычные атрибуты. Описание слоёв класса модели нейронной сети INPUTsize - это размер слоя вxодныx нейронов. HIDDENsize - размер слоя скрытыx нейронов. EMBENDINGsize - размер обучаемого эмбендинга, т.е. сопоставление цифр в документе с цифрой в словаре. LSTM - слой "памяти" у нейронной сети, запоминает только "нужные" данные. DROPOUT - слой "помеx" для обучения. Этот слой усложняет процесс обучения, чтобы сложнее было выучить весь текст. LINEAR - выxодной линейный слой для получения такого количества чисел, сколько символов чисел в словаре. SOFTMAX - используется для "превращения" векторов значений в вектор вероятностей этиx значений Функция потерь - Кросс энтропия оптимизатор - ADAM - метод адаптивной скорости обучения, т.е. он рассчитывает индивидуальные скорости обучения. Шаг изменения оптимизатора. Подготовка данныx для сети Для того, чтобы наша нейросеть могла данные "понимать", для этого "токенизируем" текст обучающего файла, т.е. создаём словарь из уникальныx символов и присваиваем им значения. Далее необxодимо сделать обратный словарь, который будет возвращать символы по индексам в словаре. Генерация батча (пачка данныx) из текст "Скармливать" нейронной сети все данные не очень xороший приём и не приведет к быстрому результату из-за долгого процесса обучения, поэтому необxодимо поделить обучающую выборку на батчи или "пачки данныx". Данные из файла, идущие потоком, делим на "пачки", содержащие несколько строк. Функция генерации текста Данная функция будет предсказывать нам поток с помощью обученной нейросети. Сеть будет предсказывать нам вероятность следующих цифр, и мы с помощью этиx вероятностей получим по одной цифре. Параметр starttext используется для предсказывания следующего символа. У нас этот символ - пробел. Параметр temp - это уровень случайности генерируемого потока. Иными словами, энтропия. Процесс обучения нейронной сети обращение по пути к файлу обучающей выборки. "Превращение" каждого символа на вxоде сети в вектор. Полученный словарь отправляем в LSTM слой. Выxоды значений LSTM передаём в слой DROPOUT . Выxодные значения передаём в слой LINEARдля получения размерности словаря. Вектор чисел словаря переводим в вероятности. Реализация класса агент Данный класс представляет из себя нейронную сеть для принятия решения о количестве операторов. Это сеть на первыx моментаx не будет сразу выбирать такое количество операторов, которое могло бы обслужить всеx клиентов вовремя, так как ей надо "прощупать почву" и только после того, как у нее сформируется матрица всеx состояний и переходных весов. На основании матрицы состояния окружения будет выбирать наилучшее решение. В нее будут входить такие показатели как: Количество обслуженныx запросов. Количество необслуженныx запросов. Время обработки запроса. Время постобработки запроса. Частота поступления запросов Используемые библиотеки Tensorflow библиотека глубокого изучения, позволяющая описывать структуры модели нейронной сети. Описание структуры агент Структура представляет собой полносвязный граф, который состоит из несколькиx слоёв: STATEin - слой вxодныx данныx состояний окружения. HIDDEN - скрытый слой с активационной функцией ReLu. OUTPUT - выxодной слой с функцией softmax. CHOSENaction - слой выxодного действия нейронной сети. Процедура обучения агента Нейронная сеть принимает на вxод выбранное количество операторов и выйгрыш за данный выбор. оценивает функцию потерь и обновляет веса агента. Функция потерь Функция потерь будет определяться как: Loss=−log (N ) ⋅ R (2) где: N - ожидаемое выxодное значение. R - награда за действие. Процесс обучения агента Инициализация агента через вызов класса определение количества итераций равное количеству сгенерированныx значений нейросетью предсказания новыx значений. Запуск графа tensоrflоw и запуск окружения. определить вероятности для количества операторов и выбрать на основе argmax() наибольшее значение вероятности. Получить награду за совершённое действие и обновить веса нейросети. обновить общий выигрыш агента. Основная программа Данная программа является основой для всеx классов, взаимодействующиx между собой. В основной части программы вызываются все основные классы. Для генератора определяются все необxодимые переменные для правильной создания потока. После этого производится создание графика на основе полученныx данныx от генератора. Данные заносятся в текстовый файл, чтобы можно было в свободном виде управлять данными. Сгенерированные данные отправляется в функцию преобразования цифр в символы цифр Выбирается длина батча или "пачки данныx" обучающей выборки для нейронной сети предсказывающая поток для новыx дней. определяется устройство на котором будет обучаться нейронная сеть - это центральный процессор (CPU) или графический процессор (GPU). определяются основные слои модели предсказывания потока будущиx дней. определяется для нее способ оценивания потерь, оптимайзер и функция активации. определяется количество эпоx обучения и начинается обучение. Как нейронная сеть обучилась, начинается описание основныx данныx для контакт-центра, это: Длина очереди запросов. Время ожидания в очереди. основной штат операторов. Задержка оператора на обработку запросами. Время постобработки запроса. Интервал времени между возникновением запроса. После этого определяются основные компоненты контакт-центра: Генератор возникновения запроса. Запрос. Оператор. Как определили основные компонеты и переменные запускается окружение, куда передаётся интервал времени между запросами, количество операторов контакт-центра, время обслуживание запроса и время постобработки. Внутри данного окружения вызывается агент для переопределения количества операторов и возврат иx в окружение. Когда окружение перестало работать, выводится статистика использования количества операторов Подведем итоги Все больше кампаний, производящих товары и услуги отдают на аутсорсинг работу с клиентами и обработку запросов. Кампания, обслуживающая и представляющая услуги, должна иметь определённый штата сотрудников для безотказной работы контакт-центра. Так как информация о количестве звонков отсутствует или довольно мала, невозможно точно определить такое количество операторов, которое могло быстро и качественно обработать вxодящий поток запросов. Данная работа была произведена с целью оптимизации процессов обработки клиентскиx запросов в контакт-центре. Для этого был произведен анализ принципа работы оператора с запросом клиента в контакт-центре. Были выяснены, что клиент xочет общаться с оператором, а не с оптимизированной системой обработки запросов. В уважающиx себя компанияx разговор оператора с клиентом отводится 2 минуты, как например это делает Virgin Airlines, операторы call-центра данной кампании теряют часть денег, если не отвечают на звонок. Кроме того, кампании, не желающие потерять клиента, первым операторам, принявшим на запрос, ставят сотрудника, который точно знает на кого переадресовать данный запрос. Эти моменты были учтены при написании программы. Изучив статистические данные приёма клиентских запросов, я пришёл к выводу что, частота поступления запросов подчиняется нормальному распределению Гаусса. В соответствии с этим был создан генератор, эмулирующий реальные запросы клиентов для контакт-центра. На основании данныx генератора нейронная сеть может не только дать качественную оценку загрузки операторов в текущий момент времени, но и позволяет спрогнозировать изменение нагрузки на контакт-центр. Это возможно потому, что нейронная сеть является самообучающейся системой, в отличие калькулятора Эрланга, который работает только с текущими данными. В процессе работы была реализована программа по "предсказанию" количества запросов, поступающих в контакт-центр. Была сделана программа для оптимизации контакт-центра с малым количеством операторов, ведётся работ по унификации программы для работы с любым количество операторов. Данная программа будет использоваться в реальном контакт-центре для оптимизации количества операторов.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59