setcap

image_print

SETCAP

PDF

Утилита для управления возможностями файлов в Linux.

Синтаксис

setcap [-q] [-n <rootuid>] [-v] {capabilities|-|-r} filename [ ... capabilitiesN fileN ]

Описание

Без опции -v (verify — проверка) setcap устанавливает указанные возможности для каждого файла, заданного параметром filename. Необязательный аргумент -n <rootuid> можно использовать для установки возможности, используемого лишь в пространстве имен пользователя, владеющего идентификатором root. Опция -v служит для проверки связывания указанных возможностей с файлом. При указании опций -v и -n проверяется также аргумент -n <rootuid>.

Возможности указываются с помощью cap_from_text, как описано ниже.

Функция cap_from_text() выделяет и инициализирует состояние возможности в рабочем хранилище. Функция устанавливает содержимое вновь созданного состояния возможности в соответствии с понятной человеку строкой символов в стиле языка C (nul-завершение), указанной buf_p и возращает указатель на созданное состояние.
Текстовое представление возможности состоит из одного или множества разделенных пробелами «слов», каждое из которых указывает те или иные операции из набора возможностей, которые включаются или отключаются после выполнения команды (по умолчанию все отключено).

Каждое слово представляет собой список разделенных запятыми имен возможностей (или all), за которым следует список действий. Список действий включает последовательность пар «оператор-флаги». Операторами могут служить =, + и -, а флагами — e, i и p. Регистр флагов имеет значение и они указывают группу (набор), к которой относятся возможности Effective, Inheritable (наследуется) и Permitted (разрешено), соответственно.

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

Оператор = задает для указанного имени сначала сброс всех 3 параметров возможности, а затем их установку в соответствии с флагами (не обязательны для этого оператора). Например, all=p сбросит установку Effective и Inheritable для батарейного питания и установит Permitted, а cap_fowner=ep установит в Effective и Permitted возможности смены владельца файла (override-file-ownership) и сбросит их в Inheritable.

При указании первым оператора = без списка возможностей предполагается воздействие на все возможности (all). Например, варианты all=, =, и cap_chown,<every-other-capability>= будут эквивалентны.

Операторы + и требуют явного указания впереди списка возможностей, а после оператора — явных флагов. Оператор + включает все указанные в списке возможности в соответствии с флагами, а оператор отключает. Например, all+p включает для всех возможностей Permitted, а cap_fowner-i отключает override-file-ownership в группе Inheritable.

Список действий может включать множество пар «оператор-флаги», действия применяются слева направо. Например, cap_fowner+p-i эквивалентно cap_fowner+p cap_fowner-i, а cap_fowner+pe-i эквивалентно cap_fowner=+pe.

Специальная строка возможностей — позволяет указать возможности, считываемые со стандартного устройства ввода (stdin). В таких случаях набор возможностей завершается пустой строкой.

Специальная строка -r служит для удаления набора возможностей файла. Отметим, что установка пустого набора возможностей отличается от удаления набора. Пустой набор может использоваться для предотвращения исполнения файла с привилегиями, несмотря на то, что превалирующие наборы Ambient и Inheritable позволили бы это.

Флаг -q служит для сокращения выводимых программой сведений.

Список возможностей

Для выполнения проверки прав доступа в традиционных системах UNIX процессы делят на две категории — привилегированные (идентификатор эффективного пользователя равен 0, как у root), и непривилегированные (ID эффективного пользователя не равен 0). Для привилегированных процессов проверки прав в ядре не выполняются, а для не привилегированных процессов выполняется полная проверка на основе возможностей процесса (обычно, эффективные UID и GID, а также и список дополнительных групп).

В ядре Linux, начиная с версии 2.2, все привилегии, обычно связываемые с суперпользователем, разделены на несколько частей, называемых возможностями (capability), которые можно разрешать и запрещать независимо. Возможности являются атрибутами потоков (нитей). Ниже приведен список возможностей, реализованных в Linux с указанием операции и поведения, разрешаемых ими. В скобках указаны версии ядра, начиная с которых каждая возможность поддерживается.

CAP_AUDIT_CONTROL (2.6.11)

Включение и выключение аудит ядра, изменение фильтрующих правил аудита, чтение состояния аудита и фильтрующие правила.

CAP_AUDIT_READ (3.16)

Чтение протокола аудита через многоадресный сокет netlink.

CAP_AUDIT_WRITE (2.6.11)

Запись данных в журнал аудита ядра.

CAP_BLOCK_SUSPEND (3.5)

Возможности, которые могут приводить к блокированию приостановки системы (epoll  EPOLLWAKEUP, /proc/sys/wake_lock).

CAP_BPF (5.8)

Привилегированные операции BPF (bpf, bpf_helpers). Возможность добавлена в Linux 5.8 для разгрузки перегруженной возможности CAP_SYS_ADMIN.

CAP_CHECKOUT_RESTORE (5.9)

    • Обновление /proc/sys/kernel/ns_last_pid (pid_namespaces);
    • использование свойства set_tid в clone3;
    • чтение содержимого символьной ссылки /proc/[pid]/map_files для других процессов.

Возможность добавлена в Linux 5.9 для переноса функциональности checkpount/restote из CAP_SYS_ADMIN.

CAP_CHOWN

Произвольные изменения UID и GID для файлов.

CAP_DAC_OVERRIDE

Пропуск проверки доступа к файлу на чтение, запись и выполнение (DAC или discretionary access control — избирательный контроль доступа).

CAP_DAC_READ_SEARCH

    • Пропуск проверки доступа к файлу на чтение и к каталогу на чтение и выполнение (просмотр);
    • вызов open_by_handle_at;
    • использование linkat с флагом AT_EMPTY_PATH для создания ссылки на файл, заданным дескриптором.

AP_FOWNER

    • Пропуск проверки доступа для операций, которые обычно требуют совпадения UID файловой системы процесса и UID файла (например, chmod,  utime), исключая операции, охватываемые CAP_DAC_OVERRIDE и CAP_DAC_READ_SEARCH, системы процесса и UID файла (например, chmod  utime),  исключая операции, охватываемые CAP_DAC_OVERRIDE и CAP_DAC_READ_SEARCH;
    • изменение флагов inode (ioctl_iflags) у произвольных файлов;
    • установка списков контроля доступа (ACL) для произвольных файлов;
    • игнорирование закрепляющего бита при удалении файла;
    • установка O_NOATIME для произвольных файлов в open и fcntl.

CAP_FSETID

Позволяет не сбрасывать биты режима set-user-ID и set-group-ID при изменении файла любыми дополнительными GID вызывающего процесса.

CAP_IPC_LOCK

Блокировка памяти (mlock, mlockall, mmap, shmctl).

CAP_IPC_OWNER

Отмена проверки доступа для операций с объектами System V IPC.

CAP_KILL

ioctl с операцией KDSIGACCEPT.

CAP_LEASE

(2.4) Установка аренды для произвольных файлов (fcntl).

CAP_LINUX_IMMUTABLE

Установка флагов inode FS_APPEND_FL и FS_IMMUTABLE_FL (ioctl_iflags).

CAP_MAC_ADMIN

(2.6.25) Изменение MAC или состояния. Реализована в Smack Linux Security Module (LSM).

CAP_MAC_OVERRIDE

(2.6.25) Замещение мандатного контроля доступа (MAC). Реализована в Smack LSM.

CAP_MKNOD

(2.4) Создание специальных файлов с помощью mknod.

CAP_NET_ADMIN

Различные сетевые операции:

    • настройка интерфейса;
    • управление IP МСЭ, трансляцией адресов и ведением учёта;
    • изменение таблиц маршрутизации;
    • привязка к любому адресу для организации прозрачного прокси;
    • назначение типа обслуживания (TOS);
    • сброс статистики драйвера;
    • управление режимом захвата (promiscuous);
    • включение групповой рассылки (multicasting);
    • использование setsockopt для включения параметров сокета SO_DEBUG, SO_MARK, SO_PRIORITY (для приоритетов вне диапазона 0 — 6), SO_RCVBUFFORCE и SO_SNDBUFFORCE.

CAP_NET_BIND_SERVICE

Привязка сокета к привилегированным портам домена Internet (номера портов меньше 1024).

CAP_NET_BROADCAST

(не используется) Позволяет выполнять широковещание с сокета и прослушивание многоадресных рассылок.

CAP_NET_RAW

Использование сокетов RAW и PACKET и привязка к любому адресу для создания прозрачного прокси.

CAP_PERFMON (5.9)

Управление механизмами мониторига, включая:

    • вызов perf_event_open;
    • реализация операций BPF, влияющих на производительность.

Возможность добавлена в Linux 5.9 для разгрузки перегруженной возможности CAP_SYS_ADMIN.

CAP_SETGID

Произвольные действия с GID процесса и списком дополнительных GID, подмена GID при передаче возможностей сокета через доменные сокеты UNIX, запись отображения идентификатора пользователя в пользовательское пространство (user_namespaces).

CAP_SETFCAP

(2.6.24) Устанавливает произвольные возможности для файла.

CAP_SETPCAP

Если поддерживаются возможности для файла, позволяет добавлять любую возможность из ограничивающего набора вызывающего потока в наследуемый набор, отменять возможности из ограничивающего набора (с помощью prctl с операцией PR_CAPBSET_DROP), изменять флаги securebits.

Если возможности для файла не поддерживается (до 2.6.24), позволяет предоставлять и отменять любую возможность из списка разрешённых вызывающего или любого другого процесса (свойство недоступно с ядрами, поддерживающими возможности для файлов, поскольку CAP_SETPCAP в таких ядрах имеет другую семантику).

CAP_SETUID

Произвольные действия с UID процесса (setuid, setreuid, setresuid, setfsuid), подмена UID при передаче возможностей сокета через доменные сокеты UNIX, запись отображения идентификатора пользователя в пользовательское пространство (user_namespaces).

CAP_SYS_ADMIN

    • Управление системой, включая quotactl, mount, umount, swapon, swapoff, sethostname, setdomainname;
    • привилегированные операции syslog (начиная с Linux 2.6.37, для этих операций нужно использовать CAP_SYSLOG);
    • команды VM86_REQUEST_IRQ vm86;
    • функциональность checkpoint/restore, обеспечиваемая CAP_CHECKPOIBT_RESTORE (предпочтительна);
    • функциональность BPF, обеспечиваемая CAP_BPF (предпочтительна);
    • функциональность мониторинга производительности, обеспечиваемая CAP_PERFMON (предпочтительна);
    • операции IPC_SET и IPC_RMID над произвольными объектами System V IPC;
    • перезапись ограничения ресурса RLIMIT_NPROC;
    • операции над расширенными атрибутами trusted и security (xattr);
    • использование lookup_dcookie;
    • использование ioprio_set для назначения классов планирования ввода-вывода IOPRIO_CLASS_RT и (до Linux 2.6.25) IOPRIO_CLASS_IDLE;
    • подмена PID при передаче возможостей сокета через доменные сокеты UNIX;
    • превышение системного ограничения (/proc/sys/fs/file-max) на количество открытых файлов в системных
      вызовах, открывающих файлы (например, accept, execve, open, pipe);
    • использование флагов CLONE_*, создающих новые пространства имён с помощью clone и unshare
      (начиная с Linux 3.8 для создания пользовательских пространств никаких возможностей не требуется);
    • вызовы perf_event_open;
    • доступ к информации о привилегированном событии perf;
    • вызовы setns (требуется CAP_SYS_ADMIN в целевом пространстве имён);
    • вызовы fanotify_init;
    • привилегированные операции KEYCTL_CHOWN и KEYCTL_SETPERM в keyctl;
    • вызовы ptrace PTRACE_SECCOMP_GET_FILTER для получения дампа фильтров seccomp трассируемого;
    • операция MADV_HWPOISON в madvise;
    • использование TIOCSTI в ioctl для вставки символов во входную очередь терминала, отличного от управляющего терминала вызывающего;
    • устаревший системный вызов nfsservctl;
    • устаревший системный вызов bdflush;
    • привилегированные операции ioctl над блочными устройствами;
    • привилегированные операции ioctl над файловой системой;
    • привилегированные операции ioctl над устройством /dev/random (random);
    • установка фильтров seccomp без начальной установки атрибута потока no_new_privs;
    • изменение правил разрешения и запрета для групп управления устройствами;
    • операция ptrace PTRACE_SECCOMP_GET_FILTER для получения дампа фильтров seccomp трассируемого;
    • операция ptrace PTRACE_SETOPTIONS для приостановки защиты seccomp трассируемого (т. е., флаг PTRACE_O_SUSPEND_SECCOMP)
    • административные операции над многими драйверами устройств;
    • изменение значений приоритета autogroup путем записи в /proc/[pid]/autogroup.

CAP_SYS_BOOT

Использование reboot и kexec_load.

CAP_SYS_CHROOT

Использование chroot и смена примонтированных пространств имен с помощью setns.

CAP_SYS_MODULE

Загрузка и выгрузка модулей ядра (init_module и delete_module), в ядрах до версии 2.6.25 — отзыв возможностей из системного набора Bounded.

CAP_SYS_NICE

    • Снижение приоритета процесса (nice, setpriority) и изменение приоритета произвольных процессов;
    • задание политики планирования в реальном масштабе времени для вызывающего процесса, а также политики планирования и приоритетов для произвольных процессов (sched_setscheduler, sched_setparam, shed_setattr);
    • привязка к ЦП для произвольных процессов (sched_setaffinity);
    • назначение класса планирования ввода-вывода и приоритета для произвольных процессов (ioprio_set);
    • применение migrate_pages к произвольным процессам для их переноса на произвольные узлы;
    • применение move_pages к произвольным процессам;
    • использование флага MPOL_MF_MOVE_ALL в mbind и move_pages.

CAP_SYS_PACCT

Использование acct.

CAP_SYS_PTRACE

    • Трассировка любого процесса с помощью ptrace;
    • применение get_robust_list к произвольным процессам;
    • перенос данных в память произвольного процесса (или из нее) с помощью process_vm_readv и process_vm_writev;
    • изучение процессов с помощью kcmp.

CAP_SYS_RAWIO

  • Операции ввода-вывода из портов (iopl и ioperm);
  • доступ к /proc/kcore;
  • использование операции FIBMAP в ioctl(2);
  • создание устройств для доступа к специальным регистрам x86 (MSR, msr);
  • обновление /proc/sys/vm/mmap_min_addr;
  • отображение памяти по адресам меньше значения, заданного в /proc/sys/vm/mmap_min_addr;
  • отображение файлов в /proc/bus/pci;
  • доступ к /dev/mem и /dev/kmem;
  • выполнение различных команд устройств SCSI;
  • определённые операции с устройствами hpsa и cciss;
  • некоторые специальные операции с другими устройствами.

CAP_SYS_RESOURCE

  • Использование зарезервированного пространства файловых систем ext2;
  • вызовы ioctl, управляющие журналом ext3;
  • превышение ограничений дисковой квоты;
  • увеличение ограничений по ресурсам (setrlimit);
  • перезапись ограничений ресурсов RLIMIT_NPROC;
  • превышение максимального числа консолей при выделении консоли;
  • превышение максимального числа раскладок;
  • использование более 64hz прерывания из часов реального времени;
  • установка значения msg_qbytes очереди сообщений System V больше /proc/sys/kernel/msgmnb (msgop и msgctl);
  • разрешение RLIMIT_NOFILE ограничивать число файловых дескрипторов, передаваемых в обход, при передаче другому процессу через доменный сокет UNIX (unix);
  • переопределение /proc/sys/fs/pipe-size-max при назначении вместимости канала с помощью команды F_SETPIPE_SZ в fcntl;
  • использование F_SETPIPE_SZ для увеличения вместимости канала сверх /proc/sys/fs/pipe-max-size;
  • переопределение /proc/sys/fs/mqueue/queues_max, /proc/sys/fs/mqueue/msg_max, /proc/sys/fs/mqueue/msg-size_max при создании очередей сообщений POSIX (mq_overview);
  • операция prctl PR_SET_MM();
  • установка в /proc/[pid]/oom_score_adj значения меньше последнего, заданного процессом с помощью CAP_SYS_RESOURCE.

CAP_SYS_TIME

Настройка системных часов (settimeofday, stime, adjtimex) и часов реального времени (аппаратных).

CAP_SYS_TTY_CONFIG

Использование vhangup(2) и привилегированные операции ioctl с виртуальными терминалами.

CAP_SYSLOG (2.6.37)

Привилегированные операции syslog, просмотр адресов ядра в /proc  и  других  интерфейсах, когда значение /proc/sys/kernel/kptr_restrict = 1 (kptr_restrict в proc).

CAP_WAKE_ALARM (3.0)

Вызов чего-либо при пробуждении системы (установка таймеров CLOCK_REALTIME_ALARM и CLOCK_BOOTTIME_ALARM).

Группы (наборы) возможностей потока

Каждый поток (нить) имеет несколько групп (наборов) возможностей из числа перечисленных выше. Группа может быть пустой.

Permitted – разрешенные возможности

Ограничивающее надмножество набора Effective с возможностями, которые поток может предполагать. Этот набор также ограничивает список возможностей, которые могут быть добавлены в наследуемый набор потоком без CAP_SETPCAP в своём наборе Effective.

Если поток отменяет возможность в своем наборе Permitted, он не сможет вернуть ее (без вызова execve из программы с set-user-ID-root или программы, чьи возможности для файла позволяют это).

Inheritable – наследуемые возможности

Этот набор возможностей, сохраняемых при вызове execve. Наследуемые возможности остаются таковыми при выполнении любой программы и добавляются в набор Permitted, если у выполняющейся программы установлены соответствующие биты в наследуемом наборе для файлов.

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

Bounding

(на уровне потока, начиная с Linux 2.6.25) Механизм, который может использоваться для ограничения возможностей, предоставляемых вызовом execve.

Начиная с Linux 2.6.25, этот набор задается на уровне потока, а в более ранних версиях это атрибут системы для всех потоков.

Effective

Набор возможностей, используемый ядром при выполнении проверок прав для потока.

Ambient — внешние (охватывающие) возможности

(начиная с Linux 4.3) Набор возможностей, сохраняемый после execve для непривилегированных программ. Для набора внешних возможностей соблюдается правило, в соответствии с которым возможность не может  быть внешней, если она не входит в оба набора Permitted и Inheritable.

Набор внешних возможностей можно изменять с помощью prctl. Этот набор автоматически сужается при сужении соответствующего набора Permitted и Inheritable.

Выполнение программы, меняющей UID или GUI из-за установленного бита set-user-ID или set-group-ID, а также програмы, которая может устанавливать возможности для файла, сбрасывает набор Ambient. Внешние возможности добавляются к набору Permitted и назначаются набору Effective при вызове execve. Если внешние возможности расширяют набор Permitted или Effective при вызове execve, это не вызывает режим защищенного исполнения (secure-execution), описанный в ld.so.

Потомки (ветви) потока, созданные с помощью fork, наследуют копии наборов родительских возможностей.

Поток может менять свои возможности с помощью capset.

Начиная с версии 2.6.24 файл /proc/sys/kernel/cap_last_cap показывает максимальное численное значение возможностей, поддерживаемых работающим ядром. Это позволяет определить старший бит, который можно установить в наборе возможностей.

Возможности для файлов

Начиная с ядра 2.6.24 поддерживается связывание наборов возможностей с исполняемым файлом с помощью утилиты setcap. Наборы возможностей хранятся в расширенном атрибуте (setxattr, xattr) с именем security.capability. Для записи в этот атрибут требуется возможность CAP_SETFCAP. Наборы возможностей файла вместе с наборами возможностей потока определяют реальные возможности потока после вызова execve.

Для файла поддерживатся три набора возможностей.

Permitted (ранее forced)

Возможности, автоматически предоставляемые потоку, независимо отнаследуемых им возможностей.

Inheritable (ранее allowed)

Пересечение (AND) этого набора с набром наследуемых потоком возможностей определяет для потока набор Permitted после вызова execve.

Effective

По сути, это не набор возможностей, а просто бит, при установке которого вызов execve переносит все вновь разрешенные для потока возможности в новый набор Effective. При сброшенном бите ни одна из вновь разрешенных вызовом execve возможностей потока не присутствует в новом наборе Effective.

Установка бита предполагает, что любая из возможностей Effective или Inheritable для файла, которая заставляет поток обретать соответствующую возможность Permitted в результате вызова execve (Правила преобразования), также будет включена в набор Effective. Поэтому при включении возможности для файла (setcap, cap_set_file, cap_set_fd) установка бита Effective для любой возможности должна сопровождаться установкой этого флага для всех других возможностей, где установлен флаг Permitted или Inheritable.

Правила преобразования

При выполнении execve ядро рассчитывает новые возможности процесса, как показано ниже.

P'(ambient)     = (файл привилегированный) ? 0 : P(ambient)
P'(permitted)   = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient)
P'(effective)   = F(effective) ? P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable)    [>т. е. не меняется]
P'(bounding)    = P(bounding)       [т. е. не меняется]

где P() указывает значение возможности потока до вызова execve, P'() — возможности после вызова, F() — набор возможностей для файла.

Отметим некоторые детали, относящиеся к правилам преобразования возможностей:

  • набор Ambient появился лишь в Linux 4.3 и при преобразовании набора внешних возможностей в процессе execve привилегированным считается файл, имеющий возможности или установленный бит set-user-ID или set-group-ID bit set;

  • до Linux 2.6.25 набор Bounding был системным атрибутом для всех потоков и это значение использовалось для расчетов при вызове execve как P(bounding).

Отметим, что при описанном выше преобразовании возможности файла можно игнорировать (считать пустыми) по тем же причинам, которые служат для игнорирования битов set-user-ID и set-group-ID. Возможности файлов игнорируются при загрузке ядра с опцией no_file_caps option.

Текст подготовлен на основании материалов man из Mageia 8.

Николай Малых

nmalykh@protocols.ru

Рубрика: Linux | Комментарии к записи setcap отключены

RFC 8972 Simple Two-Way Active Measurement Protocol Optional Extensions

image_print
Internet Engineering Task Force (IETF)                         G. Mirsky
Request for Comments: 8972                                        X. Min
Updates: 8762                                                  ZTE Corp.
Category: Standards Track                                      H. Nydell
ISSN: 2070-1721                                        Accedian Networks
                                                                R. Foote
                                                                   Nokia
                                                             A. Masputra
                                                              Apple Inc.
                                                              E. Ruffini
                                                                  OutSys
                                                            January 2021

Simple Two-Way Active Measurement Protocol Optional Extensions

Необязательные расширения протокола STAMP

PDF

Аннотация

Этот документ описывает необязательные расширения для протокола STAMP), позволяющего измерять параметры производительности. Документ также определяет идентификатор тестовой сессии (STAMP Test Session Identifier) обновляя тем самым RFC 8762.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8972.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML.

1. Введение

Простой протокол активных двухсторонних измерений (Simple Two-way Active Measurement Protocol или STAMP) [RFC8762] задает базовую функциональность STAMP. В этом документе описаны необязательные расширения, использующие кодирование TLV. Такие расширения дополняют базовые функции STAMP, такие как измерение односторонней или круговой задержки, задержки при обработке, потери пакетов, их дублирование и нарушение порядка доставки. Спецификация определяет необязательные расширения STAMP, их формат и теорию работы. Определен также идентификатор тестовых сессий (STAMP Test Session Identifier) в качестве обновления [RFC8762].

2. Используемые соглашения

2.1. Сокращения

BDS

BeiDou Navigation Satellite System (навигационная система BeiDou).

BITS

Building Integrated Timing Supply (устройство синхронизации здания).

CoS

Class of Service (класс обслуживания).

DSCP

Differentiated Services Code Point (код дифференцированного обслуживания).

ECN

Explicit Congestion Notification (явное увкдомление о перегрузке).

GLONASS

Global Orbiting Navigation Satellite System (глобальная орбитальная спутниковая система навигации).

GPS

Global Positioning System (глобальная система позиционирования) [GPS].

HMAC

Hashed Message Authentication Code (хэшированный код аутентификации сообщения).

LORAN-C

Long Range Navigation System Version C (система навигации дальнего действия, версия C).

MBZ

Must be Zero (должно быть 0).

NTP

Network Time Protocol (протокол сетевого времени) [RFC5905].

PMF

Performance Measurement Function (функция измерения производительности).

PTP

Precision Time Protocol (протокол точного времени) [IEEE.1588.2008].

RP

Reverse Path (обратный путь).

SMI

Structure of Management Information (структура информации управления).

SSID

STAMP Session Identifier (идентификатор сессии STAMP).

SSU

Synchronization Supply Unit (блок синхронизации).

STAMP

Simple Two-way Active Measurement Protocol (простой протокол активного двухстороннего измерения).

TLV

Type-Length-Value (тип, размер, значение).

2.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Идентификатор сессии STAMP

STAMP Session-Sender передает тестовые пакеты рефлектору STAMP Session-Reflector. Рефлектор принимает пакеты от Session-Sender и действует в соответствии со своей конфигурацией и необязательными управляющими сигналами в тестовых пакетах от Session-Sender. Протокол STAMP определяет два формата пакетов — один для STAMP Session-Sender, другой для STAMP Session-Reflector и может работать в режиме с аутентификацией или без нее. Тестовые пакеты STAMP без аутентификации совместимы в линии с пакетами TWAMP-Test без аутентификации [RFC5357].

По умолчанию STAMP использует симметричные пакеты, т. е. размер пакетов, переданных Session-Reflector , совпадает с размером пакетов, полученных рефлектором.

