Опубликован: 28.09.2007 | Уровень: специалист | Доступ: платный
Лекция 11:

Передача данных с коммутацией по меткам

Правила, зависящие от IP

Мы определяем поле IP TTL равным величине поля IPv4 TTL или значению поля IPv6 Hop Limit, в зависимости от того, что используется.

Когда IP-пакет помечен впервые, поле TTL в стеке должно быть установлено равным значению поля IP TTL.

Когда все метки извлекаются из стека и он оказывается пустым, значение поля IP TTL должно быть замещено величиной выходного TTL, как это определено выше. В случае IPv4 это потребует также корректировки контрольной суммы IP-заголовка.

Признается, что могут существовать ситуации, когда сетевая администрация предпочитает декрементировать IPv4 TTL на 1 при прохождении через домен MPLS, вместо того чтобы декрементировать IPv4 TTL на число LSR в домене.

Преобразование различных инкапсуляций

Иногда LSR может получить помеченный пакет через, например, интерфейс ATM (LC-ATM) [11.9] и должен послать его через PPP или LAN. Тогда входной пакет будет получен без инкапсуляции, а должен будет послан уже с применением такой инкапсуляции.

В этом случае значение входного TTL определяется процедурами обработки помеченных пакетов, например, в интерфейсе LC-ATM. Обработка TTL будет тогда происходить так, как это описано выше. Иногда LSR может получить помеченный пакет через канал PPP или LAN и должен его послать на выход через интерфейс LC-ATM. Тогда входной пакет будет принят с использованием инкапсуляции, описанной в данном документе, а выходной пакет — послан с привлечением иной инкапсуляции. В этом случае процедура формирования значения выходного TTL определяется процедурами, применяемыми к помеченным пакетам, например, в интерфейсах LC-ATM.

Фрагментация и определение MTU пути

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

Возможно также, что полученный пакет (помеченный или нет), который первоначально был достаточно мал для передачи через канал, становится слишком большим, получив одну или более меток.

При коммутации меток пакет может расти в размере, если в его стек заносятся дополнительные метки. Таким образом, если получен помеченный пакет с 1500-байтовым полем данных и в него записана дополнительная метка, переадресовать нужно будет пакет с размером 1504-байта, что может привести, в конце концов, к превышению MTU для сети Ethernet.

В этом разделе специфицируются правила обработки помеченных пакетов, которые являются слишком большими. В частности, речь идет о правилах, которые гарантируют, что ЭВМ, использующие определение MTU пути [11.4], и ЭВМ, работающие с IPv6 [11.7,11.8], будут способны формировать IP-дейтограммы, которые не нуждаются в фрагментации, даже если эти дейтограммы получили дополнительные метки при прохождении через сеть.

Вообще, ЭВМ IPv4, которые не используют определение MTU пути [11.4], посылают IP-дейтограммы, содержащие не более 576 байт. Так как большинство используемых MTU равняются 1500 байт или больше, вероятность того, что такие дейтограммы будут нуждаться в фрагментации, даже если они помечены, весьма мала.

Некоторые ЭВМ, которые не используют определение MTU пути [11.4], формируют IP-дейтограммы, содержащие 1500 байт. Поскольку IP-адреса отправителя и получателя находятся в одной и той же субсети, эти дейтограммы не проходят через маршрутизаторы и, следовательно, не будут фрагментироваться

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

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

