|
Compression Ratio = (original num of bytes / compressed num of bytes)
В Cisco IOS существует два вида сжатия - payload compression and header compression.
Payload Compression – сжимает все за исключением L2 header.
Header Compression – сжимает все заголовки за исключением L2 header.
Header Compression
В Циске есть два вида сжатия заголовков:
TCP header compression – сжимает IP и TCP заголовки (40 байтов до 3 - 5)
RTP header compression – сжимает IP, UDP и RTP заголовки (40 байтов до 2 -4)
Механизмы сжатия заголовков эффективны только для маленьких пакетов. IOS позволяет выполнять header compression через MQC: создаем класс, помещаем его в policy, и включаем для класса compression:
policy-map pm-qos
class cm-voice
priority 30
compression header ip rtp
class cm-telnet
bandwidth 20
compression header ip tcp
end
Теперь применим это к интерфейсу и посмотрим на результаты работы.
R3#show policy-map interface s0/1
Service-policy output: test-compress
Class-map: voice-only (match-all)
2880 packets, 184320 bytes
30 second offered rate 25000 bps, drop rate 0 bps
Match: protocol rtp audio
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 30 (kbps) Burst 750 (Bytes)
(pkts matched/bytes matched) 2/54
(total drops/bytes drops) 0/0
compress:
header ip rtp
UDP/RTP compression:
Sent: 2880 total, 2880 compressed, [Это кол-во пакетов]
106560 bytes saved, 66240 bytes sent
2.60 efficiency improvement factor
100% hit ratio, five minute miss rate 0 misses/sec, 0 max
rate 9000 bps
Разберемся что такое saved и что такое sent. Пусть на вход компрессора поступает последовательность из N байтов. На выходе она превращается в последовательность из М байтов (N => M). Именно М байтов и будет отправлено (sent), а вот разница (N – M) называется ‘bytes saved’, т.е. это величина, на которую мы «сэкономили», потому что на это значение уменьшилась начальная последовательность в результате её сжатия.
Итак, M – это 'bytes sent', (N – M) – это 'bytes saved'.
M + (N – M) = N – длина начальной последовательности.
| M + (N – M) N bytes sent + bytes saved
Compression Ratio = -----------------= ---- = ---------------------------------- ;
| M M bytes sent
И ещё один важный момент. Статистика в листинге учитывает общее кол-во байтов (и пакетов) вышедших из интерфейса - и заголовки и payload.
(106560 + 66240) / 2880 = 60, где 60 – это размер одного пакета G.729 (без L2 заголовка).
Однако у нас RTP Header Compression - сжимаем IP, UDP и RTP заголовки, т.е. они составляют предмет сжатия, и значит что saved – это то, что сэкономили на их сжатии.
(106560 + X) / 2880 = 40 (размер RTP заголовка)
106560/2880 + X/2880 = 37 + X/2880 = 40
37 – это то что мы сэкономили с каждого RTP заголовка, т.е. каждый RTP заголовок уменьшился до 3-х байтов.
Link Fragmentation and Interleaving
LFI борется с проблемой serialization delay, гарантируя, что большие пакеты не задерживают маленькие пакеты. Это достигается фрагментированием больших пакетов и перемешиванием фрагментов с нефрагментированными маленькими пакетами.
Термины «пакет» и «фрейм» в контексте LFI приобретают особый смысл. Пакет – это то что проходит по всей сети от одного пира до другого, т.е. это L3-заголовок и все что выше. Фрейм – это L2 заголовок + Пакет. Механизмы очередей помещают в буферы фреймы !!!
Процесс фрагментации:
- Пакет разбивается на несколько частей (а не на несколько пакетов)
- К каждой части добавляется L2-заголовок, включая дополнительные байты, требуемые для «обслуживания» фрагментации. Т.е. части исходного пакета превращаются в отдельные фреймы.
- Длина каждого получившегося фрейма, не превышает сконфигурированный fragmentation size.
- Фреймы ставятся в очередь
NOTE: Fragmentation size – это размер результирующего фрейма, а не размер частей пакета. Т.е. пакет разбивается на части с учетом того, что результирующие фреймы не превысят сконфигурированный Fragmentation size.
И еще один важный момент. В очередь ставятся именно фреймы, т.е. сначала пакет фрагментируется, затем каждый фрагмент превращается в отдельный фрейм, затем фреймы классифицируются и уже потом попадают в свои буферы очереди. Классифицируются фреймы !!! Далее всё зависит от шедулера очереди. Если он работает на уровне пакетов, например WFQ на MLP, то он сначала отправит все фрагменты одного пакета, а потом перейдет к фрагментам следующего. Если он работает именно с фреймами, то мы получим interleaving: шедулер очереди делает выборку фреймов по своему обычному алгоритму, т.е. ему без разницы – это фрейм фрагмента или цельного пакета. Для того, чтобы было перемешивание нужен такой механизм очередей, чтобы фреймы маленьких нефрагментированных пакетов попадали в приоритетный буфер (Например PQ:High, LLQ или ip rtp priority). Т.е. перемешивание – это не какая-то отдельная функция, это просто изначально правильная классификация плюс механизм очередей с приоритетным буфером. Вот и всё !
Существуют два вида LFI: Multilink PPP и FRF.12. Оба эти LFI напрямую взаимодействуют с механизмами очередей, но делают это по разному. Стоит заметить – чтобы перемешивание реально заработало нужно для каждого вида LFI правильно настроить механизм очередей.
Multilink PPP LFI (MLP LFI)
Multilink – это логическое объединение (bundle) нескольких линий связи типа point-to-point. Когда MLP объединяет две и более линий p-t-p, то фрагментирование включается автоматически – пакет любой длины разбивается на равные части по количеству линков в бандле. Если у нас только один линк в бандле, то фрагментация по умолчанию не включается.
Допустим у нас три физических РРР-интерфейса объединены в multilink bundle. С точки зрения L3 такой бандл становится отдельным логическим IP-интерфейсом поверх L2 PPP интерфейсов. Пакет маршрутизится на MLP интерфейс, далее он фрагментируется. Следующий этап – классификация и размещение фреймов в буферах механизма очереди MLP-интерфейса. Механизм очередей можно настроить на MLP интерфейсе, но на физических интерфейсах будет только FIFO (я пробовал и CBWFQ, но всегда остается только FIFO). Затем шедулер очереди MLP-интерфейса делает выборку фреймов и помещает их в FIFO физических интерфейсов. Вот так это работает. Как мы видим, фрагментация выполняется до классификации.
Теперь представим, что MLP бандл состоит только из одного физического интерфейса. По умолчанию в этом случае фрагментация не выполняется. Чтобы её включить нужна команда
interface multilink 34
bandwidth 128
fair-queue <-----[WFQ]
ppp multilink fragment-delay 10 <----- [10 ms]
Размер фрагмента будет вычислен по формуле 128 * 10 = 1280 бит = 160 байт.
Мы включили фрагментацию, но механизм очереди таков (WFQ), что перемешивания не будет. Даже если мы добавим следующую команду, ничего не изменится.
interface multilink 34
bandwidth 128
fair-queue
ppp multilink fragment-delay 10 [10 ms]
ppp multilink interleave
Дело в том, что WFQ на MLP работает с пакетами, а не с фреймами. Т.е. пока все фрагменты одного большого пакета не уйдут, маленький голосовой фрейм будет ждать. Обойти это можно заменив WFQ на LLQ или на механизм ip rtp priority. Последний является устаревшим, поэтому LLQ предпочтительней. Перемешиванием занимается шедулер очереди, т.е. от нас требуется только правильно классифицировать голос и поместить его в LLQ-буфер.
Рассмотрим пример с использованием ip rtp priority.
interface multilink 34
bandwidth 128
fair-queue
ppp multilink
ppp multilink group 34
ppp multilink fragment-delay 10
ppp multilink interleave
ip rtp priority 16384 16383 64
NOTE: ip rtp priority просто захватывает весь голос и помещает его в отдельный PQ-буфер. Весь остальной траф обрабатывается механизмом очередей, настроенном на интерфейсе, в данном случае это WFQ.
Принцип работы MLP LFI: шедулер очереди MLP-интерфейса отвечает за перемешивание (я вот только не понял: нахрена тогда нужна команда ppp multilink interleave – может быть для того, чтобы соответствующий механизм очередей начал работать на уровне фреймов, а не на уровне пакетов Тогда всё сходится. Для WFQ всё останется без изменений, а вот LLQ начнет вставлять нефрагменты между фрагментами).
ЗАПОМНИ, что MLP Interleave работает только на одной линке в бандле. Дело в том, что маленькие голосовые пакеты не фрагментируются, а значит отправляются в оригинальном виде без служебных заголовков, содержащих sequence number и пр. А раз нет sequence number'а, то принимающай сторона не сможет их упорядочить, если они придут по параллельным линкам.
Frame Relay LFI with FRF.12
FRF.12 – это фрагментация. Данный механизм работает совместно c FRTS и настраивается там же. Как только хотя бы для одного VC включается FRF.12, то на соответствующем физическом интерфейсе программная очередь заменяется на Dual FIFO.
Dual FIFO – это механизм, который обладает всеми свойствами любого другого механизма очередей, а именно:
Имеет логику классификации
Имеет несколько буферов (всегда два)
Имеет свой шедулер (PQ-like fashion)
Вообще любой LFI подразумевает перемешивание фреймов фрагментов с фреймами маленьких нефрагментированных пакетов. Если помещать маленькие фреймы в Dual FIFO High, а фреймы фрагментов в Dual FIFO Normal, то с PQ-шедулером мы получим перемешивание. LFI with FRF.12 классифицирует пакеты по буферам Dual FIFO, основываясь на механизме очередей FRTS.
FRF.12 настраивается per VC и при этом для FRTS этого VC допустимы 4 механизма очередей: WFQ, CBWFQ, LLQ и IP RTP Priority. Как только мы включаем FRF.12 хотя бы на одном VC, то у физического интерфейса включается Dual FIFO. Но это не означает, что маленькие нефрагментированные пакеты этого VC по умолчанию попадут в Dual FIFO High.
NOTE: Пакеты отдельного VC могут классифицироваться в Dual FIFO High, только если FRTS этого VC использует LLQ или IP RTP Priority. Если FRTS на VC использует WFQ или CBWFQ, то всё – и фрагменты и маленькие цельные пакеты, попадают в Dual FIFO Normal. Также если FRF.12 на VC не используется, то все пакеты летят в Dual FIFO Normal.
Итак, механизм очередей FRTS играет основную роль для трафа, которому нужно low latency. Необходимо правильно классифицировать траф и поместить его в LLQ-буфер. Если затем включить FRF.12, то именно этот траф будет попадать в Dual FIFO High. Нам остается только правильно определить размер фрагмента.
FRF.12 определяет размер фрагмента по той же формуле, что и MLP LFI: max_delay * bandwidth, где max_delay – это время отправки low-latency пакета. А вот что брать в качестве bandwidth ? FRF.12 настраивается per VC, а значит размер фрагмента может быть уникален для каждого PVC, терминирующегося на hub'е, т.е. размер фрагмента для каждого PVC может быть свой. Итак, у нас есть отдельный PVC (R1-Main): на одном его конце (spoke) clock rate равна 128kbps, а на другом (hub) – 768kbps. Для low latency трафа требуется serialization delay не более 10ms. Для этого на данном PVC мы выбираем размер фрагмента 128 * 10 = 1280 bits = 160 bytes
При движении пакета размером 160 байт слева направо и обратно serialization delay нигде не превысит 10ms. Если бы мы выбрали на Main'е фрагмент большего размера, то при отправке его с FRS1 на R1 serialization delay превысила бы 10ms. Вот почему при выборе размера фрагмента нужно привязываться к clock rate более медленного «конца» PVC. На канале R2-Main выбран больший размер фрагмента, но это не задерживает фрагменты канала R1-Main при отправке их с Main на R1.
MLP LFI over Frame Relay
Рассмотрим последнюю фичу. FR PVC – это фактически канал точка-точка, а значит на нем можно поднять РРР. Делается это с помощью шаблона virtual-template с последующим «наложением» на VC (DLCI). В результате мы получаем PPP-интерфейс, который затем можно включить в MLP-бандл. Ранее мы видели, что в MLP механизм очереди настраивается на multipoint интерфейсе, а физические РРР-интерфейсы получали FIFO. Для данной фичи это также необходимо соблюсти. Итак, наверху у нас MLP-интерфейс со своим механизмом очередей, ниже идут логические virtual-access интерфейсы, базирующиеся на FR VC’ах. Для поддержки FIFO на виртуальном интерфейсе требуется включить FIFO на VC, а для этого требуется FRTS. Вот такая фигня !
class-map match-all cm-voice
match ip rtp 16384 16383
!
policy-map pm-llq LLQ for Multipoint interface
class cm-voice
priority 128
class class-default
fair-queue
!
interface Multilink10
bandwidth 512
ip address 131.1.88.1 255.255.255.0
ppp multilink
ppp multilink fragment delay 10 Set the fragment size on MLP interface
ppp multilink interleave
ppp multilink group 10
service-policy output pm-llq LLQ for output packets
------------------------------------------------------------------------
interface Virtual-Template1
no ip address
ppp multilink
ppp multilink group 10
!
interface Serial1/0
no ip address
encapsulation frame-relay
frame-relay traffic-shaping We need FIFO queue per VC (default queue type)
!
map-class frame-relay frts-102 We need FIFO queue per VC
frame-relay cir 512000
frame-relay bc 5120 Tc will be 10 ms
frame-relay be 0
!
interface Serial1/0.102 point-to-point
frame-relay interface-dlci 102 ppp Virtual-Template1
class frts-102 Shape Class for PVC 102
------------------------------
R1#sh int se1/0
Serial1/0 is up, line protocol is up
......
Queueing strategy: dual fifo Dual FIFO even without FRF.12
Output queue: high size/max/dropped 0/256/0
Output queue: 0/128 (size/max)
......
R1#sh int mu10
Multilink10 is up, line protocol is up
......
Queueing strategy: Class-based queueing
......
R1#sh queueing interface se1/0
Interface Serial1/0 queueing strategy: priority
Output queue utilization (queue/count)
high/550 medium/0 normal/55 low/0
NOTE: Мы видим, что здесь нет FRF.12, но Dual FIFO включилась на физическом Serial-интерфейсе. Я так понимаю, что в Dual FIFO High попадают пакетики из LLQ-буфера очереди MLP-интерфейса.
|