Сессия STAMP идентифицируется квартетом (4-tuple) из IP-адресов отправителя и получателя, а также портов UDP на той и другой стороне). STAMP Session-Sender может создавать уникальный для него идентификатор сессии SSID, представляющий собой 2-октетное положительное целое число. Правила генерации SSID определяются реализацией. В [NUM-IDS-GEN] тщательно проанализированы базовые алгоритмы для генерации идентификаторов и их уязвимости. Например, реализация может использовать алгоритмы, описанные в параграфе 7.1 [NUM-IDS-GEN]. Реализации недопустимо назначать один идентификатор разным тестовым сессиям STAMP. Session-Sender может применять SSID для идентификации тестовых сессий STAMP. При использовании SSID идентификатор должен включаться в каждый тестовый пакет данной сессии. Расположение SSID в режиме без аутентификации показано на рисунке 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |             SSID              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                         MBZ (28 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Формат расширенного пакета без аутентификации.


Реализация STAMP Session-Reflector, поддерживающая эту спецификацию, должна идентифицировать сессию STAMP по SSID в комбинации с обычным квартетом для сессии. Перед началом тестовой сессии рефлектору должны быть предоставлены все элементы, идентифицирующие сессию. STAMP Session-Reflector должен отбрасывать не соответствующие сессии пакеты STAMP. Способ предоставления идентификационных данных сессии выходит за рамки документа. Соответствующая спецификации реализация STAMP Session-Reflector должна копировать значение SSID из полученных тестовых пакетов в отражаемые пакеты, как показано на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |           SSID                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Receive Timestamp                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Sequence Number                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Session-Sender Timestamp                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate |           MBZ                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL |                   MBZ                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат отраженного расширенного пакета без аутентификации.


Не поддерживающий эту спецификацию STAMP Session-Reflector будет возвращать нулевое значение поля SSID в отраженных пакетах STAMP и Session-Sender может прервать сессию при получении такого поля SSID. Реализация Session-Sender должна поддерживать управление поведением в таких случаях. Если тестовая сессия не прерывается, Session-Sender может передавать базовые пакеты STAMP [RFC8762] или продолжить передачу пакетов с SSID.

Размещение поля SSID в режиме с аутентификацией показано на рисунках 3 и 4.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      MBZ (12 октетов)                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Timestamp                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |            SSID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                         MBZ (68 октетов)                      |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Формат расширенного пакета с аутентификацией.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |            SSID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (4 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Receive Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (8 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Sequence Number                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
|                        MBZ (15 октетов)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        HMAC (16 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат отраженного расширенного пакета с аутентификацией.

4. TLV-расширения для STAMP

Кодирование TLV обеспечивает гибкий механизм расширения для необязательных информационных элементов за счет включения необязательного поля TLV в тестовый пакет STAMP. Это поле TLV может содержать другие TLV в зависимости от семантики (внешнего) TLV. TLV имеют однооктетное поле STAMP TLV Flags, однооктетное поле Type и двухоктетное поле Length, указывающее размер поля Value в октетах. Если поле Type для TLV или суб-TLV имеет значение из диапазона Private Use [RFC8126], размер должен быть не меньше 4 и первые четыре октета должны содержать фирменный код SMI (Private Enterprise Code), как указано в субреестре IANA SMI Network Management Private Enterprise Codes, с сетевым полядком байтов. Остальная часть поля Value определяется производителем. В последующих параграфах описано применение TLV для STAMP, расширяющее базовую спецификацию STAMP.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            Value                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Формат TLV в расширенном пакете STAMP.


STAMP TLV Flags

8-битовое поле. Формат и интерпретация описаны ниже.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах.

Value

Поле переменного размера, кодирование и интерпретация которого определяются значением поля Type.

Для всех многобайтовых полей в TLV, определенных этой спецификацией, используется сетевой порядок байтов.

Формат поля STAMP TLV Flags показан на рисунке 6, а флаги местоположения определены в параграфе 5.2.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|M|I|R|R|R|R|R|
+-+-+-+-+-+-+-+-+

Рисунок 6. Формат поля флагов.


U (Unrecognized)

Session-Sender должен устанавливать U = 1 перед отправкой расширенного пакета STAMP, а Session-Reflector должен устанавливать U = 1, если он не понимает данный TLV. Для известных TLV рефлектор должен указывать в отраженных пакетах U = 0.

M (Malformed)

Session-Sender должен устанавливать M = 1 перед отправкой расширенного пакета STAMP, а Session-Reflector должен устанавливать M = 1, если считает формат TLV некорректным (поле Length не соответствует типу или оставщаяся часть пакета STAMP меньше размера данного TLV). В остальных случаях рефлектор должен указывать в отраженных пакетах M = 0.

I (Integrity)

Session-Sender должен устанавливать I = 0 перед отправкой расширенного пакета STAMP, а Session-Reflector должен устанавливать I = 1, если расширения STAMP не прошли проверку HMAC (параграф 4.8). В остальных случаях рефлектор должен указывать в отраженных пакетах I = 0.

R

Зарезервированные на будущее флаги, которые должны содержать 0 при передачи и игнорироваться при получении.

Узел STAMP (Session-Sender или Session-Reflector), получивший тестовый пакет, должен проверить, является пакет базовым или содержит TLV. Узел должен сравнить значение поля Length в заголовке UDP и размер базового пакета STAMP в режиме (с аутентификацией или без нее), заданном конфигурацией сессии STAMP. Если разница превышает размер заголовка UDP, тестовый пакет включает STAMP TLV, следующие сразу за базовым пакетом STAMP. Рефлектор, не поддерживающий принятые расширения, не будет обрабатывать их, а просто скопирует в отраженный пакет, как указано в параграфе 4.3 [RFC8762]. Поддерживающий TLV рефлектор укажет необработанные им TLV установкой для них флага U = 1.

STAMP Session-Sender, получающий отраженные пакеты STAMP с TLV, должен проверить все TLV как указано ниже.

  • При установленном флаге U система STAMP должна пропустить обработку соответствующего TLV.

  • При установленном флаге M система STAMP должна прекратить обработку оставшейся части пакета STAMP.

  • При установленном флаге I система STAMP должна отбросить все TLV и должна прекратить обработку оставшейся части пакета STAMP.

  • Если реализация Session-Reflector не распознает значение поля Type, она должна включить копию TLV в отраженный пакет STAMP и должна установить для нее U = 1. Рефлектор должен пропускать обработку неизвестных TLV.

  • При нарушении формата TLV обработка TLV расширений должна прекращаться. Session-Reflector должен скопировать оставшуюся часть полученного пакета STAMP в отраженный пакет и должен установить M = 1.

4.1. TLV дополнительного заполнения

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         Extra Padding                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. TLV дополнительного заполнения.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах.

Extra Padding

Это поле следует заполнять псевдослучайными значениями, но можно заполнить нулями. Реализация должна контролировать поле Extra Padding.

Блок Extra Padding TLV похож на поле Packet Padding в пакетах TWAMP-Test [RFC5357]. Применение Extra Padding TLV рекомендуется для тестов STAMP, использующих пакеты, размер которых превышает базовый [RFC8762] размер, составляющий 44 октета в режиме без аутентификации и 112 — в режиме с аутентификацией. Extra Padding TLV может присутствовать в пакете STAMP в нескольких экземплярах.

4.2. TLV местоположения

STAMP Session-Sender может включать Location TLV переменного размера для запроса информации о местоположении рефлектора. Отправителю недопустимо заполнять в этом случае какие-либо поля, за исключением STAMP TLV Flags, Type и Length. Рефлектор должен проверять корректность формата TLV и следовать описанной в разделе 4 процедуре при обнаружении несоответствия.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Destination Port       |          Source Port          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         Sub-TLVs                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Location TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах.

Destination Port

2-октетное поле с номером целевого порта UDP в принятом пакете STAMP.

Source Port

2-октетное поле с номером порта отправителя UDP в принятом пакете STAMP.

Sub-TLVs

Последовательность суб-TLV, определенная ниже, которые Session-Sender использует для запроса информации о местоположении. Session-Reflector отвечает на них соответствующими суб-TLV для типа адреса (например, IPv4 или IPv6), используемого им.

Отметим, что все поля, не заполненные отправителем или рефлектором, передаются с заполнением нулями.

4.2.1. Суб-TLV местоположения

Location TLV использует формат, показанный на рисунке 5. Обработка флагов U и M для этого суб-TLV выполняется в соответствии с разделом 4. Для флага I отправитель и рефлектор должны устанавливать значение 0 до передачи, а на приемной стороне флаг игнорируется. Ниже приведены типы суб-TLV для Location TLV, определенные этой спецификацией (таблица 5).

Source MAC Address

12-октетный блок суб-TLV с Type = 1. Поле Length должно иметь значение 8, поле Value является 8-октетным MBZ, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source EUI-48 Address

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        EUI-48  Address                        |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |            MBZ                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Поле Value в суб-TLV Source EUI-48 Address.

12-октетный блок суб-TLV MAC-адресом отправителя EUI-48 и Type = 2. Поле Length должно иметь значение 8.

EUI-48 Address

6-октетное поле.

MBZ

2-октетное поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source EUI-64 Address

12-октетный блок суб-TLV, содержащий MAC-адрес EUI-64 для отправителя и Type = 3. Поле Length должно иметь значение 8, а Value содержит 8-октетный адрес EUI-64.

Destination IP Address

20-октетный блок суб-TLV с Type = 4. Поле Length должно иметь значение 16, а 16-октетное поле MBZ должно заполняться нулями при передаче и игнорироваться при получении.

Destination IPv4 Address

20-октетный блок суб-TLV с адресом получателя IPv4 и Type = 5. Поле Length должно иметь значение 16.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4 Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        MBZ (12 октетов)                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Поле Value в суб-TLV IPv4 Address.

IPv4 Address

4-октетное поле.

MBZ

12-октетное поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

Destination IPv6 Address

20-октетный блок суб-TLV с адресом получателя IPv6 и Type = 6. Поле Length должно иметь значение 16, а Value содержит 16-октетный адрес IPv6.

Source IP Address

20-октетный блок суб-TLV с Type = 7. Поле Length должно иметь значение 16, а Value содержит 16-октетное поле MBZ, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source IPv4 Address

20-октетный блок суб-TLV с адресом отправителя IPv4 и Type = 8. Поле Length должно иметь значение 16, а Value содержит показанные ниже поля (рисунок 10).

IPv4 Address

4-октетное поле.

MBZ

12-октетное поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source IPv6 Address

20-октетный блок суб-TLV с адресом отправителя IPv6 и Type = 9. Поле Length должно иметь значение 16, а Value содержит 16-октетный адрес IPv6.

4.2.2. Теория работы Location TLV

Session-Reflector, принимающий расширенный пакет STAMP с Location TLV, должен включить в отраженный пакет Location TLV, размер которого совпадает с размером Location TLV в полученном пакете. В соответствии с локальной политикой Session-Reflector может не сообщать значения некоторых полей, заполнив их нулями. Реализация Session-Reflector с учетом состояния должна обеспечивать управление политикой заполнения полей.

Session-Sender может включить суб-TLV Source MAC Address в Location TLV. Рефлектор, получивший Location TLV с суб-TLV Source MAC Address, должен включить суб-TLV Source EUI-48 Address, если MAC-адрес отправителя тестового пакета имеет формат EUI-48. Session-Reflector должен копировать MAC-адрес отправителя в поле EUI-48. В противном случае Session-Reflector должен использовать суб-TLV Source EUI-64 Address и должен копировать значение Source MAC Address из полученного пакета в поле EUI-64. Если полученный пакет STAMP не имеет поля Source MAC Address, рефлектор должен заполнить поле EUI-64 нулями до передачи отраженного пакета.

Session-Sender может включить суб-TLV Destination IP Address в Location TLV. Рефлектор, получивший Location TLV с суб-TLV Destination IP Address, должен включить суб-TLV Destination IPv4 Address, если IP-адрес отправителя полученного пакета относится к семейству IPv4. Session-Reflector должен копировать значение IP-адреса получателя в поле IPv4 Address. В противном случае Session-Reflector должен использовать суб-TLV Destination IPv6 Address и должен копировать значение IP-адреса получателя в поле IPv6 Address.

Session-Sender может включить суб-TLV Source IP Address в Location TLV. Рефлектор, получивший Location TLV с суб-TLV Source IP Address, должен включить суб-TLV Source IPv4 Address, если IP-адрес отправителя в полученном пакете относится к семейству IPv4. Session-Reflector должен копировать значение IP-адреса отправителя в поле IPv4 Address. В противном случае Session-Reflector должен использовать суб-TLV Source IPv6 Address и должен копировать значение IP-адреса отправителя в поле IPv6 Address.

Location TLV можно применять для определения IP-адреса и порта и MAC-адреса последнего интервала (last-hop) для пакета STAMP. MAC-адрес может указывать переключение пути на последнем интервале, адрес IP и порт UDP покажут наличие на пути маршрутизаторов NAT. Это позволяет отправителю узнать IP-адрес рефлектора, расположенного за транслятором NAT и обнаружить изменения в отображении NAT, которые могут приводить к отправке пакетов STAMP не тому рефлектору.

4.3. TLV характеристик временных меток

STAMP Session-Sender может включать Timestamp Information TLV для запроса информации у рефлектора. Отправителю недопустимо указывать информационные поля, за исключением STAMP TLV Flags, Type и Length. Все остальные поля должны заполняться нулями. Session-Reflector должен проверять поле Length в TLV и при некорректном значении выполнять процедуру, описанную в разделе 4 для TLV с ошибкой формата.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sync Src In  | Timestamp In  | Sync Src Out  | Timestamp Out |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Optional sub-TLVs                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Timestamp Information TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах (рисунок 5).

Sync Src In

1-октетное поле, указывающее источник синхронизации часов на входе Session-Reflector. Имеется несколько методов синхронизации, например, протокол NTP (Network Time Protocol) [RFC5905] (таблица 7).

Timestamp In

1-октетное поле, указывающее метод, с помощью которого Session-Reflector получает временную метку T2. Это может быть аппаратный источник, подключенный через API к местным часам (wall clock) или удаленный источник (через плоскость управления). Возможные источники синхронизации указаны в таблице 9.

Sync Src Out

1-октетное поле, указывающее источник синхронизации часов на выходе Session-Reflector. Имеется несколько методов синхронизации выхода Session-Reflector (таблица 7).

Timestamp Out

1-октетное поле, указывающее метод, с помощью которого Session-Reflector получает временную метку T3 (таблица 9).

Optional sub-TLVs

Необязательное поле переменного размера.

4.4. TLV класса обслуживания

STAMP Session-Sender может включать CoS TLV в тестовые пакеты STAMP. Формат CoS TLV показан на рисунке 12.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   DSCP1   |   DSCP2   |ECN| RP|          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. TLV класса обслуживания.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 4.

DSCP1

Код дифференцированного обслуживания (DSCP), назначенный отправителем для указания а поле DSCP отраженных пакетов.

DSCP2

Значение поля DSCP во входных пакетах рефлектора.

ECN

Значение поля ECN во входных пакетах рефлектора.

RP (Reverse Path)

2-октетное поле, для которго Session-Sender должен устанавливать значение 0.

Reserved

16-битовое поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

STAMP Session-Reflector, получающий пакет с CoS TLV, должен включить CoS TLV в отраженный пакет. От также должен копировать значения полей DSCP и ECN из заголовка IP в принятом пакете STAMP в поле DSCP2 отраженного пакета. Кроме того, Session-Reflector должен использовать локальные правила для проверки соответствия CoS значению поля DSCP1, разрешенному в домене. При соответствии Session-Reflector должен установить поле DSCP в заголовке IP отраженного пакеты в соответствии с полем DSCP1 в полученном пакете. В противном случае Session-Reflector должен использовать значение DSCP из полученного пакета STAMP и установить RP = 1. При получении отраженного пакета с RP = 0 Session-Sender будет сохранять значения DSCP и ECN для анализа CoS в обратном направлении. Если в отраженном пакете RP = 1, CoS анализирется лишь для прямого направления.

Можно использовать перемаркировку CoS для разных сценариев (например, 2G, 3G, LTE в мобильных сетях) в одной сети. Однако при некорректной настройке будет сложно определить причину избыточной потери пакетов служб верхних уровней, тогда как для нижележащего уровня уровень потерь будет нормальным. использование CoS TLV в тестах STAMP помогает в поиске неполадок, а также проверке правил Diffserv при обработке CoS, требуемой конфигурацией.

4.5. TLV прямого измерения

Direct Measurement TLV позволяет собирать пакеты по профилю, т. е. из определенного потока данных, передаваемого от Session-Sender к Session-Reflector. Определение относящихся к профилю пакетов выходит за рамки документа и отдается на откуп оператору.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Session-Sender Tx counter  (S_TxC)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Session-Reflector Rx counter  (R_RxC)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Session-Reflector Tx counter  (R_TxC)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Direct Measurement TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах. Поле должно иметь значение 12.

Session-Sender Tx counter (S_TxC)

4-октетное поле, к котором Session-Sender должен указывать число передаваемых по профилю пакетов.

Session-Reflector Rx counter (R_RxC)

4-октетное поле, которое Session-Sender должен устанавливать в 0, а Session-Reflector — игнорировать при получении. Рефлектор должен указывать в отраженных пакетах число принятых по профилю пакетов.

Session-Reflector Tx counter (R_TxC)

4-октетное поле, которое Session-Sender должен устанавливать в 0, а Session-Reflector — игнорировать при получении. Рефлектор должен указывать число переданных по профилю пакетов.

Session-Sender может включать Direct Measurement TLV в пакеты STAMP. При получении пакета STAMP с Direct Measurement TLV рефлектор должен включать этот блок TLV в отраженный пакет. Session-Reflector должен копировать значение поля S_TxC из полученного пакета в то же поле отраженного пакета.

4.6. TLV отчета о сети доступа

STAMP Session-Sender может включать Access Report TLV (рисунок 14) для индикации рефлектору изменения статуса сети доступа. Определение сети доступа выходит за рамки документа.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ID  |  Resv |  Return Code  |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Access Report TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 4.

ID (Access ID)

4-битовый идентификатор сети доступа, например, 3GPP (технологии радиодоступа, заданные 3GPP) или не-3GPP (доступ, не описанный 3GPP) [TS23501].

1

Сеть 3GPP.

2

Другая сеть (не-3GPP).

Другие значения недействительны и TLV с такими значениями должны отбрасываться.

Resv

4-битовое поле, которое должно заполнятся нулями при передаче и игнорироваться при получении.

Return Code

1-октетное поле, идентифицирующее сигнал отчета, например, доступность или недоступность. Значение предоставляется конечной точке STAMP, механизмом, выходящим за рамки этого документа. Возможные значения приведены в параграфе 5.6.

Reserved

2-октетное резервное поле, которое должно заполнятся нулями при передаче и игнорироваться при получении.

STAMP Session-Sender, включающий Access Report TLV, устанавливает в поле Access ID значение, соответствующее типу сети, для которое передается отчет. Отправитель также указывает значение поля Return Code в соответствии с рабочим состоянием сети доступа. Механизм определения этого состояния выходит за рамки спецификации. Рефлектор, получивший тестовый пакет с Access Report TLV, должен включить такой TLV в отраженный пакет. Рефлектор должен скопировать в поля Access ID и Return Code значения из соответствующих полей принятого пакета.

Session-Sender должен запустить таймер повторной передачи после отправки тестового пакета с Access Report TLV. Таймер должен быть остановлен при получении отраженного пакета STAMP с Access Report TLV. Если отсчет таймера завершается до приема такого пакета, Session-Sender должен повторить тестовый пакет с Access Report TLV. Этот повтор следует выполнять до 4 раз, после чего процедуру нужно прервать. Установка значения таймера определяется локальной политикой и сетевым окружением. По умолчанию для таймера повтора Access Report TLV следует устанавливать значение 3 секунды. Реализация должна обеспечивать управления значением таймера и числом повторов.

Access Report TLV используется функцией измерения производительности (Performance Measurement Function или PMF) в системе управления доступом, коммутацией и разделением для сети 5G networks [TS23501]. PMF в пользовательском оборудовании выступает как STAMP Session-Sender, а PMF в пользовательской плоскости (User Plane) — как STAMP Session-Reflector.

4.7. Follow-Up Telemetry TLV

Session-Reflector может оказаться способным поместить в поле Follow-Up Timestamp лишь временную метку типа SW Local (таблица 9). Однако система хостинга может предоставлять временную метку ближе к началу реальной передачи пакета, даже если невозможно доставить информацию отправителю (Session-Sender) вовремя для самого пакета. Тем не менее, эта метка может быть важна для Session-Sender, поскольку она повышает точность измерения задержки в сети за счет минимизации влияния задержки в выходных очередях.

STAMP Session-Sender может включать Follow-Up Telemetry TLV для запроса информации у рефлектора. Session-Sender должен указать в полях Follow-Up Telemetry Type и Length подходящие для него значения. Поля Sequence Number и Follow-Up Timestamp должны заполняться отправителем нулями и игнорироваться рефлектором при получении пакета STAMP с Follow-Up Telemetry TLV. Рефлектор должен проверить значение поля Length в тестовом пакете STAMP. Если это значение недействительно, рефлектор должен обнулить поля Sequence Number и Follow-Up Timestamp, а также установить флаг M в поле STAMP TLV Flags отраженного пакета. Если рефлектор работает без поддержки состояния (параграф 4.2 в [RFC8762]), он должен обнулять поля Sequence Number и Follow-Up Timestamp.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Follow-Up Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Timestamp M  |                     Reserved                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Follow-Up Telemetry TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 16.

Sequence Number

4-октетное поле, указывающее порядковый номер последнего пакета, отраженного в данной сессии STAMP. Поскольку Session-Reflector работает в режиме с поддержкой состояния (параграф 4.2 в [RFC8762]), это будет порядковый номер Session-Reflector из предыдущего отраженного пакета.

Follow-Up Timestamp

8-октетное поле, хормат которого задает флаг Z в поле Error Estimate базового пакета STAMP, который содержится в этом отраженном пакете от Session-Reflector, как описано в параграфе 4.2.1 [RFC8762]. Поле содержит временную метку момента передачи отраженного пакета с указанным номером.

Timestamp M(ode)

1-октетное поле, указывающее метод получения Follow-Up Timestamp элементом, передающим отраженный пакет STAMP (см. таблицу 9).

Reserved

2-октетное резервное поле, которое должно заполнятся нулями при передаче и игнорироваться при получении.

4.8. HMAC TLV

STAMP в режиме с аутентификацией защищает целостность данных в базовом пакете STAMP. Расширения STAMP предназначены для предоставления дополнительных сведений об условиях в сети и их целостность тоже важна. Все базовые пакеты STAMP с аутентификацией (параграфы 4.2.2 и 4.3.2 в [RFC8762]), совместимые с этой спецификацией, должны также аутентифицировать дополнительные TLV путем включения HMAC TLV, за исключением случаев наличия лишь Extended Padding TLV. Блок HMAC TLV должен помещаться после всех TLV, включенных в пакет STAMP, за исключением Extra Padding TLV. Включение HMAC TLV в другое место расширенного тестового пакета STAMP должно считаться отказом при проверке HMAC, как указано ниже. HMAC TLV можно применять для защиты целостности расширений STAMP в режиме без аутентификации. Реализация расширений STAMP должна обеспечивать элементы управления для включения защиты целостности расширений в режиме без аутентификации.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              HMAC                             |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. HMAC TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 16.

HMAC

16-октетное поле с кодом HMAC для всех предшествующих TLV.

Как определено в [RFC8762], STAMP использует HMAC-SHA-256 с отсечкой до 128 битов (см. [RFC4868]). Все вопросы использования ключей, рассмотренные в параграфе 4.4 [RFC8762], полностью применимы к HMAC TLV. Управление ключами HMAC и механизмы их распространения выходят за рамки этой спецификации. Предполагается, что HMAC TLV будет отслеживать изменения базового протокола STAMP [RFC8762], включая применение более совершенных криптографических алгоритмов. Расчет HMAC выполняется в соответствии с [RFC2104] для конкатенации поля Sequence Number в стандартном пакете STAMP и всех предшествующих TLV. Подпись должна отсекаться до 128 битов и помещаться в поле HMAC. Если HMAC TLV имеется в расширенном пакете STAMP, например, в режиме с аутентификацией, значение HMAC должно проверяться до использования данных, включенных в STAMP TLV. Если проверка HMAC рефлектором завершается отказом, Session-Reflector должен прекратить обработку полученного расширенного пакета STAMP. В этом случае рефлектор должен копировать TLV из полученного пакета STAMP в отраженный пакет и должен устанавливать флаг I = 1 в каждом TLV, копируемом в отраженный пакет, до отправки отраженного пакета. Если Session-Sender получает расширенный пакет STAMP с I = 1, он должен прервать обработку TLV в отраженном пакете. Если проверка HMAC у Session-Sender завершилась отказом, Session-Sender должен прервать обработку TLV в расширенном отраженном пакете STAMP.

5. Взаимодействие с IANA

Агентство IANA создало в реестре Simple Two-way Active Measurement Protocol (STAMP) TLV Types перечисленные в слудующих параграфах субреестры.

5.1. Субреестр STAMP TLV Types

В IANA создан субреестр STAMP TLV Types, коды в котором выделяются в соответствии с [RFC8126], как указано в таблице 1.

Таблица 1. Процедуры регистрации для субреестров типов STAMP TLV.

Диапазон

Процедура регистрации

1 — 175

IETF Review

176 — 239

First Come First Served

240 — 251

Experimental Use

252 — 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP TLV Types (таблица 2).

Таблица 2. Типы STAMP TLV.

Значение

Название

Документ

0

Резерв

RFC 8972

1

Extra Padding

RFC 8972

2

Location

RFC 8972

3

Timestamp Information

RFC 8972

4

Class of Service

RFC 8972

5

Direct Measurement

RFC 8972

6

Access Report

RFC 8972

7

Follow-Up Telemetry

RFC 8972

8

HMAC

RFC 8972

255

Резерв

RFC 8972

5.2. Субреестр STAMP TLV Flags

В IANA создан субреестр STAMP TLV Flags, коды в котором выделяются по процедуре IETF Review [RFC8126]. Флаги занимают 8 битов. В соответствии с этим документом в IANA создан субреестр STAMP TLV Flags (таблица 3).

Таблица 3. Флаги STAMP TLV.

Бит

Символ

Название

документ

0

U

Unrecognized TLV

RFC 8972

1

M

Malformed TLV

RFC 8972

2

I

Integrity check failed

RFC 8972

5.3. Субреестр STAMP Sub-TLV Types

В IANA создан субреестр STAMP Sub-TLV Types, значения в котором выделяются в соответствии с [RFC8126], как указано в таблице 4.

Таблица 4. Процедуры регистрации для субреестров типов STAMP суб-TLV.

Диапазон

Процедура регистрации

1 — 175

IETF Review

176 — 239

First Come First Served

240 — 251

Experimental Use

252 — 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Sub-TLV Types (таблица 5).

Таблица 5. Типы STAMP суб-TLV.

Значение

Название

TLV

Документ

0

Резерв

RFC 8972

1

Source MAC Address

Location

RFC 8972

2

Source EUI-48 Address

Location

RFC 8972

3

Source EUI-64 Address

Location

RFC 8972

4

Destination IP Address

Location

RFC 8972

5

Destination IPv4 Address

Location

RFC 8972

6

Destination IPv6 Address

Location

RFC 8972

7

Source IP Address

Location

RFC 8972

8

Source IPv4 Address

Location

RFC 8972

9

Source IPv6 Address

Location

RFC 8972

255

Резерв

RFC 8972

5.4. Субреестр STAMP Synchronization Sources

В IANA создан субреестр STAMP Synchronization Sources, значения в котором выделяются в соответствии с [RFC8126], как указано в таблице 6.

Таблица 6. Процедуры регистрации для источников синхронизации STAMP.

Диапазон

Процедура регистрации

1 — 127

IETF Review

128 — 239

First Come First Served

240 — 249

Experimental Use

250 — 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Synchronization Sources (таблица 7).

Таблица 7. Источники синхронизации STAMP.

Значение

Название

Документ

0

Резерв

RFC 8972

1

NTP

RFC 8972

2

PTP

RFC 8972

3

SSU/BITS

RFC 8972

4

GPS/GLONASS/LORAN-C/BDS/Galileo

RFC 8972

5

Local free-running

RFC 8972

255

Резерв

RFC 8972

5.5. Субреестр STAMP Timestamping Methods

В IANA создан субреестр STAMP Timestamping Methods, значения в котором выделяются в соответствии с [RFC8126], как указано в таблице 8.

Таблица 8. Процедуры регистрации для методов указания временных меток STAMP.

Диапазон

Процедура регистрации

1 — 127

IETF Review

128 — 239

First Come First Served

240 — 249

Experimental Use

250 — 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Timestamping Methods (таблица 9).

Таблица 9. Методы получения временных меток STAMP.

Значение

Название

Документ

0

Резерв

RFC 8972

1

HW Assist

RFC 8972

2

SW Local

RFC 8972

3

Control Plane

RFC 8972

255

Резерв

RFC 8972

5.6. Субреестр STAMP Return Codes

В IANA создан субреестр STAMP Return Codes, коды в котором выделяются в соответствии с [RFC8126], как указано в таблице 10.

Таблица 10. Процедуры регистрации для кодов возврата STAMP.

Диапазон

Процедура регистрации

1 — 127

IETF Review

128 — 239

First Come First Served

240 — 249

Experimental Use

250 — 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Return Codes (таблица 11).

Таблица 11. Коды возврата STAMP.

Значение

Название

Документ

0

Резерв

RFC 8972

1

Network available

RFC 8972

2

Network unavailable

RFC 8972

255

Резерв

RFC 8972

6. Вопросы безопасности

Этот документ определяет расширения протокола STAMP [RFC8762] и наследует все вопросы безопасности, связанные с базовым протоколом. В документе также определен блок HMAC TLV, обеспечивающий защиту целостности расширения STAMP, но он не защищает от replay-атак (повторное использование пакетов). Использование HMAC TLV описано в параграфе 4.8.

Для защиты от TLV с некорректным форматом реализации Session-Sender и Session-Reflector должны:

  • проверять значение флага M;

  • проверять корректность значения поля Length.

Поскольку эта спецификация задает механизм тестирования отображений DSCP, документ наследует все вопросы безопасности, рассмотренные в [RFC2474]. Мониторинг т необязательное управдение DSCP с помощью CoS TLV можно использовать через Internet так, что Session-Sender и Session-Reflector будут размещаться в доменах с разными профилями CoS. Поэтому важна проверка оператором набора значений CoS, применяемых в домене Session-Reflector. Реализации Session-Reflector также следует поддерживать локальную политику для подтверждения возможности использования значения поля DSCP, переданного Session-Sender (параграф 4.4).

7. Литература

7.1. Нормативные документы

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, «Simple Two-Way Active Measurement Protocol», RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.

7.2. Дополнительная литература

[GPS] «Global Positioning System (GPS) Standard Positioning Service (SPS) Performance Standard», GPS SPS 5th Edition, April 2020.

[IEEE.1588.2008] «IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems», IEEE Std. 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.

[NUM-IDS-GEN] Gont, F. and I. Arce, «On the Generation of Transient Numeric Identifiers», Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-06, 13 January 2021, <https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-06>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC4868] Kelly, S. and S. Frankel, «Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec», RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, «A Two-Way Active Measurement Protocol (TWAMP)», RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[TS23501] 3GPP, «Technical Specification Group Services and System Aspects; System Architecture for the 5G System (5GS); Stage 2 (Release 16)», 3GPP TS 23.501, 2019.

Благодарности

Аворы признательны за внимательное рецензирование и вдумчивые комментарии Tianran Zhou, Rakesh Gandhi, Yuezhong Song и Yali Wang. Срасибо Al Morton за его замечанию и ценные предложения. Авторы также признательны за комментарии и предложения, полученные от Martin Duke.

Участники работы

Ниже указан человек, внесший вклад в текст этого документа.

Guo Jun

ZTE Corporation

68# Zijinghua Road

Nanjing

Jiangsu, 210012

China

Phone: +86 18105183663

Email: guo.jun2@zte.com.cn

Адреса авторов

Greg Mirsky

ZTE Corp.

Email: gregimirsky@gmail.com

Xiao Min

ZTE Corp.

Email: xiao.min2@zte.com.cn

Henrik Nydell

Accedian Networks

Email: hnydell@accedian.com

Richard Foote

Nokia

Email: footer.foote@nokia.com

Adi Masputra

Apple Inc.

One Apple Park Way

Cupertino, CA 95014

United States of America

Email: adi@apple.com

Ernesto Ruffini

OutSys

via Caracciolo, 65

20155 Milan

Italy

Email: eruffini@outsys.org

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

Рубрика: RFC | Комментарии к записи RFC 8972 Simple Two-Way Active Measurement Protocol Optional Extensions отключены

Как новые технологии меняют отрасль Web-разработки

image_print

Artur Meyster

https://twitter.com/arturmeyster
https://www.linkedin.com/in/meyster

Артур Мейстер (Artur Meyster) — технический директор Career Karma (YC W19) —  онлайн-площадки для подбора людей, меняющих свою карьеру, с учебными курсами по программированию. Он также является ведущим подкаста Breaking Into Startups, в котором рассказывают о людях с нетрадиционным образованием, пришедшим в технологическую индустрию.

Как новые технологии меняют отрасль Web-разработки

Новые технологии меняют всю сферу разработки. Хорошо это или плохо, новинки внедряются и обратного пути нет. Отрасль web-разработок также испытывает влияние новых технологий. Ускоренные страницы для мобильных приложений, голосовой поиск и искусственный интеллект (artificial intelligence или AI) — это лишь несколько технологий, применяемых сегодня для улучшения web-сайтов.

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

Точно так же использование дополненной реальности (augmented reality или AR) для покупок в сети ставит перед web-разработчиками новые задачи и требует от них оставаться в курсе современных событий.

Чтобы понять, как новые технологии влияют на отрасль web-разработки, нужно принять во внимание несколько аспектов.

Искусственный интеллект и машинное обучение

Сегодня разработчики применяют машинное обучение и AI для улучшения web-сайтов беспрецедентными способами. Благодаря машинному обучению, сайты способны предоставлять персонифицированные услуги и пользователи получают адаптированную для них информацию. По сути, такие компании, как Netflix, Spotify и Youtube использовали машинное обучение, чтобы предлагать содержимое на основе ввода от пользователя. Сейчас пользователи чувствуют себя комфортно, поскольку не приходится тратить время на просмотр не интересующего их содержимого.

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

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

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

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

Системы управления содержимым

Системы управления содержимым (Content management systems или CMS) служат для упрощения процесса создания web-сайтов. Фактически пользователям не нужны познания в сфере web-разработки и достаточно просто понимать, какой информацией они хотят поделиться, и добавить на сайт несколько виджетов. Однако создание уникальных сайтов с помощью таких CMS как WordPress или Wix может быть затруднего необходимостью использовать базовые макеты и темы.

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

Ускоренные страницы для мобильных приложений

Ускоренные страницы для мобильных приложений (Accelerated mobile pages или AMP) получили широкое распространение с обретением популярности смартфонами. Фактически большинство пользователей сейчас применяет мобильные устройства с высокой скоростью доступа в сеть, что требует быстрой загрузки web-сайтов. Использование AMP обеспечивает решение нескольких проблем. Например, эта технология не только повышает привлекательность мобильных приложений, но и снижает нагрузку на сервер. Фактически, это улучшает взаимодействие с пользователем и снижает нагрузку на серверы хостинг-провайдера.

Однако не все идеально и AMP также имеет свои недостатки. Во-первых, использование ускоренных страниц снижает интеграцию рекламы с сайтом и у результате владельцы сайта могут столкнуться со снижением дохода. Во-вторых, сайты электронной коммерции используют динамические элементы, не поддерживаемые AMP. По этой причине приходится перенаправлять клиента, посещающего web-сайт, что может снизить доверие к компании. И, наконец, имеются ограничения для содержимого web-сайтов, поскольку финальное представление находится под контролем Google.

Дополненная реальность

Web-дизайнеры внедрили технологию дополненной реальности (AR) в камеры смартфонов и web-камеры, чтобы помочь клиентам выбирать продукцию. Фактически, применение AR улучшает взаимодействие с пользователем как в настольных системах, так и в мобильных устройствах. Пользователь может через свою камеру показать все, что пожелает, и увидеть нужную продукцию. Например, в сфере обустройства дома можно выбрать продукцию и показать свое окружение через камеру, чтобы увидеть, как будет выглядеть комната. В модной розничной торговле пользователи могут просмотреть наряды и увидеть, что им лучше подходит. Разумно отметить, что дополненная реальность изменила способы покупок через сеть, повысив уровень удовлетворенности клиентов.

Рубрика: Разное | Комментарии к записи Как новые технологии меняют отрасль Web-разработки отключены

RFC 8966 The Babel Routing Protocol

image_print
Internet Engineering Task Force (IETF)                     J. Chroboczek
Request for Comments: 8966             IRIF, University of Paris-Diderot
Obsoletes: 6126, 7557                                        D. Schinazi
Category: Standards Track                                     Google LLC
ISSN: 2070-1721                                             January 2021

The Babel Routing Protocol

Протокол маршрутизации Babel

PDF

Аннотация

Babel представляет собой протокол маршрутизации на основе вектора удаленности (distance-vector) с предотвращением петель, который устойчив к отказам и эффективен как в кабельных, так и в беспроводных сетях. Документ описывает протокол маршрутизации Babel и отменяет RFC 6126 и RFC 7557.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8966.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML.

1. Введение

Протокол маршрутизации Babel на основе вектора удаленности с предотвращением петель предназначен для отказоустойчивой и эффективной маршрутизации для сетей, использующих префиксы и плоскую маршрутизацию (многосвязные сети — mesh), как в сравнительно стабильных проводных системах, так и в очень динамичных беспроводных сетях. Этот документ описывает протокол маршрутизации Babel и отменяет [RFC6126] и [RFC7557].

1.1. Свойства

Основным свойством, которое делает протокол Babel подходящим для нестабильных сетей, является то, что он, в отличие от простых протоколов на основе вектора удаленности [RIP], строго ограничивает частоту и продолжительность аномалий маршрутизации, таких как петли и «черные дыры» в процессе схождения маршрутов. Даже после обнаружения перемещения элемента (mobility event) сеть Babel обычно остается свободной от петель. После такого события Babel быстро пересчитывает конфигурацию, которая не содержит петель и сохраняет связность, но не обязательно является оптимальной. Эта операция во многих случаях даже не требует обмена пакетами. Затем Babel выполняет медленную процедуру схождения (может занимать минуты) для получения оптимальной конфигурации. Это достигается за счет использования упорядоченных маршрутов — метода, впервые примененного в маршрутизации Destination-Sequenced Distance-Vector (упорядоченные по адресатам векторы удаленности) [DSDV].

Более точно, протокол Babel имеет перечисленные ниже свойства:

  • когда каждый префикс исходит лишь от одного маршрутизатора, в протоколе Babel не возникает петель;

  • когда один префикс исходит от нескольких маршрутизаторов, Babel может иногда создавать временные маршрутные петли, которые исчезают за время, пропорциональное диаметру петли, и больше никогда (до произвольного момента сбора мусора (garbage-collection или GC)) вовлеченные маршрутизаторы не будут попадать в петлю для того же префикса;

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

Babel обеспечивает оценку качества каналов и поддерживает достаточно произвольную метрику. При соответствующей настройке Babel может реализовать маршрутизацию по кратчайшему пути (shortest-path) или использовать метрику, например, на основе числа теряемых пакетов.

Узлы Babel устанавливают связи между собой даже при настройке с разными параметрами. Например, мобильный узел с небольшой батареей, может использовать большие временные интервалы (сообщения hello, обновления и т. п.), нежели узел с питанием от электросети. И наоборот, узел с высоким уровнем мобильности может сократить временные интервалы. Возможность создавать такие неоднородные сети делают протокол Babel адаптируемым к работе в неуправляемых и беспроводных средах.

Babel является гибридным протоколом маршрутизации в том смысле, что он может передавать маршруты для разных протоколов сетевого уровня (IPv4 и IPv6), независимо от протокола, используемого для передачи пакетов Babel.

1.2. Ограничения

Протоколу Babel присущи два ограничения, делающие его непригодным в некоторых средах. Во-первых, протокол Babel основан на периодическом обновлении таблиц маршрутизации вместо использования надежного транспорта, что ведет к росту служебного трафика в больших стабильных сетях по сравнению с протоколами, которые передают обновления лишь при наличии изменений. Для таких сетей больше подходят такие протоколы как OSPF [OSPF], IS-IS [IS-IS] или EIGRP3 [EIGRP].

Во-вторых, если не реализован второй алгоритм, описанный в параграфе 3.5.4, Babel устанавливает время удержания при удалении префикса. Хотя это время не применяется к удаляемому префиксу и поэтому не препятствует быстрому схождению после восстановления префикса, оно применимо для более коротких префиксов, которые охватывает удаленный. Это может сделать реализации Babel, не поддерживающие необязательный алгоритм, описанный в параграфе 3.5.4, не подходящими для сетей с автоматическим агрегированием префиксов.

1.3. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными буквами, как показано здесь.

2. Концептуальное описание протокола

Babel является протоколом на основе вектора удаленности с предотвращением петель. Он основан на алгоритме Беллмана-Форда (Bellman-Ford), как известный протокол RIP [RIP], но включает множество усовершенствований, предотвращающих возникновение петель или быстро устраняющих петли без их повторного появления.

Концептуально алгоритма Bellman-Ford выполняется параллельно для каждого источника маршрутной информации (получателя трафика данных). Далее источник обозначается S с напоминанием, что алгоритм выполняется параллельно для всех источников.

2.1. Стоимость, метрика, соседство

Для каждой пары смежных узлов A и B протокол Babel рассчитывает абстрактное значение, называемое стоимостью канала от A к B и обозначаемое C(A, B). Для данного маршрута между любыми двумя (не обязательно смежными) узлами метрикой маршрута будет сумма стоимости всех каналов на пути. Цель алгоритма маршрутизации заключается в расчете для каждого S дерева маршрутов в S с минимальной метрикой.

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

Узел Babel периодически передает сообщения Hello всем своим соседям, а также периодически передает сообщения IHU (I Heard You — я вас слышу) каждому соседу, от которого недавно получено сообщение Hello. На основе информации из сообщений Hello и IHU от соседа B узел A рассчитывает стоимость C(A, B) для канала от A до B.

2.2. Алгоритм Беллмана-Форда

Каждый узел A поддерживает две части данных — оценку расстояния до S — D(A) и следующий маршрутизатор в направлении S — NH(A). Исходно D(S) = 0, D(A) бесконечная, а NH(A) не определен.

Периодически каждый узел B передает всем своим соседям обновление маршрутов в сообщении, содержащем D(B). Когда сосед A узла B получает обновление маршрутов, он проверяет, выбран ли B его следующим интервалом. Если это так, в качестве NH(A) указывается B, а для D(A) устанавливается C(A, B) + D(B). В противном случае A сравнивает C(A, B) + D(B) с текущим значением D(A). Если это значение меньше, полученное обновление анонсирует лучший маршрут по сравнению с выбранным и в качестве NH(A) устанавливается B, а D(A) получает значение C(A, B) + D(B).

Возможен ряд усовершенствований этого алгоритма и они применяются в протоколе Babel. В частности скорость схождения может быть увеличена за счет отправки в дополнение к обычным плановым обновлениям не запланированных «триггерных обновлений» при обнаружении существенных изменений в топологии. Кроме того, узел может поддерживать множество дополнительных маршрутов, которые были анонсированы соседями, отличными от выбранного им соседа, и которые могут применяться сразу же, если произойдет отказ выбранного соседа.

2.3. Временные петли в Bellman-Ford

Хорошо известно, что естественное применение алгоритма Bellman-Ford к распределенной маршрутизации может вызывать временные петли после изменения топологии. Рассмотрим пример, показанный на рисунке.

         B
      1 /|
   1   / |
S --- A  |1
       \ |
      1 \|
         C


После схождения будет D(B) = D(C) = 2 и NH(B) = NH(C) = A.

Предположим, что на канале между S возник отказ, как показано на рисунке.

         B
      1 /|
       / |
S     A  |1
       \ |
      1 \|
         C


При обнаружении этого отказа узел A сменит следующий интервал на B (который продолжает анонсировать маршрут к S с метрикой 2), анонсирует метрику 3, а затем — новый маршрут с метрикой 3. Этот процесс смены выбранных соседей и увеличения их метрики продолжается, пока метрика не станет «бесконечной» (значение превысит все другие метрики, которые протокол маршрутизации способен передавать).

2.4. Условия осуществимости

Алгоритм Bellman-Ford очень устойчив к отказам и его свойства сходимости сохраняются при задержке маршрутизаторами получения маршрутов или отбрасывании некоторых обновлений. Маршрутизаторы Babel отбрасывают полученные анонсы маршрутов, пока они не уверены, что восприятие маршрута не создаст петли. Более формально, определяется условие, когда анонсы маршрутов, известные как «условие осуществимости» (feasibility condition), гарантируют отсутствие маршрутных петель, где все маршрутизаторы игнорируют обновления, не соответствующие условию осуществимости. Фактически, это возвращает алгоритм Bellman-Ford в семейство алгоритмов маршрутизации, параметризуемых условием выполнимости.

Возможно много разных условий выполнимости. Например, BGP можно представить как протокол на основе вектора удаленности с (достаточно радикальным) условием осуществимости — обновления воспринимаются лишь при условии, что номер автономной системы принимающего узла не включен в атрибут AS_PATH этого обновления (отметим, что условие выполнимости в BGP не гарантирует отсутствие временных микропетель в процессе схождения).

Другой пример условия выполнимости применяется в протоколе маршрутизации DSDV [DSDV], а также в протоколе AODV4 [RFC3561] и основан на наблюдении, что маршрутные петли могут возникать лишь после переключения маршрутизатора на маршрут, метрика которого больше выбранного ранее маршрута. Поэтому можно считать маршрута выполнимым, когда его метрика на локальном узле будет не больше метрики выбранного с маршрута, т. е. анонс с метрикой D(B) воспринимается узлом A, когда C(A, B) + D(B) <= D(A). Если все маршрутизаторы следуют этому ограничению, метрика на каждом маршрутизаторе не возрастает и всегда сохраняется следующий инвариант: если A выбрал B как следующий интервал, то D(B) < D(A), что означает отсутствие петель в графе пересылки.

Babel использует более тонкое условие выполнимости, выведенное из EIGRP [DUAL]. Для маршрутизатора A, определяется дистанция выполнимости (достижимости) A FD(A), как меньшая из метрик, анонсируемая A для S любому из своих соседей. Обновление переданное соседом B считается выполнимым, если анонсируемая узлом B метрика D(B) строго меньше дистанции достижимости A, т. е. D(B) < FD(A).

Легко видеть, что это условие не более ограничительно по сравнению с DSDV. Предположим, что узел A выполняет условие достижимости DSDV. Тогда D(A) не возрастает и в любой момент D(A) <= FD(A). Далее предположим, что A получает соответствующее условию DSDV обновление с анонсом метрики D(B). Поскольку обновление соответствует DSDV, C(A, B) + D(B) <= D(A), следовательно D(B) < D(A), а, поскольку D(A) <= FD(A), то и D(B) < FD(A). Чтобы увидеть, что это меньшее ограничение, рассмотрим приведенный ниже рисунок, где A выбрал маршрут через B и D(A) = FD(A) = 2. Поскольку D(C) = 1 < FD(A), маршрут через C достижим для A, хотя его метрика C(A, C) + D(C) = 5 больше чем для выбранного в данный момент маршрута.

   B
1 / \ 1
 /   \
S     A
 \   /
1 \ / 4
   C


Чтобы показать, что условие выполнимости сохраняет гарантию отсутствия петель, напомним, что с тот момент, когда A воспринимает обновление от B, анонсируемая B метрика D(B) не меньше FD(B), поскольку она меньше FD(A), в этот момент FD(B) < FD(A). Поскольку это свойство сохраняется, когда A передает обновления и выбирает другой следующий интервал, это будет верно всегда и гарантирует отсутствие петель в графе пересылки.

2.5. Решение проблемы истощения — нумерованные маршруты

Обычно определенное выше условие осуществимости вызывает истощение (starvation), когда у маршрутизатора не остается доступных маршрутов. Рассмотрим показанную на рисунке ситуацию, где A и B выбрали прямой маршрут к S.

   A
1 /|        D(A) = 1
 / |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B


Предположим, что канал между A и S оказался разорван.

   A
   |
   |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B


Единственный маршрут от A до S, проходящий через B, не является осуществимым и страдает от ложного истощения. В этот момент все субдерево, страдающее от истощения, должно быть сброшено, что, по сути, и делает EIGRP при выполнении глобальной синхронизации всех маршрутов в истощенном субдереве («активная» фаза EIGRP).

Babel менее резко реагирует на истощение, используя нумерованные маршруты, введенные в DSDV и адаптированные AODV. В дополнение к метрике каждый маршрут имеет порядковый номер, который является неубывающим целым числом, распространяемым через сеть без изменения и инкрементируемым лишь источником. Пара (s, m), где s — порядковый номер, а m — метрика, называется дистанцией (расстоянием).

Полученное обновление выполнимо если оно новее дистанции достижимости, поддерживаемой принимающим узлом или столь же свежее и его метрика строго меньше. Более формально, если FD(A) = (s, m), обновление с дистанцией (s’, m’) выполнимо, если s’ > s или s = s’ и m’ < m.

Предположим, что S имеет порядковый номер 137. Тогда приведенный выше рисунок примет вид

      A
      |
      |       FD(A) = (137, 1)
   S  |1
    \ |        D(B) = (137, 2)
   2 \|       FD(B) = (137, 2)
      B


После того, как S увеличит свой порядковый номер и новый номер будет распространен узлу B, мы получим

   A
   |
   |       FD(A) = (137, 1)
S  |1
 \ |        D(B) = (138, 2)
2 \|       FD(B) = (138, 2)
   B


И маршрут через B становится выполнимым.

Отметим, что порядковые номера используются для определения достижимости, но они не применяются при выборе маршрутов. Узел игнорирует порядковые номера в процессе определения лучшего маршрута к данному адресату (параграф 3.6). Иное поведение вызвало бы осцилляции маршрутов при распространении порядкового номера через сеть и могло бы даже создать постоянные «черные дыры» с экзотической метрикой.

2.6. Запросы

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

Babel использует другой подход. Когда узел обнаруживает, что он страдает от потенциально ложного истощения, этот узел передает явный запрос источнику для получения нового порядкового номера. Этот запрос пересылается поэтапно (hop by hop) к источнику, независимо от условия выполнимости. При получении запроса источник увеличивает свой порядковый номер и в широковещательном режиме передает обновление, которое пересылается запросившему узлу.

Отметим, что после изменения топологии сети не все такие запросы в общем случае будут попадать к источнику, поскольку некоторые будут отправлены через каналы, которые в данный момент разорваны. Однако, если сеть все еще подключена, хотя бы один из страдающих от ложного истощения узлов имеет (невыполнимый) маршрут к источнику. Поэтому при отсутствии потери пакетов хотя бы один запрос попадет к источнику. Для компенсации потери пакетов запросы могут повторяться несколько раз.

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

2.7. Префикс от нескольких маршрутизаторов

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

Поскольку синхронизация порядковых номеров между маршрутизаторами проблематична, Babel считает маршруты к одному префиксу разными сущностями, когда они приходят от разных маршрутизаторов. Каждый анонс маршрутов содержит router-id создавшего его маршрутизатора, а дистанции выполнимости поддерживаются не на уровне префикса, а на уровне источника, который представляет собой пару (router-id — префикс). Фактически Babel гарантирует отсутствие петель в графе пересылки для каждого источника. Поскольку объединение множества ациклических графов не всегда является ациклическим, Babel не гарантирует отсутствия петель в случае происхождения префикса от нескольких маршрутизаторов, но любые петли устраняются на время, пропорциональное диаметру петли, когда обновление «обойдет петлю».

Рассмотрим показанную ниже топологию, где узел A выбрал маршрут по умолчанию через S, а B — через S’.

           1     1     1
::/0 -- S --- A --- B --- S' -- ::/0


Предположим, что одновременно отказали оба принятых по умолчанию маршрута. В этом случае ничто не мешает узлу A переключиться на B, а B — одновременно переключиться на A. Однако, как только A успешно анонсирует новый маршрут узлу B, маршрут через A станет невыполнимым для B. И наоборот, как только B анонсирует свой маршрут через A, маршрут через B станет невыполнимым для A.

Фактически петля исчезает не позднее прохождения маршрутной информации через нее. Поскольку этот процесс может быть задержан потерей пакетов, Babel прилагает некоторые усилия для обеспечения гарантированной доставки обновлений после смены router-id (параграф 3.7.2).

Кроме того, после анонсирования маршрутизаторами двух маршрутов оба источника будут в их таблицах источников, что предотвратит их повторное попадание в маршрутную петлю, включающую маршруты от S и S’ (вплоть до времени источника GC, для которого, если позволяет память, можно устанавливать произвольно большое значение).

2.8. Перекрывающиеся префиксы

В предыдущем обсуждении предполагалось, что префиксы разъединены (не перекрываются) как в случае плоской (многосвязной — mesh) маршрутизации. Однако на практике префиксы могут перекрываться, например, принятый по умолчанию маршрут перекрывается со всеми маршрутами в сети.

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

           1     1
::/0 -- A --- B --- C


Предположим, что узел C отказал. Если B пересылает пакеты для C по принятому по умолчанию маршруту, возникнет петля, которая будет сохраняться, пока A не узнает об отсутствии у B прямого маршрута к C. Узел B избегает этой ловушки, устанавливая «невыполнимый» маршрут после вызванного отказом пропадания маршрута. Этот маршрут поддерживается, пока не будет гарантии, что утраченный маршрут отменен всеми соседями B (параграф 3.5.4).

3. Работа протокола

Каждый узел Babel (speaker) имеет свой идентификатор (router-id) — произвольную стороку размером 8 октетов, которая предполагается уникальной в домене маршрутизации. Идентификаторы могут выделяться, например, случайным образом или выводиться из адресов канального уровня. Кодирование протокола становиться чуть более компактным при выделении router-id в стиле присвоения идентификаторов узлов IPv6 (см. описание флага R в параграфе 4.6.9.).

3.1. Передача и прием сообщений

Пакеты протокола Babel передаются в теле дейтаграмм UDP (раздел 4). Каждый пакет Babel может содержать множество (возможно пустое) TLV, большинство из которых могут включать суб-TLV.

Трафик управления Babel может передаваться по протоколу IPv6 или IPv4, а префиксы любого семейства адресов могут анонсироваться через любой протокол. Таким образом, имеется по меньшей мере две модели естественного развртывания — использование исключительно IPv6 для всего трафика управления или работа двух разных экземпляров протокола, по одному для каждого семейства адресов. Рекомендуется применять исключительное использование IPv6 для всего управляющего трафика, поскольку одновременное применение двух протоколов удваивает трафик, предназначенный для обнаружения соседей и оценки качества каналов.

Адресом отправителя пакетов Babel всегда является индивидуальный адрес (link-local в случае IPv6). Пакеты Babel могут передаваться по стандартному (link-local) групповому или индивидуальному (link-local) адресу. При обычной работе узел Babel передает своим соседям групповые и индивидуальные пакеты.

За исключением подтверждений, все Babel TLV могут передаваться по групповому или индивидуальному адресу и семантика TLV от этого не зависит. Поэтому узлу Babel не требуется определять адрес получателя в принятом пакете для его интерпретации.

К передаваемым узлом Babel пакетам могут применяться произвольные вариации задержки (jitter). Исходящие TLV буферизуются и их следует передавать со случайной задержкой. Это преследует две цели — избежать синхронизации узлов Babel в сети [JITTER] и обеспечить возможность объединения множества TLV в один пакет.

Максимальная задержка TLV может зависеть от TLV. Когда описание протокола указывает срочность TLV (параграфы 3.7.2 и 3.8.1), такие TLV должны передаваться в течение короткого времени, называемого тайм-аутом срочности (urgent timeout), рекомендуемые значения тайм-аута приведены в Приложении B. Когда TLV регулируется тайм-аутом, заданным в предшествующем TLV, как в случае подтверждений (параграф 4.6.4), обновлений (параграф 3.7) и IHU (параграф 3.4.2), TLV должны передаваться достаточно быстро, чтобы уложиться в указанное время (с небольшим запасом на задержку распространения). В остальных случаях TLV следует отправлять в течение половины интервала Multicast Hello.

Для предотвращения отбрасывания пакетов (отправителем или получателем) следует вносить задержку между последовательными пакетами с одного интерфейса с учетом ограничений, указанных выше. Однако следует отметить, что задержка может препятствовать возможности агрегирования пакетов для некоторых канальных технологий (например, IEEE 802.11 [IEEE802.11]).

3.2. Структуры данных

В этом параграфе описаны структуры данных, поддерживаемые каждым узлом Babel. Это концептуальное описание и узлы Babel могут применять иные структуры данных, обеспечивающие соответствие результирующего протокола данному документу. Например, вместо поддержки одной таблицы, содержащей выбранные и резервные (fallback) маршруты, как описано в параграфе 3.2.6, реализация может использовать две разных таблицы для выбранных и резервных маршрутов.

3.2.1. Арифметика порядковых номеров

Порядковые номера (seqno) включаются во многие структуры данных Babel и интерпретируются как целые числа с модулем 216. Используемая в этом документе арифметика порядковых номеров описана ниже.

Для данного порядкового номера s и неотрицательного целого числа n сумма s и n определяется выражением

      s + n (по модулю 216) = (s + n) MOD 2^(16)

или его эквивалентом

      s + n (по модулю 216) = (s + n) AND 65535

где MOD операция деления по модулю, дающая неотрицательное целое число, а AND побитовое пересечение (И). Для двух порядковых номеров s и s’ отношение s меньше s’ (s < s’) определяется выражением

      s < s' (по модулю 216), когда 0 < ((s' - s) MOD 2^(16)) < 32768

или его эквивалентом

      s < s' (по модулю 216), когда s /= s' и ((s' - s) AND 32768) = 0.

3.2.2. Порядковый номер узла

Порядковый номер узла — это 16-битовое целое число, включаемое в обновления, передаваемые для маршрутов, исходящих из этого узла.

Узлы инкрементируют свой порядковый номер (модуль 216) при получении запроса на новый номер (параграф 3.8.1.2). Узлам не следует инкрементировать свой порядковый номер спонтанно, поскольку увеличение seqno снижает вероятность того, что другие узлы будут иметь выполнимые альтернативные маршруты при отказе выбранных ими маршрутов.

3.2.3. Таблица интерфейсов

Таблица интерфейсов содержит список всех интерфейсов, на которых узел использует протокол Babel. Каждая запись таблицы включает порядковый номер исходящего Multicast Hello (16-битовое целое число, которое передается в каждом Multicast Hello TLV на этом интерфейсе и инкрементируется с модулем 216 при передаче Multicast Hello). Отметим, что порядковый номер Multicast Hello не связан с порядковым номером узла.

С каждой записью в таблице интерфейсов связано два таймера. Таймер периодических сообщений Multicast Hello управляет плановой отправкой пакетов Multicast Hello и IHU (параграф 3.4). Таймер периодических обновлений (Update) управляет периодической отправкой маршрутных обновлений (параграф 3.7.1). Рекомендуемые значения для таймеров приведены в Приложении B.

3.2.4. Таблица соседей

Таблица соседей содержит список всех смежных интерфейсов, от которых недавно были получены пакеты Babel. Таблица индексируется по парам (интерфейс — адрес) и каждая запись содержит:

  • интерфейс локального узла, через который доступен этот сосед;

  • адрес интерфейса соседа;

  • историю недавно принятых пакетов Multicast Hello от этого соседа (это может быть, например, последовательность из n битов с небольшим n, указывающая какие из последних n сообщений hello от данного соседа были приняты локальным узлом);

  • история недавно полученных сообщений Unicast Hello от этого соседа;

  • значение «стоимости передачи» из последнего пакета IHU, полученного от этого соседа, или шестнадцатеричное значение FFFF (бесконечность), если истек таймер IHU для данного соседа;

  • ожидаемый порядковый номер Multicast Hello от этого соседа (целое число с модулем 216);

  • ожидаемый порядковый номер Unicast Hello от этого соседа (целое число с модулем 216);

  • порядковый номер исходящего Unicast Hello для этого соседа (целое число с модулем 216), передаваемый в каждом Unicast Hello TLV и инкрементируемый (модуль 216) при отправке Unicast Hello (отметим, что номер исходящего Unicast Hello для соседа отличается от номера исходящего Multicast Hello для интерфейса).

С каждой записью таблицы связано три таймера — Multicast Hello, задающий интервал, передаваемый в плановых Multicast Hello TLV от этого соседа, Unicast Hello с интервалом из плановых Unicast Hello TLV и IHU со значением, кратным (в несколько раз) интервалу из IHU TLV (см. Приложение B).

Отметим, что таблица соседей индексируется по адресам IP, а не router-id, поскольку смежность существует между интерфейсами, а не узлами. Поэтому два узла с несколькими интерфейсами могут иметь несколько отношений смежности, что часто возникает в беспроводных сетях, где участвуют узлы с несколькими радио-модулями.

3.2.5. Таблица источников

Таблица источников служит для записи дистанций выполнимости (feasibility distance) и индексируется триплетами (prefix, plen, router-id). Каждая запись таблицы включает:

  • префикс (prefix, plen), где plen указывает размер префикса в битах, применимый к этой записи;

  • router-id маршрутизатора, от которого исходит этот префикс;

  • пару (seqno, metric), указывающую дистанцию выполнимости для этого источника.

С каждой записью связан таймер «сборки мусора» (garbage-collection), имеющий значение порядка минут и сбрасываемый в соответствии с параграфом 3.7.3.

3.2.6. Таблица маршрутов

Таблица маршрутов содержит известные узлу маршруты и индексируется триплетом (prefix, plen, neighbour). Каждая запись таблицы включает:

  • источник (prefix, plen, router-id) для которого анонсирован этот маршрут;

  • сосед neighbour (запись в таблице соседей), анонсировавший этот маршрут;

  • метрика, с которой маршрут анонсирован соседом, или шестнадцатеричное значение FFFF (бесконечность) для недавно утраченного маршрута;

  • порядковый номер, с которым маршрут анонсирован;

  • адрес next-hop для этого маршрута;

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

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

Отметим, что с каждым маршрутом связаны две разных пары (seqno, metric), одна из которых указывает дистанцию (протяженность) маршрута в таблице, другая — дистанцию выполнимости, которая хранится в таблице источников и используется для всех маршрутов с данным источником.

3.2.7. Таблица ожидающих запросов порядковых номеров

Таблица ожидающих запросов seqno содержит список запросов порядкового номера, которые передал локальный узел (порождены локально или пересланы), но ответы еще не были получены. Таблица индексируется триплетом (prefix, plen, router-id) и каждая запись содержит:

  • prefix, plen, router-id и seqno из запроса;

  • сосед, для которого пересылался запрос (при наличии);

  • небольшое целое число, указывающее повторов, если запрос не был выполнен.

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

3.3. Подтверждения и запросы подтверждений

Узел Babel может запросить у соседа явного подтверждения приема отправленного тому пакета. Хотя использование подтверждений не обязательно, каждый узел Babel должен поддерживать возможность ответа на такие запросы.

Подтверждения должны передаваться по индивидуальному адресу, но запросы могут отправляться как на индивидуальные, так и на групповые адреса. В последнем случае отвечают все получившие запрос узлы.

Передача запросов на подтверждение определяется локальной политикой. Простейшая стратегия — никогда не запрашивать подтверждений и полагаться на периодические обновления в качестве гарантии того, что все доступные маршруты в конечном итоге распространяются по всему домену маршрутизации. Для повышения скорости схождения и снижения объема трафика управления запросы подтверждения могут служить для надежной отправки срочных обновлений (параграф 3.7.2) и отзывов (параграф 3.5.4), особенно при небольшом числе соседей на данном интерфейсе. Поскольку протокол Babel разработан для корректной работы при потере пакетов в ненадежных средах, отправка всех пакетов с запросом подтверждения не обязательна и не рекомендуется, поскольку подтверждения создают дополнительный трафик и могут вызывать дополнительный обмен ARP (Address Resolution Protocol) или ND (Neighbour Discovery).

3.4. Нахождение соседей

Нахождение соседей (neighbour acquisition) — процесс, с помощью которого узел Babel определяет набор соседей, слышимых через каждый из его интерфейсов и устанавливает двухстороннюю достижимость (доступность). В ненадежных средах обнаружение соседей дополнительно обеспечивает статистику, которая может быть полезна при расчете качества каналов.

До того как узел Babel сможет обмениваться маршрутными данными с соседом, он должен создать для этого соседа запись в своей таблице соседей. Когда это следует делать, определяет реализация и приемлемые стратегии включают создание записи при получении любого пакета Babel или при анализе Hello TLV. Для экономии системных ресурсов реализации следует отбрасывать записи, которые не используются слишком долго. Приемлемой стратегией является отбрасывание соседей по тайм-ауту или при пустой истории соответствующих сообщений Hello (см. Приложение A.2).

3.4.1. Определение обратной достижимости

Каждый узел Babel регулярно или не регулярно передает своим соседям Hello TLV для индикации свое активности. В каждом Hello TLV содержится увеличивающийся (модуль 216) порядковый номер и верхняя граница интервала отправки следующего Hello того же типа (см. ниже). Если установлен интервал 0, Hello TLV не указывает нового «обещания». При этом интервал из предыдущего Hello того же типа остается в силе для следующего Hello (если недавнее сообщение Hello нужного типа было получено в момент t0 и включало интервал i, прежнее обещание передать Hello до момента t0 + i остается в силе). Сообщения Hello считаются «плановыми», если они включают отличный от 0 интервал.

Имеется два типа Hello — Multicast Hello, использующие счетчик Hello на уровне интерфейса (Multicast Hello seqno), и Unicast Hello со счетчиком для соседа (Unicast Hello seqno). Сообщения Multicast Hello с данным seqno должны передаваться всем соседям на данном интерфейсе путем отправки по групповому адресу или по индивидуальным адресам каждого соседа (т. е. название Multicast Hello является не совсем точным). Unicast Hello с данным given обычно следует передавать лишь одному соседу (по индивидуальному адресу), поскольку порядковые номера для разных соседей в общем случае не синхронизированы.

Multicast Hello, переданные по групповому адресу могут служить для обнаружения соседей. Узлу следует передавать периодические (плановые) Multicast Hellos, если обнаружение соседей не выполняется вне протокола Babel. Узел может передавать Unicast Hello или неплановые Hello любого типа по любой причине, например для снижения группового трафика или повышения надежности на каналах со слабой поддержкой групповой адресации.

Узел может передать плановое сообщение Hello заранее, а также может изменить запланированный интервал Hello. Интервал Hello можно сократить в любой момент, а также можно увеличить непосредственно перед отправкой Hello TLV, но не следует увеличивать в другие моменты (эквивалентно, узлу следует передать плановые Hello сразу после увеличения интервала Hello).

Что делать с полученными Hello TLV и какую статистику для них поддерживать, определяет локальная реализация. Обычно узлы поддерживают тот или иной тип истории недавно принятых Hello. Пример подходящего алгоритма представлен в Приложении A.1.

После приема Hello или определения его пропуска узел пересчитывает стоимость ассоциации (параграф 3.4.3) и запускает процедуру выбора маршрута (параграф 3.6).

3.4.2. Двухстороннее определение достижимости

Для организации двухсторонней доступности каждый узел периодически передает IHU TLV (я вас слышу) каждому из своих соседей. Поскольку IHU содержат явный интервал, их можно передавать реже, чем Hello для снижения уровня маршрутного трафика в плотных сетях. В частности, их следует передавать реже Hello на каналах с незначительными потерями. Хотя IHU концептуально являются индивидуальными, их можно передавать по групповому адресу, чтобы избежать лишних обменой ARP или Neighbour Discovery и агрегировать множество IHU в один пакет.

В дополнение к периодическим IHU узел может в любой момент передать неплановый пакет IHU. Узел также может в любой момент снизить интервал IHU и может увеличить этот интервал непосредственно перед отправкой IHU, но не следует увеличивать интервал в другие моменты (эквивалентно, узлу следует передавать дополнительные IHU сразу после увеличения интервала Hello).

В каждом IHU TLV содержатся две части данных — rxcost для канала (стоимость приема) с точки зрения отправителя, используемое соседом для расчета стоимости канала (параграф 3.4.3), и интервал между периодическими пакетами IHU. Принявший IHU узел устанавливает значение txcost (стоимость передачи), поддерживаемое в таблице соседей, в соответствии со значением в IHU и сбрасывает таймер IHU, связанный с данным соседом, до значения кратного (в несколько раз) интервалу, полученному в IHU (см. Приложение B). По истечении таймера IHU для соседского txcost устанавливается бесконечное значение.

После обновления соседского txcost принимающий узел пересчитывает стоимость для соседа (параграф 3.4.3) и запускает процедуру выбора маршрута (параграф 3.6).

3.4.3. Расчет стоимости

Стоимость канала к соседу (neighbourship association) рассчитывается по значениям из таблицы соседей, где хранится статистика приема Hello и значения txcost, рассчитанные из пакетов IHU.

Для каждого соседа узел Babel рассчитывает значения, называемое rxcost. Оно обычно выводится из статистики Hello, которая может комбинироваться с другими данными, такими как статистика канального уровня. Значение rxcost передается соседу в каждом IHU.

Поскольку узлы не обязательно передают периодические Unicast Hello, но обычно передают Multicast Hello (параграф 3.4.1), узлу следует использовать алгоритм, который дает конечное значение rxcost, когда имеются лишь Multicast Hello, если не требуется взаимодействие лишь с узлами, которые передают только Multicast Hello.

Использование txcost и rxcost при расчете стоимости канала определяется локальными правилами. Для корректности работы Babel должны выполняться приведенные ниже условия:

  • значение стоимости всегда положительно;

  • если недавно не было принято Hello TLV любого типа, стоимость будет бесконечной;

  • если txcost имеет бесконечное значение, стоимость будет бесконечной.

Рекомендуемая стратегия расчета стоимости канал приведена в Приложении A.2.

3.5. Поддержка таблицы маршрутизации

Концептуально обновления Babel задает квинтет (prefix, plen, router-id, seqno, metric), где (prefix, plen) — префикс для маршрута, router-id — идентификатор маршрутизатора, создавшего обновление, seqno — не уменьшающееся целое число (модуль 216) — порядковый номер маршрутизатора-источника, metric — анонсируемая метрика.

Перед восприятием обновления оно проверяется на предмет выполнимости (параграф 3.5.1), что обеспечивает предотвращение маршрутных петель. Если условие осуществимости не выполняется, обновление игнорируется или маршрут не выбирается, как описано в параграфе 3.5.3. Если условие выполнимости обеспечено, обновление не может создать маршрутную петлю.

3.5.1. Условие осуществимости

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

Дистанция выполнимости задается парой (seqno, metric), где seqno — целое число с модулем 216, а метрика — положительное целое число. Дистанции сравниваются лексикографически с инвертированием номера — дистанция (seqno, metric) считается строго лучше (seqno’, metric’), что записывается в форме

      (seqno, metric) < (seqno', metric')

когда

      seqno > seqno' или (seqno = seqno' и metric < metric')

где порядковые номера сравниваются по модулю 216.

С данным источником (prefix, plen, router-id) дистанция выполнимости узла для этого источника будет минимальной (в соответствии с определенным выше порядком) среди дистанций из всех конечных обновлений, когда-либо переданных этим узлом для префикса (prefix, plen) и данного router-id. Дистанции выполнимости хранятся в таблице источников, как описано в параграфе 3.7.3.

Принятое обновление выполнимо, если оно является отзывом (метрика имеет шестнадцатеричное значение FFFF) или анонсируемая дистанция строго лучше (в соответствии с приведенным выше определением) дистанции выполнимости для соответствующего источника. Точнее говоря, анонс маршрута в (prefix, plen, router-id, seqno, metric) выполним, при выполнении одного из приведенных ниже условий:

  • метрика конечна;

  • нет записи с таблице источников с индексом (prefix, plen, router-id);

  • в таблице источников имеется запись (prefix, plen, router-id, seqno’, metric’) и выполняется одно из условий:

    • seqno’ < seqno;

    • seqno = seqno’ и metric < metric’.

Отметим, что условие выполнимости учитывает анонсированную соседом метрику, а не метрику маршрута, поэтому флуктуации стоимости для соседа не могут сделать выбранный маршрут невыполнимым. Также следует отметить, что отзывы (обновления с бесконечной метрикой) выполнимы всегда, поскольку не могут вызвать петлю.

3.5.2. Расчет метрики

Метрика маршрута рассчитывается из метрики, анонсированной соседом, и стоимости канала к соседу. Подобно расчету стоимости, вычисление метрики определяется локальной политикой. Используемая Babel функция расчета метрики M(c, m) по локально рассчитанной стоимости канала c и анонсированной соседом метрике m должна лишь соответствовать двум условиям:

  • если стоимость c бесконечная, M(c, m) также бесконечна;

  • функция M является строго монотонной, M(c, m) > m.

Кроме того, для метрики следует выполнять условие

   если m <= m', то M(c, m) <= M(c, m')

Хотя строгая монотонность функции важна для целостности сети (иначе могут возникать сохраняющиеся петли), второе условие (дистрибутивность слева) не так важно и при его нарушении Babel все равно обеспечивает схождение беспетлевой конфигурации, но может не обеспечиваться глобальной оптимизации (фактически такой оптимизации может просто не существовать).

Приведенные выше условия легко выполняются при использовании аддитивной метрики, т. е. при определении M(c, m) = c + m. Поскольку аддитивная метрика полезна для многий вариантов расчета стоимости, рекомендуется применять ее по умолчанию. В Приложении C описаны методы, позволяющие менять значения той или иной метрики без риска возникновения маршрутных петель.

3.5.3. Получение маршрутов

Когда узел Babel получает обновление (prefix, plen, router-id, seqno, metric) от соседа neigh, он проверяет наличие в таблице маршрутов записи с индексом (prefix, plen, neigh). Если такой записи нет, выполняются следующие операции:

  • если обновление невыполнимо, его можно игнорировать;

  • если метрика бесконечна (обновление служит отзывом неизвестного маршрута), обновление игнорируется;

  • в остальных случаях в таблицу маршрутов включается новая запись с индексом (prefix, plen, neigh), источником (prefix, plen, router-id), порядковым номером seqno и анонсируемой метрикой из обновления.

Если запись имеется в таблице, выполняются следующие операции:

  • если запись выбрана, обновление невыполнимо и router-id в обновлении совпадает с идентификатором маршрутизатора в записи, эту запись можно игнорировать;

  • в остальных случаях порядковый номер записи, анонсируемая метрика, метрика и router-id одновляются, даже когда для таймера срока действия маршрута установлено значение кратное (в несколько раз) интервалу, включенному в обновление (см. Приложение B). Если обновление невыполнимо, запись (невыполнимая) должна незамедлительно стать не выбранной. Если обновление вызвало смену router-id в записи, должно быть передано своевременное уведомление (возможно отзыв), как указано в параграфе 3.7.2.

Отметим, что в таблице могут присутствовать невыполнимые маршруты, ставшие таковыми в результате получения невыполнимого обновления или флуктуаций метрики. Такие маршруты никогда не выбираются, поскольку для них нет информации об отсутствии петель. Однако, если выс выполнимые маршруты перестанут быть таковыми, невыполнимые маршруты можно сделать выполнимыми и возможными для выбора путем отправки запросов по ним (параграф 3.8.2).

При срабатывании таймера срока действия маршрута поведение за висит от конечности метрики маршрута. Если метрика конечна, для нее устанавливается бесконечное значение и таймер сбрасывается. Если же метрика уже является бесконечной, маршрут удаляется из таблицы.

После обновления таблицы маршрутов запускается процедура выбора (параграф 3.6).

3.5.4. Время удержания

Когда префикс P отзывается (поскольку все маршруты стали невыполнимыми или имеют бесконечную метрику в результате завершения срока действия или по иной причине) и доступен более короткий префикс P’, охватывающий P, в общем случае P’ не может применяться для маршрутизации пакетов в P без риска появления петли (параграф 2.8).

Для предотвращения этой проблемы при отзыве префикса P поддерживается запись таблицы маршрутов с бесконечной метрикой, как описано в параграфе 3.5.3. Пока запись поддерживается, пакеты с адресом из P недопустимо пересылать по маршруту с более коротким префиксом. Запись удаляется из таблицы, как только будут получено обновление для P с конечной метрикой и выбран соответствующий маршрут. Если такого обновления не ожидается, бесконечную метрику следует поддерживать по меньшей мере до того момента, пока не будет гарантии, что ни один сосед не выбрал текущий узел в качестве следующего интервала (next-hop) для префикса P. Это можно сделать любым из двух способов:

  • дождаться завершения срока действия маршрута по таймеру (параграф 3.5.3);

  • передать отзыв с запросом подтверждения (параграф 3.3) каждому доступному соседу, который явно не отозвал префикс P, и дождаться всех подтверждений.

Первый вариант проще и гарантирует, что в этот момент для всех маршрутов к префиксу P, указывающих на текущий узел, срок действия закончился. Однако, поскольку срок действия может быть достаточно большим (несколько минут), такое решение препятствует автоматическому агрегированию, создавая ложные «черные дыры» для агрегированных маршрутов. Рекомендуется применять второй вариант, поскольку он значительно сокращает время недоступности префикса при наличии агрегированных маршрутов.

3.6. Выбор маршрута

В процессе выбора один из маршрутов для данного префикса назначается для использования при пересылке пакетов и реанонсирования соседям узла.

Протокол Babel поддерживает гибкие правила выбора маршрутов, при этом должны обеспечиваться два свойства:

  • маршруты с бесконечной метрикой (отозванные маршруты) никогда не выбираются;

  • невыполнимые маршруты никогда на выбираются.

Узлы Babel с разными правилами выбора могут взаимодействовать и не будут создавать петель при выполнении этих условий.

При выборе маршрутов недопустим учет порядковых номеров и недопустимо отдавать предпочтение маршруту с большим (более новым) seqno. Отказ от этого будет приводить к осцилляциям маршрутов при распространении нового номера по сети и может вызывать сохраняющиеся «черные дыры», если используемая метрика не дистрибутивна слева (параграф 3.5.2).

Очевидной стратегией служит выбор (для каждого получателя) выполнимого маршрута с минимальной метрикой. При стабильной метрике такой подход гарантирует сходимость дерева кратчайших путей (в предположении дистрибутивности метрики слева, см. параграф 3.5.2). Однако имеются две причины, по которым эта стратегия может вести к нестабильности при постоянно меняющейся метрике. Во-первых, если два параллельных маршрута осциллируют вокруг одного значения метрики, стратегия выбора меньшей метрики ведет к постоянным переключениям с одного маршрута на другой. Во-вторых, выбор маршрута увеличвает нагрузку для него, что может вызвать потери пакетов, а они, в свою очередь, увеличат метрику и возникшая петля обратной связи может вызвать стойкие переключения маршрутов.

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

После выбора маршрута передаются триггерные уведомления (параграф 3.7.2) и запросы (параграф 3.8.2).

3.7. Передача обновлений

Узел Babel анонсирует соседям свой набор выбранных маршрутов. Обычно это выполняется путем отправки одного или множества групповых пакетов с Update TLV через все подключенные интерфейсы. Однако для канальных технологий, где групповая передача менее эффективна по сравнению с индивидуальной, можно передавать множество копий индивидуальных пакетов, особенно при небольшом числе соседей.

Кроме того, для надежного и своевременного устранения «черных дыр» узел Babel может передавать отзывы (обновления с бесконечной метрикой) для недавно отозванных префиксов. Если обновление предназначено для маршрута, внесенного в домен Babel локальным узлом (например, оно содержит адрес локального интерфейса, префикс подключенной напрямую сети или префикс из другого протокола маршрутизации), в качестве router-id указывается идентификатор локального маршрутизатора, для метрики указывается произвольное конечное значение (обычно 0) и включается порядковый номер локального маршрутизатора.

Если обновление предназначено для маршрута от другого узла Babel, router-id и порядковый номер берутся из записи таблицы маршрутов, а метрика рассчитывается в соответствии с параграфом 3.5.2.

3.7.1. Периодические обновления

Каждый узел Babel должен анонсировать каждый из выбранных маршрутов на каждом интерфейсе хотя бы один раз в каждый интервал Update. Поскольку в Babel не возникает проблем от маршрутных петель (не требуется «счет до бесконечности») и протокол основан на триггерных обновлениях (параграф 3.7.2), полная передача маршрутов происходит достаточно редко (интервалы предложены в Приложении B).

3.7.2. Триггерные обновления

В дополнение к периодическим обновлениям узлы Babel передают неплановые (триггерные) обновления для информирования своих соседей о существенных изменениях в топологии сети.

Изменение router-id в выбранном маршруте для данного префикса может служить индикацией образующейся петли, поэтому при каждой смене router-id для данного адресата узел должен передать обновление как срочный блок TLV (см. параграф 3.1). Кроме того, следует предпринять разумные попытки обеспечить получение этого обновления всеми соседями.

Для этого есть две стратегии. Если число соседей невелико, разумно передать обновление с запросом подтверждения, которое будет повторяться несколько раз, пока все соседи не подтвердят прием пакета. При большом числе соседей такой запрос подтверждений может вызвать ощутимый трафик и более предпочтительным вариантом может оказаться простое повторение обновления несколько раз (скажем, 3 для беспроводных сетей или 2 для кабельных). Недопустимо передавать больше 5 копий и их следует разделять небольшим интервалом (параграф 3.1).

Отзыв маршрута вызывает меньше беспокойства — если он придет не всем соседям, может возникнуть «черная дыра», которая, в отличие от петли, не представляет опасности для целостности сети. При отзыве маршрута узлу следует передать триггерное обновление, а также следует предпринять разумные попытки доставить его всем соседям.

Узел может передавать триггерное уведомление при существенном изменении метрики для данного префикса в результате получения обновления, изменения стоимости канала или выбора другого следующего узла (next-hop). Узлу не следует передавать триггерные обновления по иным причинам, таким как незначительные флуктуации метрики маршрутов, смене next-hop без существенного изменения метрики маршрута или распространении нового порядкового номера (за исключением выполнения запроса, как указано в параграфе 3.8).

3.7.3. Поддержка дистанций достижимости

Перед отправкой обновления (prefix, plen, router-id, seqno, metric) с конечной метрикой (т. е. не отзыва) узел Babel обновляет дистанцию выполнимости в таблице источников, как описано ниже.

Если в таблице источников нет записи с индексом (prefix, plen, router-id), создается запись со значениями(prefix, plen, router-id, seqno, metric). Если имеется запись (prefix, plen, router-id, seqno’, metric’) она обновляется:

  • если seqno > seqno’, устанавливается seqno’ := seqno, metric’ := metric;

  • если seqno = seqno’ и metric’ > metric, устанавливается metric’ := metric;

  • в остальных случаях ничего не меняется.

Для записи сбрасывается таймер сборки мусора. Отметим, что дистанция выполнимости не обновляется и таймер сборки мусора не сбрасывается при отправке отзыва маршрута (обновления с бесконечной метрикой).

По завершении отсчета таймера сборки мусора запись удаляется из таблицы источников.

3.7.4. Расщепление горизонта

При работе в транзитивной топологии с симметричными каналами (например, соединения «точка-точка» или проводная ЛВС, такая как Ethernet) узлу Babel следует использовать оптимизацию, называемую «расщеплением горизонта» (split horizon). При использовании ее на данном интерфейсе маршрутные обновления для префикса P не передаются на интерфейс, через который был получен выбранных маршрут в направлении префикса P.

Расщепление горизонта не следует применять на интерфейсе, пока нет уверенности в симметрии и транзитивности. В частности, этот метод не применим к децентрализованным беспроводным канальным технологиям (например, IEEE 802.11 в режиме ad hoc), когда маршрутные обновления передаются по групповым адресам.

3.8. Явные запросы

При обычной работе таблица маршрутов узла заполняется из плановых и триггерных обновлений от соседей. Однако в некоторых обстоятельствах узел может передавать явные запросы для ресинхронизации с источником после перемещения (mobility event) или для предотвращения ненужного завершения срока действия маршрута.

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

3.8.1. Обработка запросов

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

3.8.1.1. Запросы маршрутов

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

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

3.8.1.2. Запросы порядковых номеров

При получении запроса seqno для данного router-id и порядкового номера узел ищет в своей таблице маршрутов выбранную запись для данного префикса. Если такая запись присутствует и имеет конечную метрику, а значения router-id различаются или эти значения совпадают, но порядковый номер записи не меньше (по модулю 216) запрошенного порядкового номера, узел должен передать обновление для данного префикса. Если router-id совпадают, но запрошенный порядковый номер больше (по модулю 216) чем в записи для маршрута, узел сравнивает router-id со своим идентификатором. При совпадении узел увеличивает свой порядковый номер на 1 (по модулю 216) и передает обновления. Узлу недопустимо увеличивать своей номер больше чем на 1 в ответ на один запрос seqno.

Если router-id в запросе не совпадает с идентификатором узла, принявший запрос узел проверяет поле Hop Count в запросе. Если поле имеет значение не меньше 2 и узел анонсирует префикс своим соседям, он выбирает соседа для пересылки тому запроса, как указано ниже.

  • Если узел имеет один или несколько выполнимых маршрутов в направлении запрошенного префикса, где next-hop не является запросившим узлом, он должен переслать запрос слудующему маршрутизатору (next-hop).

  • В остальных случаях, если узел имеет один или несколько (невыполнимых) маршрутов к запрошенному префиксу, где next-hop не является запросившим узлом, ему следует переслать этот запрос следующему маршрутизатору на одном из таких маршрутов.

Для фактической пересылки запроса узел декрементирует счетчик интервалов (hop count) и передает запрос по индивидуальному адресу выбранного соседа. Запрос следует пересылать как срочный TLV (параграф 3.1).

Узлу следует поддерживать список недавно пересланных запросов seqno и пересылать отклики на них (обновление с достаточно большим для удовлетворения запроса seqno) как срочные TLV (параграф 3.1). Узлу следует сравнивать каждый входящий запрос seqno со списком недавно пересылавшихся запросов seqno во избежание избыточной пересылки (т. е. он недавно пересылал запрос с тем же префиксом, prefix, router-id и не меньшим seqno по модулю 216).

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

3.8.2. Передача запросов

Узел Babel может отправлять запросы маршрутов и порядковых номеров по групповым и индивидуальным адресам. Отправка запросов требуется лишь в одном случае (параграф 3.8.2.1).

3.8.2.1. Предотвращение истощения

Когда маршрут отозван или закончился срок его действия, узел Babel обычно переключается на другой выполнимый маршрут для того же префикса. Однако в некоторых случаях таких маршрутов может не оказаться. Узел, потерявший все выполнимые маршруты к данному адресату, но имеющий невыполнимые маршруты к нему с не истекшим сроком действия, должен отправить запрос seqno. Если нет даже таких маршрутов, узел все равно может передать запрос seqno. В поле router-id такого запроса указывается router-id из потерянного маршрута, а запрашиваемым номером является значение из таблицы источников, увеличенное на 1. Запрос включает счетчик интервалов, который служит «механизмом последней надежды» (last-resort) для гарантии сохранения узла в сети и может включать любое значение, превышающее диаметр сети (значение 64 приемлемо по умолчанию).

Если узел имет какие-либо (невыполнимые) маршруты к нужному адресату, он должен передать запрос хотя бы одному из соседей next-hop, анонсировавших эти маршруты, и следует передать его всем. В любом случае узел может передать запрос любому другому соседу независимо от анонсирования им нужного маршрута. Простой стратегией реализации будет безусловная отправка группового запроса через все интерфейсы.

Похожие запросы могут быть переданы другими узлами, на которые повлияла потеря маршрута. Если сеть остается соединенной и предполагается отсутствие потерь, хотя бы один из таких запросов будет переслан источнику и маршрут будет анонсирован с новым порядковым номером (в результате подавления дубликатов лишь малое число таких запросов достигнет источника). Для компенсации потери пакетов узлу следует повторить запрос несколько раз, если не появилось выполнимого маршрута в течение короткого времени (см. Приложение B) Однако при значительной потере пакетов могут пропасть все такие запросы. В этом случае получение нового порядкового номера обеспечит описанный в следующем параграфе механизм.

3.8.2.2. Работа с невыполнимыми обновлениями

Когда метрика маршрута увеличивается, узел может получить невыполнимое обновление для маршрута, который выбран. Как указано в параграфе 3.5.1, узел может игнорировать обновление или отменить выбор маршрута.

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

Поскольку расчет метрики не обязательно совпадает (по времени) с задержкой распространения обновлений, узел может получить невыполнимое обновление от не выбранного в данный момент соседа, который предпочтительней выбранного маршрута (т. е. имеет меньшую метрику). В таком случае узлу следует передать индивидуальный запрос seqno соседу, анонсировавшему предпочтительное обновление.

3.8.2.3. Предотвращение завершения срока действия маршрутов

При нормальной работе таймер срока действия маршрута не срабатывает никогда, поскольку время удержания маршрута рассчитывается на основе явного интервала из Update TLV и обновления (возможно отзывы) должны поступать своевременно, чтобы избежать завершения срока действия маршрута.

Однако при наличии потерь пакетов может случиться так, что обновление не будет получено в течение срока ожидания и срок действия маршрута закончится. Для предотвращения таких ситуаций узлу Babel, незадолго до завершения срока действия маршрута, следует передать индивидуальный запрос маршрута анонсировавшему его соседу. Поскольку узлы всегда передают обновление или отзыв в ответ на запрос точного (не шаблонного) маршрута (параграф 3.8.1.1), это обычно ведет к обновлению или отзыву маршрута.

4. Кодирование протокола

Пакет Babel должен передаваться как тело дейтаграммы UDP со значением счетчика интервалов сетевого уровня (hop count) 1 по общеизвестному групповому адресу протокола IPv4 или IPv6 (для IPv6 это адреса link-local). Для потов UDP отправителя и получателя должен указываться общеизвестный номер. Пакеты Babel должны игнорироваться, если адресом отправителя не является адрес IPv6 link-local или адрес IPv4, относящийся к локальной сети, а в качестве порта не указан общеизвестный порт Babel. Пакеты могут игнорироваться, если для получателя указан глобальный (маршрутизируемый) адрес IPv6.

Для минимизации числа передаваемых пакетов и предотвращения фрагментации на нижележащих уровнях узлу Babel следует использовать пакеты максимального размера, вплоть для MTU выходного интерфейса с учетом заголовков нижележащего уровня (28 октетов для UDP по протоколу IPv4 и 48 октетов для UDP по протоколу IPv6). Недопустимо передавать пакеты, размер которых превышает большее из значений MTU выходного интерфейса (с учетом нижележащих заголовков) или 512 октетов. В любом случае размер пакета не может быть больше 216 — 1 с учетом заголовков нижележащего уровня. Каждый узел Babel должен поддерживать прием пакетов размером до большего из значений MTU приемного интерфейса с учетом заголовков нижележащего уровня или 512 октетов. Недопустимо передавать пакеты Babel в джамбограммах IPv6 [RFC2675].

4.1. Типы данных

4.1.1. Представление целых чисел

Многооктетные поля, представляющие целые числа начинаются со старшего октета (формат Big-Endian [IEN137], называемый также сетевым порядком байтов). Базовый протокол использует лишь значения без знака. Если расширению потребуются числа со знаком, оно должно будет задать кодирование (например, дополнение до 2).

4.1.2. Интервалы

Относительные значения времени указываются 16-битовыми числами в сотых долях секунды (centisecond). Это позволяет задать интервалы приблизительно до 11 минут с шагом 10 мсек., что должно быть достаточно для всех применений Babel (см. Прилжение B).

4.1.3. Идентификаторы маршрутизаторов

Идентификатор router-id представляет собой произвольной значение размером 8 октетов. Недопустимо использовать для router-id значения, содержащие только нули (шестнадцатеричное 0000000000000000) или только единицы (шестнадцатеричное FFFFFFFFFFFFFFFF).

4.1.4. Адреса

Поскольку основная работа протокола выполняется с адресами, поддерживается несколько типов их кодирования. Кроме того, в Update TLV может опускаться маска подсети при передаче множества адресов в одном пакете, это называется сжатием адресов (параграф 4.6.9). Варианты кодирования адресов приведены ниже.

AE 0

Шаблонный адрес (строка октетов размером 0).

AE 1

Адрес IPv4 (до 4 октетов).

AE 2

Адрес IPv6 с поддержкой сжатия (до 16 октетов).

AE 3

Адрес IPv6 link-local без сжатия (8 октетов, предполагается префикс fe80::/64).

Семейством адресов, связанным с форматом представления является IPv4 или IPv6. Семейство не определено для AE 0, IPv4 для AE 1 и IPv6 для AE 2 и AE 3.

4.1.5. Префиксы

Сетевые префиксы кодируются как адреса, но хранятся с минимальным числом октетов, достаточным для записи значимых битов (до размера префикса).

4.2. Формат пакетов

Пакет Babel состоит из 4-октетного заголовка, за которым следует набор TLV (тело пакета) и может следовать еще один набор TLV (трейлер).Формат является расширяемым (см. Приложение D).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Magic     |    Version    |        Body length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Packet Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|         Packet Trailer...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Magic

Тщательно подобранное произвольное значение 42 (десятичное). Пакеты, в которых первый октет имеет другое значение должны игнорироваться.

Version

Этот документ задает версию 2 протокола Babel. Пакеты, в которых второй октет имеет другое значение должны игнорироваться.

Body length

Размер следующего за заголовком тела пакета (без учета полей Magic, Version, Body length, а также трейлера) в октетах.

Packet Body

Тело пакета, представляющее собой последовательность TLV.

Packet Trailer

Трейлер пакета, содержащий последовательность TLV.

Телом и трейлером пакета служат цепочки TLV. Обычно TLV помещаются в тело пакета, а трейлеры применяются лишь для особых TLV, которые не требуют криптографической защиты. При анализе трейлера получатель должен игнорировать все TLV, в определениях которых явно не указана возможность размещения в трейлере. Из числа определенных в документе TLV таковыми являются лишь Pad1 и PadN. Поскольку эти TLV в любом случае игнорируются, реализация может полностью игнорировать трейлер, даже не анализируя его, пока не используется расширений, определяющих другие TLV для включения в трейлер.

4.3. Формат TLV

Все TLV, за исключением Pad1, имеют показанную на рисунке структуру.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Тип TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Payload

Данные TLV (payload), которые представляют собой тело, а в некоторых случаях — набор суб-TLV.

TLV неизвестного типа должны игнорироваться.

4.4. Формат суб-TLV

В заголовке каждого TLV явно указывается размер, однако большинство TLV являются самозавершающими в том смысле, что можно определить размер без явного обращения к полю Length. Если TLV имеет самозавершающий формат, пространство между естественным размером TLV и значением в поле Length может применяться для включения sub-TLV.

Структура суб-TLV не отличается от структры TLV и, кроме Pad1, все суб-TLV имеют показанный ниже формат.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Тип суб-TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Body

Тело суб-TLV, интерпретация которого зависит от типа суб-TLV и типа содержащего его TLV.

Старший бит типа суб-TLV (шестнадцатеричное значение 80) называется битом обязательности (mandatory). Иными словами, типы суб-TLV от 128 до 255 включают этот бит, который определяет обработку неизвестных суб-TLV. При сброшенном бите неизвестный суб-TLV целиком должен игнорироваться, а остальная часть TLV обрабатывается нормально. Если бит установлен, должен целиком игнорироваться блок TLV (за исключением обновления состояния анализатора с помощью Router-Id, Next Hop, Update TLV, как указано в следующем параграфе).

4.5. Состояние анализатора и кодирование обновлений

В больших сетях основную часть трафика Babel составляют обновления, поэтому были применены способы их эффективного кодирования. Включаемые в обновление данные концептуально разделены на 3 части (параграф 3.5):

  • префикс, порядковый номер и метрика содержатся в самих Update TLV (параграф 4.6.9);

  • router-id берется из Router-Id TLV, предшествующего Update TLV и может использоваться несколькими Update TLV (параграф 4.6.7);

  • следующий интервал (next-hop) берется из адреса отправителя пакета сетевого уровня, содержащего пакет Babel, или из явного Next Hop TLV (параграф 4.6.8).

В дополнение к этому в Update TLV можно опускать префикс анонсируемого префикса, который извлекается из предшествующего Update TLV с тем же семейством адресов (IPv4 или IPv6). Кроме того, в особом случае совпадения router-id с идентификатором интерфейса в адресе IPv6 можно опустить Router-Id TLV и вывести значение router-id из младших битов анонсируемого префикса (параграф 4.6.9).

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

  • Принятый по умолчанию префикс для каждой кодировки адреса с возможностью сжатия. Префикс не определен в начале пакета и обновляется каждым Update TLV с флагом Prefix (параграф 4.6.9).

  • Текущий следующий интервал пересылки (next-hop) для каждого семейства адресов (IPv4 или IPv6). Это адрес отправителя в содержащем обновление пакете для совпадающего семейства адресов в начале пакета, обновляемый каждым Next Hop TLV (параграф 4.6.8);

  • Текущее значение router-id. Значение не определено в начале пакета и обновляется каждым Router-Id TLV (параграф 4.6.7) и Update TLV с флагом Router-Id.

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

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

4.6. Специальные TLV

4.6.1. Заполнение Pad1

 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+


Type

Значение 0 указывает Pad1 TLV.

Такие TLV игнорируются при получении и могут включаться в трейлер пакета.

4.6.2. Заполнение PadN

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Значение 1 указывает PadN TLV.

Length

Размер тела в октетах без учета полей Type и Length.

MBZ

Должно иметь значение 0, устанавливаемое при передаче.

Такие TLV игнорируются при получении и могут включаться в трейлер пакета.

4.6.3. Запрос подтверждения

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 2   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Opaque            |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TLV запрашивает у получателя отправку Acknowledgment TLV в течение заданного полем Interval времени.

Type

Значение 2 указывает Acknowledgment Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Opaque

Произвольное значение, возвращаемое в Acknowledgment TLV.

Interval

Интервал времени в сотых долях секунды (centisecond), по истечении которого отправитель сочтет пакет потерянным. Установка значения 0 недопустима. Получатель должен передать Acknowledgment TLV до истечения заданного интервала (с запасом на время доставки).

TLV относится к самозавершающим и может включать суб-TLV.

4.6.4. Подтверждение

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 3   |    Length     |           Opaque              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TLV передается узлом в ответ на получение Acknowledgment Request TLV.

Type

Значение 3 указывает Acknowledgment TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Opaque

Значение поля Opaque из Acknowledgment Request, вызвавшего это подтверждение.

Поскольку значения Opaque не уникальны в глобальном масштабе, этот блок TLV должен передаваться по индивидуальному адресу.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.5. Hello

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 4   |    Length     |            Flags              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Seqno              |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TLV для обнаружения соседей и определения стоимости приема от соседа.

Type

Значение 4 указывает Hello TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Flags

Биты флагов, задающие обработку данного TLV (см. ниже).

Seqno

При установленном флаге Unicast это будет значение порядкового номера Unicast Hello передающего узла для этого соседа. Иначе это будет исходящим порядковым номером Multicast Hello для данного интерфейса.

Interval

Ненулевое значение задает верхнюю границу (в сотых долях секунды) времени, по истечение которого передающих узел будет повторять плановое сообщение Hello TLV с таким же флагом Unicast. Нулевое значение указывает неплановое сообщение Hello, которое не включает данных о времени передачи других Hello.

Формат поля Flags показан на рисунке.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


U (Unicast)

Флаг (шестнадцатеричное значение 8000), установка которого указывает Unicast Hello, сброс — Multicast Hello.

X

Все остальные биты должны иметь значение 0 при отправке и игнорируются при получении.

При каждой отправке сообщения Hello должно инкрементиваться значение соответствующего счетчика seqno. Поскольку все Multicast Hello используют общий счетчик seqno для интерфейса на узле, если флаг Unicast сброшен, TLV должен передаваться всем соседям на этом канале, что можно обеспечить отправкой по групповому адресу или передачей групповых пакетов по индивидуальным адресам всех доступных соседей. И наоборот, при установленном флаге Unicast этот блок TLV должен передаваться одному соседу по индивидуальному адресу. Во избежание существенного снижения снижения качества канала не следует передавать несколько Hello TLV в одном пакете.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.6. IHU

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 5   |    Length     |       AE      |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Rxcost             |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Address...
+-+-+-+-+-+-+-+-+-+-+-+-


IHU TLV (я слышу вас) служит для подтверждения двухсторонней доступности и передачи стоимости отправки в канал.

Type

Значение 5 указывает IHU TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Address (в большинстве случаев 1 или 3). В качестве оптимизации можно применять 0, если TLV передается по индивидуальному адресу, ассоциация организована по каналу «точка-точка» или двухсторонняя доступность устанавливается средствами другого протокола (вне Babel).

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Rxcost

Значение rxcost, соответствующее передающему узлу интерфейса, адрес которого указан в поле Address. Шестнадцатеричное значени FFFF (бесконечность) указывает недоступность интерфейса.

Interval

Верхняя граница времени по истечении которого предающий узел будет повторять IHU (в сотых долях секнды). Значение 0 недопустимо. Принимающий узел использует это значение для расчета времени удержания данной симметричной ассоциации (связи).

Address

Адрес получателя в формате, заданном полем AE. Сжатие адреса не допускается.

Концептуально IHU адресуется одному соседу. Однако IHU TLV включают явный адрес получателя и могут передаваться по групповому адресу, что позволяет объединить IHU для нескольких соседей в один пакет, избавляя от необходимости использовать обмен ARP или Neighbour Discovery, когда сосед не участвует в трафике данных.

IHU TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.7. Router-Id

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 6   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                           Router-Id                           +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Router-Id TLV устанавливает значение router-id, которое предполагается следующими Update TLV, как указано в параграфе 4.5. TLV задает router-id даже при наличии в нем неизвестного обязательного суб-TLV.

Type

Значение 6 указывает Router-Id TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Router-Id

Значение router-id для маршрутов, анонсируемых в последующих Update TLV. Недопустимы значения, содержащие только 0 или только 1.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.8. Следующий интервал

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 7   |    Length     |      AE       |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Next hop...
+-+-+-+-+-+-+-+-+-+-+-+-


Next Hop TLV задает адрес следующего интервала (next-hop) для данного семейтсва адресов (IPv4 или IPv6), которые предполагается следующими Update TLV, как указано в параграфе 4.5. TLV задает следующий интервал для последующих Update TLV даже при наличии в нем неизвестного обязательного суб-TLV.

Type

Значение 7 указывает Next Hop TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Address. Следует задавать 1 (IPv4) или 3 (IPv6 link-local), недопустимо указывать 0.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Next hop

Адрес next-hop, анонсируемый последующими Update TLV для этого семейства адресов.

Когда семейство адресов соответствует протоколу сетевого уровня, который передает пакет, Next Hop TLV не требуется и адрес следующего интервала при отсутствии Next Hop TLV берется из адреса отправителя пакета.

Next Hop TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.9. Обновление

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 8   |    Length     |       AE      |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Plen      |    Omitted    |            Interval           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |            Metric             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


Update TLV анонсирует или отзывает маршрут. В качестве оптимизации может дополнительно устанавливать новое подразумеваемое значение router-id и принятого по умолчанию префикса, как указано в параграфе 4.5.

Type

Значение 8 указывает Update TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Prefix.

Flags

Биты флагов, задающие обработку данного TLV (см. ниже).

Plen

Размер анонсируемого префикса в битах. В случае AE 3 (IPv6 link-local) поле Omitted должно иметь значение 0.

Omitted

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

Interval

Верхняя граница интервала, по истечение которого передающий узел будет отправлять новое обновление для данного префикса (в сотых долях секунды). Значение 0 недопустимо. Принимающий узел использует это значение для расчета времени удержания записи в таблице маршрутов. Шестнадцатеричное значение FFFF (бесконечность) говорит, что это обновление не будет повторяться без запроса (параграф 3.8.2.3).

Seqno

Порядковый номер инициатора для данного обновления.

Metric

Метрика маршрута. Шестнадцатеричное значение FFFF (бесконечность) указывает отзыв маршрута.

Prefix

Анонсируемый префикс размером (Plen/8 — Omitted) с округлением в большую сторону.

Формат поля Flags показан на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P|R|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+


P (Prefix)

Флаг (шестнадцатеричное значение 8000), установка которого указывает, что данный Update TLV задает новый префикс для последующих Update TLV в пакете с тем же кодированием адресов. Значение устанавливается даже при наличии в данном TLV неизвестного обязательного суб-TLV.

R (Router-Id)

Флаг (шестнадцатеричное значение 4000), установка которого указывает, что данный TLV задает новое значение принятого по умолчанию router-id для этого TLV и Update TLV в пакете с тем же кодированием адресов. Значение устанавливается даже при наличии в данном TLV неизвестного обязательного суб-TLV и рассчитывается из первого адреса анонсируемого префикса, как показано ниже.

  • Если размер адреса не меньше 8 октетов из последних 8 октетов адреса извлекается значение router-id.
  • Если размер адреса меньше 8 октетов, новое значение router-id состоит из нужного числа нулевых октетов и поля адреса, записываемого в правую часть router-id. Например, для IPv4 значение router-id будет включать 4 октета нулей, за которыми следует адрес IPv4.

X

Все остальные биты должны иметь значение 0 при отправке и игнорируются при получении.

Расчет префикса, анонсируемого данным Update TLV, выполняется в соответствии с приведенным ниже описанием.

  • Первые Omitted октетов префикса берутся из предыдущего Update TLV с флагом Prefix и тем же кодированием адресов даже при наличии так неизвестного обязательного суб-TLV. Если поле Omitted отлично от 0, но такого TLV нет, данное обновление должно игнорироваться.

  • Следующие (Plen/8 — Omitted) октетов (с округлением вверх) берутся из поля Prefix.

  • Если Plen не кратно 8, все биты вне Plen (младшие (8 — Plen MOD 8) битов последнего октета) сбрасываются.

  • В оставшихся октетах устанавливается 0.

Если поле Metric имеет конечное значение, router-id узла-инициатора для данного анонса берется из префикса, анонсируемого этим обновлением, при наличии флага Router-Id, рассчитанного, как указано выше. В остальных случаях значение берется из предшествующего Router-Id TLV или Update TLV с флагом Router-Id, в зависимости от того, что указано последним, даже при наличии в TLV неизвестного обязательного суб-TLV. При отсутствии подходящего TLV обновление игнорируется.

Адрес следующего интервала (next-hop) для обновления берется из последнего предшествующего Next Hop TLV с тем же семейством адресов (IPv4 или IPv6) в том же пакете даже при наличии неизвестного обязательного суб-TLV. Если такого TLV нет, значение берется из адреса отправителя в пакете сетевого уровня, содержащем данное обновление, если он относится к тому же семейству адресов. В остальных случаях это обновление должно игнорироваться.

Шестнадцатеричное значение FFFF в поле метри указывает отзыв маршрута. В этом случае router-id, next-hop и seqno не используются. AE может иметь значение 0 и в этом случае Update TLV отзывает все маршруты, анонсированные ранее передавшим интерфейсом. Если метрика конечна, установка AE 0 недопустима. Update TLV с конечной метрикой и AE 0 должны игнорироваться. Если метрика бесконечная и AE имеет значение 0, в полях Plen и Omitted должно быть значение 0. Update TLV, не соответствующие этому требованию, должны игнорироваться.

Update TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.10. Запрос маршрута

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 9   |    Length     |      AE       |     Plen      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


Route Request TLV приглашает получателя передать обновление для заданного префикса или всю таблицу маршрутов.

Type

Значение 9 указывает Route Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Prefix. Значение 0 указывает запрос полного дампа таблицы маршрутов (шаблонный запрос).

Plen

Размер запрашиваемого префикса в битах.

Prefix

Запрашиваемый префикс, размер которого составляет Plen/8 с округлением в большую сторону.

Route Request TLV приглашает получателя передать обновление (возможно отзыв) для префикса, указанного полями AE, Plen и Prefix или полный дамп его таблицы маршрутов, если AE имеет значение 0 (в этом случае поле Plen должно иметь значение 0 и размер Prefix также должен быть 0). Request TLV с AE 0 и ненулевым Plen должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.11. Запрос порядкового номера

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 10  |    Length     |      AE       |    Plen       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |  Hop Count    |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          Router-Id                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prefix...
+-+-+-+-+-+-+-+-+-+-+


Seqno Request TLV приглашает получателя передать Update для данного префикса с данным порядковым номером или переслать запрос, если его нельзя выполнить локально.

Type

Значение 10 указывает Seqno Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Формат кодирования поля Prefix. Значение 0 недопустимо.

Plen

Размер запрашиваемого префикса в битах.

Seqno

Запрашиваемый порядковый номер.

Hop Count

Максимальное число пересылок данного TLV плюс 1. Значение 0 недопустимо.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Router-Id

Запрашиваемый идентификатор Router-Id. Недопустимы значения, содержащие только 0 или только 1.

Prefix

Запрашиваемый префикс, размер которого составляет Plen/8 с округлением в большую сторону.

Seqno Request TLV приглашает получателя передать Update с конечной метрикой для префикса, указанного полями AE, Plen и Prefix, с router-id, отличным от заданного полем Router-Id, или Seqno не меньше (по модулю 216) указанного в поле Seqno. Если запрос нельзя выполнить локально, он пересылается в соответствии с правилами параграфа 3.8.1.2.

Хотя Seqno Request можно передавать по групповому адресу, его недопустимо пересылать по групповому адресу, а также недопустима пересылка более чем одному соседу. Запрос недопустимо пересылать при Hop Count = 1.

TLV относится к самозавершающим и может включать суб-TLV.

4.7. Специальные суб-TLV

4.7.1. Pad1

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+


Type

Значение 0 указывает суб-TLV Pad1.

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

4.7.2. PadN

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Значение 1 указывает суб-TLV PadN.

Length

Размер тела в октетах без учета полей Type и Length.

MBZ

Должно иметь значение 0, устанавливаемое при передаче.

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

5. Взаимодействие с IANA

Агентство IANA зарегистрировало порт UDP с номером 6696, названный babel, для использования протоколом Babel.

Агентство IANA зарегистрировало multicast-группы IPv6 ff02::1:6 и IPv4 224.0.0.111 для протокола Babel.

В IANA создан реестр Babel TLV Types с политикой распределения Specification Required [RFC8126] для типов 0-223 и Experimental Use для типов 224-254. Значения реестра приведены в таблице 1.

Таблица 1.

Тип

Имя

Документ

0

Pad1

RFC 8966

1

PadN

RFC 8966

2

Acknowledgment Request

RFC 8966

3

Acknowledgment

RFC 8966

4

Hello

RFC 8966

5

IHU

RFC 8966

6

Router-Id

RFC 8966

7

Next Hop

RFC 8966

8

Update

RFC 8966

9

Route Request

RFC 8966

10

Seqno Request

RFC 8966

11

TS/PC

[RFC7298]

12

HMAC

[RFC7298]

13

Reserved

14

Reserved

15

Reserved

224-254

Reserved for Experimental Use

RFC 8966

255

Reserved for expansion of the type space

RFC 8966

В IANA создан реестр Babel Sub-TLV Types с политикой распределения Specification Required для типов 0-111 и 128-239 и политикой Experimental Use для типов 112-126 и 240-254. Значения реестра приведены в таблице 2.

Таблица 2.

Тип

Имя

Документ

0

Pad1

RFC 8966

1

PadN

RFC 8966

2

Diversity

[BABEL-DIVERSITY]

3

Timestamp

[BABEL-RTT]

4-111

Unassigned

112-126

Reserved for Experimental Use

RFC 8966

127

Reserved for expansion of the type space

RFC 8966

128

Source Prefix

[BABEL-SS]

129-239

Unassigned

240-254

Reserved for Experimental Use

RFC 8966

255

Reserved for expansion of the type space

RFC 8966

В IANA создан реестр Babel Address Encodings с политикой распределения Specification Required для кодирования адресов (AE) 0-223 и Experimental Use для 224-254. Значения реестра приведены в таблице 3.

Таблица 3.

AE

Имя

Документ

0

Wildcard address

RFC 8966

1

IPv4 address

RFC 8966

2

IPv6 address

RFC 8966

3

Link-local IPv6 address

RFC 8966

4-223

Unassigned

224-254

Reserved for Experimental Use

RFC 8966

255

Reserved for expansion of the AE space

RFC 8966

Реестр Babel Flags Values переименован в Babel Update Flags Values. Для реестра применяется политика распределения Specification Required. Значения реестра приведены в таблице 4.

Таблица 4.

Бит

Имя

Документ

0

Default prefix

RFC 8966

1

Default router-id

RFC 8966

2-7

Unassigned

В IANA создан реестр Babel Hello Flags Values с политикой распределения Specification Required. Значения реестра приведены в таблице 5.

Таблица 5.

Бит

Имя

Документ

0

Unicast

RFC 8966

1-15

Unassigned

Агентство IANA заменило ссылки на RFC 6126 и RFC 7557 во всех перечисленных выше реестрах на данный документ.

6. Вопросы безопасности

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

  • подменять пакеты Babel и перенаправлять трафик, анонсируя анонсирования маршруты с меньшей метрикой, большим порядковым номером или более длинным префиксом;

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

  • повторно использовать перехваченные пакеты Babel, что может вести к перенаправлению трафика, возникновению «черных дыр» и даже нарушению работы всей сети.

При передаче по протоколу IPv6 пакеты Babel игнорируются, если они не переданы с адреса IPv6 link-local. Поскольку маршрутизаторы не пересылают пакеты IPv6 link-local, это смягчает атаки, указанные выше, необходимостью для злоумышленника иметь доступ к локальному каналу. Для пакетов Babel, переданных по протоколу IPv4 такой естественной защиты нет и это служит одной из причин рекомендуемого использования Babel на основе IPv6 (параграф 3.1).

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

  • Babel по протоколу DTLS [RFC8968] передает основную часть трафика Babel по протоколу DTLS и этот протокол применяется для аутентификации узлов, а также защиты целостности и конфиденциальности.

  • MAC-аутентификация [RFC8967] добавляет код аутентификации сообщений (message authentication code или MAC) в каждый пакет Babel для подтверждения его отправки узлом, знающим общий секрет, и включения дополнительной информации для проверки свежести пакета (предотвращение повторного использования).

Оба механизма позволяют узлам игнорировать пакеты от злоумышленника без требуемых свидетельств. Обеспечивается также целостность сообщений и предотвращается их повторное использование. Babel-DTLS использует асимметричные ключи и обеспечивает конфиденциальность, а Babel-MAC имеет более ограниченную область применения (см. параграфы 1.1, 1.2, 7 в [RFC8967]). Поскольку Babel-MAC проще и более облегчен, его рекомендуется использовать в приложениях Babel, где ограничения протокола допустимы, например, достаточно симметричных ключей, а маршрутные данные не считаются конфиденциальными.

Каждой реализации Babel следует поддерживать BABEL-MAC.

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

7. Литература

7.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8967] Dô, C., Kolodziejak, W., and J. Chroboczek, «MAC Authentication for the Babel Routing Protocol», RFC 8967, DOI 10.17487/RFC8967, January 2021, <https://www.rfc-editor.org/info/rfc8967>.

7.2. Дополнительная литература

[BABEL-DIVERSITY] Chroboczek, J., «Diversity Routing for the Babel Routing Protocol», Work in Progress, Internet-Draft, draft-chroboczek-babel-diversity-routing-01, 15 February 2016, <https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01>.

[BABEL-RTT] Jonglez, B. and J. Chroboczek, «Delay-based Metric Extension for the Babel Routing Protocol», Work in Progress, Internet-Draft, draft-ietf-babel-rtt-extension-00, 26 April 2019, <https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00>.

[BABEL-SS] Boutier, M. and J. Chroboczek, «Source-Specific Routing in Babel», Work in Progress, Internet-Draft, draft-ietf-babel-source-specific-07, 28 October 2020, <https://tools.ietf.org/html/draft-ietf-babel-source-specific-07>.

[DSDV] Perkins, C. and P. Bhagwat, «Highly dynamic Destination-Sequenced Distance-Vector routing (DSDV) for mobile computers», ACM SIGCOMM ’94: Proceedings of the conference on Communications architectures, protocols and applications, 234-244, DOI 10.1145/190314.190336, October 1994, <https://doi.org/10.1145/190314.190336>.

[DUAL] Garcia Luna Aceves, J. J., «Loop-free routing using diffusing computations», IEEE/ACM Transactions on Networking, 1:1, DOI 10.1109/90.222913, February 1993, <https://doi.org/10.1109/90.222913>.

[EIGRP] Albrightson, B., Garcia Luna Aceves, J. J., and J. Boyle, «EIGRP — a Fast Routing Protocol Based on Distance Vectors», Proc. Networld/Interop 94, 1994.

[ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, «A high-throughput path metric for multi-hop wireless networks», MobiCom ’03: Proceedings of the 9th annual international conference on Mobile computing and networking, 134-146, DOI 10.1145/938985.939000, September 2003, <https://doi.org/10.1145/938985.939000>.

[IEEE802.11] IEEE, «IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April 2012, <https://doi.org/10.1109/ieeestd.2012.6178212>.

[IEN137] Cohen, D., «On Holy Wars and a Plea for Peace», IEN 137, 1 April 1980.

[IS-IS] International Organization for Standardization, «Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)», ISO/IEC 10589:2002, 2002.

[JITTER] Floyd, S. and V. Jacobson, «The Synchronization of Periodic Routing Messages», IEEE/ACM Transactions on Networking, 2, 2, 122-136, DOI 10.1109/90.298431, April 1994, <https://doi.org/10.1109/90.298431>.

[OSPF] Moy, J., «OSPF Version 2», STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[PACKETBB] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, «Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format», RFC 5444, DOI 10.17487/RFC5444, February 2009, <https://www.rfc-editor.org/info/rfc5444>.

[RFC2675] Borman, D., Deering, S., and R. Hinden, «IPv6 Jumbograms», RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.

[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, «Ad hoc On-Demand Distance Vector (AODV) Routing», RFC 3561, DOI 10.17487/RFC3561, July 2003, <https://www.rfc-editor.org/info/rfc3561>.

[RFC6126] Chroboczek, J., «The Babel Routing Protocol», RFC 6126, DOI 10.17487/RFC6126, April 2011, <https://www.rfc-editor.org/info/rfc6126>.

[RFC7298] Ovsienko, D., «Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication», RFC 7298, DOI 10.17487/RFC7298, July 2014, <https://www.rfc-editor.org/info/rfc7298>.

[RFC7557] Chroboczek, J., «Extension Mechanism for the Babel Routing Protocol», RFC 7557, DOI 10.17487/RFC7557, May 2015, <https://www.rfc-editor.org/info/rfc7557>.

[RFC8968] Décimo, A., Schinazi, D., and J. Chroboczek, «Babel Routing Protocol over Datagram Transport Layer Security», RFC 8968, DOI 10.17487/RFC8968, January 2021, <https://www.rfc-editor.org/info/rfc8968>.

[RIP] Malkin, G., «RIP Version 2», STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

Приложение A. Расчет стоимости и метрики

Стратегия рачсета стоимости и метрики маршрутов определяется локально. Протокол Babel требует лишь соответствия условиям, указанным в параграфах 3.4.3 и 3.5.2. Разные узлы могут применять разную стратегию в одной сети и даже на разных типах интерфейсов. В это приложении описаны варианты, проверенные в реальных сетях.

Говоря кратко, узел поддерживает статистику на уровне соседа для 16 последних Hello TLV каждого типа (Приложение A.1) и рассчитывает стоимость, используя стратегию !два из трех» (Приложение A.2.1) на проводных каналах и ETX5 (Приложение A.2.2) на беспроводных. Для расчета метрики применяется аддитивная алгебра (параграф 3.5.2).

A.1. Поддержка истории Hello

Для каждого соседа узел поддерживает два комплекта истории Hello (по одному для каждого типа) и ожидаемый порядковый номер (один для Multicast, другой для Unicast Hello). Каждая история Hello представляет собой 16-битовый вектор, где 1 указывает прием Hello, а 0 — пропуск. Для каждого типа Hello ожидаемым порядковым номером (ne) является номер, который предполагается получить в следующем Hello от этого соседа.

При каждом приеме пакета Hello данного типа от соседа узел сравнивает полученный порядковый номер (nr) с ожидаемым для этого типа Hello номером ne. В зависимости от результат выполняются указанные ниже действия.

  • Если номера различаются больше чем на 16 (по модулю 216), это говорит о возможной перезагрузке передавшего пакет узла с потерей порядковых номеров. В этом случае запись таблицы соседей очищается и создается заново.

  • В остальных случаях, если nr меньше (по модулю 216) ожидаемого номера ne, это говорит об увеличении передающим узлом интервала Hello без уведомления и принимающий узел удаляет последние (ne — nr) элементов из истории Hello для этого соседа (undo history).

  • Если nr больше (по модулю 216) чем ne, это говорит об уменьшении передающим узлом интервала Hello и потере некоторых сообщения Hello. Принимающий узел добавляет (nr — ne) битов со значением 0 в историю Hello (fast-forward).

Принимающий узел добавляет бит 1 в историю Hello и устанавливает ne = (nr + 1). Если поле Interval в принятом Hello отлично от 0, для таймера Hello с соседом устанавливается значение в 1,5 анонсированного интервала (увеличение позволяет учесть вариации задержки). По завершении отсчета связанного с соседом таймера локальный узел добавляет 0 в историю Hello и инкрементирует номер ожидаемого Hello. Если обе истории Hello пусты (содержат лишь 0), запись соседа сбрасывается. В противном случае для соответствующего таймера Hello устанавливается значение, анонсированное в последнем Hello того же типа от данного соседа (без увеличения, поскольку вариации задержки уже учтены при расчете только что завершившегося тайм-аута).

A.2. Расчет стоимости

В этом параграфе описаны два алгоритма расчета стоимости (параграф 3.4.3) на основе истории Hello. Алгоритм из парарафа A.2.1 применим к проводным каналам, A.2.2 — к беспроводным. Рекомендуемые значения для установки по умолчанию для параметров этих алгоритмов указаны в Приложении B.

A.2.1. k-out-of-j

Метод k-out-of-j подходит для проводных каналов, которые могут принимать два состояния — рабочее (up), где пакеты могут иногда отбрасываться, и нерабочее (down), когда отбрасываются все пакеты.

Метод k-out-of-j параметризуется двумя небольшими целыми числами k и j, так что 0 < k <= j, и номинальной стоимостью канала C >= 1. Узел хранит историю последних j Hello и если из них не менее k были получены корректно, канал считается работающим (up) и устанавливается C. В противном случае канал считается неработающим (down) и устанавливается бесконечное значение rxcost.

Поскольку Babel поддерживает два типа Hello, узел Babel выполняет k-out-of-j дважды для каждого соседа с историей Unicast Hello и Multicast Hello. Если любой из вариантов k-out-of-j показывает рабочее (up) состояние канала, канал считается активным (up) и устанавливается rxcost = C. Если оба варианта указывают нерабочее (down) состояние канала, он считается неактивным и для rxcost устанавливается бесконечное значение. Иными словами, результирующим значением rxcost будет меньший из результатов двух экземпляров k-out-of-j link.

Стоимость канала с определением k-out-of-j будет:

  • cost = FFFF (шестнадцатеричное), если rxcost = FFFF (шестнадцатеричное);

  • cost = txcost в остальных случаях.

A.2.2. ETX

В отличии от проводных каналов, которые имеют лишь два состояния (up или down), у беспроводных соединений параметры качество могут изменяться непрерывно. Наивное применение маршрутизации по числу интервалов пересылки в сетях с беспроводными каналами для транзита имеет тенденцию к выбору длинных каналов с потерями вместо более коротких каналов без потерь, что может значительно снизить пропускную способность. По этой причине протоколы маршрутизации для беспроводных сетей должны выполнять ту или иную оценку качества соединений.

Алгоритм ETX [ETX] является простым способом оценки качества канала, предназначенным для работы с IEEE 802.11 MAC [IEEE802.11]. По умолчанию IEEE 802.11 MAC выполняет запрос автоматического повтора (Automatic Repeat Query или ARQ) и адаптацию скорости для индивидуальных кадров, но не делает этого для групповых, которые передаются с фиксированной скоростью без ARQ. Поэтому измерение частоты потерь групповых кадроа дает полезную оценку качества канала.

Узел, выполняющий оценку качества канала ETX, использует историю Multicast Hello для расчета оценки (beta) вероятности успешного приема Hello TLV. Значение параметра рассчитывается как доля битов 1 в небольшой (скажем, 6) группе последних записей истории Multicast Hello, экспоненциальное среднее значения или комбинация этих вариантов. Пусть rxcost = 256/beta.

Пусть alpha = MIN(1, 256/txcost) будет оценкой вероятности успешной передачи Hello TLV. Тогда стоимость будет cost = 256/(alpha * beta) или, эквивалентно, cost = (MAX(txcost, 256) * rxcost)/256.

Поскольку IEEE 802.11 MAC выполняет ARQ для индивидуальных кадров, такие кадры не вносят полезного вклада в измерение качества канала и ETX игнорирует историю Unicast Hello. Таким образом, узел, выполняющий оценку качества канала ETX, не будет маршрутизировать пакеты через соседние узлы, от которых он не получает Multicast Hello (возможно в дополнение в Unicast Hello).

A.3. Выбор маршрутов и гистерезис

В процессе выбора маршрута (параграф 3.6) узел выбирает один из доступных для данного адресата маршрутов. В Babel любая процедура, выбирающая лишь выполнимые маршруты с конечной метрикой будет давать маршрутизацию без петель. Однако при наличии постоянно меняющейся метрики, такой как ETX (Приложение A.2.2) наивная процедура выбора может приводить к постоянным переключениям маршрутов. Такие переключения можно ограничить и даже предотвратит путем задания гистерезиса в алгоритме выбора маршрута, например, учитывая при выборе историю маршрутов. Хорошие результаты должны давать любые разумные алгоритмы гистерезиса и ниже приведен один из вариантов, успешно развернутый во многих реализациях.

Для каждого маршрута R в дополнение к его метрике m(R) поддерживается сглаженная версия метрики ms(R) (рекомендуется рассчитывает ее как экспоненциально сглаженное среднее значение метрики в соответствии с параграфом 3.7 в [RFC793] для интервала, равного интервалу Hello, умноженному на небольшое число, например , 3). Если маршрута к данному адресату не выбрано, выбирается маршрут с наименьшей метрикой без учета сглаживания. Если выбран маршрут R, переключение на R’ выполняется лишь при условии m(R’) < m(R) и ms(R’) < ms(R).

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

Приложение B. Параметры протокола

Выбор временных констант является компромиссом между быстрым обнаружением перемещений (mobility event) и издержками протокола. Два экземпляра Babel с разными временными константами могут взаимодействовать, но при этом максимальное время схождения будет определять более медленная реализация. Интервал Hello является наиболее важной из временных констант, поскольку перебои или перемещения обнаруживаются в течение 1,5 — 3,5 интервалов Hello. В результате использования Babel таблицы маршрутов с избыточностью и работы протокола на основе триггерных обновлений интервал Update не оказывает существенного влияния на время схождения после отказа. На практике он сильно влияет лишь на время получения новых маршрутов после перемещений (mobility event). Хотя протокол разрешает интервалы меньше от 10, столь малые значения вызывают большой протокольный трафик при незначительной практической пользе.

Ниже даны проверенные на практике в разных средах значения, которые рекомендуется применять по умолчанию.

Интервал Multicast Hello

4 секунды.

Интервал Unicast Hello

Бесконечный (Unicast Hello не передаются).

Стоимость канала

Оценка ETX на беспроводных каналах и «два из трех» с C=96 — на проводных.

Интервал IHU

Анонсируемый интервал IHU составляет 3 интервала Multicast Hello. IHU передаются с каждым Hello на каналах с потерями (в соответствии с историей Hello), но лишь с каждым третьим Multicast Hello на каналах без потерь.

Интервал Update

4 интервала Multicast Hello.

Время удержания IHU

3,5 анонсированных интервала IHU.

Срок действия маршрута

3,5 анонсированных интервала обновления.

Тайм-аут для запросов

Изначально 2 секунды с удвоением при каждом повторе запроса (до 3 раз).

Тайм-аут срочности

0,2 секунды.

Время сборки мусора для источника

3 минуты.

Приложение C. Фильтрация маршрутов

Фильтрация маршрутов представляет собой процедуру, где экземпляр протокола маршрутизации отбрасывает некоторые из анонсированных соседями маршрутов или проверяет их метрику, сравнивая с ожидаемой. Подобно другим протоколам на основе вектора удаленности, Babel может применять к изучаемым маршрутам произвольные фильтры и реализации Babel с разными наборами фильтров и правилами фильтрации могут взаимодействовать, не порождая маршрутных петель. Способность протокола фильтровать маршруты обусловлена расчетом метрики, описанным в параграфе 3.5.2 — Babel может применять любую метрику со строгой монотонностью, включая метрику с бесконечным значением для выбранного подмножества маршрутов (см. также параграф 3.8.1, где запросы для несуществующих маршрутов рассматриваются как запросы маршрутов с бесконечной метрикой).

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

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

Для ограничения последствий ошибочной настройки реализации Babel поддерживают по умолчанию разумный набор правил фильтрации, даже если они не позволяют настраивать фильтры пользователю. Как минимум, реализации отбрасывают маршруты с префиксом адресатов fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32, 224.0.0.0/8.

Приложение D. Расширения протокола

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

  • увеличение номера версии в заголовке пакетов;

  • определение новых TLV;

  • определение новых суб-TLV (в битом обязательности или без него);

  • определение новых AE;

  • использование трейлеров в пакетах.

В этом приложении содержатся рекомендации для разработчиков расширений в части выбора кодирования.

Номер версии в заголовке Babel следует увеличивать лишь в тех случаях, когда не обеспечивается совместимости с более ранней версией протокола. Во многих случаях расширения можно реализовать путем определения новых TLV или добавления суб-TLV к имеющимся TLV. Например, расширение для добавления данных в обновления маршрутов можно реализовать путем «обогащения» Update TLV за счет необязательных или обязательных суб-TLV в Update TLV.

Различные кодировки по-разному обрабатываются реализациями, которым непонятно данное расширение. В случае новых TLV или суб-TLV с флагом обязательности не понимающая расширение реализация будет игнорировать TLV целиком, тогда как при нопонятных необязательных суб-TLV будет выполняться анализ и обработка TLV в целом с игнорированием непонятных суб-TLV. Поэтому для совместимых расширений Update TLV следует применять необязательные суб-TLV (расширение можно игнорировать), а обязательные суб-TLV или новые TLV должны применяться в расширениях, где непонятные TLV должны отбрасываться целиком.

Опыт показывает, что необходимость добавления данных обычно возникает в самых неожиданных местах. Поэтому рекомендуется определять новые TLV как самозавершающие, чтобы к ним можно было добавлять суб-TLV.

Добавление AE, по сути, эквивалентно определению нового TLV, поскольку Update TLV с неизвестным AE игнорируются подобно неизвестным TLV. Однако для добавление AE потребуется больше усилий, поскольку это создает новый набор состояний сжатия. А поскольку Next Hop TLV создает состояние, связанное с данным семейством адресов, а не данным AE, новое кодирование адресов AE для ранее определенного семейства даресов недопустимо применять в Next Hop TLV, если нужна совместимость с прежними версиями. Похожая проблема возникает для Update TLV с неизвестными AE, задающими новое значение router-id (в результате установки флага Router-Id). Поэтому определять новые AE нужно очень осторожно, если нужна совместимость с имеющимися реализациями.

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

Приложение E. Реализации-заглушки

Протокол Babel достаточно экономичен. Обновление для одного адресата занимает от 12 до 40 октетов в зависимости от семейства адресов, а средний размер составляет менее 24 октетов. Запись в таблице маршрутов для IPv6 занимает около 35 октетов. Таким образом, в один стандартный кадр Ethernet можно поместить около 65 обновлений а мегабайт памяти позволяет записать таблицу маршрутов с 20000 записей и связанную с ней таблицы источников.

Babel также является довольно простым протоколом и его полная реализация включает меньше 12000 строк C, а размер двоичного файла — меньше 120 Кбайт для 32-битовой архитектуры CISC, из которых около половины занимает код расширений и пользовательского интерфейса. Тем не менее, в некоторых средах с очень большими ограничениями, таких как КПК (PDA), микроволновые печи и т. п., может оказаться желательным реализовать лишь часть протокола.

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

Независимо от степени упрощения, реализация-заглушка должна анализировать суб-TLV во всех понятных TLV и проверять флаг обязательности. Она должна отвечать на запросы подтверждений и участвовать в обмене Hello и IHU, а также должна быть способна отвечать на запросы seqno для анонсируемых маршрутов и на запросы маршрутов. Опыт показывает, что реализация-заглушка с поддержкой лишь IPv6 может иметь менее 1000 строк кода C и компилироваться в 13 Кбайт исполняемого кода для 32-битовой архитектуры CISC.

Приложение F. Совместимость с предыдущими версиями

Определенный в этом документе протокол является преемником протокола, заданного [RFC6126] и [RFC7557]. Хотя эти протоколы не совместимы полностью, новый протокол можно развернуть в сетях RFC 6126 без остановки работы.

Протокол имеет 3 необязательный свойства, делающих его несовместимым с предшественником. Во-первых, RFC 6126 не требует Unicast Hello (параграф 3.4.1) и реализация RFC 6126 будет ошибочно воспринимать Unicast Hello как Multicast Hello. Поскольку для этих сообщений применяются разные порядковые номера, передача Unicast Hello реализации RFC 6126 будет приводить к сбоям при оценке качества канала. Во-вторых, RFC 6126 не определяет неплановых Hello и реализация RFC 6126 будет неверно трактовать Hello с интервалом 0. В-третьих, RFC 7557 не определяет обязательных суб-TLV (параграф 4.4), поэтому реализации RFC 6126 и RFC 7557 будут некорректно игнорировать TLV с неизвестными обязательными суб-TLV, что может нарушать корректность маршрутизации.

Реализацию данного документа, которая не будет передавать Unicast и неплановые Hello, а также поддерживать какие-либо расширения с обязательными суб-TLV, можно без опаски развертывать в сети, где некоторые узлы используют протокол, определенный в RFC 6126 и RFC7557.

При внесении двух изменений в реализации RFC 6126 и RFC 7557 они смогут безопасно взаимодействовать с реализацией данной спецификации. Во-первых, нужно игнорировать или обрабатывать незапланированные и Unicast Hello. Во-вторых, нужно анализировать суб-TLV во всех понятных TLV и игнорировать TLV с неизвестными обязательными суб-TLV. Разбор неизвестных TLV не требуется и они просто игнорируются.

Ниже другие изменения, которые не препятствуют взаимодействию:

  • смягчены условия восприятия маршрутов (параграф 3.5.3);

  • при выборе маршрута больше не требуется его порядковый номер (параграф 3.6);

  • определен формат трейлера в пакетах (параграф 4.2);

  • запрещены router-id, содержащие только 0 или только 1 (параграф 4.1.3);

  • состояние сжатия зависит от семейства адресов, а не от формата кодирования (параграф 4.5);

  • рекомендуется задавать темп отправки пакетов (параграф 3.1).

Благодарности

Много людей внесло свой вклад в текст и идеи для этой спецификации. Авторы особо признательны Matthieu Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake, Toke Høiland-Jørgensen, Benjamin Kaduk, Joao Sobrinho и Martin Vigoureux. Предыдущая версия спецификации [RFC6126] в значительной мере основана на вкладе Joel Halpern. Метод сжатия адресов был заимствован из [PACKETBB].

Адреса авторов

Juliusz Chroboczek

IRIF, University of Paris-Diderot

Case 7014

75205 Paris CEDEX 13

France

Email: jch@irif.fr

David Schinazi

Google LLC

1600 Amphitheatre Parkway

Mountain View, California 94043

United States of America

Email: dschinazi.ietf@gmail.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Enhanced Interior Gateway Routing Protocol — расширенный протокол внутренней маршрутизации.

4Ad hoc On-Demand Distance Vector.

5Expected Transmission Cost — ожидаемая стоимость передачи.

Рубрика: RFC | Комментарии к записи RFC 8966 The Babel Routing Protocol отключены

RFC 8819 YANG Module Tags

image_print
Internet Engineering Task Force (IETF)                          C. Hopps
Request for Comments: 8819                                     L. Berger
Updates: 8407                                    LabN Consulting, L.L.C.
Category: Standards Track                                  D. Bogdanovic
ISSN: 2070-1721                                           Volta Networks
                                                            January 2021

YANG Module Tags

Теги модулей YANG

PDF

Аннотация

Этот документ связывает теги с модулями YANG. Предполагается, что использование таких тегов поможет классифицировать и организовать модули. Представлен метод определения, чтения и записи тегов модулей. Теги могут регистрироваться и назначаться в процессе создания модуля, назначаться при развертывании или динамически задаваться и устанавливаться пользователем. В документе также приведены рекомендации для разработчиков новых модулей, обновляющие RFC 8407.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8819.

Авторские права

Copyright (c) 2021. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Документ является субъектом прав и ограничений, указанных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

Применение тегов для классификации и организации достаточно широко распространено не только в протоколах IETF, но и в сети в целом (например, #хештеги). Одним из преимуществ использования тегов для организации по сравнению с жесткой структурой является гибкость и простота адаптации к новым технологиям. Теги можно регистрировать, но они могут также служить не регистрируемым механизмом, позволяющим пользователям самостоятельно задавать теги. В этом документе представлен механизм для определения тегов и гибкого связывания их с модулями YANG. В частности, теги можно регистрировать, а также назначать в процессе создания модулей, назначать при реализации или динамически задавать и устанавливать силами пользователя.

Этот документ определяет модуль YANG [RFC7950], включающий список записей для модулей, который позволяет добавлять и исключать теги, а также просматривать набор связанных с модулем тегов.

Документ определяет оператор расширения для указания тегов, которые следует автоматически добавлять реализации модуля (т. е. вне процедуры настройки).

Документ также задает реестр IANA для префиксов тегов и набора тегов глобального значения.

В разделе 6 приведены рекомендации для разработчиков моделей данных YANG.

Документ обновляет [RFC8407].

Модель данных YANG в этом документе соответствует архитектуре хранилища сетевого управления (Network Management Datastore Architecture или NMDA), определенной в [RFC8342].

1.1. Примеры возможного применения тегов модулей YANG

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

Одним из примеров служит помощь в фильтрации разных дискретных категорий модулей YANG, поддерживаемых устройством. Например, при задании для модулей подходящих тегов можно использовать запрос XPath для получения всех фирменных модулей, поддерживаемых устройством.

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

Классификация по тегам полезна для пользователей при поиске в репозиториях модулей (например, каталог YANG). Запросы с тегом ietf:routing, например, можно использовать для получения лишь модулей IETF YANG, связанных с маршрутизацией. Без тега пользователю нужно знать имена всех модулей YANG для протоколов маршрутизации IETF.

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

1.2. Используемые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными буквами, как показано здесь.

2. Значения тегов

Всем тегам следует начинаться с префикса, указывающего владельца определения. Для поддержки регистрации префиксов тегов используется реестр IANA (параграф 7.1). В настоящее время определены 3 префикса. Этот документ не задает дополнительной структуры тега после префикса и значение тега может включать любые символы типа string в YANG, за исключением возврата каретки (CR), новой строки и табуляции.

За исключением префикса, служащего для предотвращения конфликтов, этот документ намеренно не задает какой-либо структуры (т. е. ограничений) для значений тегов. Цель этого состоит в предотвращении произвольных ограничений на значения тегов, которые могут применять разработчики, операторы и пользователи. Это позволяет вободно выбирать структуру (или ее отсутствие) для создаваемых тегов.

2.1. Теги IETF

Теги IETF начинаются с префикса ietf: и регистрируются в реестре IANA (параграф 7.2).

2.2. Теги производителей

Теги производителей начинаются с префикса vendor: и определяются производителем, реализующим модуль. Такие теги не регистрируются, однако производителям рекомендуется включать в тег дополнительную идентификацию для предотвращения конфликтов (это может быть имя компании или организации после префикса vendor:, например, vendor:example.com:vendor-defined-classifier).

2.3. Пользовательские теги

Пользовательскими считаются любые теги с префиксом user:. Эти теги задаются пользователем или администратором и не регистрируются. От пользователей не требуется применение префикса user:, но это рекомендуется для предотвращения конфликтов.

2.4. Зарезервированные теги

Все теги, не имеющие префикса ietf:, vendor: или user:, зарезервированы на будущее. Значения таких тегов не являются недействительными и просто резервируются в контексте спецификаций (например, RFC).

3. Управление тегами

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

3.1. Теги при создании модуля

Определение модуля может указывать набор тегов для добавления при реализации модуля. Эти теги указываются с помощью оператора расширения module-tag.

Если модуль определен в документе IETF Standards Track, теги должны относиться к IETF (параграф 2.1). Таким образом, новые модули могут приводить к добавлению тегов IETF в реестр IANA, определенный в параграфе 7.2, и реестр IANA будет служить для предотвращения дубликатов.

3.2. Теги при реализации

Реализация может включать дополнительные теги, связанные с модулем, которым следует быть тегами IETF (т. е. зарегистрированными) или производителя.

3.3. Теги, устанавливаемые пользователем

Теги любого типа (с префиксом или без него) могут быть добавлены или удалены пользователем с помощью обычных механизмов настройки конфигурации. Для удаления тега из рабочего хранилища пользователь добавляет соответствующую запись максирования (masked-tag) для данного модуля.

4. Структура модуля тегов

4.1. Дерево модуля тегов

Ниже приведено дерево, связанное с модулем ietf-module-tags. Значение символов описано в [RFC8340].

module: ietf-module-tags
  +--rw module-tags
     +--rw module* [name]
        +--rw name          yang:yang-identifier
        +--rw tag*          tag
        +--rw masked-tag*   tag

Рисунок 1. Дерево тегов модуля YANG.


4.2. Модуль YANG

   <CODE BEGINS> file "ietf-module-tags@2021-01-04.yang"
   module ietf-module-tags {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags";
     prefix tags;

     import ietf-yang-types {
       prefix yang;
     }

     organization
       "IETF NetMod Working Group (NetMod)";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/netmod/> 
        WG List: <mailto:netmod@ietf.org> 

        Author: Christian Hopps
                <mailto:chopps@chopps.org> 

        Author: Lou Berger
                <mailto:lberger@labn.net> 

        Author: Dean Bogdanovic
                <mailto:ivandean@gmail.com>"; 

     description
       "Этот модуль описывает механизм связывания тегов с модулями
        YANG. Теги могут быть выделены IANA или определены приватно.

        Авторские права (Copyright (c) 2021) принадлежат IETF Trust и 
        лицам, указанным как авторы кода. Все права защищены.

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с
        упрощенной лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к
        документам IETF (https://trustee.ietf.org/license-info).
        Данная версия модуля YANG является частью RFC 8819
        (https://www.rfc-editor.org/info/rfc8819), где правовые
        аспекты изложены более полно.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
        СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
        НЕОБЯЗАТЕЛЬНО в этом документе интерпретируются в соответствии
        с BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.";

     revision 2021-01-04 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8819: YANG Module Tags";
     }

     typedef tag {
       type string {
         length "1..max";
         pattern '[\S ]+';
       }
       description
         "Тег является значением типа string, не включающим символов
          возврата каретки, перевода строки и табулфции. Теги СЛЕДУЕТ
          начинать с зарегистрированного префикса, однако теги без
          такого префикса НЕ СЛЕДУЕТ считать недействительными.";
     }

     extension module-tag {
       argument tag;
       description
         "Аргумент tag имеет тип tag. Этот оператор расширения применяется
          авторами модулей для указания тегов, которые системе СЛЕДУЕТ
          добавлять автоматически. Таким образом, источником значения для
          предопределенных тегов следует устанавливать system [RFC8342].";
     }

     container module-tags {
       description
         "Содержит список модулей и связанных с ними тегов.";
       list module {
         key "name";
         description
           "Список модулей и связанных с ними тегов.";
         leaf name {
           type yang:yang-identifier;
           mandatory true;
           description
             "Имя модуля YANG.";
         }
         leaf-list tag {
           type tag;
           description
             "Теги, связанные с модулем. Зарезервированные префиксы 
              указаны в реестре IANA YANG Module Tag Prefixes, а теги
              IETF - в реестре IANA IETF YANG Module Tags.

              Состояние operational [RFC8342] для этого списка 
              создается, как показано ниже.

              1) Системные теги (теги с источником system).
              2) Заданные пользователем теги (теги с источником intended).
              3) Все теги, соответствующие masked-tag удаляются.";
         }
         leaf-list masked-tag {
           type tag;
           description
             "Список тегов, которые на следует связывать с этим модулем.
              Пользователь может удалить (замаскировать) теги из рабочего
              хранилища данных [RFC8342], добавляя их в этот список.
              Добавление в список тега, не связанного с модулем, не 
              является ошибкой и не будет оказывать никакого влияния.";
         }
       }
     }
   }
   <CODE ENDS>

Рисунок 2. Модуль тегов.


5. Другая классификация

Следует отметить наличие другого документа с классификацией модулей YANG [RFC8199]. Этот документ классифицирует модули логически и не включает тегов или иных механизмов. Модули YANG в нем разделены на две категории (service и element), для каждой из которых возможны 3 источника — standard, vendor или user. Это обеспечивает хороший способ обсуждения и идентификации модулей в целом. Определенные здесь теги IETF поддерживают стиль классификации, описанный в [RFC8199].

6. Рекомендации для создателей модулей

Этот раздел обновляет [RFC8407].

6.1. Определение стандартных тегов

Модуль может указывать (с помощью опрераторов расширения module-tag) набор тегов, автоматически связываемых с ним (т. е. не добавляемых при настройке конфигурации).

   module example-module {
     namespace "https://example.com/yang/example";
     prefix "ex";
     //...
     import module-tags { prefix tags; }

     tags:module-tag "ietf:some-new-tag";
     tags:module-tag "ietf:some-other-tag";
     // ...
   }

Авторы модулей могут использовать имеющиеся стандартные теги или задавать новые в определении модели. Для стандартизованных IETF модулей новые теги должны включаться в реестр IANA, определенный в параграфе 7.2.

7. Взаимодействие с IANA

7.1. Реестр YANG Module Tag Prefixes

Агентство IANA создало субреестр YANG Module Tag Prefixes в реестре YANG Module Tags для регистрации префиксов тегов. Всем тегам модулей YANG следует начинаться с одного из префиксов, включенных в этот реестр.

Префиксам в этом реестре следует быть короткими строками алфавитно-цифровых символов ASCII в нижнем регистре, заканчивающимися символом :. Включение префиксов в этот реестр выполняется по процедуре Specification Required [RFC8126]. Значения Reference и Assignee должны позволять идентифицировать организацию, которой был выделен префикс, и ее контактные данные.

Начальные значения префиксов указаны в таблице 1.

Таблица 1.

Префикс

Описание

Документ

Организация

ietf:

Теги IETF, включенные в реестр IANA IETF YANG Module Tags.

RFC 8819

IETF

vendor:

Не регистрируемые теги, выделенные разработчиком модуля.

RFC 8819

IETF

user:

Не регистрируемые теги, выделенные пользователем или для него.

RFC 8819

IETF

Другим органам стандартизации (standards development organization или SDO), желающим создать свой набор тегов, следует получить префикс из этого реестра.

7.2. Реестр IETF YANG Module Tags

Агентство IANA создало субреестр IETF YANG Module Tags в реестре YANG Module Tags ниже реестра YANG Module Tag Prefixes.

Этот реестр включает теги, имеющие зарегистрированный префикс ietf:. Новые значения тегов должны быть хорошо обдуманы и не должны представлять собой комбинацию уже имеющихся тегов IETF. Выделенные IANA теги должны соответствовать требованиям Net-Unicode [RFC5198] без нормализации. Значения тегов выделяются по процедуре IETF Review [RFC8126].

Начальные значения тегов приведены в таблице 2.

Таблица 2.

Tag

Description

Reference

ietf:network-element-class

Элемент сети в соответствии с [RFC8199].

[RFC8199]

ietf:network-service-class

Сетевая служба в соответствии с [RFC8199].

[RFC8199]

ietf:sdo-defined-class

Модуль, определенный органом стандартизации.

[RFC8199]

ietf:vendor-defined-class

Модуль, определенный производителем.

[RFC8199]

ietf:user-defined-class

Модуль, определенный пользователем.

[RFC8199]

ietf:hardware

Связан с оборудованием (например, инвентаризация).

RFC 8819

ietf:software

Связан с программой (например, установленной ОС).

RFC 8819

ietf:protocol

Представляет протокол (часто с другим тегом для уточнения).

RFC 8819

ietf:qos

Связан с качеством обслуживания.

RFC 8819

ietf:network-service-app

Связан с приложением сетевых услуг (например, сервер NTP, DNS, DHCP и т. п.).

RFC 8819

ietf:system-management

Связан с управлением системой (например, протокол управления, такой как TACACS+, SNMP, NETCONF.).

RFC 8819

ietf:oam

Связан с OAM (Operations, Administration, Maintenance, например, BFD).

RFC 8819

ietf:routing

Связан с маршрутизацией.

RFC 8819

ietf:security

Связан с безопасностью.

RFC 8819

ietf:signaling

Связан с сигнализацией плоскости управления.

RFC 8819

ietf:link-management

Связан с управлением каналом.

RFC 8819

7.3. Обновление реестра IETF XML

Этот документ регистрирует URI в IETF XML Registry [RFC3688] в соответствии с форматом [RFC3688].

   URI:  urn:ietf:params:xml:ns:yang:ietf-module-tags
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

   URI:  urn:ietf:params:xml:ns:yang:ietf-module-tags-state
   Registrant Contact:  The IESG.
   XML:  N/A; the requested URI is an XML namespace.

7.4. Обновление реестра YANG Module Names

Документ включает 2 модуля YANG в реестр YANG Module Names [RFC6020] в соответствии с форматом [RFC6020].

   name:  ietf-module-tags
   namespace:  urn:ietf:params:xml:ns:yang:ietf-module-tags
   prefix:  tags
   reference:  RFC 8819

   name:  ietf-module-tags-state
   namespace:  urn:ietf:params:xml:ns:yang:ietf-module-tags-state
   prefix:  tags-s
   reference:  RFC 8819

8. Вопросы безопасности

Определенный в этом документе модуль YANG предназначен для доступа по протоколу NETCONF [RFC6241]. Нижним уровнем NETCONF является защищенный транспорт с обязательной реализацией Secure Shell (SSH) [RFC6242].

Этот документ добавляет возможность связать метаданные (теги) с модулями YANG. Документ не задает каких-либо действий на основе этих ассоциаций, поэтому сам по себе не создает новых проблем безопасности.

Пользователи тегов могут определять различные действия на основе метаданных из тегов. Такие действия и их определения выходят за рамки данного документа. Пользователи должны самостоятельно рассмотреть влияние определяемых действий на безопасность, включая возможность «маскирования» тегов другими пользователями.

9. Литература

9.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, «YANG Module Classification», RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

[RFC8407] Bierman, A., «Guidelines for Authors and Reviewers of Documents Containing YANG Data Models», BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.

9.2. Дополнительная литература

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC5198] Klensin, J. and M. Padlipsky, «Unicode Format for Network Interchange», RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