Что касается конкретного канала данных, можно использовать следующие термины:

  • Поле данных кадра

    В это понятие входит содержимое поля данных кадра, исключая любые заголовки и поля завершения кадра (например, MAC-заголовки, LLC-заголовки, 802.1Q-заголовки, PPP-заголовки, контрольные суммы и т.д.).

    Когда кадр несет в себе непомеченную IP-дейтограмму, поле данных кадра представляет собой саму IP-дейтограмму. Когда кадр несет в себе помеченную IP-дейтограмму, поле данных кадра состоит из записей стека меток и IP-дейтограммы.

  • Обычный максимальный размер поля данных кадра

    Максимальный размер поля данных кадра определяется стандартами канала данных. Например, обычный максимальный размер поля данных кадра для Ethernet равен 1500 байтов.

  • Истинный максимальный размер поля данных кадра

    Максимальный размер поля данных кадра, который можно послать и получить через интерфейс канала данных.

    Для сетей Ethernet и 802.3, считается, что истинный максимальный размер поля данных кадра на 4-8 байта больше обычного максимального размера поля данных (поскольку ни переключатель, ни бридж не могут увеличить размер заголовка в процессе транспортировки пакета до следующего узла сети). Например, считается, что большинство оборудования Ethernet может принимать и посылать пакеты, содержащие, по крайней мере, 1504 или даже 1508 байт, поскольку заголовок Ethernet не имеет полей 802.1Q или 802.1p. В каналах PPP, истинный максимальный размер поля данных кадра может быть неограниченным.

  • Эффективный максимальный размер поля данных для помеченных кадров

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

  • Первично помеченная IP-дейтограмма

    Предположим, что непомеченная IP-дейтограмма получена конкретным LSR и что LSR вводит метку в стек перед тем, как переадресовать эту дейтограмму. Такая дейтограмма будет называться первично помеченной в этом LSR IP-дейтограммой.

Максимальный исходный размер помеченной IP-дейтограммы

Каждый LSR, который способен

  1. получать непомеченные IP-дейтограммы,
  2. добавлять метки в стек дейтограммы, и
  3. переадресовывать полученный в результате помеченный пакет, должен поддерживать конфигурационный параметр, называемый максимальный размер первично помеченной IP-дейтограммы, который должен быть установлен неотрицательным. Если этот конфигурационный параметр установлен равным нулю, он ни на что не влияет. Если он имеет положительное значение, то он используется следующим образом. Если:
  1. получена непомеченная IP-дейтограмма, и
  2. эта дейтограмма имеет в заголовке бит DF=0, и
  3. дейтограмма перед переадресацией должна быть помечена, и
  4. размер дейтограммы (до пометки) превышает значение данного параметра, тогда:
    1. дейтограмма должна быть разделена на фрагменты с размером не больше, чем указано в данном параметре, и
    2. каждый фрагмент должен быть помечен и после этого переадресован.

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

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

Заметим, что установка этого параметра не влияет на обработку IP-дейтограмм, которые содержат бит DF=1, следовательно, установка этого параметра не влияет на результат определения MTU пути.

Когда помеченная IP-дейтограмма слишком велика?

Помеченная IP-дейтограмма, чей размер превышает обычный максимальный размер поля данных канала, может рассматриваться как слишком большая.

Помеченная IP-дейтограмма, чей размер превышает истинный максимальный размер поля данных кадра канала, через который она должна переадресоваться, считается слишком большой.

Помеченная IP-дейтограмма, которая не является слишком большой, должна передаваться без фрагментации.

Обработка помеченных дейтограмм IPv4, которые слишком длинны

Если помеченная IPv4 дейтограмма слишком велика и бит DF в IP заголовке =1, тогда LSR может отбросить дейтограмму.

Заметим, что отбрасывание таких дейтограмм является разумным, только если максимальный размер первично помеченной IP-дейтограммы установлен равным ненулевому значению во всех LSR сети, способных добавлять метки в стек непомеченных IP-дейтограмм.

