Широкополосные кабельные сети : Системы терминирования кабельных модемов (CMTS)

Настройка режима планировщика потока данных к вышестоящему серверу на uBR Cisco CMTS

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


Содержание


Введение

Этот документ обсуждает конфигурацию восходящего режима планирования для Универсального широкополосного маршрутизатора Cisco (uBR) серия Систем терминирования кабельных модемов (CMTS).

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

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

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • Системы Data Over Cable Service Interface Specification (DOCSIS)

  • Cisco uBR sery CMTS

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

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

  • CMTS uBR Cisco

  • Cisco Очереди релизов программного обеспечения IOS� 12.3 (13a) BC и 12.3 (17a) BC

Примечание: Для получения информации об изменениях в более поздних версиях программного обеспечения Cisco IOS сошлитесь на соответствующие Комментарии к выпуску, доступные в вебе - узлы/URL Cisco.com.

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

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

Общие сведения

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

Это Описание технологических решений включает:

  • Обзор режимов расписания восходящей передачи в DOCSIS, включая оптимальный уровень, Unsolicited Grant Service (UGS) и оперативный сервис опроса (RTPS)

  • Операция и конфигурация соответствующего стандарту DOCSIS планировщика для CMTS uBR Cisco

  • Операция и конфигурация нового планировщика организации очереди низкой задержки для CMTS uBR Cisco

Восходящее планирование в DOCSIS

Соответствующий стандарту DOCSIS CMTS может предоставить другие режимы восходящего планирования для других потоков пакетов или приложений через понятие потока обслуживания. Поток обслуживания представляет или восходящий или нисходящий поток данных, который однозначно определяет ID потока обслуживания (SFID). Каждый поток обслуживания может иметь свои собственные параметры качества обслуживания (QoS), например, максимальную пропускную способность, минимальную гарантированную пропускную способность и приоритет. В случае исходящих управляющих потоков можно также задать режим планирования.

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

Кабельный модем и CMTS в состоянии направить корректные типы трафика в соответствующие потоки обслуживания с использованием классификаторов. Классификаторы являются специальными фильтрами, как access-lists, тот пакет соответствия свойства, такие как UDP и номера порта TCP для определения соответствующего потока обслуживания для пакетов для перемещения через.

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

Рисунок 1 – кабельный модем с тремя исходящими управляющими потоками

/image/gif/paws/69704/upstrm_sch_config_01.gif

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

Потоки обслуживания могут также быть динамично созданы и активированы после того, как кабельный модем прибывает онлайн. Этот сценарий обычно применяется к потоку обслуживания, который соответствует данным, которые принадлежат телефонному вызову VoIP. Когда телефонный разговор начинается, такой поток обслуживания создан и активирован. Когда вызов заканчивается, поток обслуживания тогда деактивирован и удален. Если поток обслуживания существует только при необходимости, можно сохранить ресурсы пропускной способности восходящего канала и системную Загрузку ЦПУ и память.

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

«Максимальные усилия»

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

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

Вот обычно используемые параметры, которые определяют поток данных максимально эффективного сервиса в DOCSIS 1.1/2.0 режим:

  • Maximum Sustained Traffic Rate(R)

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

  • Максимальный пакет трафика (B)

    Максимальный пакет трафика обращается к размеру пакета в байтах, который применяется к ограничителю алгоритма ограничения скорости token bucket, который принуждает пределы пропускной способности в восходящем направлении. Если никакое значение не задано, значение по умолчанию 3044 применяется, который является размером двух полных фреймов Ethernet. Для больших максимально - возможных скоростей непрерывной передачи трафика, набор это значение, чтобы быть, по крайней мере, максимально - возможной скоростью непрерывной передачи трафика, разделенной на 64.

  • Приоритет трафика

    Этот параметр обращается к приоритету трафика в потоке обслуживания в пределах от 0 (самое низкое) к 7 (самое высокое). В восходящем весь трафик в состоянии ожидания для высокоприоритетных потоков обслуживания планируются для передачи перед трафиком для потоков обслуживания низкого приоритета.

  • Минимальная зарезервированная скорость

    Этот параметр указывает на минимальную гарантированную пропускную способность в битах в секунду для потока обслуживания, подобного Committedinformation rate (CIR) (гарантированная скорость передачи). Объединенные минимальные зарезервированные скорости для всех потоков обслуживания на канале не должны превышать доступную пропускную способность на том канале. В противном случае невозможно гарантировать обещанные минимальные зарезервированные скорости.

  • Максимально связанное блок данных

    Максимально связанное блок данных является размером в байтах самой большой передачи связанных кадров, которые модем может сделать от имени потока обслуживания. Поскольку этот параметр подразумевает, модем может передать составные фреймы в одном пакете передачи. Если это значение не задано, Кабельные модемы DOCSIS 1.0 и более старые модемы DOCSIS 1.1 предполагают, что нет никакого явного заданного предела на размере объединенного блока. Совместимые модемы с более свежими пересмотрами DOCSIS 1.1 или более поздними спецификациями используют значение 1522 байтов.

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

Иногда CMTS планирует определенные периоды, в которые CMTS позволяет кабельным модемам передавать специальные сообщения, названные запросами полосы пропускания. Запрос полосы пропускания является очень маленьким кадром, который содержит подробные данные объема данных, который модем хочет передать плюс идентификатор сервиса (SID), который соответствует исходящему управляющему потоку, который должен передать данные. CMTS поддерживает внутреннюю таблицу соответствующее количество SID к исходящим управляющим потокам.

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

CMTS всегда гарантирует, что небольшое количество возможностей запроса полосы пропускания регулярно планируется, независимо от того как переполненный канал передачи от клиента становится. Множественные кабельные модемы могут передать запросы полосы пропускания в то же время и повредить передачи друг друга. Для сокращения потенциальной возможности коллизии, которая может повредить запросы полосы пропускания, “откат и повторить” алгоритм, существует. Последующие разделы этого документа обсуждают этот алгоритм.

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

  1. CMTS использует количество SID, полученное в запросе полосы пропускания для исследования потока обслуживания, к которому привязан запрос полосы пропускания.

  2. CMTS тогда использует алгоритм token bucket. Этот алгоритм помогает CMTS проверять, превысит ли поток обслуживания предписанную максимальную поддерживаемую скорость, если CMTS предоставляет запрошенную пропускную способность. Вот вычисление алгоритма token bucket:

    Max (T) = T * (R / 8) + B

    где:

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

    • В секундах T представляет время.

    • R указывает на максимально - возможную скорость непрерывной передачи трафика для потока обслуживания в битах в секунду

    • B является максимальным пакетом трафика для потока обслуживания в байтах.

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

    CMTS uBR Cisco внедряет два восходящих алгоритма планировщика, названные DOCSIS - совместимым планировщиком и планировщиком организации очереди низкой задержки. Посмотрите DOCSIS - совместимый раздел Планировщика и раздел Планировщика Организации очереди Низкой задержки этого документа для получения дополнительной информации.

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

    • Когда кабельный модем в состоянии передать.

    • Как долго кабельный модем в состоянии передать.

Откат запроса полосы пропускания и алгоритм повторной попытки

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

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

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

Эти параметры отката выражены как “питание двух” значений. Модемы используют эти параметры в качестве полномочий два для вычисления, сколько времени ждать, прежде чем они передадут запросы полосы пропускания. Оба значения имеют диапазон от 0 до 15, и конец отката данных должен быть больше, чем или равным откату данных, запускаются.

Первоначально кабельный модем хочет передать запрос определенной пропускной способности, кабельный модем должен сначала выбрать случайное число между 0, и 2 к питанию отката данных запускаются минус 1. Например, если запуск отката данных установлен в 3, модем должен выбрать случайное число между 0 и (23 – 1) = (8 – 1) = 7.

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

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

CMTS включает подтверждение в следующее сообщение MAP пропускной способности. Это подтверждение сообщает кабельному модему, что был успешно получен запрос полосы пропускания. Это подтверждение может:

  • когда модем может сделать передачу, любой указывает точно

    Или

  • только укажите, что запрос полосы пропускания был получен и что время для передачи будет решено в будущем сообщении MAP.

Если CMTS не включает подтверждение запроса полосы пропускания в следующем сообщении MAP, модем может прийти к заключению, что не был получен запрос полосы пропускания. Эта ситуация может произойти из-за коллизии или восходящего шума, или потому что поток обслуживания превышает предписанную скорость максимальной пропускной способности, если предоставляют запрос.

В любом случае следующий шаг для кабельного модема к откату и попытке передать запрос полосы пропускания снова. Модем увеличивает диапазон, по которому выбрано произвольное значение. Для этого модем добавляет, что тот к откату данных запускает значение. Например, если откат данных запускается, значение равняется 3, и CMTS не в состоянии получать одну передачу запроса полосы пропускания, модем ждет произвольное значение между 0 и 15 возможностями запроса полосы пропускания перед повторной передачей. Вот вычисление: 23+1 – 1 = 24 – 1 = 16 – 1 = 15

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

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

Можно настроить откат данных, запускаются и значения конца отката данных на кабель в восходящем направлении на CMTS uBR Cisco с этой командой кабельного сопряжения:

кабель восходящий data-backoff-end data-backoff-start отката данных восходящего идентификатора порта

Cisco рекомендует сохранить значения по умолчанию для data-backoff-start и параметров data-backoff-end, которые равняются 3 и 5. Основанная на конкуренции природа системы планирования оптимального уровня означает, что для потоков данных максимально эффективного сервиса, невозможно предоставить детерминированный или гарантируемый уровень восходящей задержки или дрожания. Кроме того, условия перегрузки могут лишить возможности гарантировать частичный уровень пропускной способности для потока данных максимально эффективного сервиса. Однако можно использовать свойства потока обслуживания как приоритет и минимальная зарезервированная скорость. С этими свойствами поток обслуживания может достигнуть нужного уровня пропускной способности в условиях перегрузки.

Пример алгоритма отката и повторной попытки

Данный пример включает четыре кабельных модема по имени A, B, C и D, связанный с тем же каналом передачи от клиента. В тот же момент, названный t0, модемы A, B и C решают передать некоторые данные в восходящем.

Здесь, запуск отката данных установлен в 2, и конец отката данных установлен в 4. Диапазон интервалов, от которых модемы выбирают интервал, прежде чем они сначала попытаются передать запрос полосы пропускания, между 0 и 3. Вот вычисление:

(22 – 1) = (4 – 1) = 3 интервала.

Вот количество возможностей запроса полосы пропускания, которые эти три модема выбирают для ожидания со времени t0.

  • Модем A: 3

  • Модем B: 2

  • C модема: 3

Заметьте, что модем A и C модема выбирает то же количество возможностей ждать.

Модем B ждет двух возможностей запроса полосы пропускания, которые появляются после t0. Модем B тогда передает запрос полосы пропускания, который получает CMTS. И модем A и C модема ждут 3 возможностей запроса полосы пропускания пройти после t0. Модемы A и C тогда передают запросы полосы пропускания в то же время. Эти два запроса полосы пропускания сталкиваются и становятся поврежденными. В результате никакой запрос успешно не достигает CMTS. Рисунок 2 показывает эту последовательность событий.

Рисунок 2 – пример (часть 1) запроса полосы пропускания

upstrm_sch_config_02.gif

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

Следующая радиопередача сообщений MAP от CMTS содержит предоставление на модем B, но никакие инструкции для модемов A и C. Это указывает к модемам A и C, что они должны повторно передать свои запросы полосы пропускания.

На второй попытке модем A и C модема должен инкрементно увеличить питание два для использования, когда они вычисляют диапазон интервалов, от которых можно выбрать. Теперь, модем A и C модема выбирает случайное число интервалов между 0 и 7. Вот вычисление:

(22+1 - 1) = (23 – 1) = (8 – 1) = 7 интервалов.

Предположите, что время, когда модем A и C модема понимает потребность повторно передать, является t1. Также предположите, что другой вызываемый модем модема D решает передать некоторые данные восходящего соединения в тот же момент, t1. Модем D собирается сделать передачу запроса полосы пропускания впервые. Поэтому модем D использует исходное значение для отката данных, запускаются и конец отката данных, а именно, между 0 и 3 [(22 – 1) = (4 – 1) = 3 интервала].

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

  • Модем A: 5

  • C модема: 2

  • Модем D: 2

