Другой механизм управления перегрузками

Ряд компаний используют более топкие механизмы борьбы с перегрузками, назначая не­скольких уровней перегрузки и вводя два уровня приоритета при удалении кадров: нормально­го (NDP) и высокого (HDP) приоритетов. Это позволяет избегать серьезных перегрузок. Мож­но ввести четыре уровня перегрузки:

- Мягкая перегрузка- сеть посылает уведомление FECN или BECN, или оба уведомления одновременно;

- Средняя перегрузка- сброс всех NDP-кадров с DE=1, прибывающих на перегруженный узел, для защиты новых кадров с DE=0;

- Тяжелая перегрузка- сброс всех HDP-кадров с DE=1 и NDP-кадров с DE=0, прибывающих на перегруженный узел;

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

Здесь мягкая перегрузка соответствует состоянию системы, когда се ресурсы сокращаются до 10-20%.

 

Примеры управления потоком кадров на основе CIR, EIR и DE

Рассмотрим два примера, показывающих действие CIR, EIR, DE для одного и нескольких пользователей.

 

 

Рис.5-7. Схема покадрового профилирования трафика при работе одного пользователя

Пример 1.Допустим, что в SLA оговорены параметры: ЛИ, CIR, Be, Be и Тс, за время ко­торого вы передаете кадры со скоростью AR с межкадровыми интервалами. Тогда профиль передачи на интервале Тс может иметь вид, показанный на рис.5-7. Из него видно, что первый и второй кадры будут переданы без проблем (с DE=0), т.к. объем переданных данных не пре- высил Вс. Третий кадр будет помечен (DE=1), но не сброшен, т.к. объем переданных данных не превысил (Вс+Ве). Четвертый кадр будет сброшен при входе, т.к. с его приходом объем передаваемых данных превышает допустимый уровень (Вс+Ве).

 

Пример 2а. Допустим, что в канале с AR=64 кбит/с конфигурируется одно PVC с СШ=32 кбит/с и EIR = 0, и пользователь в отсутствие перегрузки передавал поток кадров со скоростью 64 кбит/с в течение 0,5 с. В следующие 0,5 с, если интервал усреднения Тс=1 с, сеть пометит все последующие кадры, имеющие DE=0, как кадры с DE=l, и сбросит их на ближайшем узле, т.е. усреднит поток за Тс до 32 кбит/с.

 

Пример 2б. Пусть теперь в том же канале для того же PVC было выбрано CIR=32 и EIR=32 кбит/с. Тогда, учитывая, что перегрузки не будет в течение Тс, сеть пропустит и в следующие 0,5 с весь поток пользователя, несмотря на то, что все кадры, формирующие поток E1R=32 кбит/с будут помечены DE=1.

При более тонком анализе нужно было бы учесть поток кадров LMI, а также соотношение максимально допустимого размера кадра, пусть это будет 1600, а не 2100 байт, и (Вс+Ве)=32 кбайт. Тогда за Тс=1 с д.б. передано точно 20 кадров, однако, учитывая "добавку" потока LM1, последний кадр будет сброшен, в результате будет передано, только 19/20 или 95% трафика. Побочным эффектом будет то, что после 18 кадра м.б. послан BECN при мягкой перегрузке (после передачи 18 кадров у системы останется 10% ресурсов).

 

Пример 2в. Если же в том же канале было два PVC, одно с C1R=32 и EIR=32 кбит/с, а вто­рое с CIR=32 и E1R=0, то во вторые 0,5 с м.б. два сценария: А - пользователь 2-го PVC не ра­ботает в этом полуинтервале, тогда пользователь 1-го PVC имеет тс же условия, что и в При­мере 26; Б - пользователь 2-го PVC работает в этом полуинтервале с той же скоростью AR, тогда пользователь 1 PVC работает по Примеру 2а.

5.6.3. Общие рекомендации при выборе параметров PVC/SVC

 

Рассмотренное выше позволяет дать некоторые общие рекомендации при выборе параметров PVC.

· Скорость гарантированной передачи определяется только CIR, а скорости выше CIR+EIR недопустимо выби­рать в принципе.

· Скорость вероятной (допустимой) передачи данных определяется соотношением CIR+EIR и физической скоро­сти порта VФП только при одном PVC, а при наличии k других PVC - соотношением всех CIRk+EIRk и физиче­ской скорости порта VФП.

Кроме того:

- При передаче потока кадров FR и выборе CIR=VФП собственно битовая скорость передачи инкапсулированной информации пользователя VИП всегда будет меньшебитовой скорости потока кадров Vk, ограниченной Von. При выборе CIR=0 все кадры потока будут иметь DE=1 и обслуживаться только в случае наличия свободной полосы общего канала.

Требование гарантировать CIR=VФП м.б. несовместимо в сети FR даже при отсутствии пе­регрузки.

Сети Frame Relay

 

Первое представление о сети FR нам дает рис.5-1, где сервис FR использует интерфейсы поль­зователь-сеть (UNI). Они явно не указаны, по это интерфейсы между DTE и DCE. Частных сетей м.б. несколько. Для связи между ними, а также между ними и сетью общего пользова­ния, д.б. интерфейсы сеть-сеть (NNI).

Интерфейс UNI

Положение интерфейсов UN1 дано на рис.5-8, где показано соединение между устройствами А и Б. Заметим, что взаимодействующие устройства могут использовать различные адресные планы, общие для ГлС (Е.164 на стороне А и Х.121 на стороне Б). Кроме того, скорости пере- ­дачи на входе и выходе м.б. разными (CIRА=256 кбит/с и CIRБ=160 кбит/с). В общем случае сервис FR поддерживает как PVC, так и SVC. При конфигурации и на схемах сетей FR интер­фейсы UNI м.б. FUNI, FRUNI, FrUNI, FrUni, а сетевые адреса м.б. DNA, Dna или dna.

 

Рис.5-8. Схема автономной частной сети FR с интерфейсами UNI

UNI для PVC/SVC:интерфейсы UNI для PVC описаны в соглашении FRF.l, a UNI для SVC -в FRF.4. Список интерфейсов, упомянутых в FRF, включает: DSI, E1, ЕЗ, DS3, V.35, V.36/V.37, Х.21, V.24 и IISSI. Кроме указанных сегодня поддерживаются интерфейсы SONET ОС-1 и SDH STM-0 (51,84 Мбит/с).

Передача данных базируется на протоколе Q.922 с 2-байтпым адресным полем для DLCI и поддержкой поля данных 1600 байт. Управление перегрузками д.б. основано на рек. 1.370.

Интерфейс NNI

Положение интерфейсов NNI между двумя устройствами А и Б дано на рис.5-9. Заметим, что при этом, как и раньше, м.б. использованы разные адресные планы (общие для ГлС: Е.164 и Х.121) и скорости передачи.

 

Рис.5-9. Схема общей сети FR с интерфейсами UNI и NNI

На рис.5-9 устройство А в этой сети решает с помощью сервиса UNI ближайшей сети FR задачу доступа в сеть. Сервис NNI FR, кроме задачи: передать пользовательские данные по сетям, расположенным между А и Б, решает еще и задачу: примять, обработать и распростра­нить информацию о статусе ГлС в целом, чтобы конечный пользователь мог иметь точное представление о сетевом соединении, перекрывающем несколько частных сетей FR. Наконец, устройство Б использует сервис UNI, чтобы реализовать соединение с удаленной сетью FR. Это м.б. сервис UNI третьего производителя, важно, чтобы он удовлетворял спецификации FRF.2.