Голосовая связь : Передача голоса по Frame Relay (VoFR)

Разработка и развертывание многоканальных систем PPP over Frame Relay и ATM

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Протокол PPP по ATM и Протокол PPP по Frame Relay (MLPoATM и MLPoFR) были представлены в Cisco Выпуск ПО IOS� 12.1 (5) T. Эта функция предназначена для клиентов со Взаимодействием между сетями Frame Relay и ATM (IW FR/ATM), которые развертывают Передачу голоса по IP (VoIP) через чередующуюся от среднего до низкого скорость каналы WAN. До этой функции не было никакой общей схемы фрагментации Уровня 2, которая поддерживалась Cisco IOS и на ATM и на клиентах Frame Relay с IW FR/ATM, были вынуждены сделать фрагментацию Уровня 3.

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

Требования

Этот документ предназначен для специалистов по обслуживанию сети, вовлеченных в дизайн и развертывания Сетей VoIP, которые включают MLPoATM и Сети Frame Relay. Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Frame Relay

  • ATM

  • PPP

  • MLP

  • Взаимодействие между сетями Frame Relay и ATM

  • Качество голосовой связи сервиса (QoS) конфигурация

Этот документ не предназначен для обеспечения обучения технологии на этих предметах. В конце документа приведен список справочных материалов. Cisco рекомендует, чтобы вы рассмотрели и поняли эти документы до чтения этого документа:

Используемые компоненты

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

  • Программное обеспечение Cisco IOS версии 12.1(5)T или позже для MLP по IW FR/ATM

  • Программное обеспечение Cisco IOS версии 12.2(2)T или позже для Сжатого транспортного протокола реального времени (cRTP) по ATM

  • Программное обеспечение Cisco IOS версии 12.0(7)T для очередей с низкой задержкой (LLQ) по Frame Relay и ATM на физическом интерфейсе

  • Программное обеспечение Cisco IOS версии 12.1(2)T для LLQ по Frame Relay и атм на постоянную виртуальную цепь (PVC)

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

  • Базовые Маршрутизаторы Cisco 3660 выполняют Cisco IOS Software Release 12.2 (5.8) T. Требование для cRTP по ATM диктует использование Cisco IOS Software Release 12.2T. Эта известная неполадка решена в программном обеспечении Cisco IOS версии 12.2(8)T1:

    Когда ссылка/LLQ взвешенной организации очереди на основе классов (CBWFQ) достигает перегрузки, идентификатор ошибки Cisco CSCdw44216 (только зарегистрированные клиенты) - cRTP вызывает высокую загрузку CPU.

  • Маршрутизаторы Cisco 2620 ответвления находятся в процессе того, чтобы быть обновленным от программного обеспечения Cisco IOS версии 12.2(3) до 2.2 (6a). 2620-е Cisco также действуют как шлюзы H.323 ответвления. Обновление инициировано связанной со шлюзом проблемой. Насколько глобальная сеть (WAN) и Характеристики QoS затронуты, программное обеспечение Cisco IOS версии 12.2(3) не показывает значительных проблем.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Дизайн

В этом разделе рассматриваются несколько концепций проекта, отнесенных к дизайну и развертываниям Протокола PPP по Frame Relay и ATM.

Служебные данные канала данных

При разработке ATM и Сетей Frame Relay с MLP необходимо понять служебные данные канала передачи данных. Издержки влияют на величину пропускной способности, потребляемой каждым вызовом VoIP. Это также помогает определять оптимальный размер фрагмента MLP. Важно оптимизировать размер фрагмента для адаптации целому числу ячеек ATM, особенно на низкой скорости PVCs, где значительная часть пропускной способности потрачена впустую на заполнение ячеек. Служебные данные канала данных в MLP с Frame Relay и поддержкой ATM PVC зависят от следующих факторов:

  • Режим работы устройства FRF.8 IW (прозрачный либо транслирующий).

  • Направление трафика (ATM - Frame Relay или Frame Relay -ATM).

  • Участок постоянного виртуального канала. Служебные данные различаются для ветвей ATM и Frame Relay PVC.

  • Тип трафика. В отличие от пакетов VoIP, пакеты данных содержат заголовок MLP.

Эта таблица показывает служебные данные канала передачи данных для пакета данных. В ней содержится подробная информация о размере (в байтах) различных заголовков Frame Relay, ATM, LLC, PPP и MLP для всех вариантов режима работы FRF.8, направления трафика и ветви PVC.