Оба C модемов и D ждут двух возможностей запроса полосы пропускания, которые появляются после t1 времени. C модемов и D тогда передают запросы полосы пропускания в то же время. Эти запросы полосы пропускания сталкиваются и поэтому не достигают CMTS. Модем A позволяет пяти возможностям запроса полосы пропускания пройти. Затем модем передачи запрос полосы пропускания, который получает CMTS. Рисунок 3 показывает коллизию между C передачи данных модемами и D и успешным получением передачи данных модемом A. Ссылка времени начала для этого рисунка является t1.

Рисунок 3 – пример (часть 2) запроса полосы пропускания

upstrm_sch_config_03.gif

Следующая радиопередача сообщений MAP от CMTS содержит предоставление на модем A, но никакой C инструкций для модемов и D. C модемов и D понимают потребность повторно передать запросы полосы пропускания. Модем D теперь собирается передать запрос полосы пропускания во второй раз. Поэтому модем D откат данных использования запускается + 1 как питание два для использования в вычислении диапазона интервалов для ожидания. Модем D выбирает интервал между 0 и 7. Вот вычисление:

(22+1 – 1) = (23 – 1) = (8 – 1) = 7 интервалов.

C модема собирается передать запрос полосы пропускания в третий раз. Поэтому откат данных использования C модема запускается + 2 как питание два к в вычислении диапазона интервалов для ожидания. C модема выбирает интервал между 0 и 15. Вот вычисление:

(22+2 – 1) = (24 – 1) = (16 – 1) = 15 интервалов.

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

  • C модема: 9

  • Модем D: 4

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

К сожалению, когда C модема делает передачу, большой пакет внешних помех вмешивается в передачу, и CMTS не в состоянии получать запрос полосы пропускания (см. рисунок 4). В результате еще раз C модема не в состоянии видеть предоставление в следующем сообщении MAP, что CMTS передает. Это предпринимает попытку C модема четвертая попытка передачи запроса полосы пропускания.

Рисунок 4 – часть 3 запроса полосы пропускания в качестве примера

upstrm_sch_config_04.gif

C модема уже достиг значения конца отката данных 4. C модема не может увеличить диапазон, используемый для выбора случайного числа интервалов для ожидания. Поэтому C модема еще раз использует 4 в качестве питания два для вычисления случайного диапазона. C модема все еще использует диапазон от 0 до 15 интервалов согласно этому вычислению:

(24 – 1) = (16 – 1) = 15 интервалов.

На четвертой попытке C модема в состоянии сделать успешную передачу запроса полосы пропускания в отсутствие конкуренции или шума.

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

Приоритет трафика

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

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

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

Минимальная зарезервированная скорость

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

Этот метод является попыткой предоставить своего рода сервис стиля Committedinformation rate (CIR) (гарантированная скорость передачи), аналогичный сети frame-relay. CMTS имеет механизмы контроля за соединением, чтобы гарантировать, что на определенном восходящем объединенная минимальная зарезервированная скорость всех связанных потоков обслуживания не может превысить доступную пропускную способность канала передачи от клиента или процент этого. Можно активировать эти механизмы с этим на команду входного порта:

[никакой] кабель восходящий max-reservation-limit admission-control восходящего идентификатора порта

Параметр max-reservation-limit имеет диапазон 10 - 1000 процентов для указания на уровень подписки по сравнению с доступной необработанной пропускной способностью канала передачи от клиента, которую могут использовать сервисы стиля CIR. При настройке max-reservation-limit больших, чем 100 восходящий может превысить намеченную сумму сервисов стиля CIR указанным пределом процента.

CMTS не позволяет новым потокам обслуживания минимальной зарезервированной скорости быть установленными, если они заставили бы входной порт превышать настроенный процент max-reservation-limit от доступной пропускной способности восходящего канала. Потоки обслуживания минимальной зарезервированной скорости все еще подвергаются потенциальным конфликтам запросов полосы пропускания. Также, потоки обслуживания минимальной зарезервированной скорости не могут предоставить истинную гарантию определенной пропускной способности, особенно в чрезвычайно условиях перегрузки. Другими словами, CMTS может только гарантировать, что поток обслуживания минимальной зарезервированной скорости в состоянии достигнуть определенной гарантируемой пропускной способности в восходящем направлении, если CMTS в состоянии получить все запросы необходимой пропускной способности от кабельного модема. Это требование может быть достигнуто при создании потока обслуживания потоком обслуживания оперативного сервиса опроса (RTPS) вместо потока данных максимально эффективного сервиса. Посмотрите раздел предоставления каналов по результатам опроса в реальном времени (RTPS) для получения дополнительной информации.

Комбинированные запросы полосы пропускания

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

Это означает, что запрос полосы пропускания не подвергается конкуренции и поэтому имеет намного более высокую возможность, что запрос достигает CMTS. Понятие комбинированных запросов полосы пропускания уменьшает время, когда Фрейм Ethernet берет для достижения оборудования в помещении заказчика (CPE) конечного пользователя, потому что время, когда кадр берет в восходящей передаче, уменьшает. Это вызвано тем, что модем не должен проходить через откат и процесс передачи запроса полосы пропускания повторной попытки, который может подвергнуться задержкам.

Осуществление контрейлерных перевозок запросов полосы пропускания, как правило, происходит в этом сценарии:

В то время как кабельный модем ждет, чтобы передать кадр, сказать X, в восходящем, модем принимает другой кадр, SAID Y, от CPE для передачи в восходящем. Кабельный модем не может добавить байты от нового кадра Y на передаче, потому что это включает использование большего количества восходящего времени, чем предоставляют модем. Вместо этого модем заполняет поле в заголовке DOCSIS кадра X для указания на сумму времени передачи, требуемого для кадра Y.

CMTS принимает кадр X и также подробные данные запроса полосы пропускания от имени Y. На основе доступности CMTS предоставляет модему дальнейшее время передачи от имени Y.

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

Это примечательно, потому что, типовой кодек VoIP как G.711 обычно использует межкадровый период 10 или 20 мс. Типичный поток VoIP, который работает по потоку данных максимально эффективного сервиса, не может использовать преимущества осуществления контрейлерных перевозок.

Конкатенация

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

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

Поле Maximum Concatenated Burst, которое можно настроить для потока обслуживания, ограничивает максимальный размер связанного кадра, который может передать поток обслуживания. Можно также использовать команду cable default-phy-burst для ограничения размера связанного кадра и максимального размера пакета в профиле модуляции канала передачи от клиента.

Конкатенация включена по умолчанию на входных портах Cisco uBR sery CMTS. Однако можно управлять конкатенацией на основе на восходящий порт ни с [каким] кабелем восходящая конкатенация восходящего идентификатора порта [docsis10] команда кабельного сопряжения.

При настройке docsis10 параметра команда только применяется к кабельным модемам, которые работают в Режиме DOCSIS 1.0.

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

Фрагментация

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

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

Кабельные модемы, которые работают в Режиме DOCSIS 1.0, не могут выполнить фрагментацию.

Фрагментация включена по умолчанию на входных портах Cisco uBR sery CMTS. Однако можно включить или отключить фрагментацию на основе на восходящий порт ни с [каким] кабелем восходящая команда кабельного сопряжения фрагментации восходящего идентификатора порта.

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

Можно вынудить DOCSIS 1.1/2.0 кабельные модемы фрагментировать все крупные кадры ни с [каким] кабелем восходящий fragment-force восходящего идентификатора порта [величина порога фрагментов] команда кабельного сопряжения.

По умолчанию эта опция отключена. Если вы не задаете значения для порога и количества фрагментов в конфигурации, порог установлен к 2000 байтов, и номер фрагментов определен к 3. Команда fragment-force сравнивает количество байтов, которые поток обслуживания запрашивает на передачу с параметром заданной пороговой величины. Если размер запроса больше, чем порог, CMTS допускает, что пропускная способность к служебному потоку в “количестве фрагментов” одинаково измерила части.

Например, предположите, что для определенного восходящего fragment-force включен со значением 2000 байтов порогового значения и 3 для количества фрагментов. Затем предположите, что поступает запрос передать 3000-байтовый пакет. Как 3000 байтов больше, чем порог 2000 байтов, предоставление должно быть фрагментировано. Поскольку количество фрагментов установлено в 3, время передачи является тремя одинаково размерными предоставлениями 1000 байтов каждый.

Заботьтесь, чтобы гарантировать, что размеры отдельных фрагментов не превышают возможность типа карты кабельной линии в использовании. Для линейных карт MC5x20S самый большой отдельный фрагмент не должен превышать 2000 байтов, и для других линейных карт, включая MC28U, MC5x20U и MC5x20H, самый большой отдельный фрагмент не должен превышать 4000 байтов.

Unsolicited Grant Service (UGS)

Unsolicited Grant Service (UGS) выделяет периодические предоставления на исходящий управляющий поток без потребности в кабельном модеме для передачи запросов полосы пропускания. Этот тип сервиса подходит для приложений, которые генерируют кадры фиксированного размера через определенные промежутки времени и нетерпимы к потере пакета. Передача голоса по IP является классическим примером.

Сравните систему планирования UGS с временным интервалом в системе мультиплексирования с разделением по времени (TDM), такой как канал T1 или E1. UGS предоставляет гарантируемую пропускную способность и задержку, которая в свою очередь предоставляет непрерывный поток неподвижных периодических интервалов для передачи без потребности в клиенте периодически запросить или бороться за пропускную способность. Эта система совершенна для VoIP, потому что голосовой трафик обычно передан как непрерывный поток периодических данных фиксированного размера.

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

Обратите внимание на то, что невзирая на то, что потоки обслуживания стиля UGS являются самым соответствующим потоком типа сервиса для передачи однонаправленного трафика VoIP, они, как полагают, не являются соответствующими классическим интернет-приложениям, таким как сеть, электронная почта или P2P. Это вызвано тем, что классические интернет-приложения не генерируют данные в неподвижных периодических интервалах и могут, фактически, потратить данные "not transmitting" значительных периодов времени вообще. Если поток обслуживания UGS используется для передачи классического интернет-трафика, поток обслуживания может пойти неиспользованный для значительных периодов, когда приложение кратко останавливает передачи. Это приводит к неиспользованным предоставлениям UGS, которые представляют трату ресурсов пропускной способности восходящего канала, которая не выбираема.

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

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

Вот обычно используемые параметры, которые определяют поток обслуживания UGS:

  • Непредусмотренный выделенный размер (G) — Размер каждого периодического предоставления в байтах.

  • Номинальный предоставленный интервал (I) — Интервал в микросекундах между предоставлениями.

  • Допустимое дрожание (J) — Позволенное изменение в микросекундах от точно периодических предоставлений. Другими словами, это - дрейф, который имеет CMTS, когда CMTS пытается планировать предоставление UGS вовремя.

Когда поток обслуживания UGS активен, каждый (I) миллисекунды, CMTS предлагает шанс для потока обслуживания для передачи в Непредусмотренном выделенном размере (G) байтов. Несмотря на то, что идеально CMTS предлагает предоставление точно каждый (I) миллисекунды, может быть поздно до (J) миллисекунд.

Рисунок 5 показывает шкалу времени, которая демонстрирует, как предоставления UGS могут быть выделены с данным размером предоставления, интервалом предоставления и терпели дрожание.

Рисунок 5 – Шкала времени, которая Показывает Периодические Предоставления UGS

/image/gif/paws/69704/upstrm_sch_config_05.gif

Зеленые шаблонные блоки представляют время, где CMTS выделяет время восходящей передачи потоку обслуживания UGS.

Предоставление каналов по результатам опроса в реальном времени (RTPS)

Предоставление каналов по результатам опроса в реальном времени (RTPS) предоставляет периодические non-contention-based возможности запроса полосы пропускания так, чтобы поток обслуживания выделил время для передачи запросов полосы пропускания. Только потоку обслуживания RTPS позволяют использовать эту возможность запроса полосы пропускания индивидуальной рассылки. Другие кабельные модемы не могут вызвать коллизию запроса полосы пропускания.

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

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

Поток обслуживания RTPS, как правило, обладает этими атрибутами:

  • Номинальный интервал опроса — интервал в микросекундах между возможностями запроса полосы пропускания индивидуальной рассылки.

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

Рисунок 6 показывает шкалу времени, которая демонстрирует, как опросы RTPS выделены с данным номинальным интервалом опроса и допустимой рассинхронизацией опроса.