Приложение A. Примеры

Ниже приведен вымышленный пример вывода NETCONF, полученного по запросу списка тегов модулей. Для краткости показаны результаты лишь для нескольких модулей.

   <ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0">
     <t:module-tags
      xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags">
       <t:module>
         <t:name>ietf-bfd</t:name>
         <t:tag>ietf:network-element-class</t:tag>
         <t:tag>ietf:oam</t:tag>
         <t:tag>ietf:protocol</t:tag>
         <t:tag>ietf:sdo-defined-class</t:tag>
       </t:module>
       <t:module>
         <t:name>ietf-isis</t:name>
         <t:tag>ietf:network-element-class</t:tag>
         <t:tag>ietf:protocol</t:tag>
         <t:tag>ietf:sdo-defined-class</t:tag>
         <t:tag>ietf:routing</t:tag>
       </t:module>
       <t:module>
         <t:name>ietf-ssh-server</t:name>
         <t:tag>ietf:network-element-class</t:tag>
         <t:tag>ietf:protocol</t:tag>
         <t:tag>ietf:sdo-defined-class</t:tag>
         <t:tag>ietf:system-management</t:tag>
       </t:module>
     </t:module-tags>
   </ns0:data>

Рисунок 3. Пример вывода для запроса NETCONF.


Приложение B. Модуль просмотра состояния не-NMDA

