Ряд компаний используют более топкие механизмы борьбы с перегрузками, назначая нескольких уровней перегрузки и вводя два уровня приоритета при удалении кадров: нормального (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.