Если LSR решает не отбрасывать помеченные IPv4-дейтограммы, которые слишком велики, или если в дейтограмме флаг DF=1, тогда должна быть выполнена следующая последовательность операций.

  1. Удалить записи из стека, чтобы получить IP-дейтограмму.
  2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).
  3. Если IP-дейтограмма содержит в IP заголовке бит Don't Fragment=0:
    • разбить ее на фрагменты, каждый из которых должен иметь размер, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля данных кадра;
    • преобразовать каждый фрагмент, снабдив его заголовком, который имела исходная дейтограмма;
    • переадресовать фрагменты.
  4. Если IP-дейтограмма содержит в IP заголовке бит Don't Fragment =1:
    • дейтограмма не должна переадресовываться;
    • сформировать ICMP-сообщение "Адресат недостижим":
      • установить значение поля [11.3] равным "Fragmentation Required and DF Set";
      • установить значение поля NextHop MTU [11.4] равным разности между эффективным максимальным размером поля данных кадра и величиной N.
    • если возможно, послать ICMP-сообщение "Адресат недостижим" отправителю отброшенной дейтограммы.
Обработка помеченных дейтограмм IPv6, которые слишком длинны

Чтобы обработать помеченную IPv6-дейтограмму, которая слишком велика, LSR должен реализовать следующий алгоритм.

  1. Удалить записи из стека, чтобы получить IP-дейтограмму.
  2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).
  3. Если IP-дейтограмма содержит более 1280 байтов (не считая записи стека меток), или, если она не содержит заголовка фрагмента, тогда:
    • сформировать ICMP-сообщение "Too Big Message", и установить значение поля NextHop MTU равным разности между эффективным максимальным размером поля данных кадра и величиной N;
    • если возможно, послать отправителю дейтограммы ICMP-сообщение "Too Big Message";
    • отбросить помеченную IPv6-дейтограмму.
  4. Если IP-дейтограмма не длиннее 1280 октетов, и содержит заголовок фрагмента, тогда:
    • преобразовать ее в фрагменты, каждый из которых должен быть по крайней на N байт меньше, чем эффективный максимальный размер поля данных кадра;
    • снабдить каждый фрагмент тем же помеченным заголовком, который имела исходная дейтограмма;
    • переадресовать фрагменты.

Восстановление сообщения из фрагментов осуществляется конечным получателем.

Реализация с учетом определения MTU пути

Описанные выше процедуры обработки дейтограмм, которые имеют в заголовке бит DF=1, но являются слишком большими, связаны с процедурами определения MTU пути RFC-1191 [11.4]. ЭВМ, которые применяют эти процедуры, определят MTU, который достаточно мал, чтобы позволить занесение в дейтограмму n меток, без необходимости фрагментации. Здесь n равно числу меток, заносимых на используемом пути через домен.

Другими словами, дейтограммы от ЭВМ, которые применяют определение MTU пути, никогда не потребуют фрагментации из-за занесения меток в заголовок. Заметим, что дейтограммы от ЭВМ, использующих определение MTU пути, имеют бит DF=1 и, таким образом, не могут быть фрагментированы в любом случае.

Отметим также, что определение MTU пути будет работать корректно, только если в точке, где может потребоваться фрагментация помеченной IP-дейтограммы, возможна доставка отправителю ICMP сообщения Destination Unreachable. Если невозможна посылка ICMP-сообщения отправителю из MPLS туннеля, но конфигурация сети предоставляет возможность LSR конца туннеля получать пакеты, которые должны проходить через туннель, но слишком велики для этого, тогда:

  • LSR на передающем конце туннеля должен уметь определять MTU туннеля в целом. Он может это сделать путем посылки пакетов через туннель в направлении его приемной части, выполняя процедуру определения MTU пути для этих пакетов;
  • всякий раз, когда передающий конец туннеля должен посылать пакет в туннель и этот пакет имеет DF=1, а его длина превышает значение MTU туннеля, передающий конец должен послать ICMP-сообщение Destination Unreachable узлу, приславшему пакет с кодом "Fragmentation Required and DF Set" и полем NextHop MTU, установленным так, как было показано выше.
Передача помеченных пакетов через PPP