Режим FRF.8 Прозрачный Трансляция
Направление трафика Frame Relay с ATM ATM с Frame Relay Frame Relay с ATM ATM с Frame Relay
Frame Relay или ветвь ATM в PVC Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay
                 
Флаг кадра (0x7e) 1 0 0 1 1 0 0 1
Заголовок Frame Relay 2 0 0 2 2 0 0 2
LLC DSAP/SSAP1 (0xfefe) 0 0 2 2 0 2 2 0
Управление LLC (0x03) 1 1 1 1 1 1 1 1
NLPID2 (0xcf для PPP) 1 1 1 1 1 1 1 1
Идентификатор протокола MLP (0x003d) 2 2 2 2 2 2 2 2
Порядковый номер протокола MLP 4 4 4 4 4 4 4 4
ID Протокола PPP (Только первый фрагмент) 2 2 2 2 2 2 2 2
Полезная нагрузка (уровень 3+) 0 0 0 0 0 0 0 0
5 уровень адаптации ATM (AAL) 0 8 8 0 0 8 8 0
Последовательность проверки кадров (FCS) 2 0 0 2 2 0 0 2
Всего служебных данных (байт) 15 18 20 17 15 20 20 15

1DSAP/SSAP — Точка доступа к сервису назначения / Точка доступа к исходному сервису.

2NLPID — Network Layer Protocol Identification.

Переводный PVC является самым легким постигать, поскольку издержки являются тем же в обоих направлениях. Это вызвано тем, что устройство FRF.8 преобразовывает между форматами MLPoFR и MLPoATM. В результате формат фрейма является MLPoFR на Участке Frame Relay в обоих направлениях. Формат на участке ATM является MLPoATM в обоих направлениях.

Прозрачный PVC немного более беспорядочный, так как служебные данные отличаются по двум направлениям. Эта сложность возникает, потому что Маршрутизатор Frame Relay передает пакеты в формате MLPoFR. Через этот формат несет устройство IW на сторону ATM. Точно так же маршрутизатор ATM передает пакеты в формате MLPoATM. Через этот формат несет устройство IW на Сторону Frame Relay. Таким образом, результат представляет собой различные форматы кадра в двух направлениях для каждого участка.

В сравнении издержки на PVC сквозного Frame Relay, который использует FRF.12, составляют 11 байтов. Поэтому на ссылке сквозного Frame Relay, FRF.12 является более эффективным выбором для фрагментации и чередования данных в канале (LFI), чем MLP. В виртуальных сетях ATM MLP - это единственный выбор, когда нет стандартной фрагментации. Однако сквозные VC ATM являются средними к высокой скорости. Поэтому LFI не требуется. Исключением из этого правила являются VC ATM низкой скорости по цифровой абонентской линии (DSL).

ИДЕНТИФИКАТОР PPP присутствует в первом фрагменте MLP только. Таким образом, сектор служебной информации первого фрагмента всегда на два байта больше, чем у последующих фрагментов.

Таблица здесь показывает служебные данные канала передачи данных для Пакета VoIP. В ней содержится подробная информация о размере в байтах различных заголовков Frame Relay, ATM, LLC и PPP для всех вариантов режима работы FRF.8, направления трафика и ветвей PVC. Основное различие между данными и Пакетом VoIP - то, что Пакеты VoIP передаются как пакеты PPP и не как пакеты MLP. Все другие аспекты идентичны сценарию данных.

Режим FRF.8 Прозрачный Трансляция Схема Frame Relay с Frame Relay
Направление трафика Frame Relay с ATM ATM с Frame Relay Frame Relay с ATM ATM с Frame Relay  
Frame Relay или ветвь ATM в PVC Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay  
                   
Флаг кадра (0x7e) 1 0 0 1 1 0 0 1 1
Заголовок Frame Relay 2 0 0 2 2 0 0 2 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0 0
Управление LLC (0x03) 1 1 1 1 1 1 1 1 1
Идентификатор протокола сетевого уровня NLPID (0xcf для PPP) 1 1 1 1 1 1 1 1 1
Идентификатор PPP 2 2 2 2 2 2 2 2 0
Полезная нагрузка (IP+протокол дейтаграммы пользователя (UDP)+RTP+голос) 0 0 0 0 0 0 0 0 0
AAL5 0 8 8 0 0 8 8 0 0
FCS 2 0 0 2 2 0 0 2 2
Всего служебных данных (байт) 9 12 14 11 9 14 14 9 7

В сравнении служебные данные канала передачи данных для Пакета VoIP на PVC сквозного Frame Relay показывают в крайнем справа столбце.