Ниже приведен модуль [RFC8407] для поддержки просмотра рабочего состояния сервера, не поддерживающего NMDA.

   <CODE BEGINS> file "ietf-module-tags-state@2021-01-04.yang"
   module ietf-module-tags-state {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state";
     prefix tags-s;

     import ietf-yang-types {
       prefix yang;
     }
     import ietf-module-tags {
       prefix tags;
     }

     organization
       "IETF NetMod Working Group (NetMod)";
     contact
       "WG Web:  <https://datatracker.ietf.org/wg/netmod/> 
        WG List: <mailto:netmod@ietf.org> 

        Author: Christian Hopps
                <mailto:chopps@chopps.org> 

        Author: Lou Berger
                <mailto:lberger@labn.net> 
        Author: Dean Bogdanovic
                <mailto:ivandean@gmail.com>"; 

     description
       "Этот модуль описывает механизм связывания тегов с модулем YANG.
        Теги могут выделяться IANA или определяться приватно.

        Это временный модуль, предназначенный для использования 
        реализациями, еще не поддерживающими NMDA.

        Авторские права (Copyright (c) 2021) принадлежат IETF Trust и 
        лицам, указанным как авторы кода. Все права защищены.

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с
        упрощенной лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к
        документам IETF (https://trustee.ietf.org/license-info).
        Данная версия модуля YANG является частью RFC 8819
        (https://www.rfc-editor.org/info/rfc8819), где правовые
        аспекты изложены более полно.";

     revision 2021-01-04 {
       description
         "Исходный выпуск.";
       reference
         "RFC 8819: YANG Module Tags";
     }

     container module-tags-state {
       config false;
       status deprecated;
       description
         "Содержит список модулей и связанных с ними тегов.";
       list module {
         key "name";
         status deprecated;
         description
           "Список модулей и связанных с ними тегов.";
         leaf name {
           type yang:yang-identifier;
           mandatory true;
           status deprecated;
           description
             "Имя модуля YANG.";
         }
         leaf-list tag {
           type tags:tag;
           status deprecated;
           description
             "Теги, связанные с модулем. Зарезервированные префиксы 
              указаны в реестре IANA YANG Module Tag Prefixes, а теги
              IETF - в реестре IANA IETF YANG Module Tags.

              Содержимое этого списка создается, как показано ниже.

              1) Системные теги (теги, добавленные системой).
              2) Заданные пользователем теги (теги, заданные в конфигурации).
              3) Все теги, соответствующие masked-tag в соответствующем
              листе ietf-module-tags:module-tags:module-tag удаляются.";
         }
       }
     }
   }
   <CODE ENDS>