Рисунок 6 – Шкала времени, которая Показывает Периодический Опрос RTPS

/image/gif/paws/69704/upstrm_sch_config_06.gif

Маленькие зеленые шаблонные блоки представляют время, где CMTS предлагает потоку обслуживания RTPS возможность запроса полосы пропускания индивидуальной рассылки.

Когда CMTS получает запрос полосы пропускания от имени потока обслуживания RTPS, CMTS обрабатывает запрос полосы пропускания таким же образом как запрос от потока обслуживания “оптимального уровня”. Это означает, что в дополнение к вышеупомянутым параметрам, такие свойства как максимально - возможная скорость непрерывной передачи трафика и приоритет трафика должны быть включены в определение потока обслуживания RTPS. Поток обслуживания RTPS обычно также содержит минимальную зарезервированную скорость трафика, чтобы гарантировать, что трафик, привязанный к потоку обслуживания, в состоянии получить преданную гарантированную пропускную способность.

Unsolicited Grant Service с определением активности (UGS-AD)

Unsolicited Grant Service с определением активности (AS UGS) назначает время передачи стиля UGS на поток обслуживания только, когда AS UGS фактически должен передать пакеты. Когда CMTS обнаруживает, что кабельный модем не имеет переданных кадров в течение определенного периода, CMTS предлагает возможности запроса полосы пропускания стиля RTPS вместо предоставлений стиля UGS. Если CMTS впоследствии обнаруживает, что поток обслуживания делает запросы полосы пропускания, CMTS возвращается, поток обслуживания назад к предложению стиля UGS предоставляет и прекращает предлагать возможности запроса полосы пропускания стиля RTPS.

UGS-AD, как правило, используется в ситуации, куда передавался Трафик VoIP, который использовал обнаружение активности речи (VAD). Если UGS-AD обнаруживает паузу в речи пользователя, обнаружение активности речи заставляет оконечная точку VoIP останавливать передачу кадров VoIP. Несмотря на то, что это поведение может сохранить пропускную способность, оно может вызвать проблемы с качеством голосовой связи, особенно если механизм определения активности VAD или UGS-AD активирует немного после того, как конечная сторона начинает продолжать говорить. Это может привести к пересылке или нажатию звука, поскольку пользователь продолжает говорить после тишины. Поэтому UGS-AD широко не развернут.

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

Значение по умолчанию для параметра порога в секундах составляет 10 секунд. Потоки обслуживания UGS-AD обычно отряды атрибуты потока обслуживания UGS и номинального интервала опроса и атрибут допустимой рассинхронизации опроса связались с потоками обслуживания RTPS.

Сервис опроса реального времени non (NRTPS)

Режим планирования сервиса опроса реального времени non (nRTPS) является по существу тем же как RTPS за исключением того, что NRTPS обычно привязан к Интерактивным службам non, таким как передачи файла. Компонент реального времени non может подразумевать, что номинальный интервал опроса для возможностей запроса полосы пропускания индивидуальной рассылки не точно обычен или может произойти на скорости меньше чем одного в секунду.

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

Алгоритмы планирования

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

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

  • Дрожание

  • Емкость потока обслуживания UGS на восходящий

Дрожание

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

Если нижние уровни дрожания требуются, планировщик должен быть негибким и твердым, когда это планирует предоставления. Как следствие планировщик должен установить ограничения для количества потоков обслуживания UGS, поддерживаемых на восходящем.

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

Емкость потока обслуживания UGS на восходящий поток

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

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

Примечание: Другие алгоритмы планирования могут позволить определенному каналу передачи от клиента поддерживать различное количество потоков обслуживания RTPS и UGS. Однако такие сервисы не могут использовать 100% восходящей емкости в системе DOCSIS. Это вызвано тем, что канал передачи от клиента должен выделить часть трафику управления DOCSIS, такому как сообщения начального обслуживания, что использование кабельных модемов для создания исходного контакта с CMTS и трафика поддержки активности обслуживания станции использовало гарантировать, что кабельные модемы могут поддержать подключение к CMTS.

DOCSIS - совместимый планировщик

DOCSIS - совместимый планировщик является системой по умолчанию для планирования восходящих сервисов на CMTS uBR Cisco. Этот планировщик был разработан для уменьшения дрожания, которое испытывают UGS и потоки обслуживания RTPS. Однако этот планировщик все еще позволяет вам поддерживать определенную степень гибкости для оптимизации количества одновременных вызовов UGS на восходящий.

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

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

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

DOCSIS - совместимый планировщик является единственным доступным восходящим алгоритмом планировщика для Cisco IOS Software Release 12.3 (9a) BCx и ранее. Поэтому этот планировщик не требует никаких команд настройки для активации.

Для Cisco IOS Software Release 12.3 (13a) BC и позже, DOCSIS - совместимый планировщик является одним из двух альтернативных алгоритмов планировщика, но установлен как планировщик по умолчанию. Можно включить DOCSIS - совместимого планировщика для одного, всех или некоторых из этих типов планирования:

  • UGS

  • RTPS

  • NRTPS

Можно явно включить DOCSIS - совместимого планировщика для каждого из этих типов планирования с кабелем восходящий тип планирования восходящего порта [nrtps | rtps | ugs] команда кабельного сопряжения docsis режима.

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

Контроль доступа

Большое преимущество DOCSIS - совместимого планировщика состоит в том, что этот планировщик гарантирует, что потоки обслуживания UGS не переделывают, подписывают восходящий. Если новый поток обслуживания UGS должен быть установлен, и планировщик обнаруживает, что предварительный список предоставлений не возможен, потому что никакую комнату не покидают, CMTS отклоняет новый поток обслуживания UGS. Если потокам обслуживания UGS, которые передают Трафик VoIP, позволяют превысить намеченную сумму канала передачи от клиента, качество всех вызовов VoIP становится сильно ухудшенным.

Чтобы продемонстрировать, как DOCSIS - совместимый планировщик гарантирует, что потоки обслуживания UGS никогда не превышают намеченную сумму восходящего, обратитесь к рисункам в этом разделе. Рисунки 7, 8 и 9 показывают линии времени распределения пропускной способности.

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

Рисунок 7 – DOCSIS - совместимый планировщик предварительно планирует три потока обслуживания UGS

/image/gif/paws/69704/upstrm_sch_config_07.gif

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

Рисунок 8 – DOCSIS - совместимый планировщик предварительно планирует пять потоков обслуживания UGS

/image/gif/paws/69704/upstrm_sch_config_08.gif

Если вы идете вперед и добавляете еще два потока обслуживания UGS, вы заполняете всю доступную пропускную способность восходящего канала.

Рисунок 9 – потоки обслуживания UGS используют всю доступную пропускную способность восходящего канала

/image/gif/paws/69704/upstrm_sch_config_09.gif

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

Примечание: Невозможно полностью заполнить восходящий потоками обслуживания UGS, как замечено в этой серии рисунков. Планировщик должен принять другие важные типы трафика, например, пакеты Keepalive обслуживания станции и максимально эффективный трафик данных. Кроме того, гарантия для предотвращения превышения подписки с DOCSIS - совместимым планировщиком только применяется, если все режимы планирования потока обслуживания, а именно, UGS, RTPS и NRTPS, используют DOCSIS - совместимого планировщика.

Несмотря на то, что явная конфигурация контроля доступа не необходима при использовании DOCSIS - совместимого планировщика Cisco рекомендует гарантировать, что использование восходящего канала не повышается к уровням, которые могут негативно повлиять на трафик категории Best effort. Cisco также рекомендует, чтобы общее использование восходящего канала не превышало 75% для значительных частей времени. Это - уровень восходящего использования, где максимально эффективные сервисы начинают испытывать много более длительной задержки и более медленной пропускной способности. Сервисы UGS все еще работают, независимо от восходящего использования.

Если вы хотите ограничить объем трафика, который допускают на определенном восходящем, настройте контроль доступа для UGS, RTPS, NRTPS, UGS-AD или потоков данных максимально эффективного сервиса с глобальным, на кабельное сопряжение или на восходящую команду. Самый важный параметр является полем монопольного порогового процента.

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

Вот параметры:

  • [в восходящем направлении <восходящий number>]: Задайте этот параметр, если вы хотят применить команду к определенному восходящему, а не кабельному сопряжению или глобально.

  • <UGS|AD-UGS|RTPS|NRTPS|BE>: Этот параметр задает режим планирования потоков обслуживания, к которым вы хотите применить контроль доступа.

  • <незначительный пороговый процент>: Этот параметр указывает на процент от восходящего использования настроенным типом планирования, в котором второстепенный сигнал передается станции управления сетью.

  • <главный пороговый процент>: Этот параметр задает процент от восходящего использования настроенным типом планирования, в котором основной сигнал передается станции управления сетью. Это значение должно быть выше, чем значение, которое вы устанавливаете для <незначительный пороговый процент> параметр.

  • <монопольный пороговый процент>: Этот параметр представляет процент от восходящего использования, исключительно зарезервированного для указанного типа планирования. Если вы не задаете значение для <non-excl-threshold-percent>, это значение представляет ограничение максимального значения на использовании для этого типа служебного потока. Это значение должно быть больше, чем <главный пороговый процент> значение.

  • <non-excl-threshold-percent>: Этот параметр представляет процент от восходящего использования выше <монопольный пороговый процент>, который этот тип планирования может использовать, пока другой тип планирования уже не использует его.

Например, предположите, что вы хотите ограничить потоки обслуживания UGS 60% общей доступной пропускной способности восходящего канала. Также предположите, что вам уведомили станции управления сетью, что, если процент от восходящего использования из-за потоков обслуживания UGS повысился на более чем 40%, второстепенный сигнал должен быть передан и более чем 50%, основной сигнал должен быть передан. Введите следующую команду:

тип планирования нас-пропускной-способности admission-control кабеля второстепенные UGS 40 главных 50 монопольных 60

Планирование Трафика категории Best effort с помощью Фрагментации

DOCSIS - совместимый планировщик просто планирует трафик категории Best effort вокруг предварительно выделенного UGS или предоставлений RTPS. Рисунки в этом разделе демонстрируют это поведение.

Рисунок 10 – планирование ожидания предоставлений оптимального уровня

/image/gif/paws/69704/upstrm_sch_config_10.gif

Рисунок 10 показывает, что восходящий имеет три потока обслуживания UGS с тем же размером предоставления и заранее запланированным интервалом предоставления. Восходящий получает запросы полосы пропускания от имени трех отдельных потоков обслуживания, A, B и C. Поток обслуживания запросы, средняя сумма времени передачи, поток обслуживания B запрашивает малую величину времени передачи и C потока обслуживания, запрашивает большое количество времени передачи.

Равный приоритет соглашения к каждому из потоков данных максимально эффективного сервиса. Кроме того, предположите, что CMTS получает запросы полосы пропускания для каждого из этих предоставлений в заказе A тогда B, и затем C. CMTS сначала выделяет время передачи для предоставлений в том же заказе. Рисунок 11 показывает, как DOCSIS - совместимый планировщик выделяет те предоставления.

Рисунок 11 – предоставления оптимального уровня, запланированные вокруг неподвижных предоставлений потока обслуживания UGS

/image/gif/paws/69704/upstrm_sch_config_11.gif

Планировщик в состоянии сжать предоставления на A и B вместе в разрыве между первыми двумя блоками предоставлений UGS. Однако предоставление на C больше, чем какой-либо доступный разрыв. Поэтому DOCSIS - совместимый планировщик фрагментирует предоставление на C вокруг третьего блока предоставлений UGS в два меньших предоставления по имени C1 и C2. Фрагментация предотвращает задержки предоставлений UGS и гарантирует, что эти предоставления не подвергаются дрожанию тот трафик категории Best effort причины.

Фрагментация немного увеличивает издержки протокола DOCSIS, привязанные к передаче данных. Для каждого дополнительного переданного фрагмента должен также быть передан дополнительный набор заголовков DOCSIS. Однако без фрагментации планировщик не может эффективно чередовать предоставления оптимального уровня между неподвижными предоставлениями UGS. Фрагментация не может произойти для кабельных модемов, которые работают в Режиме DOCSIS 1.0.

Приоритет

DOCSIS - совместимый планировщик размещает предоставления, которые ждут выделения в очереди на основе приоритета потока обслуживания, которому принадлежит предоставление. Существует восемь приоритетов DOCSIS с нолем как самое низкое и семь как самое высокое. Каждый из этих приоритетов имеет cвязанную очередь.

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