Требования VoIP к пропускной способности

При инициализации пропускной способности для VoIP служебные данные канала передачи данных должны быть включены в расчеты полосы пропускания. Эта таблица показывает на требования пропускной способности вызова для различных разновидностей VoIP. Это основывается на характеристиках PVC. Вычисления в этой таблице принимают лучший случай для cRTP (например, никакая контрольная сумма UDP и никакие ошибки трансляции.) Заголовки тогда последовательно сжимаются от 40 байтов до 2 байтов.

Режим FRF.8 Прозрачный Трансляция Схема Frame Relay с Frame Relay
Направление трафика Frame Relay с ATM ATM с Frame Relay Frame Relay с ATM ATM с Frame Relay  
Frame Relay или ветвь ATM в PVC Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay  
                   
G.729 - Выборки на 20 мс - Никакой cRTP 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G.729 - Выборки на 20 мс - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G.729 - Выборки на 30 мс - Никакой cRTP 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G.729 - Выборки на 30 мс - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G.711 - Выборки на 20 мс - Никакой cRTP 83.6 106.0 106.0 84.4 83.6 106.0 106.0 83.6 82.8
G711 - 20 мс Примеры - cRTP 68.4 84.8 84.8 69.2 68.4 84.8 84.8 68.4 67.6
G711 – сэмплы 30 мс – без cRTP 76.3 97.9 97.9 76.8 76.3 97.9 97.9 76.3 75.8
G.711 - Выборки на 30 мс - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

Вследствие того, что служебные данные отличаются на разных участках PVC, необходимо разработать самый неблагоприятный сценарий. Например, считайте G.729 с 20 миллисекундами (msec) выборкой и cRTP через прозрачный PVC. В этом сценарии требования к пропускной способности на участке Frame Relay составляют 12,4 Кбит/с в одном направлении и 13,2 Кбит/с в другом. Инициализация потребностей, которые будут сделаны с предположением 13.2 кбит/с за вызов.

В сравнении Требования VoIP к пропускной способности на PVC сквозного Frame Relay также показывают в крайнем справа столбце вышеупомянутой таблицы. Дополнительные служебные данные протокола РРР, которые сравниваются с собственной инкапсуляцией Frame Relay, требуют дополнительной полосы пропускания от 0,5 до 0,8 кбит/с на один вызов. Поэтому Инкапсуляция Frame Relay с FRF.12 имеет больше смысла, чем MLP на VC сквозного Frame Relay.

Примечание: cRTP по ATM требует программного обеспечения Cisco IOS версии 12.2(2)T или позже.

Оптимизируйте размер фрагментации

Причина использовать MLP на Frame Relay / ПОСТОЯННЫЙ ВИРТУАЛЬНЫЙ КАНАЛ ATM состоит в том, чтобы обеспечить большие пакеты данных, которые будут фрагментированы в меньшие блоки. Маршрутизатор тогда ускоряет Пакеты VoIP путем чередования их промежуточный фрагменты данных. В Cisco IOS размер фрагментации не настроен непосредственно. Вместо этого необходимая задержка настроена с помощью команды ppp multilink fragment-delay . Cisco IOS тогда использует эту формулу для вычисления соответствующего размера фрагмента:

fragment size = delay x bandwidth/8

Когда вы делаете MLP через ATM, размер фрагмента должен быть оптимизирован так, чтобы это вписалось в целое число ячеек. Если эта оптимизация не сделана, требуемая пропускная способность может почти удвоиться из-за заполнения. Например, если каждый фрагмент 49 байтов длиной, две ячейки ATM требуются, чтобы нести каждый фрагмент. Поэтому 106 байтов используются для переноса информационного наполнения только 49 байтов.

Cisco IOS автоматически оптимизирует размер фрагмента для использования целого числа ячеек ATM, когда это выполняет MLPoATM и MLPoFR. Cisco IOS автоматически окружает расчетный размер фрагмента к следующему целому числу ячеек ATM. Никакие новые команды CLI не добавлены. Cisco IOS выполняет эту оптимизацию и на Frame Relay и на концах ATM MLPOFR/ПОСТОЯННОГО ВИРТУАЛЬНОГО КАНАЛА ATM. Возможно, что PVC MLP может быть сквозным Frame Relay. В этом случае оптимизация его для ATM не требуется. Однако Cisco IOS оптимизирует этот сценарий для ATM, так как это не имеет никакого способа обнаружить, является ли удаленный конец ATM или Frame Relay.