Рисунок 4. Модуль состояния тегов модуля не-NMDA


Благодарности

Большое спасибо Robert Wilton за помощь в предоставлении примеров использования а также в создании модуля non-NMDA.

Адреса авторов

Christian Hopps

LabN Consulting, L.L.C.

Email: chopps@chopps.org

Lou Berger

LabN Consulting, L.L.C.

Email: lberger@labn.net

Dean Bogdanovic

Volta Networks

Email: ivandean@gmail.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

Рубрика: RFC | Комментарии к записи RFC 8819 YANG Module Tags отключены

О конфиденциальности WhatsApp

image_print

О конфиденциальности WhatsApp

PDF

Наверное каждый, кто пользовался популярным менеджером WhatsApp, обращал внимание на повторяющееся сообщение: «Сообщения защищены сквозным шифрованием. Третьи лица, включая WhatsApp, не могут прочитать или прослушать их». Если щелкнуть по ссылке в этом сообщении, вы будете направлены на сайт службы, где будет написано

 
Рисунок 1. Заявление о конфиденциальности WhatsApp.


Будучи скептиком, я решил проверить это громкое заявление. Для проверки использовались два клиента WhatsApp на мобильных устройствах GSM, связанные каждый со своим компьютером. Оба компьютера располагались в одной локальной сети Ethernet и имели адреса IP из одного блока, т. е. маршрутизации между ними не было и был возможен прямой обмен пакетами.

