4.1.3. Идентификация IP
Поле Identification (IP ID) в заголовке IPv4 показывает какой фрагмент содержит дейтаграмма при сборке фрагментов пакета. Спецификация IPv4 не задает порядок присвоения значений идентификатора, указывая лишь, что каждому пакету следует давать уникальное для пары отправитель-получатель и используемого протокола значение IP ID. Уникальность должна обеспечиваться в течение интервала времени, которое дейтаграмма (или любой из ее фрагментов) могут находиться в сети. Это означает, что присвоение значений IP ID может выполняться различными путями, которые мы будем делить на три класса:
- Sequential jump — нарастание
- Это наиболее распространенная политика присвоения идентификаторов в современных вариантах стека IP. Один счетчик IP ID используется для всех потоков пакетов. Когда отправитель работает с множеством потоков одновременно, значение IP ID между последовательными пакетами одного потока может увеличиваться более, чем на 1. Значения IP ID являются легко предсказуемыми, для их передачи требуется меньшее количество битов, а увеличение идентификатора от пакета к пакету (определяется числом активных потоков исходящих пакетов и частотой передачи) обычно бывает ограничено.
- Random — случайные значения
- Некоторые варианты стека IP используют в качестве IP ID псевдослучайные значения. В этом случае отсутствуют корреляции между значениями ID в последовательных пакетах. Следовательно, отсутствует возможность предсказать значение IP ID для следующей дейтаграммы. С точки зрения компрессии заголовков это означает, что поле IP ID нужно передавать без сжатия, что приводит к использованию двух лишних октетов в сжатом заголовке. Реализациям стека IP в терминалах сотовых сетей требуется эффективная компрессия, поэтому им не следует использовать данный вариант задания значений IP ID.
- Sequential — равномерное увеличение
В этом варианте используется отдельный счетчик для каждого исходящего потока пакетов и значения IP ID будут увеличиваться на единицу для каждого следующего пакета (за исключением случаев достижения максимума и возврата к началу отсчета). Следовательно, изменение значения этого поля постоянно и заранее известно. Такой вариант присвоения идентификаторов наиболее подходит для сжатия заголовков. Однако его использование не столь широко, как следовало бы ожидать.
Во избежание нарушения требований спецификации RFC 791 [1], пакеты, использующие одну пару адресов «отправитель- получатель» и номер протокола IP, не могут иметь одинаковых значений IP ID. Следовательно, при выделении значений идентификатора по порядку нужно разделять значения идентификаторов для разных потоков одного протокола между одной парой конечных точек. Это можно сделать разными путями, каждый из которых использует случайные пропуски в порядке нумерации, что делает распределение идентификаторов не вполне последовательным. С точки зрения компрессии желательно реже использовать пропуски в значениях идентификаторов.
Отметим, что эти идентификаторы используются только в IPv4 и, следовательно, не рассматриваются в IPv6. Для IPv4 поля ID могут обрабатываться тремя разными способами. Во-первых, имеется малоэффективное, но надежное решение, в котором поле идентификации передается без изменений во всех пакетах, что ведет к увеличению сжатых заголовков на 2 октета. Этот способ является наилучшим вариантом обработки полей ID в иех случаях, когда отправитель использует случайные значения ID. Во-вторых, может использоваться более гибкий механизм, который обеспечит снижение числа битов для полей ID при нарастающей (sequential jump) нумерации. Такие механизмы могут в некоторых случаях увеличивать число требуемых битов при использовании отправителем случайных значений идентификаторов. Следовательно, информация об используемом отправителем механизме выделения идентификаторов полезна при выборе между двумя упомянутыми выше решениями. Наконец, даже для IPv4 могут быть созданы схемы компрессии, не включающие в сжатый заголовок никакой дополнительной информации о поле ID. Для использования таких схем нужно знать какой из механизмов выделения значений поля ID применяется отправителем. Получение такой информации возможно не во всех случаях, что ведет к весьма редкому применению таких механизмов. Однако разработчикам стеков IPv4 для терминалов сотовых сетей следует использовать политику выделения идентификаторов, близкую к последовательной.
В контексте компрессии TCP поведение поля IP ID остается таким же. Однако в RFC 3095 [31] значения IP ID в общем случае получаются из порядковых номеров RTP. Для случая TCP нет подходящего кандидата на роль «ведущего порядкового номера».
Очевидно, что наблюдаемое поведение загруженного сервера может быть достаточно изменчивым. В некоторых случаях возможность совместного использования контекста компрессии IP для множества потоков (между одной парой конечных точек) может давать некоторые преимущества. Однако реальное воздействие может наблюдаться лишь в случаях использования большого числа потоков между конкретной машиной и сервером. Если рассматривается совместное использование контекста, предпочтительным будет совместное использование связанной с IP части контекста.