Примечание: Из-за округления, задержка, которая результаты могут быть немного выше, чем настроенный. Эта ошибка округления является более значительной на низкоскоростном PVCs.

Можно также настроить оптимизацию вручную. Так как размер фрагмента не может быть задан непосредственно в Cisco IOS, вычислить оптимальный размер фрагмента и преобразовывать его в задержку. Когда вы вычисляете размер фрагмента, отрегулировали для служебных данных канала передачи данных, поскольку код MLP предполагает, что каждая ссылка является High-Level Data Link Control (HDLC) и имеет 2 байта служебных данных канала передачи данных. Кроме служебных данных канала данных HDLC, код MLP включает в своих расчетах 8 байтов для идентификатора протокола MLP, порядкового номера протокола MLP и идентификатора PPP, как указано в первой таблице выше.

Используйте эту процедуру для вычисления задержки, которая будет настроена в Cisco IOS:

  1. Вычислите теоретический размер фрагмента на основе необходимой задержки и пропускной способности PVC:

    fragment = bandwidth * delay / 8
  2. Убедитесь, что фрагмент кратен 48 байтам, чтобы он соответствовал целому числу ячеек ATM.

    Формула для вычисления размера фрагмента выровненного по ячейке:

    fragment_aligned = (int(fragment/48)+1)*48
  3. Выполните настройку для служебных данных канала передачи, которые не учитываются MLP.

    Как замечено ранее, эти издержки отличаются на основе характеристик PVC. Рассмотрите сторону ATM PVC, поскольку это - сторона, для которой вы оптимизируете. Эта таблица показывает количество байтов служебных данных канала передачи данных на стороне ATM.

    Режим FRF.8 Прозрачный Трансляция
    Направление трафика Frame Relay с ATM ATM с Frame Relay Frame Relay с ATM ATM с Frame Relay
    Frame Relay или ветвь ATM в PVC ATM ATM ATM ATM
             
    LLC DSAP/SSAP (0xfefe) 0 2 2 2
    Управление LLC (0x03) 1 1 1 1
    Идентификатор протокола сетевого уровня NLPID (0xcf для PPP) 1 1 1 1
    AAL5 8 8 8 8
             
    Не MLP служебных данных (байт) 10 12 12 12

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

    Формула для вычисления размера фрагмента, для которого предназначается код MLP:

    fragment_mlp = fragment_aligned - datalink_overhead + 2
  4. Преобразуйте размер фрагмента, который заканчивается в соответствующую задержку с этой формулой:

    delay = fragment_mlp/bandwidth x 8bits/byte
  5. В большинстве случаев вычисленная задержка не является целым числом миллисекунд. Поскольку Cisco IOS принимает только целочисленные значения, требуется округление с понижением. Поэтому значение задержки, которое вы настраиваете в Cisco IOS с помощью команды ppp multilink fragment-delay:

    fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)
  6. Для компенсации вышеупомянутую ошибку округления уклонитесь от пропускной способности, используемой MLP для преобразования от задержки до фрагмента. Пропускная способность, от которой уклоняются, которую вы настраиваете в Cisco IOS с помощью команды bandwidth:

    bandwidth = fragment_mlp/fragment_delay * 8

Эта таблица показывает оптимальные значения ppp multilink fragment delay и пропускной способности для наиболее распространенных скоростей PVC. Принимается конечная задержка в 10 мсек. Для упрощения таблицы вычисления не дифференцируются между прозрачным и переводным PVC, или между направлениями трафика. Максимальная разница в служебных данных канала составляет только 2 байта. Следовательно, потери в самом худшем случае с 12 байтами невелики. Также показанный в таблице "реальная" задержка, с которой встречаются вследствие того, что вы увеличиваете размер фрагмента так, чтобы фрагменты вписались в целое число ячеек.

Скорость PVC Fragment size ppp многоканальная задержка фрагмента Bandwidth Реальная задержка
(Кбит/с) (ячейки) (msec) (Кбит/с) (msec)
56 2 12 57 13.7
64 2 10 68 12.0
128 4 11 132 12.0
192 6 11 202 12.0
256 7 10 260 10.5
320 9 10 337 10.8
384 11 10 414 11.0
448 12 10 452 10.3
512 14 10 529 10.5
576 16 10 606 10.7
640 17 10 644 10.2
704 19 10 721 10.4
768 21 10 798 10.5

Обсуждение политики формирования трафика