Из приведенного заявления о конфиденциальности можно предположить, что клиенты обменяются между собой ключами TLS и смогут напрямую взаимодействовать, используя свои ключи. Но не тут-то было и никакого прямого обмена между хостами увидеть не удалось, т. е. каждый взаимодействовал с сервером WhatsApp (в моем случае это был mmx-ds.cdn.whatsapp.net (31.13.72.52) у обоих клиентов.

Для отслеживания обмена трафиком на обоих хостах была запущена программа WireShark. Ниже на рисунках представлены отфильтрованные результаты сбора пакетов, включающие лишь обмен между клиентами и упомянутым сервером WhatsApp (фильтр отображения в WireShark). Итак, запускаем на компьютере web-клиента и WireShark для отслеживания трафика. Не обязательно выполнять какие-либо действия в web-интерфейсе, он может служить лишь для просмотра и отслеживания пакетов, а писать можно непосредственно на мобильном устройстве.

 
Рисунок 2. Обмен пакетами между клиентом и сервером WhatsApp.


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

На другом компьютере при соединении с сервером WhatsApp наблюдалась совершенно аналогичная картина, поэтому рисунок для него не включен в текст.

Пакеты на обоих хостах были собраны WireShark и можно их посмотреть. Ниже представлены пакеты отправителя (рисунок 3) и получателя (рисунок 4), соответствующие передаче одного короткого сообщения.

 
Рисунок 3. Зашифрованный пакет у отправителя.

 
Рисунок 4. Зашифрованный пакет у получателя.

На обоих рисунках приведены данные «одного» пакета, содержащего сообщение отправленное в WhatsApp с одного мобильного устройства на другое. При сквозном шифровании (клиент-клиент), анонсированном WhatsApp, данные в этих пакетах должны быть идентичными, т. е. зашифрованный отправителем текст сообщения должен совпадать с зашифрованным текстом в принятом получателем сообщении. Но не тут-то было. На приведенных рисунках очевидно, что шифрованные данные (выделены синим цветом на рисунках) не имеют между собой ничего общего, кроме размера.

Вывод очевиден — клиенты не взаимодействуют между собой напрямую, а каждый из них организует соединение TLS с сервером WhatsApp. При этом сервер расшифровывает сообщение, используя согласованный с отправителем ключ, затем снова шифрует его для получателя, используя согласованный с тем ключ. То есть говорить о конфиденциальности вашей переписки не приходится, коль скоро она подвергается расшифровке и повторному шифрованию на сервере WhatsApp. Очевидно, что никто (ничто) не препятствует перлюстрации переписки. Полагаться на приведенное выше заявление WhatsApp (принадлежит Facebook Inc.) я бы не рискнул.

Николай Малых

nmalykh@protocols.ru

Рубрика: Разное | Комментарии к записи О конфиденциальности WhatsApp отключены

RFC 8948 Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6

image_print
Internet Engineering Task Force (IETF)                     CJ. Bernardos
Request for Comments: 8948                                          UC3M
Category: Standards Track                                      A. Mourad
ISSN: 2070-1721                                             InterDigital
                                                           December 2020

Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6

Опция выбора квадранта SLAP для DHCPv6

PDF

Аннотация

Пространство 48-битовых адреса IEEE MAC1 исходно было разделено на 2 половины, одна из которых предназначена для локального использования. В 2017 г. был опубликован новый стандарт IEEE Std 802c с необязательным планом структурированных локальных адресов (Structured Local Address Plan — SLAP), задающим разный подход к распределению адресов из 4 указанных областей локального пространства MAC-адресов.

В IEEE разрабатываются протоколы для назначения адресов (IEEE P802.1CQ). В рамках IETF также ведется работа по определению новых механизмов для расширения операций DHCPv6 в части выделения локальных MAC-адресов.

Этот документ представляет расширение протоколов DHCPv6, позволяющее клиенту или ретранслятору DHCPv6 указать серверу предпочтительный квадрант SLAP, из которого могут быть назначены адреса, запрошенные клиентом или ретранслятором. Для этого определена новая опция DHCPv6 — QUAD.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF2 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG3. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8948.

Авторские права

Авторские права (Copyright (c) 2020) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

Пространство 48-битовых адресов IEEE MAC разделено так, что одна половина предназначена для локального использования (бит Universal/Local (U/L) имеет значение 1). В 2017 г. был опубликован новый стандарт IEEE [IEEEStd802c], определяющий новый необязательный план структурированных локальных адресов (SLAP), который задает разный подход к назначению адресов в 4 заданных областях локальных адресов MAC. Эти 4 области, названные квадрантами SLAP, кратко описаны ниже (см. рисунок 1 и таблицу 1).

  • В квадранте SLAP 01 с расширенным локальным идентификатором (Extended Local Identifier или ELI) MAC-адреса назначаются на основе 24-битового идентификатора компании (Company ID — CID), выделенного IEEE Registration Authority (RA). Оставшиеся биты указываются как расширение уполномоченным CID или протоколом, назначенным им.

  • В квадранте SLAP 11 со стандартным идентификатором (Standard Assigned Identifier — SAI) MAC-адреса назначаются на основе протокола, заданного стандартом IEEE 802. Для 48-битовых MAC-адресов доступно 44 бита. Для назначения SAI в стандартах IEEE может быть задано множество протоколов. Сосуществование разных протоколов может поддерживаться ограничением доступного протоколу подпространства адресов.

  • В квадранте SLAP 00 с административно назначенным идентификатором (Administratively Assigned Identifier — AAI) MAC-адреса назначаются администратором локально. Групповые пакеты IPv6 используют адреса получателей, начинающиеся с 33-33, поэтому адреса AAI из этого диапазона не следует выделять. Для 48-битовых MAC-адресов доступно 44 бита.

  • В резервном квадранте SLAP 10 адреса MAC могут назначаться с помощью новых метолов (еще не заданы) или администратором как в квадранте AAI. Для 48-битовых MAC-адресов доступно 44 бита.

LSB                MSB
M  X  Y  Z  -  -  -  -
|  |  |  |
|  |  |  +------------ SLAP бит Z
|  |  +--------------- SLAP бит Y
|  +------------------ бит X (U/L) = 1 для локальных адресов
+--------------------- бит M (I/G) (unicast/group)

LSB - Least Significant Bit (младший бит)
MSB - Most Significant Bit (старший бит)

Рисунок 1. Структура 48-битового MAC-адреса (представления IEEE).


Таблица 1. Квадранты SLAP.

Квадрант

Бит Y

Бит Z

Тип локального идентификатора

Локальный идентификатор

01

0

1

Расширенный локальный идентификатор

ELI

11

1

1

Стандартное назначение

SAI

00

0

0

Административное назначение

AAI

10

1

0

Резерв

Резерв

1.1. Постановка задачи

В IEEE разрабатываются механизмы назначения адресов [IEEE-P802.1CQ-Project]. В [RFC8947] задано новое расширение DHCPv6 для обработки назначения локальных MAC-адресов. Этот документ предлагает расширение протокла DHCPv6, позволяющее клиентам и ретрансляторам DHCPv6 указать серверу предпочтительный квадрант SLAP для назначения MAC-адресов.

Ниже описаны 2 варианта, где имеется потребность выделения локальных MAC-адресов из заданного квадранта SLAP.

1.1.1. Устройства Wi-Fi (IEEE 802.11)

Сегодня большинство устройств Wi-Fi поставляются с интерфейсами, имеющими «вшитый» MAC-адрес из универсального пространства, распределяемого с помощью 24-битовых уникальных идентификаторов организаций (Organizationally Unique Identifier — OUI), выдаваемых производителям интерфейсов IEEE 802. Однако недавно возникла потребность локального (взамен универсального) назначения MAC-адресов, вызванная указанными ниже сценариями.

  • IoT (Internet of Things — Интернет вещей) используют в основном устройства с ограниченными возможностями [RFC7228] в части питания, памяти и ресурсов обработки. Примерами служат датчики и исполнительные механизмы для здравоохранения или домашней автоматизации. Учитывая рост числа таких устройств, производители могут предпочесть установку для них временных MAC-адресов, используемых лишь при первой загрузке. Эти временные адреса служат лишь для отправки начальных пакетов DHCP доступным серверам. Устройствам IoT обычно нужен 1 MAC-адрес для каждого доступного сетевого интерфейса. После назначения сервером MAC-адреса устройство откажется от временного адреса. Устройства IoT для домашней автоматизации обычно не перемещаются (хотя следует отметить рост числа мобильных интеллектуальных устройств для охраны здоровья). Для таких устройств обычно подходит любой квадрант SLAP, но квадранты ELI и SAI в некоторых случаях будут лучше. Например, устройству может потребоваться адрес из CID, выделенного производителю коммуникационного устройства IoT, а не адрес из квадранта ELI.

  • Приватность. Сегодня MAC-адреса позволяют раскрыть местоположение пользователя, позволяя сравнительно просто отслеживать перемещение. Одним из механизмов смягчения этой проблемы является использование случайных локальных MAC-адресов, изменяемых при подключении пользователя к другой сети. В этом варианте устройства в основном мобильны и квадрант AAI может оказаться лучшим для назначения адресов, поскольку здесь проще обеспечить их случайный характер и не требуется сохранение адреса при смене сети.

1.1.2. Гипервизор — возможность перемещения функций

В больших средах виртуализации могут быть активны тысячи виртуальных машин (VM), которые обычно управляются гипервизором, запускающим и останавливающим VM при необходимости. Обычно гипервизор назначает и новые MAC-адреса для VM. Если для этого служит сервер DHCP, гипервизор выступает клиентом DHCP и запрашивает у доступных серверов DHCP назначение одного или множества (блок) MAC-адресов. Гипервизор не использует эти адреса для себя, а назначает их создаваемым VM. В современных ЦОД часто используется деление сети на области, каждая из которых назначает свои адреса. В этом варианте следует рассмотреть два случая, описанных ниже.

  • Перемещаемые функции. Если VM (обеспечивающую функцию) нужно перенести в другую область ЦОД (например, для обслуживания, обеспечения отказоустойчивости, перемещения конечного пользователя и пр.), вместе с VM нужно перенести ее сетевой контекст, включая MAC-адреса VM. Поскольку назначение адресов из квадрантов ELI/SAI подчиняется правилам IEEE Std 802c, они лучше подходят для обеспечения уникальности MAC-адресов в рамках ЦОД.

  • Неперемещаемые функции. Если VM не перемещается в другую область ЦОД, связанных с MAC-адресом требований не возникает. В этом случае проще выделять адреса из квадранта AAI, которые не обязаны быть уникальными в рамках множества ЦОД (т. е. каждая область может управлять своим назначением MAC-адресов без глобальной проверки дубликатов).

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Когда возможно, в документе используются относящиеся к задаче термины из [RFC8415]. Ниже приведены определения терминов, которые отличаются от указанного документа или введены заново.

address — адрес

Если явно не указано иное, это адрес канального уровня (MAC-адрес) [IEEEStd802] размером 6 или 8 октетов.

address block — блок адресов

Множество последовательных адресов канального уровня. Блок указывается первым адресом и числом дополнительно выделяемых адресов. Один адрес можно представить блоком из этого адреса и 0 дополнительных.

client — клиент

Узел, заинтересованный в получении адреса канального уровня. Он реализует базовые механизмы DHCP, описанные в [RFC8415], и поддерживает новые опции, заданные [RFC8947] (IA_LL и LLADDR), а также этим документом (QUAD). Клиент может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

IA_LL

Identity Association для Link-Layer Address — ассоциация отождествления (IA — identity association), используемая для запроса или назначения адресов канального уровня (параграф 11.1 [RFC8947]).

LLADDR

Опция адреса канального уровня, используемая для запроса или назначения блока адресов (параграф 11.2 [RFC8947]).

relay — ретранслятор

Узел, служащий посредником при доставке сообщений DHCP между клиентами и серверами. Ретранслятор на основе локальной информации и правил может указывать предпочтительный квадрант SLAP в передаваемой серверу опции QUAD. Ретранслятор реализует базовую фцнкциональность агента трансляции DHCPv6 [RFC8415].

server — сервер

Узел, который поддерживает назначение адресов канального уровня и способен отвечать на запросы клиентов. Узел реализует базовую функциональность сервера DHCP [RFC8415] и поддерживает новые опции, заданные [RFC8947] (IA_LL и LLADDR), а также этим документом (QUAD). Сервер может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

3. Расширения DHCPv6

3.1. Назначение адресов из квадранта SLAP, указанного клиентом

Далее описаны операции протокола для выбора клиентом предпочтительного квадранта SLAP с помощтю сигнальных процедур DHCPv6, описанных в [RFC8947] и показанных на рисунке 2.


+--------+                            +--------+
| Клиент |                            | Сервер |
| DHCPv6 |                            | DHCPv6 |
+--------+                            +--------+
    |                                      |
    +----1. Solicit(IA_LL(LLADDR,QUAD))--->|
    |                                      |
    |<--2. Advertise(IA_LL(LLADDR,QUAD))---+
    |                                      |
    +---3. Request(IA_LL(LLADDR,QUAD))---->|
    |                                      |
    |<------4. Reply(IA_LL(LLADDR))--------+
    |                                      |
    .     (завершен отсчет таймера)        .
    |                                      |
    +---5. Renew(IA_LL(LLADDR,QUAD))------>|
    |                                      |
    |<-----6. Reply(IA_LL(LLADDR))---------+
    |                                      |

Рисунок 2. Поток сигнализации DHCPv6 (клиент-сервер).

  1. Адреса канального уровня (MAC) выделяются блоками, начиная с одного. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR. Для указания предпочтительного квадранта SLAP опция IA_LL включает новую опцию OPTION_SLAP_QUAD в поле IA_LL-option (наряду с опцией LLADDR).

  2. Сервер при получении опции IA_LL в сообщении Solicit проверяет ее содержимое. Для каждой записи в OPTION_SLAP_QUAD в порядке значений поля preference (от большего к меньшему) сервер проверяет наличие настроенного пула адресов MAC, соответствующего запрошенному квадранту, и наличие доступного блока адресов запрошенного размера. Если подходящие адреса найдены, сервер передает сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предлагаемые адреса. Если у сервера есть блк адресов в указанном квадранте, должны предлагаться адреса из этого квадранта. Если соответствующих запросу клиента адресов нет у сервера, ему следует возвратить опцию IA_LL с адресами из поддерживаемого сервером квадранта (в соответствии с локальной политикой выбора квадранта). Если у сервера есть пул адресов в запрошенном квадранте, но в нем нет доступных адресов, сервер должен вернуть опцию IA_LL, где Status Code имеет значение NoAddrsAvail.

  3. Клиент ждет от доступных серверов откликов Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Клинету не следует выбирать сервер, которые не анонсировал адреса из запрошенного квадранта. Затем клиент передает сообщение Request, включающее контейнер IA_LL с опцией LLADDR, скопированной из сообщения Advertise от выбранного сервера, указав предпочтительные квадранты SLAP в новой опции QUAD IA_LL.

  4. При получении Request с контейнером IA_LL сервер назначает запрошенные адреса, при этом он может изменить выделение (например, уменьшить блок). Затем сервер создает и отправляет клиенту сообщение Reply. При получении Reply клиент анализирует контейнер IA_LL и может начинать использование назначенных ему адресов. Отметим, что клиент, включивший опцию Rapid Commit в сообщение Solicit, может получить в ответ сообщение Reply и пропустить описанные выше этапы Advertise и Request (следуя стандартным процедурам DHCPv6).

  5. Предполагается, что клиент будет периодически обновлять адреса канального уровня по таймерам T1 и T2. Этот механизм можно отключить административно путем отправки сервером «бесконечного» (infinity) значения для T1 и T2 (см. раздел 7.7 в [RFC8415]). Клиент передает опцию Renew по таймеру T1, включая предпочтительные квадранты в новую опцию QUAD IA_LL, чтобы в случае неспособности сервера расширить срок действия имеющихся адресов он знал предпочтительные квадранты для выделения других адресов.

  6. Сервер отвечает сообщением Reply с опцией IA_LL, включающей опцию LLADDR с расширенным сроком.

Клиенту следует проверять принадлежность MAC-адреса к одному из запрошенных квадрантов. Клиент может повторить процесс выбора сервера DHCP.

3.2. Назначение адресов из квадранта SLAP, указанного ретранслятором

Далее описана работа протокола по выбору предпочтительного квадранта по запросу ретранслятора с помощью сигнальных процедур DHCPv6, описанных в [RFC8947]. Это полезно при работе сервера DHCPv6 в большой инфраструктуре, разделенной на области с разными требованиями. Поток сигналов показан на рисунке 3.

  1. +--------+                  +--------+                     +--------+
    | Клиент |                  |Ретранс.|                     | Сервер |
    | DHCPv6 |                  | DHCPv6 |                     | DHCPv6 |
    +--------+                  +--------+                     +--------+
       |                            |                                |
       +-----1. Solicit(IA_LL)----->|                                |
       |                            +----2. Relay-forward            |
       |                            |    (Solicit(IA_LL),QUAD)------>|
       |                            |<---3. Relay-reply              |
       |                            |    (Advertise(IA_LL(LLADDR)))--+
       |<4. Advertise(IA_LL(LLADDR))+                                |
       |-5. Request(IA_LL(LLADDR))->|                                |
       |                            +-6. Relay-forward               |
       |                            | (Request(IA_LL(LLADDR)),QUAD)->|
       |                            |                                |
       |                            |<--7. Relay-reply               |
       |                            |   (Reply(IA_LL(LLADDR)))-------+
       |<--8. Reply(IA_LL(LLADDR))--+                                |
       |                            |                                |
       .               (завершен отсчет таймера)                     .
       |                            |                                |
       +--9. Renew(IA_LL(LLADDR))-->|                                |
       |                            |--10. Relay-forward             |
       |                            |  (Renew(IA_LL(LLADDR)),QUAD)-->|
       |                            |<---11. Relay-reply             |
       |                            |     (Reply(IA_LL(LLADDR)))-----+
       |<--12. Reply(IA_LL(LLADDR))-+                                |
       |                            |                                |

    Рисунок 3. Поток сигнализации DHCPv6 (клиент-ретранслятор-сервер).


    Адреса канального уровня (MAC) выделяются блоками, начиная с одного. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR.

  2. Ретранслятор DHCP получает сообщение Solicit и инкапсулирует его в Relay-forward. Ретранслятор на основе локальных сведений и правил включает в сообщение Relay-forward опцию QUAD с предпочтительным квадрантом. Ретранслятор может знать, какой квадрант следует запросить, из локальной конфигурации (например, обслуживаемая сеть содержит лишь устройства IoT и запрашивать следует ELI/SAI) или иных данных. Отметим, что при передаче клиентом множества опций IA_LL в одном сообщении, ретранслятор DHCP может добавить лишь один экземпляр опции QUAD.

  3. При получении ретранслированного сообщения с опцией IA_LL сервер проверяет содержимое экземпляров OPTION_SLAP_QUAD в сообщении Relay-forward и вложенном в него клиентском сообщении. В зависимости от правил сервера выбирается экземпляр опции для обработки при выборе (см. конец этот параграфа). Для каждой записи в OPTION_SLAP_QUAD в порядке значений поля (от высшего к низшему) сервер проверяет наличие настроенного пула адресов MAC, соответствующего запрошенному квадранту, и наличие доступного блока адресов запрошенного размера. Если подходящие адреса найдены, сервер передает сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предлагаемые адреса. Это сообщение передается ретранслятору в сообщении Relay-reply. Если сервер поддерживает семантику предпочтительного квадранта из опции QUAD и поддерживает блок адресов в этом квадранте, он должен предлагать адреса из запрошенного квадранта. Серверу следует применять содержимое представленной ретранслятором опции QUAD для всех клиентских IA_LL, если в конфигурации не задано иное.

  4. Ретранслятор передает клиенту полученное сообщение Advertise.

  5. Клиент ждет от доступных серверов откликов Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Затем клиент передает сообщение Request, включающее контейнер IA_LL с опцией LLADDR, скопированной из сообщения Advertise от выбранного сервера.

  6. Ретранслятор пересылает полученное сообщение Request в сообщении Relay-forward, доавляя опцию QUAD IA_LL с предпочитаемым квадрантом.

  7. При получении пересланного сообщения Request с контейнером IA_LL сервер назначает запрошенные адреса, которые он может изменить. Затем сервер создает и передает сообщение Reply ретранслятору в Relay-reply.

  8. При получении сообщения Reply клиент разбирает контейнер IA_LL и может начать использование адресов.

  9. Предполагается, что клиент будет периодически обновлять адреса канального уровня по таймерам T1 и T2. Этот механизм можно отключить административно путем отправки сервером «бесконечного» (infinity) значения для T1 и T2 (см. раздел 7.7 в [RFC8415]). Клиент передает опцию Renew по таймеру T1.

  10. Это сообщение пересылается ретранслятором в сообщении Relay-forward с опцией QUAD IA_LL, указывающей предпочтительный квадрант.

  11. Сервер отвечает сообщением Reply с опцией IA_LL, включающей опцию LLADDR с расширенным сроком, которое передается в сообщении Relay-reply.

  12. Ретранслятор передает сообщение Reply клиенту.

Серверу следует реализовать конфигурационный параметр для обработки случаев, конда клинетское сообщение DHCP содержит экземпляр OPTION_SLAP_QUAD а ретранслятор добавляет второй экземпляр в своем сообщении Relay-forward. Этот параметр настраивает сервер на обработку одного из экземпляров QUAD. Рекомендуется по умолчанию обрабатывать опцию их запроса клиента.

Клиент может проверить принадлежность полученного MAC-адреса к желаемому квадранту и принять на основе этой проверки решение об использовании или настройке полученного адреса.

4. Определение опции DHCPv6

4.1. Опция QUAD

Опция QUAD служит для задания предпочтений при выборе квадрантов в опции IA_LL. Опция должна инкапсулироваться в поле IA_LL-options опции IA_LL или в сообщение Relay-forward. Формат QUAD показана на рисунке 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_SLAP_QUAD        |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   quadrant-1  |    pref-1     |   quadrant-2  |    pref-2     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  quadrant-n-1 |   pref-n-1    |   quadrant-n  |    pref-n     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат опции QUAD.


option-code

OPTION_SLAP_QUAD (140).

option-len

Удвоенное число пар (quadrant, preference). Это 2-байтовое поле указывает общий размер всех пар (quadrant, preference), включенных в опцию.

quadrant-n

Идентификатор квадранта (0- AAI, 1 — ELI, 2 — резерв IEEE [IEEEStd802c], 3 — SAI). Каждый квадрант должен включаться в опцию не более 1 раза. Поле имеет размер 1 байт.

pref-n

Предпочтение для quadrant-n (большее значение для большего приоритета). Поле имеет размер 1 байт.

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

Если для нескольких квадрантов указано одинаковое предпочтение, сервер может выбрать квадрант (при условии наличия адресов в нескольких квадрантах с одинаковым предпочтением). assign addresses from all or some of the quadrants with the same assigned preference). Отметим, что это не просто список квадрантов, упорядоченных по предпочтению, а список с явными значениями предпочтения. Таким образом, может поддерживаться случай, когда у клиента действительно нет предпочтения среди двух или трех квадрантов и он отдает решение серверу.

