Для  того  чтобы  маршрутизаторы  поддерживали  обработку  пакетов  в 

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

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

Для  того  чтобы  пакеты  с  установленными  битами  DTR    появлялись  в  сети, 

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

Синхронные  приложения,  например  приложения  -аудио  и  -видео 

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

Следующие  два  бита  поля  TOS  в  RFC791  являются  зарезервированными, 

однако есть еще два RFC, дополняющие правила использования поля TOS. 
 

В  RFC1349  предлагается  использование  седьмого  бита  поля  TOS  как  бита  С 

(Cost,  Monetary  Cost).  Предлагается  устанавливать  этот  бит  в  том  случае,  если 
передача  данных  по  разным  маршрутам  может  иметь  различную  денежную 

стоимость.  В  таком  случае  установка  бита  C  означает  просьбу  узла 
маршрутизатору передать пакет с минимальной денежной стоимостью.  

 

В  RFC1455  предлагается  использование  одновременной  установки  битов 

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

Таким  образом,  поле  TOS  –  механизм,  с  помощью  которого  узел  может 

попросить  от  маршрутизатора  специального  подхода  к  маршрутизации  пакета, 
маршрутизаторы в свою очередь могут обрабатывать пакеты, так как они могут это 
делать,  ничего  не  гарантируя  узлу  с  точки  зрения  специального  обслуживания, 
независимо от установленного поля TOS. 
 
Поле  Total Length. 
 

Version 

IHL 

TOS 

Total Length 

0  1  0  0  0  1  0  1  P  P  P  D  T  R  0  0 

 

Данное  поле  показывает  длину  IP  пакета  в  байтах,  включая  полный 

заголовок  IP  пакета  и  поле  данных  пакета,  следующее  за  заголовком.  Из  длины 
поля  Total  Length  (2  байта),  следует,  что  максимальная  длина  IP  пакета  может 
составить  не  более  65535  байт.  Однако,  применение  таких  пакетов  затруднено 
тем,  что  MTU  большинства  сетей  канального  уровня  гораздо  меньше,  нежели 
65535 байт. RFC791 рекомендует отправлять IP пакеты не длиннее 576 байт, если