Специальные вопросы даны формированию трафика и определяющий политику в Frame Relay / среда IW ATM. Проблемы, возникающие в направлении Frame Relay на ATM отличаются от проблем в направлении ATM на Frame Relay. Поэтому каждая тема описана отдельно.

Основная проблема в Frame Relay к направлению ATM является потенциальным расширением в потребляемой полосе пропускания при движении от кадра до ячейки. Например, 49 битных фреймов на Стороне Frame Relay используют две ячейки, или 106 байтов, на стороне ATM. Поэтому нельзя предположить, что поддерживаемое число ячеек (SCR) равняется Committedinformation rate (CIR) (гарантированная скорость передачи). Когда каждый Фрейм Frame Relay содержит 1 байт полезных данных, наихудший случай происходит. Каждый из этих байтов использует полные 53 байтовых ячейки на стороне ATM. Как пример этого понятия, этот экстремальный и нереалистичный сценарий диктует SCR, который является 53 раза CIR. Еще два реалистичных примера:

  • Пакет VoIP G.729 60 байтов длиной, или 69 байтов (когда MLP и издержки Frame Relay включены). На участке ATM это использует две ячейки или 106 байтов. Поэтому, если весь трафик, который несут, является VoIP, то соответствующее сопоставление является SCR = 106/69 = 1.5 x CIR.

  • Пакет Telnet, который несет одиночное нажатие клавиши, содержит 40 байтов заголовка TCP/IP и 1 байт данных. На стороне Frame Relay общий объем составляет 56 байтов, включая служебную информацию. Однако на стороне ATM этот пакет расширяется до двух ячеек. В этом случае, SCR = 106/56 = 1.9 x CIR.

Приложение A Стандарта форума ATM, BISDN Предает Интерфейс оператора земле (B-ICI) Версия спецификации 2.0, описывает два метода сопоставления между SCR и CIR. В то время как оба предоставляют научный подход для получения SCR из CIR, никакой не больше точен, чем данные, к которым они применены. Один из номеров, требуемых формулами, является типичным размером фрейма, номер, который трудно определить в реальной сети. Кроме того, номер, который может потенциально измениться как новые приложения, реализован на существующей Сети Frame Relay ATM/Frame. Для устранения данной проблемы рекомендуется выполнить согласование с политикой контроля соблюдения правил поставщика услуг. С помощью носителя этот отказоустойчивый подход возможен:

  • Frame Relay к Направлению ATM - В Frame Relay к направлению ATM, носитель должен определить политику трафика, входящего в Точке входа Frame Relay только. Например, на Коммутаторе Frame Relay, связанном с Frame Relay, подключил устройство Customer Premises Equipment (CPE), носитель определяет политику трафика согласно договорному CIR. Эта политика ограничения скорости проиллюстрирована на рисунке здесь. Никакое дальнейшее применение политик не должно происходить, как только трафик позволен в сеть в точке входа. Следствием данной политики ограничения скорости является то, что данные, полученные на стороне Frame Relay, могут расширяться или использовать любую пропускную способность, необходимую для 5 байт заголовка ячейки, служебных данных AAL и заполнения данных для передачи их по ветви ATM сети. В большинстве случаев требуемая пропускная способность ATM является меньше, чем дважды используемая пропускная способность Frame Relay.

    http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-ingress-policing.gif

  • От ATM к Frame Relay Направление - В направлении Ота ATM к Frame Relay, противоположное испытано. При переходе от ATM к Frame Relay полоса пропускания будет использоваться менее интенсивно, поскольку ATM cell tax, служебные данные AAL и время заполнения данными будут удалены. Однако, потому что потенциальная скорость передачи стороны ATM намного выше, чем то из Соединения Frame Relay, устанавливая формирование трафика правильно на маршрутизаторе ATM важно для целостности голоса. Если формирование слишком свободно, то данные подачи маршрутизатора ATM на скорости быстрее, чем скорость физической передачи Соединения Frame Relay в другом конце. В результате пакеты начинают стоять в очереди на коммутаторе FRF.8. В некоторый момент пакеты начинают понижаться. и так как Сети Frame Relay ATM/Frame не различают речь и данные, Пакеты VoIP также отброшены.

    В то же время, при слишком строгих правилах формирования трафика страдает пропускная способность. RXD. Это не использует пропускную способность на Соединении Frame Relay. Поэтому можно превысить намеченную сумму стороны ATM PVC немного. Объем заполнения данными и служебного заголовка AAL зависит от среднего размера кадра и степени фрагментации. Поскольку вы не можете точно квалифицировать эти издержки, вы более обеспечены не попытка оптимизировать для них. С другой стороны, "cell tax" абсолютно детерминирован. Это - 5 байтов для каждых 48 байтов полезных данных. Можно оптимизировать для "cell tax", ставя цель формирования на маршрутизаторе ATM к 53/48 x SCR. Применение политик на стороне поставщика услуг должно собираться обеспечить это небольшое превышение предела подписки.