Протокол PPP (Point-toPoint Protocol) [11.6] предоставляет стандартный метод транспортировки многопротокольных дейтограмм через каналы точка-точка. PPP определяет расширяемый протокол управления каналом и предлагает семейство протоколов управления сетью для установления и конфигурации различных протоколов сетевого уровня.

В этом разделе определен протокол управления сетью для установления и конфигурации коммутации меток в канале PPP. PPP содержит три основные компонента.

  1. Метод инкапсуляции мультипротокольных дейтограмм.
  2. Протокол управления каналом LCP (Link Control Protocol) для установления, конфигурирования и тестирования канала.
  3. Семейство протоколов управления сетью для установления и конфигурирования различных протоколов сетевого уровня.

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

Протокол управления PPP для MPLS

Протокол управления MPLS (MPLSCP) отвечает за разрешение/запрещение использования коммутации меток в канале PPP. Он использует тот же механизм обмена, что и протокол управления каналом LCP (Link Control Protocol). Пакеты MPLSCP не могут пересылаться до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Пакеты MPLSCP, полученные до достижения этой фазы, должны просто отбрасываться.

Протокол управления MPLS тождественен протоколу управления каналом [11.6] за следующими исключениями:

  1. Модификации кадра

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

  2. Поле протокола канального уровня

    В информационное поле пакета PPP вкладывается только один пакет MPLSCP, где поле протокола PPP содержит шестнадцатеричный код 8281 (MPLS).

  3. Поле кода

    Используются только коды от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Прочие коды должны рассматриваться как нераспознанные и приводить к Code-Rejects (отбрасыванию).

  4. Тайм-ауты

    Пакеты MPLSCP не могут пересылаться, пока PPP не достигнет фазы протокола сетевого уровня. Реализация должна быть готова ждать окончания аутентификации и определения качества канала, прежде чем наступит тайм-аут в ожидании Configure-Ack или других откликов.

Посылка помеченных пакетов

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

В информационное поле пакета PPP вкладывается только один помеченный пакет, где поле протокола PPP содержит шестнадцатеричные значения кода тип 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальная длина помеченного пакета, переданного через канал PPP, та же, что и максимальная длина информационного поля инкапсулированного пакета PPP.

Заметим, что определены два кода для помеченных пакетов, один для мультикастных и один для уникастных. Как только MPLSCP переходит в рабочее состояние (Opened), по каналу PPP могут посылаться как мультикаст, так и уникаст-пакеты.

Пересылка помеченных пакетов в среде LAN

В каждом кадре транспортируется только один помеченный пакет. Записи стека меток размещаются непосредственно после заголовка сетевого уровня, а сразу за ними следует заголовок канального уровня, включая, например, любые заголовки 802.1Q, которые только могут существовать.

Шестнадцатеричный код Ethertype 8847 применяется для индикации того, что кадр содержит уникастный MPLS-пакет. Шестнадцатеричный код Ethertype 8848 служит для указания того, что кадр содержит MPLS-пакет.

Эти значения Ethertype могут быть использованы либо при Ethernet-инкапсуляции, либо при инкапсуляции 802.3 LLC/SNAP для транспортировки помеченных пакетов.

11.6. Требования для управления трафиком

Введение