Например, предположите, что DOCSIS - совместимый планировщик получает пять предоставлений за короткий период в заказе A, B, C, D, E и F. Очереди планировщика каждое из предоставлений в очереди, которая соответствует приоритету потока обслуживания предоставления.

Рисунок 12 – предоставляет с другими приоритетами

upstrm_sch_config_12.gif

DOCSIS - совместимый планировщик планирует предоставления оптимального уровня вокруг заранее запланированных предоставлений UGS, которые появляются как скопированные блоки на рисунке 12. Первое действие DOCSIS - совместимые взятия планировщика должно проверить очередь наивысшего приоритета. В этом случае приоритет 7 очередей имеет предоставления, готовые планировать. Планировщик идет вперед и выделяет время передачи для предоставлений B и E. Заметьте, что предоставление E требует фрагментации так, чтобы предоставление не вмешивалось в синхронизацию предварительно выделенных предоставлений UGS.

Рисунок 13 – приоритет планирования 7 предоставлений

/image/gif/paws/69704/upstrm_sch_config_13.gif

Планировщик удостоверяется, что весь приоритет 7 предоставлений получает время передачи. Затем планировщик проверяет приоритет 6 очередей. В этом случае приоритет, 6 очередей пусты так планировщик, переходит к приоритету 5 очередей, которые содержат C предоставления.

Рисунок 14 – приоритет планирования 5 предоставлений

/image/gif/paws/69704/upstrm_sch_config_14.gif

Планировщик тогда продолжается подобной формой через очереди с более низким приоритетом, пока все очереди не пусты. Если существует большое число предоставлений для планирования, новые запросы полосы пропускания могут достигнуть CMTS, прежде чем DOCSIS - совместимый планировщик закончит выделение времени передачи ко всем предоставлениям в состоянии ожидания. Предположите, что CMTS получает запрос полосы пропускания G приоритета 6 на этом этапе в примере.

Рисунок 15 – Приоритет 6 Гранта Помещен в очередь

/image/gif/paws/69704/upstrm_sch_config_15.gif

Даже при том, что предоставления A, F и D ждут дольше, чем недавно предоставление с очередями G, DOCSIS - совместимый планировщик должен затем выделить время передачи G, потому что G имеет более высокий приоритет. Это означает, что следующие распределения пропускной способности DOCSIS - совместимого планировщика будут G, тогда D (см. рисунок 16).

Рисунок 16 – приоритет планирования 6 и приоритет 2 предоставления

/image/gif/paws/69704/upstrm_sch_config_16.gif

Следующее предоставление, которое будет планироваться, является F, если вы предполагаете, что никакие предоставления более высокого приоритета не вводят систему массового обслуживания тем временем.

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

Нефрагментируемые предоставления DOCSIS 1.0

От примеров в предыдущем разделе предоставления иногда должны фрагментироваться во множественные части, чтобы гарантировать, что дрожание не вызвано в предварительно выделенных предоставлениях UGS. Это может быть проблемой для кабельных модемов, которые воздействуют в Режиме DOCSIS 1.0 на восходящие сегменты со значительной частью трафика UGS, потому что Кабельный модем DOCSIS 1.0 может попросить передавать кадр, который является слишком большим для вписываний в следующую доступную возможность передачи.

Вот другой пример, который предполагает, что планировщик получает новые предоставления A и B в том заказе. Также предположите, что оба предоставления имеют тот же приоритет, но что предоставление B для кабельного модема, который работает в Режиме DOCSIS 1.0.

Рисунок 17 – DOCSIS 1.1 и DOCSIS 1.0, ожидающий предоставления

/image/gif/paws/69704/upstrm_sch_config_17.gif

Планировщик пытается выделить время для предоставления первое. Затем планировщик пытается выделить следующую доступную возможность передачи для предоставления B. Однако нет никакой комнаты для предоставления B, чтобы остаться нефрагментированной между A и следующим блоком предоставлений UGS (см. рисунок 18).

Рисунок 18 – предоставление DOCSIS 1.0 B задержанный

upstrm_sch_config_18.gif

Поэтому предоставление B задержано до окончания второго блока предоставлений UGS, где существует комната для предоставления B для адаптации. Заметьте, что существует теперь неиспользуемое пространство перед вторым блоком предоставлений UGS. Использование кабельных модемов на этот раз для передачи запросов полосы пропускания к CMTS но это представляет неэффективное использование пропускной способности.

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

Рисунок 19 – Предоставление DOCSIS 1.0 B не Может Планироваться

/image/gif/paws/69704/upstrm_sch_config_19.gif

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

Для преодоления этой проблемы с крупными нефрагментируемыми предоставлениями DOCSIS 1.0 DOCSIS - совместимый планировщик периодически предварительно планирует блоки восходящего времени, столь же большого как самый большой кадр, который может передать Кабельный модем DOCSIS 1.0. Планировщик делает так, прежде чем любые потоки обслуживания UGS планируются. На этот раз, как правило, эквивалент приблизительно 2000 байтов восходящей передачи и назван “нефрагментируемым Блоком” или “свободным блоком UGS”.

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

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

Рисунок 20 – нефрагментируемый Блок: Никакие Дальнейшие Предоставления UGS нельзя Допустить

/image/gif/paws/69704/upstrm_sch_config_20.gif

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

Возвратитесь к примеру предоставления A и Предоставления DOCSIS 1.0 B, вы видите, что с нефрагментируемым блоком на месте, DOCSIS - совместимый планировщик может теперь успешно планировать предоставление B после первого блока предоставлений UGS.

Рисунок 21 – планирующие предоставления с использованием нефрагментируемого блока

/image/gif/paws/69704/upstrm_sch_config_21.gif

Несмотря на то, что DOCSIS 1.0 допускает, что B успешно планируется, существует все еще маленький разрыв неиспользуемого пространства между предоставлением A и первым блоком предоставлений UGS. Этот разрыв представляет субоптимальное использование пропускной способности и демонстрирует, почему необходимо использовать кабельные модемы Режима DOCSIS 1.1 при развертывании сервисов UGS.

Cable default-phy-burst

По умолчанию на CMTS uBR Cisco, самый большой пакет, который может передать кабельный модем, составляет 2000 байтов. Это значение для самого большого размера восходящего блока используется для вычисления размера нефрагментируемого блока как DOCSIS - совместимое использование планировщика.

Можно изменить самый большой размер пакета с default-phy-burst кабеля max-bytes-allowed-in-burst на команду кабельного сопряжения.

Параметр <max-bytes-allowed-in-burst> имеет диапазон от 0 до 4096 байтов и значение по умолчанию 2000 байтов. Существуют некоторые важные ограничения на то, как необходимо установить это значение, если вы хотите изменить значение от значения по умолчанию.

Для кабельных сопряжений на линейной карте MC5x20S сделайте "not set" этот параметр выше по умолчанию 2000 байтов. Для всех других типов линейной карты, включая MC28U, MC5x20U и линейные карты MC5x20H, можно установить этот параметр целых 4000 байтов.

Сделайте "not set" параметр <max-bytes-allowed-in-burst> ниже, чем размер самого большого одиночного Фрейма Ethernet, который кабельный модем может должен быть передать включая DOCSIS или 802.1q издержки. Это означает, что это значение должно быть не ниже, чем приблизительно 1540 байтов.

При установке <max-bytes-allowed-in-burst> в специальное значение 0 CMTS не использует этот параметр для ограничения размера восходящего блока. Необходимо настроить другие переменные для ограничения размера восходящего блока разумным пределом, таким как значение максимальна связанного блок данных в файле конфигурации DOCSIS или команда cable upstream fragment-force.

При изменении default-phy-burst кабеля для изменения размера максимального размера восходящего пакета, размер свободного блока UGS также модифицируется соответственно. Рисунок 22 показывает, что при сокращении значения default-phy-burst кабеля размер свободного блока UGS уменьшает, и следовательно DOCSIS - совместимый планировщик может позволить, что больше UGS обращается к восходящему. В данном примере уменьшите default-phy-burst кабеля от настройки по умолчанию 2000 к более низкому значению 1600 для предусмотрения пространства для еще одного потока обслуживания UGS для становления активными.

Рисунок 22 – уменьшенный Default-phy-burst уменьшает нефрагментируемый размер блока

/image/gif/paws/69704/upstrm_sch_config_22.gif

Сокращение максимального допустимого размера пакета с командой cable default-phy-burst может немного уменьшить эффективность восходящего для трафика категории Best effort, потому что эта команда сокращает количество кадров, которые могут быть связаны в одном пакете. Когда восходящий имеет большее число активных потоков обслуживания UGS, такое сокращение может также привести к увеличенным уровням фрагментации.

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

Иногда, максимальный размер пакета согласно конфигурации в “длинном” IUC modulation-profile кабеля применился к восходящему, может определить самый большой размер восходящего блока. Если максимальный размер пакета в профиле модуляции является меньше, чем значение default-phy-burst кабеля в байтах, это может произойти. Это - редкий сценарий. Однако при увеличении параметра default-phy-burst кабеля с по умолчанию 2000 байтов проверьте максимальный размер пакета в конфигурации “длинного” IUC, чтобы гарантировать, что это не ограничивает пакеты.

Другое ограничение к размеру восходящего блока - то, что максимум 255 минислотов может быть передан в одном пакете. Если размер временного подслота установлен в минимум 8 байтов, это может стать фактором. Минислот является самым маленьким модулем восходящей передачи в сети DOCSIS и обычно эквивалентен 8 или 16 байтам.

Нефрагментируемое дрожание слота

Другой способ настроить DOCSIS - совместимого планировщика для разрешения более высокого количества одновременных потоков UGS на восходящем состоит в том, чтобы позволить планировщику позволять большим пакетам нефрагментируемого трафика категории Best effort представлять малые величины дрожания к потокам обслуживания UGS. Можно сделать так с кабелем, восходящее восходящее количество unfrag-slot-jitter ограничивает val команду кабельного сопряжения.

В этой команде <val> задан в микросекундах и имеет значение по умолчанию ноля, что означает, что поведение по умолчанию для DOCSIS - совместимого планировщика не должно позволять нефрагментируемым предоставлениям вызывать дрожание для потоков обслуживания RTPS и UGS. Когда положительное нефрагментируемое дрожание слота задано, DOCSIS - совместимый планировщик может задержать предоставления UGS до <val> микросекунд от того, когда предоставление UGS должно идеально планироваться, и следовательно вызвать дрожание.

Это имеет тот же эффект как сокращение нефрагментируемого размера блока эквивалентом длины к количеству заданных микросекунд. Например, при поддержании значения по умолчанию для default-phy-burst (2000 байтов) и если вы задаете значение 1000 микросекунд для нефрагментируемого дрожания слота, нефрагментируемый блок уменьшает (см. рисунок 23).

Рисунок 23 – ненулевое нефрагментируемое дрожание слота уменьшает нефрагментируемый размер блока

/image/gif/paws/69704/upstrm_sch_config_23.gif

Примечание: Количество байтов, которым соответствует время с 1000 микросекундами, зависит от того, как быстро канал передачи от клиента настроен для работы посредством параметров настройки схемы модуляции и ширины канала.

Примечание: С ненулевым нефрагментируемым дрожанием слота DOCSIS - совместимый планировщик в состоянии увеличить число предоставлений UGS что восходящие поддержки подобной формой к наличию уменьшенного default-phy-burst.

Примечание: Возвратитесь к примеру с крупным предоставлением DOCSIS 1.1, которое что придерживавшийся большим нефрагментируемым DOCSIS 1.0 предоставляет, что B планирует на восходящем. Вы устанавливаете нефрагментируемое дрожание слота в 1000 микросекунд. DOCSIS - совместимый планировщик ведет себя как показано на рисунках в этом разделе.

Примечание: Во-первых, планировщик выделяет время передачи для предоставления A. Для этого планировщик фрагментирует предоставление в предоставления A1 и A2 так, чтобы адаптация предоставлений прежде и после первого блока UGS предоставила. Для планирования предоставления B, планировщик должен решить, может ли планировщик вместить нефрагментируемый блок в свободное место после A2 предоставления без задержки к следующему блоку предоставлений UGS больше, чем настроенное нефрагментируемое дрожание слота 1000 микросекунд. Эти данные показывают, что, если планировщик размещает предоставление B затем для предоставления A2, следующий блок трафика UGS задержан или пододвинут обратно больше чем на 1500 микросекунд. Поэтому планировщик не может разместить предоставление B непосредственно после A2 предоставления.