Советы и Предупреждения

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

  • MLPoATM/Frame Relay клонирует два интерфейса виртуального доступа для каждого PVC. Один из них представляет Канал "PPP". Другой представляет Пучок MLP. Команда show ppp multilink используется для сообщения, который является который. Множественные ссылки PPPoFR на связку (bundle) не поддерживаются. Помещение двух каналов PPPOFR в один трафик связки (bundle) не будет с балансировкой нагрузки хорошо через каналы, так как драйвер PPPOFR не предоставляет управление потоками, сигнализирующее, что реальные последовательные драйверы делают. Распределение нагрузки MLPPP по ATM или Frame Relay могло бы показать заметно меньше эффективности, чем то же распределение нагрузки по физическому интерфейсу.

  • Каждый PVC связан с четырьмя различными интерфейсами, а именно - физическим, подчиненным интерфейсом и двумя интерфейсами виртуального доступа. Только интерфейсу виртуального доступа MLP включили организацию сложной очереди. Другие три интерфейса должны иметь first in, first out (FIFO) организация очереди.

  • При применении команды service-policy к virtual-template Cisco IOS отображает это обычное предупреждающее сообщение:

    cr7200(config)#interface virtual-template 1
    cr7200(config-if)#service-policy output Gromit
    Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
    Note CBWFQ supported on MLP bundle interface only.
    

    Такие сообщения - нормальное явление. Первое сообщение сообщает, что стратегия обслуживания не поддерживается на интерфейсе виртуального доступа PPP. Второе сообщение подтверждает, что стратегия обслуживания вступила в силу на интерфейсе виртуального доступа Пучка MLP. Этот факт проверен с помощью команд show interfaces virtual-access, show queue and show policy-map interface для проверки механизма организации очередей.

  • Проверка подлинности PPP строго не требуется, так как PVC походит на выделенную линию. Однако проверка подлинности PPP удобна, поскольку команда show ppp multilink тогда используется для определения названия маршрутизатора в другом конце PVC.

  • Frame Relay Traffic Shaping должен быть включен для MLPoFR PVCs на Маршрутизаторе Frame Relay.

  • Программное обеспечение Cisco IOS версии 12.2 первоначально поддержало максимум двадцати пяти виртуальных шаблонов на маршрутизатор. Если каждый PVC требуется, чтобы иметь уникальный IP - адрес, это ограничение может повлиять на масштаб маршрутизатора распределения ATM. Обходной путь для затрагиваемых версий должен использовать ненумерованный IP или использовать интерфейсы номеронабирателя вместо виртуальных шаблонов. В программном обеспечении Cisco IOS версии 12.2(8)T поддержка увеличена до 200 виртуальных шаблонов.

  • Некоторые поставщики услуг еще не поддерживают трансляцию PPP на своих устройствах FRF.8. Каждый раз, когда это ограничение существует, поставщики должны настроить свой PVCs для прозрачного режима.

  • В большинстве примеров в документации по Cisco IOS приводятся конфигурации, включающие подчиненный интерфейс ATM или Frame Relay. Этот подчиненный интерфейс не служит никакой цели. Виртуальный шаблон должен просто быть присоединен к физическому интерфейсу. Результатом является более компактное и управляемая конфигурация. Если существует большое число PVCs, это особенно важно.

  • Используйте команду show ppp multilink в качестве надежного способа определить, существует ли какая-либо ячейка/сбросы кадров на стороне поставщика услуг. Единственная допустимая потеря фрагмента — вызванная ошибками контроль циклическим избыточным кодом.

  • Несмотря на то, что MLPoATM/Frame Relay был представлен в программном обеспечении Cisco IOS версии 12.1(5)T, дефекты в этом и последующих релизах диктуют тот уход быть взятыми при выборе Cisco IOS Software Release. Cisco рекомендует использовать последнюю отладочную версию Cisco IOS 12.2 господствующих тенденций. Если Survivable Remote Site Telephony (SRST) требуется, Однако другие требования к характеристикам VoIP могут продиктовать использование другого Cisco IOS Software Release, такой как 12.2 (2) XT. Эта таблица приводит некоторые известные неполадки. При выборе Cisco IOS каждый идентификатор ошибки Cisco должен быть оценен против выбранного IOS.

