Контроль параметров использования ( UPC ) и контроль сетевых параметров ( NPC ) — это функции, которые могут выполняться в компьютерной сети . UPC может выполняться на входе в сеть «для защиты сетевых ресурсов от вредоносного, а также непреднамеренного неправильного поведения». [1] NPC — это то же самое и выполняется по тем же причинам, что и UPC, но на интерфейсе между двумя сетями.
UPC и NPC могут включать в себя формирование трафика , при котором трафик задерживается до тех пор, пока он не будет соответствовать ожидаемым уровням и времени, или контроль трафика , при котором несоответствующий трафик либо немедленно отбрасывается, либо его приоритет снижается, чтобы его можно было отбросить ниже по течению в сети, если он может вызвать или усилить перегрузку .
Действия для UPC и NPC в протоколе ATM определены в Рекомендации ITU-T I.371 Управление трафиком и контроль перегрузки в B ISDN [2] и Спецификации интерфейса «пользователь-сеть» (UNI) Форума ATM . [3] Они предоставляют определение соответствия, используя форму алгоритма дырявого ведра , называемого алгоритмом общей скорости ячеек (GCRA), который определяет, как ячейки проверяются на соответствие скорости ячеек или ее обратному интервалу излучения, а также допустимому отклонению: либо допустимое отклонение задержки ячеек (CDVt) для проверки соответствия пиковой скорости ячеек (PCR), либо допустимое отклонение всплеска или максимальный размер всплеска (MBS) для проверки соответствия устойчивой скорости ячеек (SCR).
UPC и NPC определяют параметр максимального размера пакета (MBS) для средней или постоянной скорости передачи ячеек (SCR) и допуск вариации задержки ячеек (CDVt) для пиковой скорости передачи ячеек (PCR), при которой передаются пакеты. Этот MBS может быть получен из или использован для получения максимального изменения между временем прибытия трафика в пакетах и временем его прибытия в SCR, т. е. джиттера вокруг этого SCR. [4]
UPC и NPC обычно выполняются на основе виртуального канала (VC) или виртуального пути (VP), т. е. интервалы измеряются между ячейками, имеющими одинаковый идентификатор виртуального канала (VCI) и/или идентификатор виртуального пути (VPI). Если функция реализована, например, на входе коммутатора, то, поскольку ячейки на разных VC и VP поступают последовательно, требуется только одна реализация функции. Однако эта единственная реализация должна иметь возможность доступа к параметрам, относящимся к определенному соединению, используя VCI и/или VPI для их адресации. Это часто делается с использованием адресуемой памяти (CAM), где VCI и/или VPI формируют адресуемое содержимое.
Ячейки, которые не соответствуют требованиям, например, потому что они появляются слишком рано после предыдущей ячейки на канале или пути, потому что средняя скорость слишком высока или потому что джиттер превышает допуск, могут быть отброшены, т. е. отброшены, или их приоритет может быть снижен, чтобы их можно было отбросить ниже по потоку в случае перегрузки.
GCRA, хотя, возможно, и сложен для описания и понимания, может быть реализован очень просто. Хотя он, скорее всего, будет реализован на аппаратном уровне, например, реализация на языке ассемблера может быть написана всего за 15–20 инструкций с самым длинным путем выполнения всего за 8–12 инструкций, в зависимости от языка (наличие косвенности и ортогональность набора инструкций).
Передачи в сети Avionics Full-Duplex Switched Ethernet (AFDX) должны быть ограничены пропускной способностью распределения (BAG). Соответствие этому BAG (и максимальному джиттеру передачи) затем проверяется в сетевых коммутаторах аналогично UPC в сетях ATM. Однако для AFDX рекомендуется алгоритм маркерного контейнера , а версия, которая допускает кадры переменной длины (та, которая подсчитывает байты), предпочтительнее той, которая подсчитывает только кадры и предполагает, что все кадры имеют максимально допустимую длину. [5]