Рисунок 24 – Предоставление B Неспособный Планироваться Затем для Предоставления A2.

/image/gif/paws/69704/upstrm_sch_config_24.gif

Следующий шаг для DOCSIS - совместимого планировщика должен видеть, может ли следующий доступный разрыв принять предоставление B. Рисунок 25 показывает, что, если планировщик размещает предоставление B после второго блока предоставлений UGS, третий блок не задержан больше, чем настроенное нефрагментируемое дрожание слота 1000 микросекунд.

Рисунок 25 – предоставляет B, запланированный после второго блока предоставлений UGS

/image/gif/paws/69704/upstrm_sch_config_25.gif

Со знанием, что вставка предоставления B на этом этапе не вызывает недопустимое дрожание к предоставлениям UGS, DOCSIS - совместимый планировщик вставляет предоставление B и немного задерживает придерживающийся блок предоставлений UGS.

Рисунок 26 – нефрагментируемое Предоставление B Планируется, и Предоставления UGS Задержаны

/image/gif/paws/69704/upstrm_sch_config_26.gif

Выходные данные команд show

Можно использовать команду восходящего количества mac-scheduler interface-number show interface cable для измерения текущего статуса DOCSIS - совместимого планировщика. Вот пример выходных данных этой команды, как замечено на Cisco uBR7200VXR с линейной картой MC28U.

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

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

  • DOCSIS 1.1 MAC scheduler for Cable3/0/U0

    Первая линия выходных данных command указывает на входной порт, которому принадлежат данные.

  • Queue[Rng Polls] 0/128, 0 drops, max 1

    Эта линия показывает состояние очереди, которая подает пакеты Keepalive обслуживания станции или возможности ранжирования в DOCSIS - совместимого планировщика. 0/128 указывает, что в настоящее время существует ноль максимум из 128 возможностей ранжирования в состоянии ожидания в очереди.

    Счетчик отбрасываний указывает на число раз, возможность ранжирования не могла стояться в очереди, потому что эта очередь была уже полна (т.е. 128 возможностей ранжирования в состоянии ожидания). Если было большое число UGS или активных потоков обслуживания RTPS, отбрасывания здесь только, вероятно, произошли бы на восходящем с чрезвычайно большим числом кабельных модемов онлайн и. Когда планировщик претензии DOCSIS выполняется, эта очередь обслуживается с наивысшим приоритетом. Поэтому падения этой очереди очень маловероятны, но наиболее вероятный указывают на серьезное превышение подписки канала передачи от клиента.

    Max. счетчик указывает на максимальное число подарка элементов и в этой очереди, так как была в последний раз выполнена команда show interface cable mac-scheduler. Идеально это должно остаться максимально близко к нолю.

  • Queue[CIR Grants] 0/64, 0 drops, max 0

    Эта линия показывает состояние очереди, которая управляет предоставлениями на потоки обслуживания с минимальной заданной зарезервированной скоростью трафика. Другими словами, эта очередь сервисы предоставляет для потоков обслуживания Committedinformation rate (CIR) (гарантированная скорость передачи). 0/64 указывает, что в настоящее время существует ноль максимум из 64 предоставлений в состоянии ожидания в очереди.

    Счетчик отбрасываний указывает на число раз, предоставление CIR не могло стояться в очереди, потому что эта очередь была уже полна (т.е. 64 предоставления в очереди). Если UGS, RTPS и потоки обслуживания стиля CIR превышают намеченную сумму восходящего и могут указать на потребность в более строгом контроле доступа, отбрасывания могут накопиться здесь.

    Max. счетчик указывает на максимальное число предоставлений в этой очереди, так как была в последний раз выполнена команда show interface cable mac-scheduler. У этой очереди есть второй наивысший приоритет, таким образом, DOCSIS - совместимый планировщик выделяет время для элементов этой очереди перед сервисами планирования очереди оптимального уровня.

  • Queue[BE(w) Grants] x/64, y drops, max z

    Следующие восемь записей показывают состояние очередей, которые управляют предоставлениями на приоритет 7 через 0 потоков обслуживания. Поля в этих записях имеют то же значение как поля в элементе очереди CIR. Первой очередью, которая будет подана в этой группе, является BE (7), очередью и последним, которое будет подаваться, является BE (0) очередь.

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

  • Req Slots 36356057

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

  • Req/Data Slots 185165

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

    Запрос/Возможности данных совпадает с возможностями запроса полосы пропускания за исключением того, что кабельные модемы также в состоянии передать маленькие пакеты данных в эти периоды. Cisco uBR sery CMTSs в настоящее время не планируют реальный запрос/возможности данных.

  • Init Mtn Slots 514263

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

  • Stn Mtn Slots 314793

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

  • Short Grant Slots 12256, Long Grant Slots 4691

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

  • ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0, ATDMA UGS Grant Slots 0

    Эта линия представляет количество предоставлений данных, предлагаемых в режиме усовершенствованной системы параллельного доступа с разделением во времени (ATDMA) на восходящем. Если существуют кабельные модемы, которые работают в режиме DOCSIS 2.0, и они передают данные восходящего соединения, это количество должно непрерывно повышаться. Обратите внимание на то, что ATDMA отдельно составляет трафик UGS.

  • Awacs Slots 277629

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

  • Fragmentation count 41

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

  • Fragmentation test disabled

    Эта линия указывает, что не была вызвана команда test cable fragmentation. Не используйте эту команду в рабочей сети.

  • Средний коэффициент использования восходящего канала: 26%

    Эта линия показывает текущее использование восходящего канала передачами данных восходящего соединения. Это охватывает передачи, сделанные через короткий, долго, короткий ATDMA, ATDMA долго и предоставления UGS ATDMA. Значение вычисляется каждую секунду как прокручивающееся среднее число. Cisco рекомендует, чтобы это значение не превысило 75% на расширенной основе в течение времен пиковой нагрузки. В противном случае конечные пользователи могут начать замечать проблемы производительности с трафиком категории Best effort.

  • Средний процент слотов для создания конфликта: 73%

    Эта линия показывает процент восходящего времени, выделенного запросам полосы пропускания. Это составляет уравнение на сумму свободного времени в восходящем, и поэтому уменьшает, когда увеличивается процент Avg upstream channel utilization.

  • Среднее количество (в процентах) слотов исходного ранжирования: 2%

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

  • Средний процент минигнезд, потерянных на последних прерываниях MAP: 0%

    Эта линия указывает на процент восходящего времени, которое не планировалось, потому что CMTS был неспособен передать сообщение таблицы распределения пропускной способности к кабельным модемам своевременно. Этот параметр должен всегда быть близко к нолю, но может начать показывать большие значения в системах, которые имеют Загрузку ЦПУ чрезвычайна высокого.

  • Sched Table Rsv-state: Grants 0, Reqpolls 0

    Эта линия показывает количество потоков обслуживания стиля UGS (Предоставления) или потоки обслуживания стиля RTPS (Reqpolls), которые имеют предоставления, предварительно выделенные для них в DOCSIS - совместимом планировщике, но еще не активированные. Это происходит при перемещении кабельного модема с существующим UGS или потоками обслуживания RTPS от одного восходящего до другого посредством распределения нагрузки. Обратите внимание на то, что этот рисунок только применяется к предоставлениям, которые используют DOCSIS - совместимого планировщика, а не планировщика LLQ.

  • Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%

    Эта линия указывает на количество потоков обслуживания стиля UGS (Предоставления) или потоки обслуживания стиля RTPS (Reqpolls), которые имеют предоставления, предварительно выделенные для них в DOCSIS - совместимом планировщике для этого восходящего. Util является предполагаемым использованием общей доступной пропускной способности восходящего канала этими потоками обслуживания. Обратите внимание на то, что этот рисунок только применяется к предоставлениям, которые используют DOCSIS - совместимого планировщика, а не планировщика LLQ.

  • <Scheduling-type> : x SIDs, Reservation-level in bps y

    Эта линия указывает на количество <Типа планирования> потоки обслуживания или SID, которые присутствуют на восходящем и сумме пропускной способности в битах в секунду, которые резервировали эти потоки обслуживания. Если потоку обслуживания настроили минимальную зарезервированную скорость, для оптимального уровня и потоков обслуживания стиля RTPS, только зарезервирована пропускная способность.

Преимущества и недостатки DOCSIS - совместимого планировщика

Цель DOCSIS - совместимого планировщика состоит в том, чтобы минимизировать дрожание для UGS и потоков обслуживания стиля RTPS и также принять нефрагментируемые пакеты DOCSIS 1.0. Компромисс, который делает DOCSIS - совместимый планировщик для достижения этих целей - то, что максимальное число потоков обслуживания UGS, поддерживаемых на восходящий, является меньше, чем теоретическое максимальное значение, которое в восходящем направлении может физически поддержать DOCSIS, и тот трафик категории Best effort может подвергнуться степени фрагментации.

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

Например, никакой планировщик не может поддержать jitterless потоки обслуживания UGS, которые используют близко к 100%-й пропускной способности канала передачи от клиента и одновременно поддерживают большие нефрагментируемые связанные кадры от Модемов DOCSIS 1.0. В отношении дизайна DOCSIS - совместимого планировщика существует два важных момента для понимания.

  • 75% являются максимальным выбираемым восходящим использованием.

    Cisco нашел, что, когда восходящий последовательно выполняется в большем, чем 75%-е использование, включая использование вследствие к потокам обслуживания UGS, производительность трафика категории Best effort начинает заметно влияться. Это означает, что, если UGS и VoIP передача сигналов используют больше чем 75% восходящего, любой обычный IP - трафик, переданный потоками данных максимально эффективного сервиса, начинает страдать от добавленной задержки, которая вызывает заметно более низкую пропускную способность и времена отклика. Это снижение производительности в более высоких Уровнях использования является свойством, что самые современные системы сети множественного доступа совместно используют, например, Ethernet или Беспроводные локальные сети.

  • Когда, как правило, развертываемая ширина восходящего канала (от абонента к оператору) 3.2 МГц используется, DOCSIS - совместимый планировщик позволяет потокам обслуживания UGS использовать приблизительно до 75% канала передачи от клиента. Эти потоки обслуживания передают вызовы VoIP G.711.

Эти две точки дают некоторое понимание вопросов проектирования, которые были приняты во внимание, когда был создан DOCSIS - совместимый планировщик. DOCSIS - совместимый планировщик был разработан так, чтобы для типичных потоков обслуживания UGS (G.711) и с обычно развернутой шириной канала 3.2 МГц, вызов на восходящие пределы начал применяться в пределах 75%-й марки использования. Это означает, что планировщик успешно минимизирует дрожание и также позволяет целесообразное количество потоков обслуживания UGS в восходящем.

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

Можно настроить DOCSIS - совместимого планировщика для размещения увеличенного количества вызовов UGS на восходящий, хотя в ущерб дрожанию UGS и эффективности трафика категории Best effort. Для этого необходимо уменьшить параметр default-phy-burst кабеля до минимальной рекомендуемой настройки 1540 байтов. Если вы требуете дальнейшей интенсивности вызовов, устанавливаете кабель восходящий unfrag-slot-jitter в значение, такое как 2000 микросекунд. Однако Cisco не рекомендует эти параметры настройки обычно для рабочей сети.

Другое преимущество DOCSIS - совместимого планировщика состоит в том, что нет никакого обязательного требования, что операторы CMTS явно настраивают контроль доступа для UGS и потоков обслуживания стиля RTPS. Это вызвано тем, что метод планирования перед выделением устраняет возможность случайного превышения подписки. Даже при том, что дело обстоит так Cisco все еще предлагает, чтобы операторы гарантировали, что общее восходящее использование не превышает 75% для длительных периодов времени в течение часа пик. Поэтому Cisco рекомендует конфигурацию контроля доступа как оптимальный метод.

Один недостаток DOCSIS - совместимого планировщика - то, что фиксированная позиция предоставлений UGS может потребовать фрагментации предоставлений оптимального уровня, когда использование UGS высоко. В целом фрагментация не вызывает значимые проблемы производительности, но действительно приводит к незначительному увеличению в задержке для трафика категории Best effort и увеличения подарка служебной информации протокола на канале передачи от клиента.