Идентификатор ошибки Cisco Описание
CSCdt09293 (только зарегистрированные клиенты) Быстрое коммутирование LFI-на 7200 причинах одним путем голосовые вызовы.
CSCdt25586 (только зарегистрированные клиенты) Переброска доступа PPPoA или коммутируемый виртуальный канал (SVC), не разъединенный на времени простоя.
CSCdt29661 (только зарегистрированные клиенты) Завершение MLP-ATM-интерфейса во время маршрутизатора сбоев быстрой коммутации.
CSCdt53065 (только зарегистрированные клиенты) Повышение производительности в atm_lfi кодирует для функции LFI ATM.
CSCdt59038 (только зарегистрированные клиенты) MLPoATM: Эхо-запрос с большими пакетами отказывает на PA-A3.
CSCdu18344 (только зарегистрированные клиенты) Пропускная способность MLPoATM/постоянной виртуальной сети Frame Relay PVC является меньше чем половиной SCR/CIR.
CSCdu19297 (только зарегистрированные клиенты) PVC MLPoATM без политики обслуживания генерирует ошибки.
CSCdu41056 (только зарегистрированные клиенты) MLPoATM: Драйвер vc_soutput подпрограмма, вызываемая дважды.
CSCdu44491 (только зарегистрированные клиенты) Счетчики VirtualAccess, неправильные в MLPoFR.
CSCdu51306 (только зарегистрированные клиенты) Пакеты Keepalive, сломанные на PPPoX.
CSCdu57004 (только зарегистрированные клиенты) CEF не работает с MLP.
CSCdu84437 (только зарегистрированные клиенты) Реализация управления потоками между MLP и вызовом tx настроила драйверы.
CSCdv03443 (только зарегистрированные клиенты) Передача исправляет для u76585 на Cisco Выпуск ПО IOS� 12.2 - Входящие пакеты MLP являются коммутированным процессом.
CSCdv10629 (только зарегистрированные клиенты) MLPoATM: Голосовые пакеты не помещены в очередь в LLQ.
CSCdv20977 (только зарегистрированные клиенты) Входящие пакеты MLP получают коммутированный процесс.
CSCdw44216 (только зарегистрированные клиенты) когда ссылка CBWFQ/LLQ достигает перегрузки, cRTP вызывает высокую загрузку CPU.
CSCdy70337 (только зарегистрированные клиенты) Когда Пучки MLP с политикой обслуживания QoS используется.
CSCdx71203 (только зарегистрированные клиенты) Пучок MLP мог бы иногда иметь несколько неактивных ссылок.

Примеры практического применения

Введение

Данный раздел описывает одно из первых клиентских развертываний функции MLPoATM/Frame Relay. Клиент упомянут фиктивным именем XYZ Ltd. В 2001 XYZ Ltd заменила их PBXs Решением IP-телефонии. Как часть этого проекта, был создан новый IP - сеть. и Взаимодействие между сетями Frame Relay и ATM было выбрано для глобальной сети (WAN). Носитель, который предоставляет сервис глобальной сети (WAN), использует коммутаторы Ньюбриджа для отправки ATM и Сервисов Frame Relay.

Обзор сети

Сеть XYZ Ltd является концентратором и говорит сеть, которая подключает двадцать шесть ответвлений с двумя центральными узлами. Все основные узлы обслуживаются маршрутизатором Cisco 3660 с модулем E3 ATM. Восемнадцать из двадцати шести ответвлений среднего размера. У них есть двойные ПВКи Frame Relay, которые соединяются назад с 3660 в этих двух центральных узлах через IW Реле ATM/Frame. Оставление восемью ответвлениями является очень маленьким. Они соединяются назад с самым близким ответвлением среднего размера через PVC одного канала Frame Relay. Все маршрутизаторы для филиалов являются Cisco 2620. Сквозной постоянный виртуальный канал ATM соединяется два 3660 маршрутизаторов в этих двух концентраторах. Этот рисунок иллюстрирует топологию.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-network.gif

Эта таблица показывает скорости Доступа по каналам Frame Relay и CIR. CIR варьируется от 32 кбит/с до 256 кбит/с. В таблице также показано максимальное число одновременных вызовов VoIP через каждый ПВК.