Мультипротокольная коммутация пакетов по меткам (MPLS) [11.1,[11.2] интегрирует в себе технику операций с метками и сетевую маршрутизацию. Базовой идеей является присвоение меток фиксированной длины пакетам на входе облака MPLS (базирующегося на концепции переадресации классов эквивалентности [11.1,[11.2]). Всюду внутри домена MPLS метки, присвоенные пакету, используются для принятия решения о переадресации (обычно без рассмотрения исходных заголовков пакета).

Одним из наиболее важных применений MPLS будет управление трафиком. Важность этого приложения является уже широко признанной (смотри [11.1,2,3]).

Далее рассматриваются требования управления трафиком в больших опорных сетях Интернет. Описаны базовые возможности и функциональности, которым должна соответствовать реализация MPLS.

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

Предлагается архитектура, которая включает в себя MPLS и RSVP, чтобы предоставить масштабируемые дифференцированные услуги и управление трафиком в Интернет.

Управление трафиком

В этом разделе описываются базовые функции управления трафиком в автономной системе современного Интернет. Рассмотрены ограничения IGP с точки зрения управления трафиком и ресурсами.

Управление трафиком (TE) связано с оптимизацией рабочих характеристик сетей. Вообще, ТЕ включает в себя технологию и научные принципы измерения, моделирования, описание, управление трафиком Интернет и приложение таких знаний и техники для получения определенных рабочих характеристик.

Главной целью управления трафиком в Интернет является достижение эффективной и надежной работы сети. Управление трафиком стало непременной функцией многих автономных систем — из-за высокой стоимости услуг Интернет.

Объективные характеристики управления трафиком

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

  1. ориентированные на трафик, или
  2. ориентированные на ресурсы.

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

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

  1. сетевых ресурсов недостаточно или они не соответствуют существующей загрузке;
  2. потоки трафика неэффективно распределены по имеющимся ресурсам.

Первый тип проблем перегрузки может быть решен путем:

  • расширения ресурса, или
  • применением классических средств управления перегрузкой, или
  • сочетанием этих подходов. Классическое управление перегрузкой пытается регулировать уровень потребности, снижая его до имеющегося в распоряжении уровня ресурсов. Классическое управление перегрузкой включает в себя: ограничение потока, управление шириной окна для потока, управление очередями в маршрутизаторе, диспетчеризацию и т.д. (смотри [11.8]).

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

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

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

Управление трафиком и ресурсами

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

  1. модификацию параметров управления трафиком,
  2. модификацию параметров, связанных с маршрутизацией, и
  3. модификацию атрибутов и констант, связанных с ресурсами.

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

Ограничения механизмов управления IGP

В этом подразделе рассматриваются некоторые хорошо известные ограничения современных IGP с точки зрения управления трафиком.

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

  1. кратчайшие пути нескольких потоков трафика объединяются в каких-то каналах или интерфейсах маршрутизатора, или
  2. данный трафик потока маршрутизирован через канал или интерфейс маршрутизатора, который не имеет достаточной полосы пропускания.

Эти сценарии проявляются даже тогда, когда имеются альтернативные маршруты с избытком ресурсов. Именно этого аспекта проблем перегрузки (симптом неоптимального распределения ресурсов) управление трафиком стремится всеми способами избежать. Равномерное распределение загрузки может использоваться для разрешения второй проблемы, упомянутой выше, однако такое решение бесполезно в случае первого варианта перегрузки.

Популярным подходом преодоления недостатков современных IGP является использование модели наложений, таких, как IP поверх ATM или IP поверх Frame Relay. Модель наложений расширяет пространство для маневра, делая возможным произвольные виртуальные топологии, накладываемые поверх реальной физической сети. Виртуальная топология формируется из виртуальных каналов, которые проявляются как физические каналы в протоколах маршрутизации IGP. Модель наложений предоставляет дополнительные важные услуги для поддержания управления трафиком и ресурсами, включая: (1) маршрутизацию, базирующуюся на ограничениях в рамках VC, (2) поддержку административно конфигурируемых VC-путей, (3) сжатие маршрута, (4) функции управления доступом, (5) формирование трафика и функции реализации политики при управлении трафиком, и (6) надзор за VC. Эти возможности допускают реализацию самых разных политик в сфере управления трафиком. Например, виртуальные каналы могут легко перемаршрутизироваться, чтобы перенаправить трафик в менее загру женные каналы.

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

Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Мария Архипова
Мария Архипова
виктор виноградов
виктор виноградов
Россия, Курская область
Евгений Миловзоров
Евгений Миловзоров
Россия, Пенза, ПГУ, 2004