Другой недостаток - то, что, когда Кабельные модемы DOCSIS 1.0 хотят сделать большие нефрагментируемые восходящие передачи, может быть задержка, прежде чем появится соответствующий разрыв между блоками заранее запланированных предоставлений UGS. Это может также привести к увеличению продолжительности задержки для трафика восходящего направления DOCSIS 1.0 и меньше оптимального использования доступного времени восходящей передачи.

Наконец, DOCSIS - совместимый планировщик разработан для работы лучше всего в средах, где все потоки обслуживания UGS совместно используют тот же размер предоставления и предоставляют интервал. Т.е. где все вызовы VoIP совместно используют тот же кодек, такой как G.711 пакетизации на 20 мс или на 10 мс, как произошел бы в основанной системе типичного Packetcable 1.0. Когда различные интервалы предоставлений и размеры присутствуют, емкость DOCSIS - совместимого планировщика поддержать большое число потоков обслуживания UGS уменьшает на восходящем. Кроме того, очень малая величина дрожания (меньше чем 2 мс) может произойти для некоторых предоставлений, поскольку планировщик пытается чередовать потоки обслуживания UGS с другими периодами и размерами.

Поскольку сети PacketCable MultiMedia (PCMM) становятся более распространенными, это может больше стать распространено для разнообразия кодеков VoIP с различными интервалами пакетирования, чтобы быть в одновременном функционировании. Этот тип среды может предоставить себя Планировщику Организации очереди Низкой задержки.

Планировщик организации очереди низкой задержки

Планировщик организации очереди низкой задержки (LLQ) был представлен в программном обеспечении Cisco IOS версии 12.3 (13a) BC. LLQ является альтернативным методом для планирования восходящих сервисов на CMTS uBR Cisco. Этот планировщик был разработан для максимизации количества UGS и потоков обслуживания стиля RTPS, которые восходящий может поддержать одновременно и также улучшить эффективность трафика категории Best effort в присутствии потоков обслуживания UGS. Компромисс является планировщиком LLQ, не делает гарантий в отношении дрожания для потоков обслуживания RTPS и UGS.

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

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

Использование слова “гарантирует” для на основе TDM система и “минимизированный” для системы на основе LLQ относительно дрожания и задержки. В то время как гарантия нулевой задержки и дрожания выбираема, компромисс - то, что такая система является обычно негибкой, трудной реконфигурировать и обычно неспособный легко адаптироваться к изменениям в состояниях сети.

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

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

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

Для Cisco IOS Software Release 12.3 (13a) BC и позже, планировщик LLQ является одним из двух альтернативных алгоритмов планировщика. Можно включить LLQ для одного, всех или некоторых из этих режимов планирования:

  • UGS

  • RTPS

  • NRTPS

Планировщик LLQ не включен по умолчанию. Необходимо явно включить планировщика LLQ для требуемых восходящих типов планирования. Используйте кабель восходящий тип планирования восходящего порта [nrtps | rtps | ugs] команда кабельного сопряжения llq режима.

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

Потоки обслуживания RTPS не имеют никаких жестких требований для дрожания, но потоки обслуживания UGS делают. В этом случае можно включить планировщика LLQ для потоков обслуживания RTPS и сохранить DOCSIS - совместимого планировщика для UGS.

Операция планировщика LLQ

Планировщик LLQ работает таким же образом как функция постановки в очередь с установлением приоритетa DOCSIS - совместимого планировщика с добавлением специальной очереди с низкой задержкой (LLQ), которая имеет приоритет по всем другим очередям.

Планировщик LLQ запускает таймер от имени всего активного UGS (и RTPS) потоки обслуживания стиля. Таймер собирается уйти один раз в “интервал предоставления”. Каждый раз, когда таймер истекает, предоставление UGS помещено в очередь в очереди LLQ. Когда это предоставление размещено в очередь LLQ, которая имеет высший приоритет, предоставление планируется в следующий вероятный момент, где существует свободное место.

Схемы в этом разделе показывают пример системы с тремя активными потоками обслуживания UGS с тем же интервалом предоставления. Рисунок 27 показывает таймеры для потоков обслуживания UGS слева, маркированного UGS-1 через UGS 3. Желтая стрелка перемещается в направлении по часовой стрелке. Когда желтая стрелка показывает вверх к красной точке, предоставление UGS добавлено к Очереди LLQ. Можно также видеть знакомые восемь очередей с приоритетами 0 через к 7 и новая очередь LLQ, которая берет приоритет над всеми ними. Наконец, вправо, линия времени распределения пропускной способности, которая описывает, как предоставления планируются на восходящем. Для добавленной ясности линия времени распределения пропускной способности включает указатель “текущего времени”. Этот указатель продвигается вдоль шкалы времени, поскольку продолжается пример.

Рисунок 27 – система массового обслуживания низкой задержки

upstrm_sch_config_27.gif

Первое событие, которое происходит, - то, что истекает таймер UGS-1, наверху оставленный. Соответствующее предоставление помещено в очередь в очереди LLQ. В то же время предоставление оптимального уровня под названием с приоритетом 2 помещено в очередь.

Рисунок 28 – Предоставление на UGS-1 и Приоритет 2 Предоставления A Помещено в очередь

/image/gif/paws/69704/upstrm_sch_config_28.gif

Планировщик LLQ теперь выделяет время передачи предоставлениям в состоянии ожидания в порядке очередности. Первое предоставление, которое получит время передачи, является предоставлением на UGS-1, который ждет в очереди LLQ. Предоставление A придерживается.

Рисунок 29 – UGS-1 Предоставления и Предоставление A являются Выделенным Временем передачи

/image/gif/paws/69704/upstrm_sch_config_29.gif

Следующее событие, которое произойдет, - то, что таймер UGS-2 истекает и заставляет предоставление на поток обслуживания UGS-2 быть помещенным в очередь в очереди LLQ. В то же время приоритет, 0 предоставлений B помещены в очередь и приоритет 6 C предоставления, помещен в очередь.

Таймер рисунка 30 - UGS-2 Истекает. Допускает, что B и C Помещены в очередь

/image/gif/paws/69704/upstrm_sch_config_30.gif

Планировщик LLQ еще раз выделяет время передачи в заказе приоритета предоставления, что означает, что сначала планировщик выделяет время предоставлению на UGS-2, затем на C предоставления, и наконец для предоставления B.

Рисунок 31 – Предоставляет UGS-2, C и B являются Выделенным Временем передачи

/image/gif/paws/69704/upstrm_sch_config_31.gif

Предположите, что никакие предоставления оптимального уровня не вводят планировщика некоторое время. Таймеры UGS каждый истекает несколько раз больше. Можно теперь видеть вид периода, с которым планировщик выделяет предоставления потокам обслуживания UGS. Они, кажется, равномерно расположены с интервалами. Предположите, что, когда предоставления появляются этот путь друг относительно друга на шкале времени распределения пропускной способности, они не испытывают значительного дрожания.

Рисунок 32 - UGS-1, UGS-2 и UGS 3 Получают много Предоставлений. Предоставление D Помещено в очередь

/image/gif/paws/69704/upstrm_sch_config_32.gif

Рисунок 32 указывает на идеальную позицию для следующего предоставления UGS-2. Если UGS-2 можно было разместить предоставление в это пятно, UGS-2 не испытает дрожания для предоставления. Заметьте, что существует все еще время для следующего предоставления UGS-2, которое будет помещено в очередь в очереди LLQ.

Рисунок 32 также указывает, что очень большой приоритет 0 предоставлений D только что ввел приоритет 0 очередей. Следующее действие взятия планировщика LLQ должно планировать время передачи для предоставления D.

Рисунок 33 отображает этот сценарий. Вейтесь часы передают немного точке, где следующее предоставление на UGS-2 помещено в очередь.

Рисунок 33 – Предоставление D Получает Время передачи. Предоставление на UGS-2 Помещено в очередь

/image/gif/paws/69704/upstrm_sch_config_33.gif

Предоставление D, кажется, планируется в то время, когда следующее предоставление UGS-2 должно планироваться для нулевого дрожания. Теперь вопрос состоит в том, почему планировщик LLQ позволяет предоставлению D планироваться в той точке и не задерживает предоставление D до окончания предоставления на UGS-2 или почему не фрагментирован D. Ответ - то, что планировщик LLQ не предварительно выделяет время передачи для потоков обслуживания UGS. Поэтому планировщик LLQ не знает заранее, куда предоставления UGS будут размещены в линию времени распределения пропускной способности. Планировщик LLQ не знает о предоставлениях UGS, пока они не помещены в очередь в очереди LLQ. В данном примере, к тому времени, когда предоставление на UGS-2 входит в очередь, предоставление D уже планируется.

Планировщик LLQ планирует предоставление на UGS-2 в следующей доступной возможности, но это предоставление немного задержано от идеальной позиции, которая по определению означает, что это определенное предоставление испытывает некоторое дрожание.

Рисунок 34 – Предоставление на UGS-2 Задержано и Дрожание Опыта

/image/gif/paws/69704/upstrm_sch_config_34.gif

В то время как DOCSIS - совместимый планировщик, возможно, избежал этого дрожания, планировщик LLQ избегает задержки или фрагментации предоставления D за счет только малой величины дрожания. Буфер дрожания в оконечной точке VoIP может легко компенсировать это дрожание.

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

Согласно DOCSIS - совместимому планировщику, планировщик LLQ имеет еще две очереди, которые не упоминают примеры. Вот очереди:

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

  2. Второй является очередь для предоставлений, выделенных потокам обслуживания с минимальной зарезервированной скоростью (потоки обслуживания CIR). Эта очередь CIR обработана как “приоритет 8” очередей, чтобы гарантировать, что потоки обслуживания с фиксированной скоростью получают свою требуемую минимальную пропускную способность.

Контроль доступа

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

Cisco обычно предлагает, чтобы вы не позволяли использованию канала передачи от клиента превышать 75% для длительных периодов времени в течение периодов пиковой нагрузки. Например, если трафик UGS использует больше чем 75% пропускной способности восходящего канала, данные оптимального уровня начинают страдать с проблем производительности пропускной способности и избыточной задержки.

Естественно, если оператор CMTS может принять негативные последствия для трафика категории Best effort, можно позволить потокам обслуживания UGS использовать более высокое, чем 75% доступной пропускной способности восходящего канала. Однако необходимо также рассмотреть влияние на трафик управления Уровня 2 на канале передачи от клиента. Необходимо позволить время для начальной буквы и обмена сообщениями обслуживания станции (пакеты Keepalive кабельного модема). Если вы не принимаете это во внимание, и трафик UGS использует близко к 100% пропускной способности, кабельные модемы не могут прибыть онлайн или могут упасть офлайн.

Вот пример конфигурации для контроля доступа. Данный пример ограничивает потоки обслуживания UGS на определенном восходящем к 50% доступной пропускной способности восходящего. Когда незначительные и крупнейшие пороги 30%-го и 40%-го использования достигнуты, эта форма команды также передает trap-сообщения SNMP к любым настроенным сетевым станциям управления. Используйте команду:

кабель восходящий тип планирования нас-пропускной-способности admission-control восходящего количества второстепенные UGS 30 главных 40 монопольных 50

Посмотрите раздел Контроля доступа под DOCSIS - совместимым разделом Планировщика этого документа для того, как настроить контроль доступа.

Выходные данные команд show

Выполните команду восходящего количества mac-scheduler interface-number show interface cable для измерения текущего статуса планировщика LLQ.

Вот пример выходных данных этой команды. Части выходных данных command, которые отличаются от того, когда DOCSIS - совместимый планировщик в рабочем состоянии, являются полужирным текстом:

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

Для пояснения линий открытого текста в этих выходных данных посмотрите раздел Выходных данных команды show для DOCSIS - совместимого Планировщика.