Узел Удаленный сайт Доступ (кбит/с) CIR (кбит/с) Число вызовов
Ветвь 1 Ядро 1 320 192 6
Ответвление 2 Ответвление 22 128 64 2.0
Ответвление 3 Ядро 1 576 256 8.0
Ответвление 4 Ответвление 16 64 32 2.0
Ответвление 5 Ядро 1 128 64 2.0
Ответвление 6 Ответвление 3 64 32 2.0
Ответвление 7 Ядро 1 512 256 8.0
Ответвление 8 Ядро 1 512 256 8.0
Ответвление 9 Ответвление 13 128 256 2.0
Ответвление 10 Ядро 1 256 128 4.0
Ответвление 11 Core 2 128 96 2.0
Ответвление 12 Ядро 1 128 64 2.0
Ответвление 13 Ядро 1 768 256 12.0
Ответвление 14 Ядро 1 192 96 4.0
Ответвление 15 Ядро 1 192 96 4.0
Ответвление 16 Ядро 1 448 192 8.0
Ответвление 17 Ответвление 13 128 64 2.0
Ответвление 18 Ядро 1 128 96 2.0
Ответвление 19 Ответвление 16 128 64 2.0
Ответвление 20 Ядро 1 64 32 2.0
Core 2 Ядро 1 34000 256 12.0
Ответвление 21 Ответвление 13 128 64 2.0
Ответвление 22 Ядро 1 384 192 6.0
Ответвление 23 Ядро 1 512 256 8.0
Ответвление 24 Ядро 1 192 96 2.0
Ответвление 25 Ядро 1 128 96 4.0
Ответвление 26 Ветвь 1 64 32 2.0

Формирование трафика Frame Relay выполняется вспомогательными маршрутизаторами. Пакетная передача за CIR разрешена. Формирование трафика Cisco IOS собирается сформировать к скорости доступа с mincir, равным CIR. Если явные уведомления о перегрузке при обратной передаче (BECN) получены от носителя, то маршрутизатор возвращает к исходному состоянию к mincir. Этот подход против Рекомендаций Cisco при выполнении VoIP over Frame Relay. Голос уже в беде к тому времени, когда маршрутизатор ответил на уведомления о перегрузке. Однако в этом случае носитель считает, что его сеть имеет значительный запас, чтобы не терять кадры или ячейки, и поэтому BECN не должны быть видны.

Управление трафиком ATM выполняется со скоростью выборки кадров на удаленном конце с добавлением пятибайтового заголовка ячейки. Например, если скорость доступа составляет 512 кбит/с, то SCR установлен в 512x53/48 = 565 кбит/с. Это нормирование скорости трафика используется для максимизации пропускной способности. Это безопасно, потому что "cell tax" разделен в точке IW. Ограничение трафика на стороне поставщика услуг выполнено со значительным запасом, поэтому небольшое превышение объема подписки допустимо.

cRTP используется в WAN. Оперативная точка до ЦП затронута, маршрутизатор распределения Cisco 3660 в центральном узле 1. Путем включения номеров вышеупомянутая таблица определено, что количество теоретического максимального значения вызовов VoIP, которые пересекают этот маршрутизатор, является 102 вызовами. Числа производительности от этого графика указывают, что Загрузка ЦПУ Cisco 3660 для 100 сеансов cRTP (которые быстро коммутированы) составляет приблизительно 50 процентов.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-3660-performance.gif

Виртуальные шаблоны используются с каналами WAN с IP-нумерацией. Один виртуальный шаблон требуется на PVC, который возможен начиная с общего числа PVCs, которые завершаются на каждом Cisco 3660, меньше чем двадцать пять.

Конфигурации

Эти конфигурации используются в данном документе:

Основной маршрутизатор ATM

!--- Note: This section shows the parts of a core Cisco 3660 router 
!--- configuration that is relevant to MLPoATM.

        
class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58 
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


!--- Note:  Do not configure 
!--- IP addresses directly on any configuration source, 
!--- such as a virtual template, whenever the possibility 
!--- exists that this information  is cloned to multiple 
!--- active interfaces. The exception to this rule is the 
!--- rare case where the intent is to define multiple parallel 
!--- IP routes and have IP do load balancing between them. 
!--- If an IP address is present on the configuration source, 
!--- this IP address  is copied to all the cloned interfaces.
!---  IP  installs a route to each of these interfaces.
 

Маршрутизатор на ветви сети Frame Relay

!--- Note: This section shows the parts of a branch Cisco 2600 router 
!--- configurations that is relevant to MLPoFR.


class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000


Дополнительные сведения


Document ID: 25084