Если клиент или ретранслятор задает OPTION_SLAP_QUAD, сервер должен использовать значения quadrant-n/pref-n для упорядочения выбора квадрантов. Если сервер может предоставить адреса в одном из указанных квадрантов, ему следует выполнить это назначение. Если у сервера нет пула адресов, соответствующего какому-либо из указанных значений quadrant-n, или есть пул в нужном квадранте, но в нем нет доступных адресов, сервер должен вернуть опцию IA_LL со статусом NoAddrsAvail.

От клиента и ретранслятора не требуется упорядочивать значения quadrant/pref определенным образом, поэтому серверу недопустимо предполагать, что quadrant-1/pref-1 имеет высший приоритет (кроме случая, когда есть лишь один набор значений).

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

5. Взаимодействие с IANA

Агентство IANA выделило код опции QUAD (140) из субреестра Option Codes в реестре Dynamic Host Configuration Protocol for IPv6 (DHCPv6), доступном по ссылке http://www.iana.org/assignments/dhcpv6-parameters.

   Value:  140
   Description:  OPTION_SLAP_QUAD
   Client ORO:  No
   Singleton Option:  Yes
   Reference:  RFC 8948

6. Вопросы безопасности

Вопросы безопасности и конфиденциальности DHCPv6 рассмотрены в [RFC8415] и [RFC7227], а безопасность IPv6 — в [RFC8200].

Вопросы безопасности назначения адресов канального уровня с помощью DHCP рассмотрены в [RFC8947].

7. Литература

7.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC8947] Volz, B., Mrugalski, T., and CJ. Bernardos, «Link-Layer Address Assignment Mechanism for DHCPv6», RFC 8947, DOI 10.17487/RFC8947, December 2020, <https://www.rfc-editor.org/info/rfc8947>.

7.2. Дополнительная литература

[IEEE-P802.1CQ-Project] IEEE, «P802.1CQ — Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment», <https://standards.ieee.org/project/802_1CQ.html>.

[IEEEStd802] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture», IEEE Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.

[IEEEStd802c] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture — Amendment 2: Local Medium Access Control (MAC) Address Usage», IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, <https://doi.org/10.1109/IEEESTD.2017.8016709>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, «Guidelines for Creating New DHCPv6 Options», BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, «Terminology for Constrained-Node Networks», RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. Sehgal, «Management of Networks with Constrained Devices: Use Cases», RFC 7548, DOI 10.17487/RFC7548, May 2015, <https://www.rfc-editor.org/info/rfc7548>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

Приложение A. Пример использования механизма выбора квадранта

В этом приложении рассмотрены некоторые примеры использования механизмов предпочтения квадрантов.

В качестве первого примера рассмотрим вариант IoT. Устройство IoT может самостоятельно выбрать квадрант SLAP для использования локального MAC-адреса, используя для выбора приведенные ниже сведения.

  • Тип развертывания IoT, например, промышленное, домашнее, сельское и т. п. Для небольших систем, например, в доме, устройство IoT может само выбрать квадрант AAI (это возможно даже без DHCP путем выбора случайного адреса самим устройством). Для больших систем, таких как промышленные, где могут быть тысячи устройств, могут использоваться квадранты ELI или SAI.

  • Мобильность. Если устройство IoT может перемещаться, оно может предпочесть выбор квадрантов SAI или AAI для минимизации адресных конфликтов при перемещении между сетями. Если устройство знает, что оно не будет перемещаться, лучшим решением может оказаться квадрант ELI.

  • Управляемость. В зависимости от того, управляется ли устройство IoT в течение своего срока действия или его конфигурацию нельзя изменить [RFC7548], решение о выборе подходящего квадранта может меняться. Например, если устройство IoT может управляться (например, настраиваться) и топология сети может меняться в течение срока службы (например, в результате изменения системы при добавлении устройств), это может влиять на выбор предпочтительного квадранта (например, для предотвращения будущих конфликтов).

  • Срок работы от батареи. В зависимости от возможной продолжительности работы устройства предпочтительный квадрант может изменяться (например, для минимизации возможных конфликтов).

Предыдущие параметры служат аспектами, которые производитель или администратор могут учитывать при выборе правил запроса MAC-адресов устройствами IoT (выбор квадранта SLAP). Устройства IoT обычно очень ограничены в ресурсах, поэтому в них может применяться лишь очень простой процесс выбора на основе заданных предпочтений.

Далее рассматривается вариант Wi-Fi с учетом, например, подключения ноутбука или смартфона к сети с использованием встроенного MAC-адреса. Из соображений конфиденциальности и безопасности устройство может пожелать использовать локальный MAC-адрес. При этом для устройства можно использовать разные параметры и данные контекста — квадрант SLAP для назначения локального MAC-адреса, условия смены адреса (например, может потребоваться неоднократная смена). Эта информация может включать перечисленные ниже аспекты, а также иное.

  • Тип сети, к которой подключается устройство — общественная, рабочая, домашняя.

  • Является ли сеть доверенной.

  • Является ли подключение к сети первым.

  • Местоположение сети.

  • Мобильность, т. е. возможность смены точки подключения устройства к сети.

  • Сетевой профиль операционной системы (OS), включая параметры безопасности и доверия. Многие современные OS хранят метаданные, связанные с сетями, к которым устройство может подключаться, например, уровень доверия, заданный для сети пользователем или администратором. Эта информация служит для настройки повердения устройства в плане анонсирования себя в сети, настройки межсетевого экранирования и т. п. Но эта информация может также служить для решения вопроса об использовании локального MAC-адреса, выборе для него квадранта SLAP и частоте назначения такого адреса.

  • Триггеры приложений, связанные с конфиденциальностью местоположения. Приложение может запросить у OS максимальную конфиденциальность местоположения (в силу прилоды этого приложения), а это может потребовать от OS использования или смены локального MAC-адреса.

Эта информация может служить устройству для выбора квадранта SLAP. Например, если устройство перемещается (скажем в общественной сети аэропорта), вполне вероятна смена точки доступа, поэтому разумно минимизировать вероятность конфликта адресов, выбрав квадрант SAI или AAI. Если устройство подключено к доверенной сети и его перемещение не предполагается (например, на работе), лучшим решением может оказаться квадрант ELI. Это лишь несколько примеров использования указанной выше информации при выборе квадранта.

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

В варианте ЦОД гипервизор может запросить выделение локальных MAC-адресов для виртуальных машин. Как и в описанных раньше вариантах, гипервизор может выбрать предпочтительный квадрант SLAP, используя данные системы управления облаком или менеджера виртуальной инфраструктуры. Примеры таких данных приведены ниже.

  • Перемещаемость VM. Возможность переноса функции, реализуемой VM, на другой физический сервер может влиять на выбор предпочтительного квадрант SLAP, поскольку квадранты ELI и SAI лучше подходят для поддержки переноса в крупных ЦОД.

  • Характеристики связности VM. Например, этом может быть автономная машина, часть пула или часть цепочки услуг. Если характеристики связности VM известны, гипервизор может использовать их при выборе квадранта SLAP.

Благодарности

Авторы благодарят Bernie Volz за полезные замечания к документу. Спасибо также Ian Farrer, Tomek Mrugalski, Éric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba, Alvaro Retana, Murray Kucherawy за подробные и полезные рецензии. Спасибо Roger Marks и Antonio de la Oliva за комментарии, связанные с работой IEEE, и ссылки.

Разработка этого документа поддержана проектами H2020 5GROWTH (Grant 856709) и 5G-DIVE (Grant 859881).

Адреса авторов

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

28911 Leganes, Madrid

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

Alain Mourad

InterDigital Europe

Email: Alain.Mourad@InterDigital.com

URI: http://www.InterDigital.com/

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Media Access Control — управление доступом к среде.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

Рубрика: RFC | Комментарии к записи RFC 8948 Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 отключены

RFC 8947 Link-Layer Address Assignment Mechanism for DHCPv6

image_print
Internet Engineering Task Force (IETF)                           B. Volz
Request for Comments: 8947                                         Cisco
Category: Standards Track                                   T. Mrugalski
ISSN: 2070-1721                                                      ISC
                                                           CJ. Bernardos
                                                                    UC3M
                                                           December 2020

Link-Layer Address Assignment Mechanism for DHCPv6

Механизм назначения адресов канального уровня для DHCPv6

PDF

Аннотация

В некоторых средах, например, в больших системах с виртуализацией, новые устройства создаются автоматически и адреса канального уровня могут устанавливаться для них автоматизированным способом. В больших системах при случайном распределении адресов могут возникать совершенно неприемлемые конфликты адресов, поэтому требуется механизм контролируемого назначения. В этом документе предложено расширение DHCPv6, которое позволяет создать расширяемую системы назначения адресов канального уровня с исключением недопустимых (например, выделенных производителям оборудования) или нежелательных адресов.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8947.

Авторские права

Авторские права (Copyright (c) 2020) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

Имеется несколько типов развертывания, где нужно инициализировать большое число устройств. Одним из них являются системы с большим числом создаваемых виртуальных машин (VM). Обычно новым экземплярам VM назначаются адреса канального уровня, но случайное назначение не обеспечивает нужной расширяемости в силу риска совпадения адресов (см. Приложение A.1 к [RFC4429]). Другой вариант связан с устройствами «Интернета вещей» (Internet of Things или IoT) [RFC7228]. Огромное число таких устройств может исчерпать глобальное пространство адресов IEEE OUI3. Хотя глобальная уникальность таких адресов обычно не требуется, нужно предотвращать конфликты адресов в рамках административного домена. Поэтому желательно иметь тот или иной механизм, который обеспечит в локальном масштабе уникальность адресов MAC4.

В этом документе предложен новый механизм расширяющий DHCPv6 для распределения адресов канального уровня.

Поскольку протокол DHCPv6 [RFC8415] может распределять различные типы ресурсов (временные и постоянные адреса, префиксы и пр.) и имеет требуемую инфраструктуру для поддержки такого назначения (множество реализаций клиентов и серверов, инфраструктура развернутых ретрансляторов и вспомогательные решения, такие как как запрос аренды и аварийное переключение), он является подходящим кандидатом для решения задачи.

Хотя в документе описано решение, применимое к любому типу адресов канального уровня, некоторые детали связаны с 48-битовыми MAC-адресами IEEE 802 [IEEEStd802]. Документы для иных адресов могут быть созданы в будущем.

Комитет IEEE 802 изначально выделил половину пространства 48-битовых адресов MAC для локального применения (бит U/L5 имеет значение 1). В 2017 г. IEEE была опубликована поправка [IEEEStd802c], разделяющая пространство адресов на квадранты с разными правилами, которые описаны в Приложении A.

В IEEE также разрабатываются протоколы и процедуры для назначения уникальных в локальном масштабе адресов (IEEE 802.1CQ). Эта работа может обеспечить дополнительный вариант назначения адресов. Дополнительную информацию можно найти в [IEEE-P802.1CQ-Project].

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Терминология

В документе используются относящиеся к задаче термины DHCP из [RFC8415]. Ниже приведены определения терминов, которые отличаются от указанного документа или введены заново.

address — адрес

Если явно не указано иное, это адрес канального уровня (MAC-адрес) [IEEEStd802]. Обычно адрес имеет размер 6 октетов, но иногда применяются другие размеры.

address block — блок адресов

Множество последовательных адресов канального уровня. Блок указывается первым адресом и числом дополнительно выделяемых адресов. Один адрес можно представить блоком из этого адреса и 0 дополнительных.

client — клиент

Узел, заинтересованный в получении адреса канального уровня. Он реализует базовые механизмы DHCP, описанные в [RFC8415], и поддерживает новые опции, заданные этим документом (IA_LL и LLADDR). Клиент может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

IA_LL

Identity Association для Link-Layer Address — ассоциация отождествления (IA — identity association), используемая для запроса или назначения адресов канального уровня (параграф 11.1).

LLADDR

Опция адреса канального уровня, используемая для запроса или назначения блока адресов (параграф 11.2).

server — сервер

Узел, который поддерживает назначение адресов канального уровня и способен отвечать на запросы клиентов. Узел реализует базовую функциональность сервера DHCP [RFC8415] и поддерживает новые опции, заданные этим документом (IA_LL и LLADDR). Сервер может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

4. Варианты развертывания

Механизм предназначен на роль базового и приемлемого в разных системах, но имеется два основных варианта, где механизм пытается решить задачу назначения адресов — (i) режим прокси-клиента (proxy client) и (ii) режим прямого клиента (direct client).

4.1. Режим прокси-клиента

Этот режим применяется в тех случаях, когда выступающий клиентом DHCP элемент запрашивает у доступных серверов DHCP один или множество (блок) адресов для последующего распределения конечным устройствам. Большие системы с виртуализацией являются примером использования прокси-клиентов. В таких средах запрашивающий адреса элемент часто называется гипервизором и он зачастую нужен для создания новых VM, которым гипервизор должен назначать новые адреса. Гипервизор сам не использует полученные адреса, а распределяет их создаваемым VM. Следует отметить кумулятивных характер этого режима — гипервизор скорей всего будет позднее запрашивать дополнительные адреса. Адреса удаленных VM могут применяться для новых.

4.2. Режим прямого клиента

Этот режим применяется в тех случаях, когда выступающий клиентом DHCP элемент запрашивает у доступных серверов DHCP один или множество (блок) адресов для своих нужд. Этот вариант связан с IoT (раздел 1). При первой загрузке устройство использует для каждого интерфейса временный адрес, как описано в [IEEEStd802.11] и IEEE 802.1CQ [IEEE-P802.1CQ-Project], для отправки начальных пакетов DHCP доступным серверам DHCP, у которых клиент запрашивает 1 адрес для данного интерфейса. После получения такого адреса устройство отбрасывает (забывает) временный адрес и пользуется полученным (арендованным).

Отметим, что работающий в соответствии с приведенным описанием клиент не имеет глобально уникального адреса ни на одном из своих интерфейсов и ему недопустимо применять основанный на канальном уровне идентификатор DUID (DHCP Unique Identifier), описанный в разделе 11 [RFC8415]).

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

5. Обзор механизма

В описанных в разделе 4 вариантах протокол работает в основном одинаково. Устройство, запрашивающее адрес, действуя в качестве клиента DHCP, передает сообщение Solicit с опцией IA_LL всем доступным серверам DHCP. Эта опция IA_LL должна включать опцию LLADDR, указывающую link-layer-type и link-layer-len, а также может задавать желаемый адрес или блок в качестве совета серверу. Каждый из доступных серверов отвечает сообщением Reply с подтвержденными адресами (если было запрошено и выполнено Rapid Commit) или сообщением Advertise с предложенными адресами. Клиент выбирает отклик в соответствии с [RFC8415]. При необходимости клиент передает сообщение Request, по которому сервер назначит адреса и передаст их в сообщении Reply. После приема сообщения Reply клиент может начать использование полученных адресов.

Используются обычные механизмы DHCP. Предполагается, что клиент периодически обновляет адреса в соответствии с таймерами T1 и T2 и прекращает использовать адрес по истечении срока его действия. Обновление может быть запрещено сервером административно путем установки бесконечного значения (infinity) для таймеров T1 и T2 (см. параграф 7.7 в [RFC8415]). Администратор может сделать выделенные адреса постоянными, указав бесконечный (infinity) срок действия, как указано в параграфе 7.7 [RFC8415].

Клиент может освободить адреса, когда они не нужны, передав сообщение Release (см. параграф 18.2.7 в [RFC8415]).

На рисунке 9 в [RFC8415] показана временная диаграмма обмена сообщениями между клиентом и двумя серверами для типичного срока действия одной или нескольких аренд.

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

Использующим этот механизм клиентам следует задавать опцию Rapid Commit, как указано в параграфах 5.1 и 18.2.1 [RFC8415], для получения адресов в результате обмена лишь двумя сообщениями, когда это возможно.

Устройства, поддерживающие это предложение, могут поддерживать также механизм реконфигурации, описанный в параграфе 18.2.11 [RFC8415]. Если механизм реконфигурации поддерживается клиентом и сервером, он позволяет администратору своевременно уведомлять клиентов об изменении конфигурации и инициировать незамедлительное получение соответствующих изменений, не ожидая таймера T1. Поскольку для этого механизма нужна реализация протокола Reconfiguration Key Authentication (раздел 20.4 в [RFC8415]), мелкие устройства могут не поддерживать его.

6. Допущения

Одним из важных свойств механизма является его кумулятивная природа, особенно при работе с гипервизором. Отношения «клиент-сервер» не похожи на другие транзакции DHCP в сценарии с гипервизором. В типичной среде будет использоваться один сервер и небольшое (возможно 1) число гипервизоров. Однако с течением времени число запрашиваемых гипервизором адресов будет расти по мере создания VM.

Другим аспектом, важным для эффективного проектирования, является то, что один клиент-гипервизор вероятно будет использовать тысячи адресов. Подход, аналогичный применяемому при назначении адресов или префиксов IPv6 (контейнер IA со списком назначенных адресов, по одной записи на адрес), здесь работать не будет. Поэтому механизм должен работать не с отдельными адресами, а с их блоками. При этом отдельный адрес считается просто блоком с одним адресом.

Механизмы DHCP часто применяются многократно, в частности, используются одинаковые форматы сообщений и опций, механизмы передачи, инфраструктура ретрансляторов и пр. Однако устройствам, желающим лишь распределять адреса канального уровня, не обязательно полностью поддерживать DHCP. Иными словами, устройство может выделять лишь адреса канального уровня, не поддерживая назначение адресов или префиксов IPv6.

7. Представление информации

Клиент должен передавать опцию LLADDR, инкапсулированную в опцию IA_LL, для задания значений link-layer-type и link-layer-len. Для link-layer-type 1 (Ethernet) и 6 (IEEE 802 Networks) клиент устанавливает поле link-layer-address как показано ниже.

  1. Все 0, если клиент не указывает начального адреса блока индивидуальных адресов. В таких адресах бит IEEE 802 individual/group имеет значение 0 (индивидуальный).

  2. Любое другое значение указывате начальный адрес запрашиваемого блока.

Представление других link-layer-type может быть добавлено в новых RFC.

Клиент указывает в поле extra-addresses значение 0 (один адрес) или размер запрашиваемого блока минус 1.

Клиент должен установить valid-lifetime = 0 (сервер должен игнорировать это поле).

8. Запрос адреса

Адреса выделяются блоками с минимальным размером 1. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR, как указано в разделе 7.

Сервер при получении опции IA_LL проверяет ее содержимое и может предложить адрес или адреса для каждой опции LLADDR в соответствии со своими правилами. Сервер может учитывать блок адресов, запрошенный клиентом в опции LLADDR. Однако сервер может игнорировать все или часть параметров, запрошенного блока адресов. В частности, сервер может выделить другой начальный адрес или меньшее число адресов в блоке. Сервер передает в ответ сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предложенные адреса. Если сервер не способен выделить адреса, он должен передать опцию IA_LL с опцией Status Code (см. параграф 21.13 в [RFC8415]), указывающей NoAddrsAvail.

Отметим, что сервер, не поддерживающий опцию IA_LL, будет игнорировать ее и не будет возвращать сообщение Advertise (и Reply). Передающий опции IA_LL клиент должен рассматривать это как возврат сервером статуса NoAddrsAvail для этих опций IA_LL.

Клиент ждет от доступных серверов отклики Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Затем клиент передает сообщение Request с контейнером IA_LL, содержащим опцию LLADDR, скопированную из сообщения Advertise от выбранного сервера.

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

При получении сообщения Request с контейнером опции IA_LL сервер выделяет запрошенные адреса в соответствии с настроенными на нем правилами. Сервер может выделить другой (или меньший) блок, нежели указано в сообщении Request. Затем сервер создает и отправляет клиенту сообщение Reply.

При получении сообщения Reply клиент анализирует контейнер опции IA_LL и может начать использование предоставленных адресов. Клиент должен заново запустить таймеры T1 и T2, используя значения из опции IA_LL.

Клиент должен использовать блоки адресов из сообщения Reply, которые могут быть меньше запрошенных или просто другими.

Клиент, включивший опцию Rapid Commit в сообщение Solicit, может получить ответное сообщение Reply и пропустить описанные выше этапы с сообщениями Advertise и Request (см. параграф 18.2.1 в [RFC8415]).

Клиенту, меняющему адрес канального уровня на своем интерфейсе, следует выполнять рекомендации параграфа 7.2.6 [RFC4861] для быстрого информирования своих соседей о новом адресе канального уровня.

9. Обновление адреса

Обновление адресов выполняется по обычной процедуре DHCP, описанной в параграфе 18.2.4 [RFC8415]. По завершении времени T1 клиент начинает отправку сообщений Renew с опцией IA_LL, содержащей опцию LLADDR для обновляемого блока адресов. Сервер отвечает сообщением Reply с обновленным блоком адресов. Серверу недопустимо сокращать или расширять блок адресов. Когда блок адресов назначен и имеет ненулевой срок действия, его размер, начальный и конечный адрес менять недопустимо.

Если запрашивающему клиенту нужны дополнительные адреса (например, гипервизору нужны адреса для новых VM), он должен отправить опцию IA_LL с другим идентификатором отождествления (IAID — Identity Association IDentifier) для создания другого «контейнера» с дополнительными адресами.

Если клиент не способен обновить адреса к моменту T2, он начинает передачу сообщений Rebind, как описано в параграфе 18.2.5 [RFC8415].

10. Освобождение адреса

Клиент может принять решение об освобождении выделенных ему адресов. Клиент должен освобождать выделенный блок целиком. Для освобождения блока клиент передает сообщение Release с опцией IA_LL, содержащей опцию LLADDR для освобождаемого блока адресов. Механизм передачи Release описан в параграфе 18.2.7 [RFC8415].

Отметим, что клиент, освобождающий свой адрес канального уровня, должен прекратить его использование до отправки сообщения Release (как указано в [RFC8415]) и для отправки сообщения Release клиент должен использовать иной адрес (например, тот, который применялся при инициировании DHCPv6 для получения выделенного адреса канального уровня).

11. Определения опций

В этом механизме используется подход, похожий на имеющиеся механизмы DHCP. Имеется контейнерная опция IA_LL с фактическими адресами в опциях LLADDR. Каждая опция LLADDR представляет блок адресов, который указывается начальным адресом и числом адресов.

11.1. Опция IA_LL

Опция IA_LL (Identity Association for Link-Layer Addresses6) служит для передачи параметров и адресных блоков, связанных с IA_LL. Формат опции показан на рисунке 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          OPTION_IA_LL         |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        IAID (4 октета)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          T1 (4 октета)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          T2 (4 октета)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                         IA_LL-options                         .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Формат опции IA_LL.


option-code

OPTION_IA_LL (138).

option-len

12 + размер поля IA_LL-options.

IAID

Уникальный идентификатор для данной опции IA_LL. Значение IAID должно быть уникальным среди всех IA_LL этого клиента. Пространство номеров для IA_LL IAID отделено от пространства номеров других типов опций IA (IA_NA, IA_TA и IA_PD). Выражается 4-октетным целым числом без знака.

T1

Временной интервал, по истечении которого клиенту следует контактировать с сервером, предоставившим адреса в IA_LL, для расширения срока их действия. T1 указывается в секундах относительно текущего времени 4-октетным целым числом без знака.

T2

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

IA_LL-options

Опции, связанные с данной опцией IA_LL. Поле имеет переменный размер (на 12 меньше значения option-len).

Опция IA_LL может указыватьмя лишь в области опций сообщения DHCP. Можно включать в сообщение DHCP несколько опций IA_LL, каждая из которых должна иметь уникальное значение IAID.

Статус операций, связанных с этой опцией IA_LL, указывается в опции Status Code (раздел 21.13 в [RFC8415]) поля IA_LL-options.

Отметим, что IA_LL не имеет явного срока действия (lifetime или lease length). Когда истекает срок действия всех адресов в IA_LL, можно считать IA_LL просроченной. Параметры T1 и T2 дают серверам явный контроль над повторными контактами клиента с сервером для конкретной опции IA_LL. В сообщении от клиента поля T1 и T2 должны иметь значение 0. Сервер должен игнорировать значения этих полей в сообщениях от клиентов. Клиент должен использовать значения полей T1 и T2 из сообщения от сервера для таймеров T1 и T2, если эти значения отличны от 0. Поля T1 и T2 указывают значения одноименных таймеров в секундах. В соответствии с разделом 7.7 [RFC8415], значение 0xffffffff указывает «бесконечный» (infinity) срок действия и должно применяться с осторожностью.

Сервер выбирает значения T1 и T2, чтобы позволить клиенту расширить срок действия блоков адресов в IA_LL, даже если сервер недоступен в течение короткого промежутка времени. Для T1 и T2 рекомендуются значения 0,5 и 0,8 от кратчайшего срока действия блока адресов в IA, который сервер желает продлить. Если «кратчайший» срок действия задан значением 0xffffffff (неограничен), для T1 и T2 также рекомендуется значение 0xffffffff. Если выбор времени обновления адресов в IA_LL следует оставить за клиентом, сервер устанавливает в T1 и T2 значение 0. Клиент должен следовать правилам, указанным в параграфе 14.2 [RFC8415].

Если клиент получает IA_LL с T1 > T2 > 0, он отбрасывает опцию IA_LL и обрабатывает остальное сообщение как будто в нем нет опции IA_LL.

Поле IA_LL-options обычно включает одну или множество опций LLADDR (см. раздел 11.2). Если клиент не включил опцию LLADDR в сообщение Solicit или Request, сервер должен считать это запросом одного адреса без рекомендованного клиентом значения.

11.2. Опция LLADDR

Опция адресов канального уровня (LLADDR — Link-Layer Addresses) служит для указания блока адресов, связанного с IA_LL. Опция должна инкапсулироваться в поле IA_LL-options опции IA_LL, включающее опции, относящиеся к данному блоку адресов. Формат опции показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        OPTION_LLADDR          |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       link-layer-type         |        link-layer-len         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                     link-layer-address                        .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      extra-addresses                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      valid-lifetime                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                      LLaddr-options                           .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат опции LLADDR.


option-code

OPTION_LLADDR (139).

option-len

12 + значение поля link-layer-len + размер поля LLaddr-options. В предположении 6-битовых значений link-layer-address и отсутствия дополнительных опций поле option-len будет иметь значение 18.

link-layer-type

Поле link-layer-type должно указывать действительный тип оборудования, выделенный IANA, как описано в [RFC5494], и включенный в реестр Hardware Types, доступный по ссылке https://www.iana.org/assignments/arp-parameters. Значение является 2-октетным целым числом без знака.

link-layer-len

Задает размер поля link-layer-address в октетах (обычно 6 для link-layer-type = 1 (Ethernet) и 6 (IEEE 802 Networks)). Это поле включено с учетом канальных уровней, которые могут использовать адреса переменного размера. Значение является 2-октетным целым числом без знака.

link-layer-address

Задает первый адрес канального уровня, который запрашивается или выделяется (в зависимости от сообщения). Клиент может передать специальное значение для запроса любого адреса. Для link-layer-type 1 и 6 подробности приведены в разделе 7. Поле имеет размер link-layer-len.

extra-addresses

Задает число дополнительных адресов, следующих за указанным полем link-layer-address. Для выделения одного адреса используется значение 0. Например, при указании link-layer-address 02:04:06:08:0a и extra-addresses 3 будет назначаться 4 адреса, начиная с 02:04:06:08:0a и заканчивая 02:04:06:08:0d (включительно). Значение является 4-октетным целым числом без знака.

valid-lifetime

Действительный срок действия для адресов в опции, указанный в секундах. Значение является 4-октетным целым числом без знака.

LLaddr-options

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

В сообщении от клиента поле valid-lifetime должно иметь значение 0, сервер должен игнорировать значение поля.

Клиент должен использовать значение valid-lifetime из сообщения от сервера для установки срока действия блока адресов. Поле задает число секунд, в течение которого адреса блока будут действительны.

В соответствии с разделом 7.7 [RFC8415] valid-lifetime со значением 0xffffffff задает неограниченный срок действия адресов (infinity) и следует использовать это значение с осторожностью.

В опцию IA_LL можно включать более одной опции LLADDR.

12. Выбор адресов канального уровня для назначения IA_LL

Сервер выбирает адреса канального уровня для IA_LL в соответствии с правилами, заданными администратором и требованиями к пространству адресов.

Адреса канального уровня обычно зависят от типа соединения и серверу следует выполнять процедуры раздела 13.1 в [RFC8415] для определения типа клиентского канала.

Для адресов IEEE 802 MAC ([IEEEStd802] с дополнением [IEEEStd802c]) процедура выбора описана ниже.

  1. Администратору сервера следует соблюдать спецификации IEEE 802 в части пулов индивидуальных адресов, доступных для назначения (см. Приложение A и [IEEEStd802c]). Распределять можно лишь адресное пространство, выделенное для локального использования, или при наличии полномочий назначать иные адреса.

  2. Для серверов недопустимо позволять администратору настраивать пул адресов, который будет пересекать границу 242 битов (для 48-битовых адресов MAC), чтобы предотвратить проблемы при изменении первого октета адреса и специальных битов в нем (Приложение A). Клиенты должны отвергать назначения, в которых блок пересекает эту границу (клиент должен отвергать назначение, см. параграф 18.2.8 в [RFC8415]).

  3. Сервер может использовать опции, представленные ретранслятором или клиентом, для выбора квадранта (Приложение A), из которого будут назначаться адреса. Это могут быть опции из [RFC8948].

13. Взаимодействие с IANA

Агентство IANA выделило код опции OPTION_IA_LL (138) из субреестра Option Codes в реестре Dynamic Host Configuration Protocol for IPv6 (DHCPv6), доступном по ссылке http://www.iana.org/assignments/dhcpv6-parameters.

   Value:        138
   Description:  OPTION_IA_LL
   Client ORO:   No
   Singleton Option:  No
   Reference:    RFC 8947

Агентство IANA выделило код опции OPTION_LLADDR (139) из субреестра Option Codes в реестре Dynamic Host Configuration Protocol for IPv6 (DHCPv6), доступном по ссылке http://www.iana.org/assignments/dhcpv6-parameters.

   Value:        139
   Description:  OPTION_LLADDR
   Client ORO:   No
   Singleton Option:  No
   Reference:    RFC 8947

14. Вопросы безопасности

Вопросы безопасности DHCP рассмотрены в разделе 22 [RFC8415] и разделе 23 [RFC7227], для IPv6 -в [RFC8200].