Вот описания для жирных линий выходных данных команды show:

  • Queue[LLQ Grants] 0/64, 0 drops, max 3

    Эта линия показывает состояние очереди LLQ, которая управляет предоставлениями на типы потока обслуживания, заданные в команде cable upstream scheduling type [nrtps | rtps | ugs] mode llq. 0/64 указывает, что в настоящее время существует ноль максимум из 64 предоставлений в состоянии ожидания в очереди.

    Счетчик отбрасываний указывает на число раз, планировщик был неспособен поместить в очередь предоставление UGS или опрос RTPS, потому что эта очередь была уже полна (другими словами, когда 64 предоставления находятся в очереди). Если отбрасывания происходят в этой очереди, наиболее вероятное пояснение - то, что восходящий превышен с UGS или потоками обслуживания RTPS, и необходимо применить более строгий контроль доступа.

    Max. счетчик указывает на максимальное число предоставлений, которые находятся в этой очереди, так как была в последний раз выполнена команда show interface cable mac-scheduler. Когда подарок, у этой очереди есть наивысший приоритет всех перечисленных очередей.

  • r4k ticks in 1ms 600000

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

  • Total scheduling events 5009

    Эта линия указывает на число раз, планировщик LLQ пытается поместить предоставление в очередь начиная с прошлый раз, команда show interface cable mac-scheduler была выполнена для этого восходящего. Этот счетчик перезагружен каждый раз, когда команда показа выполнена.

  • No search was needed 5009

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

  • Previous entry free 0, Next entry free 0

    Ни один из этих счетчиков никогда не инкрементно увеличивается в текущих релизах программного обеспечения Cisco IOS. Эти счетчики всегда остаются в ноле.

  • Could not schedule 0, Recovery failed 0

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

  • Curr time 1341 entry 61

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

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

  • Entry 188, Bin 13

    Когда значение “Записи” равно полю “записи” в предыдущем элементе, таймер для этого потока обслуживания истекает, и предоставление входит в очередь LLQ. Это поле перезагружает каждый раз, когда потоку обслуживания поместили предоставление в очередь.

  • SID: 416

    Идентификатор сервиса (SID) для потока обслуживания, чьи предоставления списки планировщика LLQ.

  • IUC: 5

    Свод правил использования временных интервалов дал объявление в сообщении MAP для предоставлений, которые принадлежат этому потоку обслуживания. Когда поток обслуживания стиля UGS используется, это почти всегда 5 для “коротких данных”, 6 для “Длинных Данных” или 11 для “Усовершенствованного UGS PHY”. Для потока обслуживания стиля RTPS это значение всегда 1 для “Запроса”.

  • size_ms: 17 size_byte: 232

    Размер предоставления в минислотах, придерживавшихся размером предоставления в байтах. Минислот является самым маленьким модулем восходящей передачи в сети DOCSIS и обычно эквивалентен 8 или 16 байтам.

  • Frag: N

    Указывает, является ли предоставление fragmentable. В настоящее время это значение всегда установлено к N.

  • Inval: 20

    Предоставление или интервал опроса в миллисекундах.

  • type 8

    8 указывает, что этот поток обслуживания является UGS, 10 указывает, что RTPS и 11 указывает на NRTPS.

  • perfect time ref 188

    Идеальное время, когда, должно быть, планировалось это предоставление. Это обычно - то же как “Запись” наверху. В противном случае существует индикация относительно в большой степени переполненного восходящего, который требует более строгого контроля доступа.

  • skew from ref 0

    Различие между тем, когда это предоставление планировалось и когда идеально, должно быть, планировалось предоставление. Это - различие между “Записью” и “совершенное время касательно”. Поэтому это значение должно обычно быть нолем.

  • priority 10

    В текущих релизах программного обеспечения Cisco IOS это значение всегда установлено к 10, но может варьироваться по будущему.

  • position 188, bin 13

    Эти поля должны совпасть с “Записью, Bin” наверху этого списка.

Преимущества и недостатки планировщика LLQ

Цель планировщика LLQ состоит в том, чтобы увеличить UGS и емкость RTPS для каналов передачи от клиента, и увеличить эффективность трафика категории Best effort. Компромисс, который делает планировщик LLQ для достижения этих целей - то, что этот планировщик явно не дает гарантии UGS и дрожания потока обслуживания RTPS. Скорее планировщик LLQ планирует предоставления UGS и опросы RTPS максимально близко к идеальному времени, в целях минимизируют дрожание.

Планировщик LLQ также в состоянии лучше обработать множественные потоки обслуживания UGS через другие интервалы предоставления и размеры предоставления, чем DOCSIS - совместимый планировщик. Эта функция может быть полезной в среде PCMM, где различные типы вызовов VoIP и возможно других приложений все одновременно подаются на одном канале передачи от клиента.

Планировщик LLQ планирует трафик категории Best effort более эффективно, потому что планировщик LLQ уменьшает вероятность фрагментации предоставлений. Когда нефрагментируемые пакеты DOCSIS 1.0 планируются, планировщик LLQ не создает разрывы неиспользуемой пропускной способности перед предоставлениями UGS, или опросы RTPS как DOCSIS - совместимый планировщик иногда делает. Это приводит к лучшему использованию доступного восходящего времени.

Несмотря на то, что дрожание UGS обычно выше при использовании планировщика LLQ чем тогда, когда вы используете DOCSIS - совместимого планировщика в типичном DOCSIS или основанных на PacketCable сетях, уровни дрожания планировщика LLQ хорошо в емкости технологии буферизации дрожания конечной точки VoIP. Это означает, что нет никакого значимого влияния на качество вызова VoIP при использовании планировщика LLQ в должным образом разработанной Сети VoIP.

Можно ограничить дрожание, которое проистекает из больших восходящих блоков. Для этого гарантируйте хранение параметра default-phy-burst кабеля в значении по умолчанию 2000 байтов или меньше. Если система использует особенно медленный канал передачи от клиента, SAID с 800 кГц или меньшей шириной канала, можно достигнуть дальнейших сокращений дрожания, если вы вынуждаете большие пакеты быть фрагментированными в меньшие с командой cable upstream fragment-force.

Когда планировщик LLQ используется, необходимо настроить контроль доступа кабеля для предотвращения вероятности превышения лимита подписки канала передачи от клиента. Более активные потоки обслуживания UGS, чем восходящий могут физически обработать, приводит к низкому качеству голосовой связи по всем потокам обслуживания UGS на восходящем. В наихудших ситуациях это также означает, что кабельные модемы падают, офлайновые и новые кабельные модемы неспособны прибыть онлайн. Cisco рекомендует, чтобы операторы CMTS настроили контроль доступа так, что, общее восходящее использование на любом входном порту не выше 75% для длительных периодов времени.

Заключения

Cisco uBR sery продуктов DOCSIS ДЛЯ CMTS предоставляют два альтернативных восходящих алгоритма планирования, и так в состоянии обслужить множество состояний сети.

DOCSIS - совместимый планировщик, который оптимизирован для малых колебаний задержки, больше всего подходит для типичного Packetcable 1.x системы голосовой связи с универсальным кодеком VoIP на месте и где требуются стандартные уровни использования восходящего канала потоками обслуживания UGS.

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

Приложение А: Минислоты

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

Максимальное число минислотов, которые модем может запросить передать в одном пакете, 255. Размер временного подслота задан в модулях, названных галочками DOCSIS. Галочка DOCSIS является эквивалентом 6.25 микросекунд своевременно.

Для установки размера временного подслота в галочках для входного порта выполните кабель в восходящем направлении <размер временного подслота восходящего number> [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128] команда кабельного сопряжения.

Только определенные, некоторый размеры временного подслота позволены с определенными ширинами восходящего канала (от абонента к оператору). Эта таблица показывает допустимые размеры временного подслота по сравнению с ширинами восходящего канала (от абонента к оператору) DOCSIS, и также показывает длину в символах схемы модуляции минислота с допустимыми параметрами настройки.

Примечание: X марки показывают недопустимую комбинацию.

  Ширина канала 200 кГц 400 кГц 800 кГц 1. 6 МГц 3.2 МГц 6.4 МГц
Размер временного подслота в галочках              
1   X X X X X 32
2   X X X X 32 64
4   X X X 32 64 128
8   X X 32 64 128 256
16   X 32 64 128 256 X
32   32 64 128 256 X X
64   64 128 256 X X X
128   128 256 X X X X

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

Схемы модуляции TDMA DOCSIS 1.1 Биты на символ
QPSK 2
С 16 QAM 4

Схемы модуляции ATDMA DOCSIS 2.0 Биты на символ
С 8 QAM 3
С 32 QAM 5
С 64 QAM 6

Например, с шириной канала на 1.6 МГц и размером временного подслота 4 галочек, можно использовать первую таблицу для достижения рисунка 32 символов на минислот. Используйте вторую таблицу для преобразования этого рисунка в байты, потому что символ QPSK содержит 2 бита. Один минислот в данном примере эквивалентен 32 символам на минислот * 2 бита за символ = 64 бита за минислот = 8 байтов за минислот.

Помните, что максимальное число минислотов, которые кабельный модем может запросить передать, 255. Поэтому в данном примере в восходящем направлении самый большой пакет в байтах, которые может сделать модем, является 255 минислотами * 8 байтов за минислот = 2040 байтов.

Обратите внимание на то, что этот рисунок в байтах является почтовым прямым исправлением ошибок и почтовым рисунком служебных сигналов физического уровня. Исправление ошибок и другие издержки уровня PHY DOCSIS добавляют приблизительно 10 - 20 процентов к длине Фрейма Ethernet, поскольку это проходит через канал передачи от клиента. Для получения точного рисунка использование, профиль модуляции применился к входному порту.

Это обсуждение является значительным, потому что более ранний раздел этого документа сообщает, что один из пределов на максимальном размере пакета кабельного модема является значением, настроенным в команде cable default-phy-burst. Если команда cable default-phy-burst установлена в 4000 байтов в контексте данного примера, ограничивающий фактор или размер пакета являются 255 пределами минислота (издержки на 2040 байтов минус), а не значение default-phy-burst кабеля.

Можно наблюдать другие выражения размера временного подслота для восходящего с interface-number кабеля контроллера показа восходящая команда восходящего количества. Например:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

Cisco рекомендует установить размер временного подслота так, что, минислот эквивалентен 16 байтам или самое близкое допустимое значение. Размер временного подслота 16 байтов дает кабельным модемам возможность генерировать почтовый пакет FEC до 255 * 16 = 4096 байтов.

Приложение Б: Продвижение отображения

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

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

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

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

  • Время, когда электрические сигналы берут для перемещения через сеть HFC от CMTS до кабельного модема и затем назад снова. DOCSIS задает максимум one-way-trip-time между CMTS и кабельным модемом 800 микросекунд. Это значение варьируется в зависимости от физической длины кабельного участка. Схема нисходящей модуляции и ширина восходящего канала (от абонента к оператору) и схема модуляции также влияют на это значение.

  • Время для кабельного модема, чтобы обработать полученное сообщение MAP и быть в состоянии подготовить к восходящей передаче. Это должно быть не больше, чем 200 микросекундами плюс любой восходящий interleaver задержка согласно рекомендациям в спецификации DOCSIS. В действительности на этот раз могут быть целых 300 микросекунд или всего 100 микросекунд в зависимости от того, чтобы делать, модели и редакции микропрограммного обеспечения кабельного модема.

Рисунок 35 – компоненты во время продвижения отображения

/image/gif/paws/69704/upstrm_sch_config_35.gif

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

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

Рисунок 36 показывает отношение между MAP, что CMTS генерирует и получение соответствующих данных в восходящем.

Рисунок 36 – отношение между генерацией MAP и получением данных восходящего соединения

/image/gif/paws/69704/upstrm_sch_config_36.gif

Глубина перемежителя

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

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

Я (Количество ответвителей) J (Инкремент) Задержка, с 64 QAM Задержка, с 256 QAM
8 16 220 �sec 150 �sec
16 8 480 �sec 330 �sec
32 4 980 �sec 680 �sec
64 2 2000 �sec 1400 �sec
128 1 4000 �sec 2800 �sec
12 (EuroDOCSIS) 17 (EuroDOCSIS) 430 �sec 320 �sec

Можно установить interleaver параметры с cable downstream interleave-depth [8 | 16 | 32 | 64 | 128] команда настройки кабельного сопряжения

Примечание: Значение, поскольку я (количество ответвителей) задан и неподвижное соответствующее значение для J (инкремент), как замечено в таблице автоматически, применяется. Кроме того, для EuroDOCSIS (приложение A) режим interleaver параметры исправлены во мне = 12 и J = 17. Значение по умолчанию, поскольку мне 32 года, который дает значение по умолчанию для J 4.

Round Trip Time

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

Мандаты спецификации DOCSIS, что максимум, допустимый один путь время распространения между CMTS и самым далеким кабельным модемом в системе быть не больше, чем 800 микросекундами. Это подразумевает Round Trip Time, исключая задержку обработки кабельного модема, приблизительно 1600 микросекунд.

Скорость света в вакууме составляет приблизительно 186,000 миль в секунду (300,000 километров в секунду), и скорость распространения для волокна, как правило, указывается как 0.67. Поэтому максимум, допустимый один путь расстояние между CMTS и кабельным модемом, приблизительно:

	Distance = Velocity * Time

       		 = (186,000 miles/sec * 0.67) * 800 microseconds

       		 = 100 miles or 161 kilometers.

Согласно спецификации DOCSIS задержка обработки кабельного модема не должна превышать 200 микросекунд плюс никакая задержка интервалов в восходящем направлении. Однако в редких случаях, некоторые более старые бренды кабельного модема могут занять целых 300 микросекунд для обрабатывания сообщения MAP. Более новые модемы типов кабеля с более мощными ЦПУ могут занять всего 100 микросекунд для обрабатывания сообщения MAP.

Предположите, что кабельные модемы, в среднем, совместимы со спецификацией DOCSIS. Поэтому максимальный Round Trip Time должен быть 1600 + 200 = 1800 микросекунд.

Большинство кабельных сетей намного короче, чем 100 миль. Поэтому это не оптимально для CMTS, чтобы всегда предположить, что электрический Round Trip Time между CMTS и самым далеким кабельным модемом является максимальным значением 1800 микросекунд.

Для приближенной оценки в течение самого большого ожидаемого электрического Round Trip Time сложите расстояние волокна между CMTS и кабельным модемом и умножьтесь на 16 микросекунд на милю (10 микросекунд на км). Затем сложите расстояние любого коаксильного кабеля и умножьте то значение на 12.4 микросекунд на милю (7.6 микросекунд на км). Затем добавьте задержку обработки с 200 микросекундами.

Например, сегмент HFC с в общей сложности 20 милями оптоволокна и один миля коаксильного кабеля между CMTS и самым далеким кабельным модемом могли ожидать электрическую задержку приема-передачи:

20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds
 
= 320 microseconds + 12.4 microseconds + 200 microseconds

= 532.4 microseconds

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

Больше точного способа для определения Round Trip Time в системе должно наблюдать “Временной сдвиг” для кабельных модемов, как замечено в выходных данных команды show cable modem. Как часть процесса ранжирования, что использование кабельных модемов для поддержания связи с CMTS CMTS вычисляет Round Trip Time для каждого кабельного модема. Этот Round Trip Time появляется как “Временной сдвиг” в выходных данных команды show cable modem в модулях 1/10.24MHz = 97.7 наносекунд, названных модули смещения ранжирования или временной сдвиг. Для преобразования временного сдвига для модема к микросекундам умножьте значение на 25/256, или очень примерно разделите значение на 10.

Вот пример, в котором временные сдвиги различных модемов в выходных данных команды show cable modem преобразованы в значение микросекунды:

Примечание: Значение микросекунды появляется курсивом.

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F       MAC         Prim RxPwr Timing  Num BPI
                                      State       Sid  (dB)  Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0   online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0   online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0   online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0   online(pt)  19   0.00  6030     0   Y  (589μs)

В этом случае самый далекий модем далеко электрически является последним модемом с временным сдвигом 6030. Это составляет уравнение к Round Trip Time 6030 * 25/256 = 589 микросекунд.

Продвижение статического сопоставления

В системе, где вы знаете, что длина сети HFC - значительно меньше чем 100 миль, можно настроить CMTS для использования максимального Round Trip Time, который является меньше, чем микросекунды стандарта 1800 года, когда вы вычисляете время Продвижения отображения.

Чтобы вынудить CMTS использовать значение custom в течение Round Trip Time в вычислении Продвижения отображения, выполните cable map-advance статическая max-round-trip-time команда кабельного сопряжения.

Диапазон для max-round-trip-time составляет 100 - 2000 микросекунд. Если никакое значение не задано для max-round-trip-time, по умолчанию 1800 микросекунд применяется.

Примечание: Можно заменить статическое ключевое слово динамическим ключевым словом. Посмотрите следующий раздел.

Удостоверьтесь, что указанный Round-trip-time действительно больше, чем самый большой CMTS к Round Trip Time кабельного модема на нисходящем канале. Если кабельный модем имеет больший Round Trip Time, чем заданный в max-round-trip-time, модем может найти трудным остаться онлайновым. Это вызвано тем, что такой модем не имеет достаточного времени для ответа на сообщение MAP и поэтому неспособен связаться с CMTS.

Если сдвиг времени кабельного модема, преобразованного в микросекунды, превышает указанный max-round-trip-time, модем отмечен с плохим флагом временного сдвига. Этот флаг смещения появляется как восклицательный знак (!) рядом с временным сдвигом кабельного модема в выходных данных команды show cable modem. Эта ситуация может произойти, если max-round-trip-time параметр установлен слишком низко или если кабельный модем страдает от проблемы, где ее временной сдвиг нестабилен и постоянно увеличивается в течение долгого времени.

Например:

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F      MAC         Prim RxPwr  Timing  Num BPI
                                     State       Sid  (dB)   Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0  online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0  online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0  online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0  online(pt)  19   0.00  !5120    0   Y  (500μs)

В данном примере задана команда cable map-advance static 500. Однако один из кабельных модемов, связанных с кабельным сопряжением, имеет временной сдвиг больших, чем 500 микросекунд (эквивалентный 500 * 256/25 = 5120 модулей временного сдвига).

Обратите внимание на то, что временной сдвиг последнего кабельного модема отмечен с плохим флагом временного сдвига, a “!”. Это также исправлено к максимальному позволенному значению 5120 модулей даже при том, что истинный временной сдвиг может быть намного выше. Этот кабельный модем может пойти офлайн и пострадать от низкой производительности.

Даже если временной сдвиг падает ниже max-round-trip-time, плохой флаг временного сдвига остается установленным для кабельного модема. Единственный способ очистить флаг состоит в том, чтобы удалить модем временно из списка show cable modem. Для этого можно использовать ясную команду delete mac-address модема кабеля. Также можно перезагрузить кабельное сопряжение или входной порт.

Для наблюдения операции алгоритма продвижения статического сопоставления на на восходящее основание выполните interface-number кабеля контроллера показа восходящая команда восходящего количества. Например:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group is overridden
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037
  Ranging Backoff automatic (Start 0, End 3)
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff automatic (Start 0, End 3)
  Modulation Profile Group 43
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 16
  Minislot Size in Symbols = 128
  Bandwidth Requests = 0x6ECEA
  Piggyback Requests = 0xDE79
  Invalid BW Requests= 0x63D
  Minislots Requested= 0x8DEE0E
  Minislots Granted  = 0x7CE03
  Minislot Size in Bytes = 32
  Map Advance (Static) : 3480 usecs
  UCD Count = 289392

Поле Map Advance (Static) показывает время продвижения отображения 3480 микросекунд. При изменении нисходящего interleaver характеристики или max-round-trip-time параметр изменение отражено в значении продвижения статического сопоставления.

Dynamic MAP Advance

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

Алгоритм усовершенствованного динамического отображения решает эту проблему. Алгоритм усовершенствованного динамического отображения периодически просматривает список show cable modem для поиска модема с самым большим временным сдвигом исходного ранжирования, и затем автоматически использует то значение для вычисления времени Продвижения отображения. Таким образом CMTS всегда использует самое низкое время продвижения отображения.

Временной сдвиг исходного ранжирования для кабельного модема является временным сдвигом, что модем является в точку, куда модем прибывает онлайн. В большинстве случаев это близко к на идущем временном сдвиге, как замечено в выходных данных команды show cable modem. Однако некоторые модемы типов кабеля имеют проблему, где временной сдвиг вползает вверх в течение долгого времени к очень большим значениям. Это может исказить вычисление времени продвижения отображения. Поэтому только временной сдвиг исходного ранжирования, который только обновлен, если модем прибывает онлайн, используется. Для просмотра временного сдвига исходного ранжирования и продолжающегося временного сдвига для кабельного модема выполните команду show cable modem verbose. Например:

uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose
MAC Address                         : 00aa.bbf3.7858
IP Address                          : 4.24.64.18
Prim Sid                            : 48
Interface                           : C5/1/U0
Upstream Power                      : 39.06 dBmV (SNR = 36.12 dB)
Downstream Power                    : 14.01 dBmV (SNR = 35.04 dB)
Timing Offset                       : 2566
Initial Timing Offset               : 2560
Received Power                      :  0.00 dBmV
MAC Version                         : DOC1.1
QoS Provisioned Mode                : DOC1.1
Enable DOCSIS2.0 Mode               : Y
Phy Operating Mode                  : tdma
Capabilities                        : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+}
Sid/Said Limit                      : {Max US Sids=16, Max DS Saids=15}
Optional Filtering Support          : {802.1P=N, 802.1Q=N}
Transmit Equalizer Support          : {Taps/Symbol= 1, Num of Taps= 8}
Number of CPE IPs                   : 0(Max CPE IPs = 16)
CFG Max-CPE                         : 32
Flaps                               : 4(Mar 13 21:13:50)
Errors                              : 0 CRCs, 0 HCSes
Stn Mtn Failures                    : 0 aborts, 1 exhausted
Total US Flows                      : 1(1 active)
Total DS Flows                      : 1(1 active)
Total US Data                       : 321 packets, 40199 bytes
Total US Throughput                 : 129 bits/sec, 0 packets/sec
Total DS Data                       : 28 packets, 2516 bytes
Total DS Throughput                 : 0 bits/sec, 0 packets/sec
Active Classifiers                  : 0 (Max = NO LIMIT)
DSA/DSX messages                    : permit all
Total Time Online                   : 1h00m

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

Для активации вычисления dynamic map advance выполните фактор безопасности cable map-advance dynamic команда кабельного сопряжения max-round-trip-time.

С 100 до 2000 микросекунд колеблется параметр фактора безопасности. Этот параметр добавлен ко времени Продвижения отображения, чтобы предоставить небольшую гарантию для составления любых дополнительных непредвиденных задержек сигнального распространения. Значение по умолчанию составляет 1000 микросекунд. Однако для стабильных кабельных сетей, которые не претерпевают значительные изменения на кабельном участке или в восходящем или характеристиках нисходящего канала, используйте минимальное значение, такое как 500 микросекунд.

С 100 до 2000 микросекунд колеблется max-round-trip-time параметр. Этот параметр используется в качестве верхнего предела для сдвигов времени кабельных модемов, связанных с сегментом кабеля. Значение по умолчанию составляет 1800 микросекунд. Если сдвиг времени кабельного модема, преобразованного в микросекунды, превышает указанный max-round-trip-time, это кажется отмеченным с плохим флагом временного сдвига.

Установите параметр времени Max. приема - передачи на значение по умолчанию non, когда вы знаете, что длина кабельной сети - значительно меньше чем 100 миль, и если вы знаете то, что должно быть максимальным смещением обычного времени для кабельных модемов, связанных с сегментом.

Наблюдайте операцию алгоритма усовершенствованного динамического отображения для на восходящее основание с interface-number кабеля контроллера показа восходящая команда восходящего количества. Например:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

Значение ошибки синхронизации Tx показывает самый большой временной сдвиг для всех кабельных модемов, связанных с восходящим в модулях временного сдвига. Используйте это значение для вычисления времени Продвижения отображения. Поле Map Advance (Dynamic) показывает результирующее время продвижения отображения. Это значение может варьироваться, если Временной сдвиг Tx изменяется, если значение безопасности модифицируется, или если изменен нисходящий interleaver характеристики.

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

Сообщения об ошибках, подобные %UBR7200-4-BADTXOFFSET: Bad timing offset -2 detected for cable modem 00ff.0bad.caf3, могут появиться на таких кабельных модемах. Эти модемы типов кабеля не сообщают о своих временных сдвигах DOCSIS - совместимым способом, алгоритм усовершенствованного динамического отображения не может правильно вычислить время продвижения отображения, которое, как гарантируют, даст каждый раз кабельного модема, чтобы получить и ответить на сообщения MAP.

Если такие кабельные модемы присутствуют на сегменте кабеля, отключают алгоритм усовершенствованного динамического отображения и возвращаются к алгоритму продвижения статического сопоставления. Обратитесь к тому, Почему Делают Некоторый Показ Кабельных модемов Отрицательное смещение времени? дополнительные сведения.

Связанные обсуждения сообщества поддержки Cisco

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


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


Document ID: 69704