В разделе 22 [RFC8415] отмечено:

В DHCP отсутствует сквозное шифрование между клиентами и серверами, что открывает возможность для атак с захватом, подменой и прослушиванием трафика.

В некоторых средах можно обеспечить защиту на основе рекомендаций раздела 22 в [RFC8415].

Если не все узлы на канале используют этот механизм для получения адресов из пространства, выделенного серверу DHCP, возможно назначение одного адреса канального уровня нескольким устройствам. Отметим, что эта проблема будет присутствовать в таких сетях даже без использования DHCP для получения адресов.

Реализациям серверов следует рассмотреть использование опции конфигурации для ограничения числа выделяемых клиенту адресов (в одном запросе и в целом). Однако следует отметить, что это не помешает злоумышленнику притвориться разными клиентами для запроса всех доступных адресов.

15. Вопросы конфиденциальности

Вопросы конфиденциальности DHCP рассмотрены в разделе 23 [RFC8415].

Для клиента, запрашивающего адрес канального уровня напрямую у сервера, выделенный адрес скорей всего будет использован клиентом на этом канале и раскроется тем, кто может прослушивать канал. Партнеры по каналу, способные прослушивать обмен DHCP, могут также сопоставить выделенный адрес с отождествлением клиента (на основе DUID). Для повышения уровня анонимности могут применяться механизмы, подобные описанным в [RFC7844], которые минимизируют раскрытие информации.

Как отмечено в разделе 23 [RFC8415], серверам DHCP и гипервизорам может потребоваться учитывать влияние последовательного выделения адресов. Хотя в общем случае относится лишь к локальным соединениям в отличие от назначения адресов и префиксов IPv6, которые могут использоваться для коммуникаций через Internet.

16. Литература

16.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

16.2. Дополнительная литература

[IEEE-P802.1CQ-Project] IEEE, «P802.1CQ — Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment», <https://standards.ieee.org/project/802_1CQ.html>.

[IEEEStd802] IEEE, «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, IEEE Std 802», IEEE STD 802-2014, DOI 10.1109/IEEESTD.2014.6847097, <https://doi.org/10.1109/IEEESTD.2014.6847097>.

[IEEEStd802.11] IEEE, «IEEE Standard for Information technology—Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements — Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», IEEE Std 802.11, DOI 10.1109/IEEESTD.2016.7786995, <https://doi.org/10.1109/IEEESTD.2016.7786995>.

[IEEEStd802c] IEEE, «IEEE Standard for Local and Metropolitan Area Networks:Overview and Architecture—Amendment 2: Local Medium Access Control (MAC) Address Usage», IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, <https://doi.org/10.1109/IEEESTD.2017.8016709>.

[RFC2464] Crawford, M., «Transmission of IPv6 Packets over Ethernet Networks», RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.

[RFC4429] Moore, N., «Optimistic Duplicate Address Detection (DAD) for IPv6», RFC 4429, DOI 10.17487/RFC4429, April 2006, <https://www.rfc-editor.org/info/rfc4429>.

[RFC5494] Arkko, J. and C. Pignataro, «IANA Allocation Guidelines for the Address Resolution Protocol (ARP)», RFC 5494, DOI 10.17487/RFC5494, April 2009, <https://www.rfc-editor.org/info/rfc5494>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, «Guidelines for Creating New DHCPv6 Options», BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, «Terminology for Constrained-Node Networks», RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, «Anonymity Profiles for DHCP Clients», RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.

[RFC8200] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8948] Bernardos, CJ. and A. Mourad, «Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6», RFC 8948, DOI 10.17487/RFC8948, December 2020, <https://www.rfc-editor.org/info/rfc8948>.

Приложение A. IEEE 802c

В этом приложении дана краткая сводка IEEE 802c [IEEEStd802c].

Исходная спецификация IEEE 802 выделяет половину 48-битового пространства MAC-адресов для локального использования. Эти адреса имеют установленный бит U/L (1) и администрируются локально без задания структуры.

В 2017 г. была выпущена спецификация IEEE Std 802c с определением необязательного плана структурированной локальной адресации (Structured Local Address Plan или SLAP), который задает разные подходы к четырем указанным областям пространства локальных адресов MAC. В соответствии с этим планом для 4 квадрантов SLAP заданы разные правила назначения адресов.

В первом (младшем) октете MAC-адреса биты Z и Y определяют квадрант для назначаемых локально адресов (бит X имеет значение 1). Представление IEEE для этих битов показано на рисунке 3

LSB                MSB
M  X  Y  Z  -  -  -  -
|  |  |  |
|  |  |  +------------ SLAP бит Z
|  |  +--------------- SLAP бит Y
|  +------------------ бит X (U/L) = 1 для локальных адресов
+--------------------- бит M (I/G) (unicast/group)

Рисунок 3. Биты SLAP.


Квадранты SLAP описаны в таблице 1.

Таблица 1. Квадранты SLAP.

Квадрант

Бит Y

Бит Z

Тип локального идентификатора

Локальный идентификатор

01

0

1

Расширенный локальный идентификатор

ELI

11

1

1

Стандартное назначение

SAI

00

0

0

Административное назначение

AAI

10

1

0

Резерв

Резерв

MAC-адреса из квадранта расширенных локальных идентификаторов (Extended Local Identifier — ELI) основаны на идентификаторе компании (CID) размером 24 бита (включая M, X, Y, Z) для 48-битовых MAC-адресов. Это оставляет 24 бита для локального назначения с каждым идентификатором CID для индивидуальных (M = 0) и групповых (M = 1) адресов. Значения CID распределяются IEEE Registration Authority (RA).

MAC-адреса из квадранта стандартных идентификаторов (Standard Assigned Identifier — SAI) назначаются протоколом, заданным в стандарте IEEE 802. Для 48-битовых адресов MAC доступны 44 бита. Для назначения SAI в стандартах IEEE может быть задано множество протоколов. Сосуществование разных протоколов может поддерживаться за счет ограничения субпространства, доступного каждому протоколу.

MAC-адреса из квадранта административно выделяемых идентификаторов (Administratively Assigned Identifier — AAI) назначаются локально. Администраторы поддерживают пространство адресов по своему разумению. Отметим, что групповые пакеты IPv6 [RFC2464] используют адрес получателя, начинающийся с 33-33, поэтому адреса AAI не следует выделять из этого диапазона. Для 48-битовых MAC-адресов доступны 44 бита.

Последний квадрант зарезервирован на будущее. Хотя этот квадрант можно использовать аналогично пространству AAI, администраторам следует учитывать, что будущие спецификации могут задать иное использование адресов, что может привести к несовместимости.

Благодарности

Спасибо члена рабочей группы DHC за рецензирование документа, комментарии и поддержку. Отдельная благодарность Ian Farrer за внимательное рецензирование и помощь при прохождении процесса IETF. Спасибо также рецензентам от директората Samita Chakrabarti, Roni Even, Tianran Zhou и членам IESG Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry Leiba, Alvaro Retana, Éric Vyncke, Robert Wilton за их предложения. Спасибо Roger Marks, Robert Grow, Antonio de la Oliva за комментарии, относящиеся к работе IEEE, и ссылки.

Адреса авторов

Bernie Volz

Cisco Systems, Inc.

300 Beaver Brook Rd

Boxborough, MA 01719

United States of America

Email: volz@cisco.com

Tomek Mrugalski

Internet Systems Consortium, Inc.

PO Box 360

Newmarket, NH 03857

United States of America

Email: tomasz.mrugalski@gmail.com

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

28911 Leganes, Madrid

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Organizationally Unique Identifier — уникальный идентификатор организации.

4Media Access Control — управление доступом к среде.

5Universal/Local — универсальный или локальный адрес.

6Идентификационная ассоциация для адресов канального уровня.

Рубрика: RFC | Комментарии к записи RFC 8947 Link-Layer Address Assignment Mechanism for DHCPv6 отключены

RFC 8961 Requirements for Time-Based Loss Detection

image_print
Internet Engineering Task Force (IETF)                         M. Allman
Request for Comments: 8961                                          ICSI
BCP: 233                                                   November 2020
Category: Best Current Practice                                         
ISSN: 2070-1721

Requirements for Time-Based Loss Detection

Требования к детектированию потерь по времени

PDF

Аннотация

Многим протоколам нужно по той или иной причине детектировать потерю пакетов (например, для гарантированной доставки за счет повтора или понимания уровня перегрузки на пути через сеть). Хотя для обнаружения потерь было разработано много механизмов, протоколы на деле могут рассчитывать лишь на прошедшее без подтвеждений время, чтобы счесть пакет потерянным. Каждая реализация механизма обнаружения потерь на основе времени вынуждена соблюдать баланс между корректностью и своевременностью, поэтому нет решения на все случаи. В этом документе представлены требования высокого уровня к детекторам потерь на основе времени для использования в базовых индивидуальных (unicast) коммуникациях через Internet. В рамках этих требований реализации могут определять параметры, наиболее подходящие для каждой ситуации.

Статус документа

Документ относится к категории Internet Best Current Practice.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8961.

Авторские права

Авторские права (Copyright (c) 2020) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

Будучи сетью сетей, Internet включает множество разных каналов и систем, которые поддерживают широкий класс задач. Предоставляемые через сеть услуги варьируются по качеству от доступного (best-effort) для множества слабо связанных элементов до надежно предсказуемого в контролируемых средах (например, между физически соединенными узлами или в строго контролируемом ЦОДе). У каждого пути через сеть имеется набор параметров, например, доступная пропускная способность, задержка и потеря пакетов. Учитывая разнородность сетей в Internet, можно считать эти свойства варьирующимися от статических до быстро меняющихся.

В этом документе рассматривается одно из свойств пути — потеря пакетов. В частности, предложены рекомендации по разработке и реализации детекторов потерь на основе времени, которые были выработаны за прошедшие десятки лет. Рассматривается достаточно общий случай, когда свойства потери пакетов в пути (a) не известны заранее и (b) меняются с течением времени. Кроме того, несмотря на возможность различных причин потери пакетов, здесь принят консервативный подход о том, что потери являются неявным признаком перегрузки [RFC5681]. Хотя эта позиция верна не во всех случаях, она хорошо послужила в качестве базового допущения, использованного еще в [Jac88]. Как будет отмечено в разделе 2, рекомендации этого документа следует считать базовыми для индивидуального трафика в сетях с доставкой по возможности (best-effort) и неоптимальными, хотя и применимыми в других ситуациях.

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

  1. Обеспечение гарантированной доставки данных.Отправитель должен понимать, какие из переданных пакетов не достигли адресата, чтобы можно было повторить их передачу.
  2. Контроль насыщения (перегрузок).Как уже было отмечено, потеря пакетов часто служит неявной индикацией того, что отправитель передает пакеты слишком быстро и перегружает ту или иную часть пути через сеть. Поэтому отправителю нужно знать о потерях для снижения скорости.

Для обнаружения потерь в потоке пакетов применяются разные механизмы. Часто для этого служат постоянные или периодические подтверждения от получателя для информирования отправителя об отсутствии пакетов. Однако, несмотря на добрые намерения и отказоустойчивые механизмы, невозможно полностью доверять таким подтверждениям, поскольку они могут зависеть от времени и реальным подтверждением потери может являться лишь тайм-аут. То есть отправитель задает те или иные ожидания в части времени подтверждения доставки той или иной порции данных. Когда это время проходит без доставки подтверждения, отправитель считает данные потерянными.

Специфика схем обнаружения потерь на основе времени является компромиссом между корректностью и быстродействием, поскольку хочется одновременно:

  • ждать достаточно долго для корректного детектирования;
  • сократить задержку для приложений (перед повтором) и сети (перед снижением нагрузки).

Достичь обеих целей сложно, поскольку они противонаправлены [AP99]. Без долгого ожидания можно своевременно повторять передачу, но это ведет к риску ненужных (ложных) повторов и неоправданногоу снижения скорости передачи. Если ждать долго для достижения уверенности в потере пакетов, не будет своевременного восстановления и возникает риск продления перегрузки в сети.

Многие протоколы и приложения, такие как TCP [RFC6298], SCTP [RFC4960] и SIP [RFC3261], включают механизмы обнаружения потерь на основе времени. Опыт использования этих механизмов показывает, что зачастую конкретные настройки, отклоняющиеся от стандартизованных детекторов на основе времени, не оказывают нужного влияния на безопасность сети в части контроля перегрузок [AP99]. Поэтому в данном документе представлен набор независимых от протоколов требований высокого уровня к детектирования потерь на основе времени. Цель документа заключается в создании надежной основы для реализаций, обеспечивающих гибкие механизмы решения конкретной задачи.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

2. Контекст

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

К настоящему времени накопленный сообществом опыт позволяет задать базовые требования высокого уровня для схем детектирования на основе времени. Понятно, как отделить стратегию этих механизмов, имеющую важное значение для безопасности сети, от мелких деталей, не оказывающих существенного влияния. Приведенные здесь требования могут не оказаться подходящими для всех случаев. В частности, рекомендации раздела 4 относятся к базовому случаю, но в некоторых конкретных ситуациях могут быть более гибкие в плане обнаружения потерь решения, учитывающие аспекты конкретной среды (например, при работе по одному физическому каналу или в ЦОД с единым контролем). Поэтому в некоторых случаях могут быть полезны и даже необходимы варианты, отклонения или совершенно иные решения по детектированию потерь на основе времени. Этот документ следует рассматривать как принятый по умолчанию вариант, а не универсальное решение во всех ситуациях.

Добавление «зонтика» требований к имеющимся спецификациям по сути не является аккуратным решением и возникает риск несовместимости как с прошлыми, так и с будущими механизмами. Поэтому здесь приведены несколько допущений о связи этого документа с имеющимися и будущими спецификациями.

  • Документ не обновляет и не отменяет имеющиеся RFC. Прежние спецификации в общем случае соответствуют требованиям документа и отражают согласованное мнение сообщетва, поэтому сохранены.
  • Требования документа нацелены на обеспечение защиты сети, поэтому их следует применять в будущих механизмах обнаружения потери пакетов на основе времени.

  • Требования документа применимы не во всех случаях, поэтому в будущем могут потребоваться варианты и отклонения (поэтому применен термин следует). Однако несовместимости должны быть (a) объяснены и (b) получить согласие сообщества.

3. Область действия

Описанные в документе принципы не зависят от протокола и широко применимы. Ниже представлены заявления о применимости требований, приведенных в разделе 4.

  1. Хотя в протоколах применяется множество таймеров (от контроля скорости до обнаружения отказов в соединениях и т. п.), здесь рассматривается лишь обнаружение потерь.

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

    Хотя для таких простых протоколов, как DNS [RFC1034] [RFC1035], достаточно простого детектора потерь, более сложные протоколы часто применяют более совершенные механизмы обнаружения потерь для повышения производительности. Например, в TCP и SCTP имеются методы обнаружения (и восстановления) потерь на основе явного обобщения состояния конечной точки [RFC2018] [RFC4960] [RFC6675]. Такие механизмы часто обеспечивают более своевременное и точное обнаружение потерь, нежели детекторы на основе времени. Однако эти механизмы не избавляют от необходимости поддерживать тайм-аут повтора (retransmission timeout) или RTO, как отмечено в разделе 1, и в конечном счете могут полагаться лишь на прохождение времени для детектирования потери. Иными словами, нет возможности рассчитывать на прибытие подтверждения отправителю данных как на указание пакетов, которые не пришли к получателю. В таких случаях все равно нужен детектор на основе времени, который сработает в крайнем случае.

    Отметим также, что некоторые недавние предложения включают время как часть метода обнаружения потерь в качестве агрессивного детектирования первой потери в некоторых ситуациях или вместе с обобществлением состояний конечных точек [DCCM13] [CCDJ20] [IS20]. Хотя эти механизмы могут способствовать своевременному восстановлению, протокол в конечном итоге опирается на более консервативный таймер для обеспечения надежности при выходе этих механизмов из строя. Требования этого документа напрямую применимы лишь к крайнему варианту обнаружения потерь (last-resort). Однако предполагается, что многие из требований послужат полезным руководством для менее агрессивных таймеров, не предназначенных для крайних случаев.

  3. Требования этого документа относятся лишь к взаимодействию между парами конечных точек по индивидуальным (unicast) адресам. Протоколы группового взаимодействия (например, [RFC5740]) явно выходят за рамки документа.Такие протоколы, как SCTP [RFC4960] и Multipath TCP (MP-TCP) [RFC6182], использующие unicast-адресацию для множества конечных точек, могут применять требования документа при условии отслеживания состояний и независимого выполнения требований каждой точкой. Т.е. при взаимодействии хоста A с хостами B и C хост A должен применять независимое детектирование потерь на основе времени для трафика, передаваемого B и C.
  4. В некоторых случаях общее состояние используется несколькими соединениями или потоками (например, [RFC2140] и [RFC3124]). Состояние, относящееся к обнаружению потерь по времени, часто считается доступным для совместного использования. Такие ситуации вызывают вопросы, которые простой механизм обнаружения связанных с потоком потерь по времени, рассматриваемый здесь, не решает (например, продолжительность сохранения состояний между соединениями). Поэтому совместное использование потоками общей информации о потерях на основе времени выходит за рамки документа, хотя к нему и применимы общие принципы раздела 4.

4. Требования

Здесь приведены требования, применимые при разработке основных (primary) или крайних (last-resort) механизмов обнаружения потерь на основе времени. По историческим причинам и для простоты описания время между отправкой пакета и фиксацией его потери по отсутствию подтверждения называется тайм-аутом повтора (retransmission timeout или RTO). По истечении RTO без подтверждения доставки отправитель может в суверенностью считать пакет потерянным. Однако, как было отмечено выше, обнаруженную потерю не требуется восстанавливать (т. е. потеря принимается для контроля перегрузок, но не для обеспечения гарантий доставки).

  1. Как отмечено выше, обнаружение потери происходит, когда отправитель не получает подтверждения доставки в ожидаемом интервале времени. В отсутствие информации о задержке на пути, начальное значение RTO должно быть не меньше 1 секунды.

    Корректность имеет важнейшее значение при передаче в сеть с неизвестными свойствами по ряду причин.

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

Конкретная константа (1 сеунда) получена из анализа времени кругового обхода в Internet (RTT), приведенного в Приложении A [RFC6298].

  1. Здесь заданы 4 требования, относящиеся к установке ожидаемого интервала подтверждения доставки.

    Часто измерение времени, требуемого для подтверждения доставки, воспринимается как определение RTT для сетевого пути. RTT — это минимальное время, которое требуется для подтверждения доставки, которое часто зависит от поведения протокола в части скорости генерации подтверждения при доставке. Например, это относится к RTO, используемому в TCP [RFC6298] и SCTP [RFC4960]. Однако это иной раз вводит в заблуждение и ожидаемую задержку лучше означит как время обратной связи (feedback time или FT). Иными словами, ожидаемое время не всегда отражает свойства сети и может включать дополнительную задержку, которую следует учитывать отправителю.

    Рассмотрим, например, UDP-запрос DNS от клиента к рекурсивному распознавателю [RFC1035]. При обслуживании запроса из кэша распознавателя, время обратной связи (FT) будет близко к RTT между клиентом и распознавателем. Однако при отсутствии записи в кэше распознаватель будет запрашивать нужную информацию у одного или нескольких полномочных серверов DNS, что приведет к тредно оцениваемому росту FT по сравнению с RTT между клиентом и распознавателем.

    Поэтому требования выражаются в терминах FT. Для простоты описания по-прежнему используется RTO в качестве индикатора интервала между отправкой пакета и принятием решения о потере, независимо от повтора передачи пакета.

    1. Для установки RTO следует использовать несколько наблюдений FT, если они доступны.

      Иными словами, значение RTO должно представлять эмпирически доступное разумное время, в течение отправителю следует ждать подтверждения доставки, прежде чем принимать решение о потере данных. Пути в сети по природе динамичны, поэтому важно учитывать в RTO несколько недавних измерений FT.

      Например, TCP RTO [RFC6298] удовлетворяет этим требованиям благодаря использованию экспоненциально взвешенного скользящего среднего значения (EWMA3) для объединения множества измерений FT в «сглаженное время RTT». Во имя консервативности TCP идет дальше, включая явный учет дисперсии при расчете RTO.

      Несмотря на то, что использование нескольких измерений FT очень важно для учета динамики задержки в пути, здесь явно не задается число и срок действия таких измерений для расчета RTO, поскольку это может зависеть от ситуации и задач конкретного детектора потерь.

      Измерения FT выполняются на основе обмена пакетами между партнерами. Разработчикам протоколов (особенно новых) рекомендуется обеспечивать сложность подделки обратной связи злоумышленниками в сети с целью исказить оценку хостом значения FT. В идеале все сообщения следует защищать криптографически, но это не всегда возможно (особенно в устаревших протоколах), поэтому рекомендуется использовать в пакетах разумный объем случайных значений.

    2. Измерение FT следует выполнять и включать в RTO не менее 1 раза за период RTT или с частотой обмена пакетами, если пакеты передаются с интервалами больше RTT.

      Измерения в Internet показывают, что однократное измерение FT для соединения TCP приводит к достаточно плохой работе механизма RTO [AP99], поэтому введено требование многократного измерения FT в течение всего времени связи.

      Например, TCP может оценивать FT 1 раз в интервале RTT или для каждого приема подтверждения с временной меткой [RFC7323]. В [AP99] показано, что оба варианта дают близкие оценки RTO.

    3. Оценки FT можно делать не только на основе обмена данными.

      Некоторые протоколы по тем или иным причинам передают не только данные, но и служебные сообщения keepalive, heartbeat, управляющие сообщения. Задержки при таких обменах могут применяться при оценке FT для механизма RTO в той мере, в какой они отражают задержки при обмене данными. Такие измерения могут помочь протоколам сохранить точность RTO при возникновении перерывов в обмене данными. Однако с учетом того, что задержки этих сообщений могут отличаться от задержки при передаче данных, они могут быть полезны не всегда.

    4. Механизму RTO недопустимо применять неоднозначные измерения FT.

      Предположим, что были переданы две копии пакета X в моменты t0 и t1, затем в момент t2 отправитель получил подтверждение доставки X. В некоторых случаях невозможно узнать, какая из копий X вызвала подтверждение, поэтому значением FT может быть как t2-t1, так и t2-t0. В такой ситуации реализации недопустимо использовать любое из этих значений FT для обновления RTO ([KP87] и [RFC6298]).

      В некоторых случаях при отправке двух копий данных можно различить, какую из них подтверждает принятое сообщение ACK. Например, временные метки TCP [RFC7323] позволяют точно установить подтвержденный пакет. Неоднозначности не возникает и измерение пригодно для обновления RTO.

  2. Потеря, обнаруженная механизмом RTO, должна служить индикацией перегрузки в сети и вызывать корректировку скорости передачи стандартным механизмом (например, TCP сжимает окно насыщения до одного пакета [RFC5681]). Это обеспечивает защиту сети.

    Исключением являются случаи, когда стандартизованный IETF механизм определяет, что данная потеря не связана с перегрузкой (например, повреждение пакета), поэтому контроль перегрузки включать не нужно. Кроме того, действия по контролю перегрузки на основе детектирования потерь по времени могут быть отменены, когда стандартный механизм постфактум определяет, что потеря не связана с перегрузкой (например, [RFC5682]).

  3. При каждом использовании RTO для обнаружения потери значение RTO должно экспоненциально увеличиваться, чтобы следующее срабатывание происходило через более долгий интервал. Изменение тайм-аута следует отменять, если (a) последующая передача произошла без потерь или (b) в течение RTO не было обнаружено дополнительных потерь. Первый вариант обычно наступает быстрее, а второй относится к случаям, когда потеря обнаружена но не устранена. Это обеспечивает защиту сети.

    Для RTO можно задать максимальное значение, которое недопустимо делать меньше 60 секунд, как указано в [RFC6298].

    Как и в случае (3), имеется исключение, если стандартизованный IETF механизм определяет, что потеря не связана с перегрузкой.

5. Обсуждение

Отметим, что исследования показали фундаментальность противоречия между своевременностью и точностью при обнаружении проблем по времени в контексте TCP [AP99]. Т. е. более энергичное применение RTO (например, изменение прироста EWMA, снижение минимального RTO и т. п.) может ускорить обнаружение действительной потери. Однако при этом будет больше ошибочных срабатываний, когда отмеченные потери не будут таковыми на деле. Поэтому максимальная энергичность, разрешаемая приведенными выше требованиями не будет лучшим решением, ведь детектирование потерь (даже ложное) требует реакции на перегрузку, снижающей в итоге скорость передачи.

Хотя противоречие между точностью и своевременностью детектирования является фундаментальным, его важность можно снизить, если отправитель может обнаружить и скомпенсировать ложные срабатывания детектора потерь. Для этого было предложено несколько механизмов, таких как Eifel [RFC3522], F-RTO4 [RFC5682], DSACK5 [RFC2883] [RFC3708]. Применение таких механизмов позволяет отправителю данных реагировать быстрее, но без сопутствующих издержек, связанных с ошибочным детектированием потерь.

Следует также отметить, что в дополнение к экспериментам, описанным в [AP99], реализация Linux TCP много лет использует различные нестандартные механизмы RTO без каких-либо серьезных проблем (например, использование коэффициентов усиления EWMA, отличных от [RFC6298]). Кроме того, во многих реализациях TCP используется минимальное значение RTO в установившемся состоянии, которое меньше 1 секунды, заданной в [RFC6298]. Хотя эти отклонения от стандартов могут приводить к росту числа ложных обнаружений потерь (согласно [AP99]), неизвестно о каких-либо значимых проблемах с безопасностью сетей, вызванных изменением минимального значения RTO. Это учтено в последней рекомендации раздела 4, где не задано минимальное значение RTO.

В заключение следует отметить, что хотя более энергичное поведение реализаций может вести к росту числа ненужных повторов, приведенные выше требования не будут работать в той части, где требуется экспоненциальное снижение тайм-аута и уменьшение скорости передачи. Поэтому предоставление разработчикам большей свободы по сравнению с действующими спецификациями IETF для механизмов RTO не открывает ворота для такого энергичного поведения. Это поведение имеет оборотную сторону и механизм сохраняет стимулы к реализации корректного поведения.

6. Вопросы безопасности

Этот документ не меняет свойств безопасности основанных на времени механизмов обнаружения потерь. Рассмотрение этого вопроса в контексте TCP приведено в [RFC6298].

7. Взаимодействие с IANA

Документ не требует действий со стороны IANA.

8. Литература

8.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Дополнительная литература

[AP99] Allman, M. and V. Paxson, «On Estimating End-to-End Network Path Properties», Proceedings of the ACM SIGCOMM Technical Symposium, September 1999.

[CCDJ20] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, «The RACK-TLP loss detection algorithm for TCP», Work in Progress, Internet-Draft, draft-ietf-tcpm-rack-13, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-tcpm-rack-13>.

[DCCM13] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, «Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses», Work in Progress, Internet-Draft, draft-dukkipati-tcpm-tcp-loss-probe-01, 25 February 2013, <https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01>.

[IS20] Iyengar, J., Ed. and I. Swett, Ed., «QUIC Loss Detection and Congestion Control», Work in Progress, Internet-Draft, draft-ietf-quic-recovery-32, 20 October 2020, <https://tools.ietf.org/html/draft-ietf-quic-recovery-32>.

[Jac88] Jacobson, V., «Congestion avoidance and control», ACM SIGCOMM, DOI 10.1145/52325.52356, August 1988, <https://doi.org/10.1145/52325.52356>.

[KP87] Karn, P. and C. Partridge, «Improving Round-Trip Time Estimates in Reliable Transport Protocols», SIGCOMM 87.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.

[RFC2140] Touch, J., «TCP Control Block Interdependence», RFC 2140, DOI 10.17487/RFC2140, April 1997, <https://www.rfc-editor.org/info/rfc2140>.

[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, «An Extension to the Selective Acknowledgement (SACK) Option for TCP», RFC 2883, DOI 10.17487/RFC2883, July 2000, <https://www.rfc-editor.org/info/rfc2883>.

[RFC3124] Balakrishnan, H. and S. Seshan, «The Congestion Manager», RFC 3124, DOI 10.17487/RFC3124, June 2001, <https://www.rfc-editor.org/info/rfc3124>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.

[RFC3522] Ludwig, R. and M. Meyer, «The Eifel Detection Algorithm for TCP», RFC 3522, DOI 10.17487/RFC3522, April 2003, <https://www.rfc-editor.org/info/rfc3522>.

[RFC3708] Blanton, E. and M. Allman, «Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions», RFC 3708, DOI 10.17487/RFC3708, February 2004, <https://www.rfc-editor.org/info/rfc3708>.

[RFC4960] Stewart, R., Ed., «Stream Control Transmission Protocol», RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, «TCP Congestion Control», RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, «Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP», RFC 5682, DOI 10.17487/RFC5682, September 2009, <https://www.rfc-editor.org/info/rfc5682>.

[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, «NACK-Oriented Reliable Multicast (NORM) Transport Protocol», RFC 5740, DOI 10.17487/RFC5740, November 2009, <https://www.rfc-editor.org/info/rfc5740>.

[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, «Architectural Guidelines for Multipath TCP Development», RFC 6182, DOI 10.17487/RFC6182, March 2011, <https://www.rfc-editor.org/info/rfc6182>.

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, «Computing TCP’s Retransmission Timer», RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., and Y. Nishida, «A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP», RFC 6675, DOI 10.17487/RFC6675, August 2012, <https://www.rfc-editor.org/info/rfc6675>.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., «TCP Extensions for High Performance», RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

Благодарности

Этот документ основан на многолетнем обсуждении с Ethan Blanton, Sally Floyd, Jana Iyengar, Shawn Ostermann, Vern Paxson, а также с членами рабочих групп TCPM и TCPIMPL. Полезные комментарии к предварительным вариантам документа предоставили Ran Atkinson, Yuchung Cheng, David Black, Stewart Bryant, Martin Duke, Wesley Eddy, Gorry Fairhurst, Rahul Arvind Jadhav, Benjamin Kaduk, Mirja Kühlewind, Nicolas Kuhn, Jonathan Looney, Michael Scharf.

Адрес автора

Mark Allman

International Computer Science Institute

2150 Shattuck Ave., Suite 1100

Berkeley, CA 94704

United States of America

Email: mallman@icir.org

URI: https://www.icir.org/mallman

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Exponentially weighted moving average.

4Forward RTO-Recovery — ускоренное восстановление RTO.

5Duplicate Selective Acknowledgement — селективное подтверждение дубликатов.

Рубрика: RFC | Комментарии к записи RFC 8961 Requirements for Time-Based Loss Detection отключены

RFC 8944 A YANG Data Model for Layer 2 Network Topologies

image_print
Internet Engineering Task Force (IETF)                           J. Dong
Request for Comments: 8944                                        X. Wei
Category: Standards Track                                          Q. Wu
ISSN: 2070-1721                                                   Huawei
                                                            M. Boucadair
                                                                  Orange
                                                                  A. Liu
                                                                  Tecent
                                                           November 2020

A YANG Data Model for Layer 2 Network Topologies

Модель YANG для сетевой топологии канального уровня

PDF

Аннотация

Этот документ определяет модель данных YANG для сетевой топологии канального уровня (L2). В частности, модель дополняет базовые модели сети и сетевой топологии атрибутами, относящимися к L2.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8944.

Авторские права

Авторские права (Copyright (c) 2020) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

[RFC8345] определяет модели данных YANG [RFC6020] [RFC7950] абстрактной (базовой) сети и сетевой топологии, которые можно дополнить зависящими от технологии деталями для построения соответствующей технологии модели.

Этот документ определяет модель данных YANG для сетевых топологий канального уровня (L2) путем дополнения моделей данных базовой сети (параграф 6.1 в [RFC8345]) и базовой топологии (параграф 6.2 в [RFC8345]) относящимися к уровню L2 атрибутами. Пример представлен в приложении B.

Такая модель данных имеет много применений. Например, в контексте интерфейса в систему маршрутизации I2RS3 узлы сети могут использовать модель данных для фиксации своего представления о топологии сети в целом и раскрытия его контроллеру сети. Контроллер может использовать экземпляры данных топологии для сравнения и согласования со своим представлением о топологии сети. В дополнение к этому узлы сети могут сравнивать и согласовывать эти представления между собой самостоятельно или с помощью контроллера. Помимо элементов сети и самого контекста I2RS контроллер сети может применять модель данных для представления контролируемой им топологии внешним приложениям. Другие варианты применения модели данных рассмотрены в [I2RS-UR].

В документе применяются базовые типы YANG, определенные в [RFC6991], и принимается архитектура хранилища NMDA4 [RFC8342].

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Термины для описания модулей YANG определены в [RFC7950], значения символов, используемых в диаграммах деревьев, — в [RFC8340].

3. Модель топологии L2

Модуль YANG для сетевой топологии уровня L2 разработан в качестве базового для сетей L2 на основе разных технологий канального уровня. Модуль можно применять как для физических, так и для логических (виртуальных) топологий L2.

Связь модуля топологии L2 с модулями базовой сети и сетевой топологии показана на рисунке 1. Для представления топологии L2 модели базовой сети и сетевой топологии дополнены относящейся к L2 информацией, такой как идентификаторы, сущности (элементы, например, PBB5 [IEEE802.1ah], QinQ [IEEE802.1ad], VXLAN6 [RFC7348]), атрибуты и состояния сетей L2, узлы, каналы и точки завершения. Часть информации может быть собрана протоколом LLDP7 [IEEE802.1AB] или другим протоколом L2, а другая часть настроена в локальной конфигурации.

+---------------------+
|    ietf-network     |
+----------^----------+
           |
           |
+---------------------+
|ietf-network-topology|
+----------^----------+
           |
           |
+----------^----------+
|   ietf-l2-topology  |
+---------------------+