Энциклопедия сетевых протоколов | от Николая Малых

RFC 7801 GOST R 34.12-2015: Block Cipher «Kuznyechik»

Опубликовано 08.03.2016 автором Nikolai Malykh

Independent Submission                                  V. Dolmatov, Ed.
Request for Comments: 7801                  Research Computer Center MSU
Category: Informational                                       March 2016
ISSN: 2070-1721

ГОСТ Р 34.12-2015 — Блочный шифр «Кузнечик»

GOST R 34.12-2015: Block Cipher «Kuznyechik»

PDF

Аннотация

Этот документ публикуется в качестве источника информации о Национальном стандарте Российской федерации ГОСТ Р 34.12-2015, описывающем блочное шифрование с размером блока n=128 битов и размером ключа k=256 битов, называемого также «Кузнечик». Данный алгоритм является одним из множества российских стандартных криптографических алгоритмов (алгоритмы ГОСТ).

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

Документ не является спецификацией стандарта Internet и публикуется с информационными целями.

Документ включается в серию RFC, но не связан с каким-либо потоком документов RFC. Редактор (RFC Editor) принял решение о публикации документа по своему усмотрению и не делает каких-либо заявления о реализации или развертывании. Документы, одобренные для публикации их редакторами не претендуют на какой-либо уровень стандартизации Internet (см. раздел 2 в RFC 5741).

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

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

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Сфера действия стандарта

Национальный стандарт Российской федерации [GOST3412-2015] описывает базовые блочные шифры, используемые в качестве криптографических методов обработки и защиты информации, включая защиту конфиденциальности, достоверности и целостности информации при ее передаче, обработке и хранении в компьютерных системах.

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

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

2. Общие сведения

Блочный шифр «Кузнечик» [GOST3412-2015] Разработан Центром защиты информации и специальной связи Федеральной службы безопасности Российской федерации с участием ОАО «Инфотекс» («Информационные Технологии и Коммуникационные Системы» — InfoTeCS JSC). Стандарт ГОСТ Р 34.12-2015 одобрен и введен в действие Приказом №749-ст Федерального агентства по техническому регулированию и метрологии от 19 июня 2015 г.

Терминологически и концептуально стандарт согласован с международными стандартами:

ISO/IEC 10116 [ISO-IEC10116];
серия стандартов ISO/IEC 18033 [ISO-IEC18033-1] [ISO-IEC18033-3].

3. Определения и обозначения

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

3.1. Определения

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

encryption algorithm — алгоритм шифрования

Процесс, преобразующий открытый текст в зашифрованный (параграф 2.19 [ISO-IEC18033-1]).

decryption algorithm — алгоритм дешифрования

Процесс, преобразующий зашифрованный текст в открытый (параграф 2.14 [ISO-IEC18033-1]).

basic block cipher — базовый блочный шифр

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

block — блок

Строка битов определенного размера (параграф 2.6 [ISO-IEC18033-1])

block cipher – блочный шифр

Симметричная система шифрования, в которой алгоритм шифрования применяется к блокам открытого текста (строкам битов определенного размера) для получения блоков шифрованного текста (параграф 2.7 [ISO-IEC18033-1]).

Примечание. В ГОСТ Р 34.12-2015 установлено, что термины «блочный шифр» (block cipher) и «алгоритм блочного шифрования» (block encryption algorithm) являются синонимами.

encryption — шифрование

Обратимое преобразование данных с помощью криптографического алгоритма для создания шифрованного текста, т. е., сокрытия содержимого этих данных (параграф 2.18 [ISO-IEC18033-1]).

round key — итерационный ключ

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

key — ключ

Последовательность символов, определяющая криптографическое преобразование (например, шифрование или дешифрование) (параграф 2.21 [ISO-IEC18033-1]).

Примечание. В ГОСТ Р 34.12-2015 ключ должен быть двоичной последовательностью.

plaintext — открытый текст

Незашифрованная информация (параграф 3.11 [ISO-IEC10116]).

key schedule — развертывание ключа

Расчет итерационного ключа на основе ключа шифра.

decryption — дешифрование

Операция, обратная шифрованию (параграф 2.13 [ISO-IEC18033-1]).

symmetric cryptographic technique — симметричный криптографический метод

Криптографический метод, в котором используется один и тот же секретный ключ как для шифрования, так и для дешифрования (параграф 2.32 [ISO-IEC18033-1]).

cipher — шифр

Другой термин, используемый для обозначения криптографической системы (параграф 2.20 [ISO-IEC18033-1]).

ciphertext — шифрованный текст

Данные, которые были преобразованы с целью сокрытия их содержимого (параграф 3.3 [ISO-IEC10116]).

3.2. Обозначения

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

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

V_s

множество всех двоичных строк размера s, где s — неотрицательное целое число; нумерация подстрок и компонент строки осуществляется справа налево, начиная с 0.

U[*]W

прямое (декартово) произведение множеств U и W.

|A|

число компонент (размер) строки A из множества V* (если A — пустая строка, |A| = 0).

A||B

конкатенация строка A и B из множества V*, т.е., строка из V_(|A|+|B|), где левая подстрока из V_|A| равна A, а правая подстрока из V_|B| равна B.

Z_(2ⁿ)

кольцо вычетов по модулю 2ⁿ,

конечное поле GF(2)[x]/p(x), где p(x)=x⁸+x⁷+x⁶+x+1 принадлежит GF(2)[x]; элементы поля Q представлены целыми числами так, что элемент z_0+z_1*theta+…+z_7*theta⁷, принадлежащий Q, соответствует целому числу z_0+2*z_1+…+2⁷*z_7, где z_i=0 или z_i=1, i=0,1,…,7, а theta означает класс вычетов по модулю p(x), содержащий x.

(xor)

исключающее ИЛИ для двух двоичных строк одинаковых размеров.

Vec_s: Z_(2^s) -> V_s

взаимно-однозначное¹ отображение, сопоставляющее элемент из кольца Z_(2^s) с его двоичным представлением; т.е., для любого элемента z в кольце Z_(2^s), представленного в виде z_0 + (2*z_1) + … + (2^(s-1)*z_(s-1)), где z_i принадлежит {0, 1}, i = 0, …, n-1, справедливо равенство Vec_s(z) = z_(s-1)||…||z_1||z_0.

Int_s: V_s -> Z_(2^s)

отображение, обратное по отношению к Vec_s (т.е., Int_s = Vec_s^-1).

delta: V_8 -> Q

взаимно-однозначное отображение, сопоставляющее двоичную строку из V_8 с элементом из поля Q следующим образом — строке z_7||…||z_1||z_0, где z_i принадлежит {0, 1}, i = 0, …, 7, соответствует элемент z_0+(z_1*theta)+…+(z_7*theta⁷), принадлежащий Q²,

nabla: Q -> V8

отображение, обратно по отношению к delta, т.е., delta = nabla^-1,

композиция отображений, в которой отображение S выполняется первым.

P^s

композиция отображений P^s-1 и P, где P¹=P.

4. Значения параметров

4.1. Нелинейное взаимно-однозначное преобразование

Нелинейное взаимно-однозначное преобразование представляет собой подстановку Pi = (Vec_8)Pi'(Int_8): V_8 -> V_8, где Pi’: Z_(2⁸) -> Z_(2⁸). Значения для подстановки Pi’ приведены ниже в форме массива Pi’ = (Pi'(0), Pi'(1), … , Pi'(255)):

    Pi' =
   (       252, 238, 221,  17, 207, 110,  49,  22, 251, 196, 250,
           218,  35, 197,   4,  77, 233, 119, 240, 219, 147,  46,
           153, 186,  23,  54, 241, 187,  20, 205,  95, 193, 249,
            24, 101,  90, 226,  92, 239,  33, 129,  28,  60,  66,
           139,   1, 142,  79,   5, 132,   2, 174, 227, 106, 143,
           160,   6,  11, 237, 152, 127, 212, 211,  31, 235,  52,
            44,  81, 234, 200,  72, 171, 242,  42, 104, 162, 253,
            58, 206, 204, 181, 112,  14,  86,   8,  12, 118,  18,
           191, 114,  19,  71, 156, 183,  93, 135,  21, 161, 150,
            41,  16, 123, 154, 199, 243, 145, 120, 111, 157, 158,
           178, 177,  50, 117,  25,  61, 255,  53, 138, 126, 109,
            84, 198, 128, 195, 189,  13,  87, 223, 245,  36, 169,
            62, 168,  67, 201, 215, 121, 214, 246, 124,  34, 185,
             3, 224,  15, 236, 222, 122, 148, 176, 188, 220, 232,
            40,  80,  78,  51,  10,  74, 167, 151,  96, 115,  30,
             0,  98,  68,  26, 184,  56, 130, 100, 159,  38,  65,
           173,  69,  70, 146,  39,  94,  85,  47, 140, 163, 165,
           125, 105, 213, 149,  59,   7,  88, 179,  64, 134, 172,
            29, 247,  48,  55, 107, 228, 136, 217, 231, 137, 225,
            27, 131,  73,  76,  63, 248, 254, 141,  83, 170, 144,
           202, 216, 133,  97,  32, 113, 103, 164,  45,  43,   9,
            91, 203, 155,  37, 208, 190, 229, 108,  82,  89, 166,
           116, 210, 230, 244, 180, 192, 209, 102, 175, 194,  57,
            75,  99, 182)

Pi^-1 представляет собой значение, обратное Pi (1/Pi); значения для подстановки Pi^-1‘ приведены ниже в форме массива Pi^-1‘ = (Pi^-1‘(0), Pi^-1‘(1), … , Pi^-1‘(255)):

    Pi^-1' =
   (    165,  45,  50, 143,  14,  48,  56, 192,  84, 230, 158,
         57,  85, 126,  82, 145, 100,   3,  87,  90,  28,  96,
          7,  24,  33, 114, 168, 209,  41, 198, 164,  63, 224,
         39, 141,  12, 130, 234, 174, 180, 154,  99,  73, 229,
         66, 228,  21, 183, 200,   6, 112, 157,  65, 117,  25,
        201, 170, 252,  77, 191,  42, 115, 132, 213, 195, 175,
         43, 134, 167, 177, 178,  91,  70, 211, 159, 253, 212,
         15, 156,  47, 155,  67, 239, 217, 121, 182,  83, 127,
        193, 240,  35, 231,  37,  94, 181,  30, 162, 223, 166,
        254, 172,  34, 249, 226,  74, 188,  53, 202, 238, 120,
          5, 107,  81, 225,  89, 163, 242, 113,  86,  17, 106,
        137, 148, 101, 140, 187, 119,  60, 123,  40, 171, 210,
         49, 222, 196,  95, 204, 207, 118,  44, 184, 216,  46,
         54, 219, 105, 179,  20, 149, 190,  98, 161,  59,  22,
        102, 233,  92, 108, 109, 173,  55,  97,  75, 185, 227,
        186, 241, 160, 133, 131, 218,  71, 197, 176,  51, 250,
        150, 111, 110, 194, 246,  80, 255,  93, 169, 142,  23,
         27, 151, 125, 236,  88, 247,  31, 251, 124,   9,  13,
        122, 103,  69, 135, 220, 232,  79,  29,  78,   4, 235,
        248, 243,  62,  61, 189, 138, 136, 221, 205,  11,  19,
        152,   2, 147, 128, 144, 208,  36,  52, 203, 237, 244,
        206, 153,  16,  68,  64, 146,  58,   1,  38,  18,  26,
         72, 104, 245, 129, 139, 199, 214,  32,  10,   8,   0,
         76, 215, 116 )

4.2. Линейное преобразование

Линейное преобразование обозначается l: (V_8)¹⁶ -> V_8 и определяется выражением

 l(a_15,...,a_0) = nabla(148*delta(a_15) + 32*delta(a_15) + 133*delta(a_13) + 16*delta(a_12) +
 194*delta(a_11) + 192*delta(a_10) + 1*delta(a_9) + 251*delta(a_8) + 1*delta(a_7) +
 192*delta(a_6) + 194*delta(a_5) + 16*delta(a_4) + 133*delta(a_3) + 32*delta(a_2) + 
 148*delta(a_1) +1*delta(a_0))

для всех a_i, принадлежащих V_8, i = 0, 1, …, 15, где операции сложения и умножения выполняются в поле Q, а постоянные являются элементами поля, как указано выше.

4.3. Преобразования

Для реализации алгоритмов шифрования и дешифрования используются следующие преобразования:

X[x]:V_128->V_128 X[k](a)=k(xor)a

где k принадлежит V_128,

S:V_128-> V_128 S(a)=(a_15||...||a_0)=pi(a_15)||...||pi(a_0)

где a_15||…||a_0 принадлежит V_128, a_i принадлежит V_8, i=0,1,…,15,

S^-1:V_128-> V_128

значение, обратное по отношению к результату преобразования S, которое можно выполнить, как показано ниже

S^-1(a_15||...||a_0)=pi^-1 (a_15)||...||pi^-1(a_0)

где a_15||…||a_0 принадлежит V_128, a_i принадлежит V_8, i=0,1,…,15,

R:V_128-> V_128 R(a_15||...||a_0)=l(a_15,...,a_0)||a_15||...||a_1

где a_15||…||a_0 принадлежит V_128, a_i принадлежит V_8, i=0,1,…,15,

L:V_128-> V_128 L(a)=R¹⁶(a)

где a принадлежит V_128,

R^-1:V_128-> V_128

значение, обратное по отношению к результату преобразования R, которое можно выполнить, как показано ниже

R^-1(a_15||...||a_0)=a_14|| a_13||...||a_0||l(a_14,a_13,...,a_0,a_15)

где a_15||…||a_0 принадлежит V_128, a_i принадлежит V_8, i=0,1,…,15,

L^-1:V_128-> V_128 L^-1(a)=(R^-1)(16)(a)

где a принадлежит V_128,

F[k]:V_128[*]V_128 -> V_128[*]V_128 F[k](a_1,a_0)=(LSX[k](a_1)(xor)a_0,a_1)

где k, a_0, a_1 принадлежат V_128.

4.4. Развертывание ключа

При развертывании ключа используются итерационные константы C_i принадлежащие V_128, i=1, 2, …, 32, и определяемые, как

   C_i=L(Vec_128(i))
      i=1,2,...,32

Итерационные ключи (Round key) K_i, i=1, 2, …, 10 создаются на основе ключа K=k_255||…||k_0 принадлежащего V_256, k_i принадлежащих V_1, i=0, 1, …, 255, как показано ниже

   K_1=k_255||...||k_128
   K_2=k_127||...||k_0
   (K_(2i+1),K_(2i+2))=F[C_(8(i-1)+8)]...F[C_(8(i-1)+1)](K_(2i-1),K_(2i))
       i=1,2,3,4

4.5. Базовый алгоритм шифрования

4.5.1. Шифрование

В зависимости от значений итерационных ключей K_1,…,K_10 алгоритм шифрования определяется подстановкой E_(K_1,…,K_10), определяемой как:

E_(K_1,...,K_10)(a)=X[K_10]LSX[K_9]...LSX[K_2]LSX[K_1](a)

где a принадлежит V_128.

4.5.2. Дешифрование

В зависимости от значений итерационных ключей K_1,…,K_10 алгоритм дешифрования определяется подстановкой D_(K_1,…,K_10), определяемой как:

   D_(K_1,...,K_10)(a)=X[K_1]L^-1S^-1X[K_2]... L^-1S^-1X[K_9] L^-1S^-1X[K_10](a)

где a принадлежит V_128.

5. Примеры (для информации)

Приведенная в этом разделе информация не относится к нормативной части стандарта.

5.1. Преобразование S

   S(ffeeddccbbaa99881122334455667700) = b66cd8887d38e8d77765aeea0c9a7efc
   S(b66cd8887d38e8d77765aeea0c9a7efc) = 559d8dd7bd06cbfe7e7b262523280d39
   S(559d8dd7bd06cbfe7e7b262523280d39) = 0c3322fed531e4630d80ef5c5a81c50b
   S(0c3322fed531e4630d80ef5c5a81c50b) = 23ae65633f842d29c5df529c13f5acda

5.2. Преобразование R

   R(00000000000000000000000000000100) = 94000000000000000000000000000001
   R(94000000000000000000000000000001) = a5940000000000000000000000000000
   R(a5940000000000000000000000000000) = 64a59400000000000000000000000000
   R(64a59400000000000000000000000000) = 0d64a594000000000000000000000000

5.3. Преобразование L

   L(64a59400000000000000000000000000) = d456584dd0e3e84cc3166e4b7fa2890d
   L(d456584dd0e3e84cc3166e4b7fa2890d) = 79d26221b87b584cd42fbc4ffea5de9a
   L(79d26221b87b584cd42fbc4ffea5de9a) = 0e93691a0cfc60408b7b68f66b513c13
   L(0e93691a0cfc60408b7b68f66b513c13) = e6a8094fee0aa204fd97bcb0b44b8580

5.4. Развертывание ключа

В этом примере используется ключ

   K = 8899aabbccddeeff0011223344556677fedcba98765432100123456789abcdef

   K_1 = 8899aabbccddeeff0011223344556677
   K_2 = fedcba98765432100123456789abcdef

   C_1 = 6ea276726c487ab85d27bd10dd849401
   X[C_1](K_1) = e63bdcc9a09594475d369f2399d1f276
   SX[C_1](K_1) = 0998ca37a7947aabb78f4a5ae81b748a
   LSX[C_1](K_1) = 3d0940999db75d6a9257071d5e6144a6
   F[C_1](K_1, K_2) = = (c3d5fa01ebe36f7a9374427ad7ca8949, 8899aabbccddeeff0011223344556677)

   C_2 = dc87ece4d890f4b3ba4eb92079cbeb02
   F [C_2]F [C_1](K_1, K_2) = (37777748e56453377d5e262d90903f87,
          c3d5fa01ebe36f7a9374427ad7ca8949)

   C_3 = b2259a96b4d88e0be7690430a44f7f03
   F[C_3]...F[C_1](K_1, K_2) = (f9eae5f29b2815e31f11ac5d9c29fb01,
          37777748e56453377d5e262d90903f87)

   C_4 = 7bcd1b0b73e32ba5b79cb140f2551504
   F[C_4]...F[C_1](K_1, K_2) = (e980089683d00d4be37dd3434699b98f,
          f9eae5f29b2815e31f11ac5d9c29fb01)

   C_5 = 156f6d791fab511deabb0c502fd18105
   F[C_5]...F[C_1](K_1, K_2) = (b7bd70acea4460714f4ebe13835cf004,
          e980089683d00d4be37dd3434699b98f)

   C_6 = a74af7efab73df160dd208608b9efe06
   F[C_6]...F[C_1](K_1, K_2) = (1a46ea1cf6ccd236467287df93fdf974,
          b7bd70acea4460714f4ebe13835cf004)

   C_7 = c9e8819dc73ba5ae50f5b570561a6a07
   F[C_7]...F [C_1](K_1, K_2) = (3d4553d8e9cfec6815ebadc40a9ffd04,
          1a46ea1cf6ccd236467287df93fdf974)

   C_8 = f6593616e6055689adfba18027aa2a08
   (K_3, K_4) = F [C_8]...F [C_1](K_1, K_2) = (db31485315694343228d6aef8cc78c44,
           3d4553d8e9cfec6815ebadc40a9ffd04)

Итерационные ключи K_i для i = 1, 2, …, 10 имеют значения:

   K_1 = 8899aabbccddeeff0011223344556677
   K_2 = fedcba98765432100123456789abcdef
   K_3 = db31485315694343228d6aef8cc78c44
   K_4 = 3d4553d8e9cfec6815ebadc40a9ffd04
   K_5 = 57646468c44a5e28d3e59246f429f1ac
   K_6 = bd079435165c6432b532e82834da581b
   K_7 = 51e640757e8745de705727265a0098b1
   K_8 = 5a7925017b9fdd3ed72a91a22286f984
   K_9 = bb44e25378c73123a5f32f73cdb6e517
   K_10 = 72e9dd7416bcf45b755dbaa88e4a4043

5.5. Тестовое шифрование

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

a = 1122334455667700ffeeddccbbaa9988

тогда

   X[K_1](a) = 99bb99ff99bb99ffffffffffffffffff
   SX[K_1](a) = e87de8b6e87de8b6b6b6b6b6b6b6b6b6
   LSX[K_1](a) = e297b686e355b0a1cf4a2f9249140830
   LSX[K_2]LSX[K_1](a) = 285e497a0862d596b36f4258a1c69072
   LSX[K_3]...LSX[K_1](a) = 0187a3a429b567841ad50d29207cc34e
   LSX[K_4]...LSX[K_1](a) = ec9bdba057d4f4d77c5d70619dcad206
   LSX[K_5]...LSX[K_1](a) = 1357fd11de9257290c2a1473eb6bcde1
   LSX[K_6]...LSX[K_1](a) = 28ae31e7d4c2354261027ef0b32897df
   LSX[K_7]...LSX[K_1](a) = 07e223d56002c013d3f5e6f714b86d2d
   LSX[K_8]...LSX[K_1](a) = cd8ef6cd97e0e092a8e4cca61b38bf65
   LSX[K_9]...LSX[K_1](a) = 0d8e40e4a800d06b2f1b37ea379ead8e

Зашифрованный текст будет иметь вид

b = X[K_10]LSX[K_9]...LSX[K_1](a) = 7f679d90bebc24305a468d42b9d4edcd

5.6. Тестовая расшифровка

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

b = 7f679d90bebc24305a468d42b9d4edcd

тогда

   X[K_10](b) = 0d8e40e4a800d06b2f1b37ea379ead8e
   L^(-1)X[K_10](b) = 8a6b930a52211b45c5baa43ff8b91319
   S^(-1)L^(-1)X[K_10](b) = 76ca149eef27d1b10d17e3d5d68e5a72
   S^(-1)L^(-1)X[K_9]S^(-1)L^(-1)X[K_10](b) = 5d9b06d41b9d1d2d04df7755363e94a9
   S^(-1)L^(-1)X[K_8]...S^(-1)L^(-1)X[K_10](b) = 79487192aa45709c115559d6e9280f6e
   S^(-1)L^(-1)X[K_7]...S^(-1)L^(-1)X[K_10](b) = ae506924c8ce331bb918fc5bdfb195fa
   S^(-1)L^(-1)X[K_6]...S^(-1)L^(-1)X[K_10](b) = bbffbfc8939eaaffafb8e22769e323aa
   S^(-1)L^(-1)X[K_5]...S^(-1)L^(-1)X[K_10](b) = 3cc2f07cc07a8bec0f3ea0ed2ae33e4a
   S^(-1)L^(-1)X[K_4]...S^(-1)L^(-1)X[K_10](b) = f36f01291d0b96d591e228b72d011c36
   S^(-1)L^(-1)X[K_3]...S^(-1)L^(-1)X[K_10](b) = 1c4b0c1e950182b1ce696af5c0bfc5df
   S^(-1)L^(-1)X[K_2]...S^(-1)L^(-1)X[K_10](b) = 99bb99ff99bb99ffffffffffffffffff

Расшифрованный текст имеет вид

a = X[K_1]S^(-1)L^(-1)X[K_2]...S^(-1)L^(-1)X[K_10](b) = 1122334455667700ffeeddccbbaa9988

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

Документ целиком посвящен вопросам безопасности.

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

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

[GOST3412-2015] «Information technology. Cryptographic data security. Block ciphers», GOST R 34.12-2015, Federal Agency on Technical Regulating and Metrology, 2015.

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

[ISO-IEC10116] ISO/IEC, «Information technology — Security techniques – Modes of operation for an n-bit block cipher», ISO/IEC 10116, 2006.

[ISO-IEC18033-1] ISO/IEC, «Information technology — Security techniques – Encryption algorithms — Part 1: General», ISO/IEC 18033-1, 2015.

[ISO-IEC18033-3] ISO/IEC, «Information technology — Security techniques – Encryption algorithms — Part 3: Block ciphers», ISO/IEC 18033-3, 2010.

Адрес автора

Василий Долматов (редактор)

Research Computer Center MSU

Leninskiye Gory, 1, Building 4, MGU NIVC

Moscow 119991

Russian Federation

Email: dol@srcc.msu.ru

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

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

nmalykh@gmail.com

1Используется также термин «биективное». Прим. перев.

2В исходном документе ошибочно сказано «Z». См. RFC Errata. Прим. перев.

Рубрика: RFC | Комментарии отключены

RFC 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields

Опубликовано 05.03.2016 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        T. Mizrahi
Request for Comments: 7822                                       Marvell
Updates: 5905                                                   D. Mayer
Category: Standards Track                        Network Time Foundation
ISSN: 2070-1721                                               March 2016

Network Time Protocol Version 4 (NTPv4) Extension Fields

Поля расширения протокола NTPv4

PDF

Аннотация

Протокол сетевого времени версии 4 (Network Time Protocol version 4 или NTPv4) определяет применение необязательных полей расширения. Полем расширения в соответствии с RFC 5905 является необязательное поле, размещённое в конце заголовка NTP, которое иожет служить для добавления свойств или информации, отсутствующих в стандартном заголовке NTP. Этот документ обновляет RFC 5905, разъясняя некоторые вопросы, связанные с полями расширения NTP и их применения с кодами аутентификации сообщений (Message Authentication Code или MAC).

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

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

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

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

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

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

1. Введение

Формат заголовка NTP включает набор фиксированных полей, за которыми могут следовать необязательные поля. Определено два типа опциональных полей: коды MAC и поля расширения, заданные в параграфе 7.5 [NTPv4].

При использовании MAC этот код размещается в конце пакета. Поле может иметь размер 24 или 20 октетов или содержать 4-октетное значение crypto-NAK.

Поля расширения NTP определены в [NTPv4] как базовый механизм добавления расширений и свойств без изменения формата заголовка NTP (раздел 16 в [NTPv4]).

К настоящему времени определены лишь поля расширения, применяемые протоколом Autokey [Autokey] и Checksum Complement [RFC7821]. За полем расширения Autokey всегда следует MAC и в разделе 10 [Autokey] указаны правила анализа, позволяющие отделить поле расширения от MAC. Однако MAC может не быть за полем расширения, пакет NTPv4 может включать поля расширения без MAC. Это поведение описано в параграфе 7.5 [NTPv4] и в [Err3627], а также дополнительно разъяснено в этом документе.

Этот документ обновляет [NTPv4] (RFC 5905), разъясняя вопросы использования полей расширения. Обновления включают изменения ошибок в части полей расширения, обнаруженных после публикации [NTPv4]. В частности, обновлён параграф 7.5 [NTPv4] с разъяснением связи между полями расширения и кодами MAC, а также определением поведения хоста при получении неизвестного поля расширения.

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

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

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

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

MAC

Message Authentication Code — код проверки подлинности сообщения.

NTPv4

Network Time Protocol version 4 [NTPv4] — протокол сетевого времени версии 4.

3. Поля расширения NTP — обновление RFC 5905

Далее показаны внесённые этим документом изменения в параграфе 7.5 [NTPv4].

Старый текст

7.5. Формат поля расширения NTP

В NTPv4 может присутствовать одно или несколько полей расширения после заголовка и перед кодом MAC, который всегда присутствует при наличии поля расширения. Этот документ определяет лишь формат поля, не задавая его использования. Поле расширения содержит сообщение запроса или отклика в формате, показанном на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Field Type           |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Value                              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Padding (при необходимости)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат поля расширения.

Все поля расширения дополняются нулями до границы слова (4 октета). Поле Field Type определяется заданной функцией и здесь не рассматривается. Хотя минимальный размер поля, содержащего обязательные компоненты, составляет 4 слова (16 октетов), максимальный размер поля ещё не установлен.

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

Новый текст

7.5. Формат поля расширения NTP

В NTPv4 может присутствовать одно или несколько полей расширения после заголовка и перед кодом MAC, если MAC присутствует.

Этот документ определяет лишь формат поля, не задавая его использования. Поле расширения содержит сообщение запроса или отклика в формате, показанном на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Field Type           |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                            Value                              .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Padding (при необходимости)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат поля расширения.

Все поля расширения дополняются нулями до границы слова (4 октета).

Поля Field Type, Value, Padding зависят от заданной функции и не рассматриваются здесь. Значения Field Type заданы в ррестре IANA, а значения Length, Value, Padding определяются указанным в этом реестре документом. Если хост получает поле расширения с неизвестным Field Type, ему следует игнорировать это поле расширения и можно отбросить пакет совсем, если правила требуют этого.

Хотя минимальный размер поля, содержащего обязательные компоненты, составляет 4 слова (16 октетов), максимальный размер не может превышать 65532 октетов по причине ограниченного размера поля Length.

7.5.1. Поля расширения и коды MAC

7.5.1.1. Поля расширения при наличии MAC

Поле расширения может использоваться в пакете NTP с кодом MAC, например, как задано в [Autokey]. Спецификация, определяющая новое поле расширения, должна указывать, требует ли это поле наличия MAC. Если поле расширения требует MAC, спецификация поля должна указывать алгоритм создания и размер MAC. Поле расширения может разрешать применение нескольких алгоритмов и в этом случае сведения об использованном алгоритме должны включаться в само поле расширения.

7.5.1.2. Несколько полей расширения с MAC

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

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

7.5.1.3. MAC без полей расширения

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

7.5.1.4. Поля расширения без MAC

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

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

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

Вопросы безопасности протоколов передачи времени в целом рассмотрены в [SecTime], а вопросы безопасности NTP — в [NTPv4].

Распределенные атаки на отказ в обслуживании (Distributed Denial-of-Service или DDoS) против серверов NTP включают лавинные потоки пакетов NTP с высокой скоростью. Злонамеренное применение полей расширения не может усиливать такие атаки, поскольку серверы смягчают их, игнорируя неизвестные поля (см. раздел 3), и отвечают при необходимости лишь известными полями расширения. Поля расширения из входящих пакетов серверы NTP не распространяют и не включают в отклики. Серверы NTP создают свои поля расширения, если это нужно для отклика. Большое число полей расширения серверу NTP следует помечать как возможную атаку. Большой размер полей расширения также следует помечать, если он не был ожидаемым.

Промежуточным устройствам, таким как межсетевые экраны, недопустимо фильтровать пакеты NTP по полям расширения. Таким устройствам не следует проверять поля расширения в пакетах, поскольку пакеты NTP могут содержать новые поля расширения, ещё не известные промежуточному устройству.

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

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

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

[NTPv4] 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, <http://www.rfc-editor.org/info/rfc5905>.

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

[Autokey] Haberman, B., Ed., and D. Mills, «Network Time Protocol Version 4: Autokey Specification», RFC 5906, DOI 10.17487/RFC5906, June 2010, <http://www.rfc-editor.org/info/rfc5906>.

[Err3627] RFC Errata, Erratum ID 3627, RFC 5905.

[RFC7821] Mizrahi, T., «UDP Checksum Complement in the Network Time Protocol (NTP)», RFC 7821, DOI 10.17487/RFC7821, March 2016, <http://www.rfc-editor.org/info/rfc7821>.

[SecTime] Mizrahi, T., «Security Requirements of Time Protocols in Packet Switched Networks», RFC 7384, DOI 10.17487/RFC7384, October 2014, <http://www.rfc-editor.org/info/rfc7384>.

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

Авторы признательны Dave Mills за важные замечания. Спасибо также Tim Chown, Sean Turner, Miroslav Lichvar, Suresh Krishnan, Jari Arkko за их рецензии и полезные комментарии.

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

Tal Mizrahi

Marvell

6 Hamada St.

Yokneam, 20692

Israel

Email: talmi@marvell.com

Danny Mayer

Network Time Foundation

PO Box 918

Talent, OR 97540

United States

Email: mayer@ntp.org

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 7821 UDP Checksum Complement in the Network Time Protocol (NTP)

Опубликовано 05.03.2016 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        T. Mizrahi
Request for Comments: 7821                                       Marvell
Category: Experimental                                        March 2016
ISSN: 2070-1721

UDP Checksum Complement in the Network Time Protocol (NTP)

Дополнение контрольной суммы UDP в NTP

PDF

Аннотация

Протокол сетевого времени (Network Time Protocol или NTP) позволяет синхронизировать клиентов с сервером времени с помощью протокольных сообщений с временными метками. Для повышения точности временных меток в некоторых реализациях применяются аппаратные средства создания меток времени, встраивающие точное время передачи в каждый исходящий пакет NTP. Поскольку эти пакеты доставляются по протоколу UDP, поле Checksum обновляется с учётом вставки временной метки. Этот документ предлагает использовать 2 последних октета каждого пакета как дополнение контрольной суммы (Checksum Complement), что позволяет средствам записи временных меток возможность отразить изменение контрольной суммы в этих 2 октетах, а не в поле UDP Checksum. Задаваемое этим документом поведение полностью совместимо с имеющимися реализациями NTP.

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

Документ не относится к категории Internet Standards Track и публикуется лишь для проверки, экспериментальной реализации и оценки.

Документ содержит экспериментальный протокол для сообщества Internet и является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 5741.

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

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

1. Введение

Протокол Network Time Protocol [NTPv4] позволяет клиентам синхронизировать свои часы с сервером точного времени путём обмена пакетами NTP. Рост требований к точности синхронизации часов служит мотивом для повышения точности меток времени.

1.1. Промежуточные элементы

В этом документе термин «промежуточный элемент» (intermediate entity) означает элемент на пути между отправителем и получателем пакета NTP, меняющим этот пакет.

             Клиент или сервер  NTP
               +-------------------+
               |                   |
               |   +-----------+   |
Программа      |   | Протокол  |   |
               |   |    NTP    |   |
               |   +-----+-----+   |
               |         |         |     +-----------------------+
               |   +-----+-----+   |    / Промежуточный элемент  |
               |   |  Модуль   |   |   /  отвечающий за          |
ASIC/FPGA      |   | временных |   |  /__ - обновление           |
               |   |   меток   |   |     |- контрольной суммы или|
               |   +-----------+   |     |  Checksum Complement  |
               |         |         |     +-----------------------+
               +---------+---------+
                         |
                         |Тестовые пакеты
                         |
                     ___ v _
                    /   \_/ \__
                   /           \_
                  /    Сеть     /
                  \_    IP     /
                   /           \
                   \__/\_   ___/
                         \_/

ASIC: Application-Specific Integrated Circuit
FPGA: Field-Programmable Gate Array

Рисунок 1. Точная установка временных меток в NTP.

Для повышения точности меток времени реализация может использовать аппаратный модуль временных меток (timestamping engine), как показано на рисунке 1. В таких случаях пакеты NTP передаются и принимаются на программном уровне, а аппаратный модуль меток меняет каждый исходящий пакет NTP, встраивая точное время передачи в поле пакета <Transmit Timestamp>.

Точность синхронизации часов через пакетную сеть сильно зависит от вариаций задержки в базовой сети и это сильно влияет на точность измерения времени. Для решения этой проблемы протокол точного времени (Precision Time Protocol или PTP) [IEEE1588] определяет «прозрачные часы» (Transparent Clock или TC) — коммутаторы и маршрутизаторы, которые повышают сквозную точность часов, обновляя поле корректировки Correction Field в пакете PTP путём добавления задержки, внесённой текущими часами TC. В NTP эквивалентных элементов в настоящее время нет, но в будущие версии NTP могут быть добавлены промежуточные узлы, меняющие пакеты NTP «на лету» с использованием поля Correction Field.

1.2. Обновление UDP Checksum

Когда данные UDP (payload) изменяются промежуточным узлом, таким как модуль меток времени, поле UDP Checksum должно соответственно обновляться. При использовании UDP по протоколу IPv4 [UDP] у промежуточного узла, не способного обновить значение UDP Checksum не остаётся вариантов кроме установки значения 0 в поле Checksum, заставляющего получателя игнорировать поле Checksum и, возможно, принимать повреждённые пакеты. UDP по протоколу IPv6, как указано в [IPv6], не разрешает значение 0 для контрольной суммы за исключением особых случаев [ZeroChecksum]. Как отмечено в [ZeroChecksum], использование нулевой контрольной суммы в общем случае не рекомендуется и его следует избегать, когда это возможно.

Поскольку промежуточный элемент меняет лишь конкретное поле пакета (Timestamp), обновление UDP Checksum можно выполнить инкрементно с использованием концепций, представленных в [Checksum].

Этот документ определяет Checksum Complement для [NTPv4]. Поле Checksum Complement является 2-октетным полем, комещаемым в конце данных UDP (payload). Это позволяет промежуточным элементам обновлять пакеты NTP и сохранять корректность UDP Checksum путём изменения 2 последних октетов в пакете вместо обновления поля UDP Checksum. Это реализуется путём добавления поля расширения NTP в конце пакета, где 2 последних октета используются как дополнение контрольной суммы (Checksum Complement).

Использование Checksum Complement позволяет в некоторых случаях упростить реализацию, поскольку при последовательной обработке данных пакета проще сначала обновить поле Timestamp, а затем — Checksum Complement вместо обновления временной метки и последующего обновления поля UDP Checksum в заголовке UDP. Отметим, что несмотря на невозможность аппаратной реализации модуля меток времени, обновляющего UDP Checksum, использование Checksum Complement может существенно упростить реализацию.

Отметим, что программный уровень и промежуточный элемент (Рисунок 1) являются модулями одних часов NTP. Это предполагает согласованность обоих модулей в части включения поля Checksum Complement при передаче пакетов NTP.

В [RFC7820] определён механизм Checksum Complement для протоколов односторонних активных измерений (One-Way Active Measurement Protocol или OWAMP) и двухсторонних активных измерений (Two-Way Active Measurement Protocol или TWAMP). Похожий механизм представлен в приложении E к [IEEE1588].

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

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

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

MAC

Message Authentication Code — код проверки подлинности сообщения.

NTP

Network Time Protocol — протокол сетевого времени.

PTP

Precision Time Protocol — протокол точного времени.

UDP

User Datagram Protocol — протокол пользовательских дейтаграмм.

3. Применение UDP Checksum Complement в NTP

3.1. Обзор

UDP Checksum Complement представляет собой 2-октетное поле, добавляемое в конец данных UDP, с использованием поля расширения NTP. На рисунке 2 показан формат пакета NTP с расширением Checksum Complement.

         +----------------------------------+
         |       Заголовок IPv4/IPv6        |
         +----------------------------------+
         |         Заголовок UDP            |
         +----------------------------------+
  ^      |              Пакет               |
  |      |               NTP                |
  |      |                                  |
  |      +----------------------------------+
  UDP    | Необязательные поля NTP Extension|
Payload  +----------------------------------+
  |      |   Поле расширения UDP Checksum   |
  |      |   Complement (28 октетов)        |
  v      +----------------------------------+

Рисунок 2. Checksum Complement в пакетах NTP.

Поле Checksum Complement служит для компенсации изменений, внесённых в пакет NTP промежуточными элементами, как описано в разделе 1. Пример использования Checksum Complement представлен в Приложении A.

3.2. Checksum Complement в пакетах NTP

Пакеты NTP передаются по протоколу UDP с использованием IPv4 или IPv6. Этот документ применим к обоим вариантам использования NTP.

Пакеты NTP могут включать поля расширения, как определено в [NTPv4]. Checksum Complement в пакетах NTP размещается в выделенном поле расширения NTP, как показано на рисунке 3.

Если пакет NTP включает более одного поля расширения, Checksum Complement всегда является последним полем. Таким образом, поле Checksum Complement — это 2 последних октета данных UDP, расположенные со смещением (UDP Length — 2) от начала заголовка UDP. Отметим, что Checksum Complement не применяется в аутентифицированных пакетах NTP (см. параграф 3.4).

3.2.1. Использование Checksum Complement

Как указано в разделе 1, промежуточный элемент, который обновляет временную метку в пакете NTP, может использовать Checksum Complement для сохранения корректности поля UDP Checksum. В частности. При обновлении временной метки это вызывает изменение значения UDP Checksum. Таким образом, промежуточный элемент задаёт новое значение Checksum Complement для компенсации этого изменения, сохраняя корректность текущего поля UDP Checksum. Пример использования Checksum Complement представлен в Приложении A.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Field Type           |      Length = 28 октетов      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              MBZ                              |
|                                                               |
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |      Checksum Complement      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Поле расширения NTP Checksum Complement.

Field Type

Для указания расширения Checksum Complement применяется выделенное значение Field Type (раздел 5).

Length

Размер поля расширения Checksum Complement составляет 28 октетов. Это гарантирует корректный анали принятых пакетов получателем независимо от наличия в них кода MAC. Дополнительные детали относительно размера поля расширения при отсутствии MAC приведены в [RFC7822].

MBZ

Это поле расширения включает 22 октета MBZ (MUST be zero — должно быть 0). В этом поле отправитель должен устанавливать 0, а получатель должен игнорировать поле. Поле MBZ служит для заполнения поля расширения до 28 октетов.

Checksum Complement

расширение Checksum Complement включает поле Checksum Complement, размещающееся в 2 последних октетах.

3.2.2. Передача NTP с Checksum Complement

Передатчик пакета NTP может включать поле расширения Checksum Complement.

3.2.3. Обновление NTP с Checksum Complement

Промежуточный элемент, получающий и изменяющий пакет NTP с расширением Checksum Complement может использовать поле Checksum Complement для сохранения корректности значения UDP Checksum.

3.2.4. Приём NTP с Checksum Complement

Этот документ не задаёт дополнительных требований к приёму пакетов NTP.

Уровень UDP на приёмной стороне проверяет значение UDP Checksum в полученных пакетах NTP, а уровню NTP следует игнорировать поле расширения Checksum Complement.

3.3. Совместимость с имеющимися реализациями

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

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

3.4. Checksum Complement и проверка подлинности

Checksum Complement недопустимо применять при включённой проверке подлинности. Поле Checksum Complement полезно в режиме без аутентификации, позволяя промежуточным элементам последовательно обрабатывать пакет без записи и пересылки.

При использовании аутентификации промежуточный узел, изменяющий пакет NTP, должен пересчитать код MAC. В этом случае невозможно обновить поле Checksum Complement, поскольку это изменение требует повторного расчёта MAC и вносит циклическую зависимость между MAC и Checksum Complement. Т. е. при обновлении MAC необходимо обновить поле UDP Checksum, что делает поле Checksum Complement ненужным при использовании аутентификации.

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

Этот документ описывает использование расширения Checksum Complement для обеспечения корректности UDP Checksum. Вопросы безопасности протоколов передачи времени в целом рассмотрены в [SecTime], а вопросы безопасности NTP — в [NTPv4].

Целью этого расширения является упрощение реализации модулей точных временных меток, как показано на рисунке 1. Расширение предназначено для внутреннего использования клиентами или серверами NTP и не рассчитано на промежуточные коммутаторы или маршрутизаторы между клиентом и сервером. В отличие от PTP [IEEE1588], протокол NTP не требует промежуточных коммутаторов или маршрутизаторов для изменения содержимого пакетов NTP, поэтому такие изменение следует рассматривать как вредоносную MITM-атаку (man-in-the-middle).

Важно подчеркнуть, что описанная здесь схема не повышает уровень уязвимости протоколов к MITM-атакам. Злоумышленник MITM, злонамеренно изменяющий пакет и Checksum Complement в нем, логически эквивалентен злоумышленнику MITM, который меняет пакет и его поле UDP Checksum.

Описанная в документе концепция предназначена лишь для применения в режиме unauthenticated. Как указано в параграфе 3.4, при использовании криптографических механизмов защиты Checksum Complement не упрощает реализации со сравнению с традиционным расчётом контрольных сумм, поэтому Checksum Complement не применяется в этом случае.

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

Агентство IANA выделило в реестре NTP Extension Field Types новое значение

      0x2005 Checksum Complement

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

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

[Checksum] Rijsinghani, A., Ed., «Computation of the Internet Checksum via Incremental Update», RFC 1624, DOI 10.17487/RFC1624, May 1994, <http://www.rfc-editor.org/info/rfc1624>.

[IPv6] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

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

[RFC7822] Mizrahi, T. and D. Mayer, «Network Time Protocol Version 4 (NTPv4) Extension Fields», RFC 7822, DOI 10.17487/RFC7822, March 2016, <http://www.rfc-editor.org/info/rfc7822>.

[UDP] Postel, J., «User Datagram Protocol», STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, <http://www.rfc-editor.org/info/rfc768>.

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

[IEEE1588] IEEE, «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.

[RFC7820] Mizrahi, T., «UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)», RFC 7820, DOI 10.17487/RFC7820, March 2016, <http://www.rfc-editor.org/info/rfc7820>.

[SecTime] Mizrahi, T., «Security Requirements of Time Protocols in Packet Switched Networks», RFC 7384, DOI 10.17487/RFC7384, October 2014, <http://www.rfc-editor.org/info/rfc7384>.

[ZeroChecksum] Fairhurst, G. and M. Westerlund, «Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums», RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.

Приложение A. Пример использования Checksum Complement

Рассмотрим пакет NTP, переданный от клиента серверу NTP.

Программный уровень клиента (Рисунок 1) генерирует пакет NTP с Origin Timestamp T и UDP Checksum U. Значение U учитывает заголовок и данные UDP, а также псевдозаголовок. Таким образом,

                        U = Const + checksum(T)                      (1)

где Const — контрольная сумма всех охватываемых полей, за исключением T.

Напомним, что программа отправителя выдаёт тестовый пакет с полем Checksum Complement, которое представляет собой просто 2 последних октета заполнения. В этом примере предполагается, что отправитель заполнил эти октеты нулями.

Модуль временных меток отправителя обновляет поле Timestamp точным знасением, меняя T на T’, а также обновляет поле Checksum Complement, помещая вместо 0 значение C, так что

                  checksum(C) = checksum(T) - checksum(T')           (2)

Когда модуль временных меток отправителя передаёт пакет, значение контрольной суммы U остаётся прежним

      U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
          checksum(T') = Const + checksum(T') + checksum(C)          (3)

Таким образом, после обновления метки времени модулем меток значение U в пакете остаётся корректным.

Когда тестовый пакет приходит к получателю, тот выполняет обычный расчёт UDP Checksum и получает значение U. Поскольку Checksum Complement является частью заполнение, значение checksum(C) «прозрачно» включается в расчёт в соответствии с уравнением (3) без специальных действий сервера.

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

Автор признателен Danny Mayer, Miroslav Lichvar, Call Kyzivat, Suresh Krishnan, Brian Haberman за рецензии и полезные комментарии.

Адрес автора

Tal Mizrahi

Marvell

6 Hamada St.

Yokneam, 20692

Israel

Email: talmi@marvell.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC, Измерения и тестирование | Оставить комментарий

RFC 7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)

Опубликовано 05.03.2016 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                        T. Mizrahi
Request for Comments: 7820                                       Marvell
Category: Experimental                                        March 2016
ISSN: 2070-1721

UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)

Дополнение контрольной суммы UDP в протоколах OWAMP и TWAMP

PDF

Аннотация

Протоколы одностороннего активного измерения задержки (One-Way Active Measurement Protocol или OWAMP) и двухстороннего активного измерения задержки (Two-Way Active Measurement Protocol или TWAMP) служат для мониторинга производительности в сетях IP. Измерение задержки в этих протоколах выполняется по тестовым пакетам с временными метками. В некоторых реализациях применяются аппаратные средства создания меток времени, встраивающие точное время передачи в каждый исходящий тестовый пакет OWAMP или TWAMP. Поскольку эти пакеты доставляются по протоколу UDP поле Checksum обновляется с учётом вставки временной метки. Этот документ предлагает использовать 2 последних октета каждого тестового пакета как дополнение контрольной суммы (Checksum Complement), что позволяет средствам записи временных меток возможность отразить изменение контрольной суммы в этих 2 октетах, а не в поле UDP Checksum. Задаваемое этим документом поведение полностью совместимо с имеющимися реализациями OWAMP и TWAMP.

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

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

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

1. Введение

Протоколы OWAMP [OWAMP] и TWAMP [TWAMP] применяются для мониторинга производительности сетей IP.

Задержка и её вариации являются показателями, которые могут измерять OWAMP и TWAMP. Измерение выполняется с использованием временных меток в тестовых пакетах. В некоторых вариантах применения, таких как сети операторов, эти два показателя являются важной частью соглашений об уровне обслуживания (Service Level Agreement или SLA) и поэтому должны измеряться с высокой точностью. Если метки времени включаются в пакеты на аппаратном уровне при выходе пакета с хоста, это может существенно повысить точность по сравнению с метками времени от вышележащих уровней, как описано ниже.

Точность измерения задержки зависит от меток времени и их реализации. Для точной установки меток реализация может использовать аппаратный модуль временных меток (timestamping engine), как показано на рисунке 1. В таких случаях пакеты OWAMP/TWAMP передаются и принимаются на программном уровне, а аппаратный модуль меток меняет каждый исходящий пакет, встраивая точное время передачи в поле пакета Timestamp.

             Узел с поддержкой OWAMP/TWAMP
               +-------------------+
               |                   |
               |   +-----------+   |
Программа      |   | Протокол  |   |
               |   |OWAMP/TWAMP|   |
               |   +-----+-----+   |
               |         |         |     +-----------------------+
               |   +-----+-----+   |    / Промежуточный элемент  |
               |   |  Модуль   |   |   /  отвечающий за          |
ASIC/FPGA      |   | временных |   |  /__ - обновление           |
               |   |   меток   |   |     |- контрольной суммы или|
               |   +-----------+   |     |  Checksum Complement  |
               |         |         |     +-----------------------+
               +---------+---------+
                         |
                         |Тестовые пакеты
                         |
                     ___ v _
                    /   \_/ \__
                   /           \_
                  /    Сеть     /
                  \_    IP     /
                   /           \
                   \__/\_   ___/
                         \_/

ASIC: Application-Specific Integrated Circuit
FPGA: Field-Programmable Gate Array

Рисунок 1. Точная установка временных меток в OWAMP и TWAMP.

Тестовые пакеты OWAMP/TWAMP передаются по протоколу UDP. Когда данные UDP (payload) изменяются промежуточным узлом, таким как модуль меток времени, поле UDP Checksum должно соответственно обновляться. При использовании UDP по протоколу IPv4 [UDP] у промежуточного узла, не способного обновить значение UDP Checksum не остаётся вариантов кроме установки значения 0 в поле Checksum, заставляющего получателя игнорировать поле Checksum и, возможно, принимать повреждённые пакеты. UDP по протоколу IPv6, как указано в [IPv6], не разрешает значение 0 для контрольной суммы за исключением особых случаев [ZeroChecksum]. Как отмечено в [ZeroChecksum], использование нулевой контрольной суммы в общем случае не рекомендуется и его следует избегать, когда это возможно.

Аналогичная задача рассматривается в Приложении E к [IEEE1588]. При работе протокола точного времени (Precision Time Protocol или PTP) по протоколу IPv6 добавляются 2 октета в конец данных PTP для обновления UDP Checksum. Значение этих 2 октетов может обновляться промежуточным узлом для сохранения корректности поля UDP Checksum.

Этот документ задаёт похожий подход для протоколов [OWAMP] и [TWAMP], позволяющий промежуточным элементам обновлять тестовые пакеты OWAMP/TWAMP и поддерживать корректность UDP Checksum путем изменения двух последних октетов в пакете.

Термин Checksum Complement (дополнение контрольной суммы) в этом документе относится к 2 октетам в конце данных UDP, используемым для обновления UDP Checksum промежуточными узлами.

Механизм Checksum Complement определён также для протокола сетевого времени (Network Time Protocol) в [RFC7821].

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

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

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

HMAC

Hashed Message Authentication Code — хэшированный код проверки подлинности сообщения.

OWAMP

One-Way Active Measurement Protocol — односторонний протокол активных измерений.

PTP

Precision Time Protocol — протокол точного времени.

TWAMP

Two-Way Active Measurement Protocol — двухсторонний протокол активных измерений.

UDP

User Datagram Protocol — протокол пользовательских дейтаграмм.

3. Применение UDP Checksum Complement в OWAMP и TWAMP

3.1. Обзор

UDP Checksum Complement представляет собой 2-октетное поле, добавляемое в конец тестового пакета. Оно будет занимать 2 последних октета данных UDP (payload).

         +----------------------------------+
         |       Заголовок IPv4/IPv6        |
         +----------------------------------+
         |         Заголовок UDP            |
         +----------------------------------+
  ^      |              Пакет               |
  |      |           OWAMP/TWAMP            |
 UDP     |                                  |
Payload  +----------------------------------+
  |      |UDP Checksum Complement (2 октета)|
  v      +----------------------------------+

Рисунок 2. Checksum Complement в пакетах OWAMP/TWAMP.

Поле Checksum Complement служит для компенсации изменений, внесённых в пакет промежуточными элементами, как описано в разделе 1. Пример использования Checksum Complement представлен в Приложении A.

3.2. Тестовые пакеты OWAMP и TWAMP с Checksum Complement

Протоколы OWAMP [OWAMP] и TWAMP [TWAMP] используют пакеты с метками времени. Поле Checksum Complement можно использовать в следующих случаях:

в тестовых пакетах OWAMP от отправителя к получателю;
в тестовых пакетах TWAMP от отправителя к рефлектору;
в тестовых пакетах TWAMP от рефлектора к отправител.

Тестовые пакеты OWAMP/TWAMP передаются по протоколу UDP с использованием IPv4 или IPv6. Этот документ применим к обоим вариантам использования OWAMP и TWAMP (IPv4 и IPv6).

Тестовые пакеты OWAMP/TWAMP включают поле заполнения Packet Padding. Этот документ предлагает использовать два последних октета поля Packet Padding в качестве Checksum Complement. В этом случае Checksum Complement всегда будет занимать 2 последних октета данных UDP и размещаться со смещением (UDP Length — 2 ) от начала заголовка UDP.

На рисунке 3 показан тестовый пакет OWAMP с полем UDP Checksum Complement.

 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         |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
.                         Packet Padding                        .
.                                                               .
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |      Checksum Complement      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Checksum Complement в тестовом пакете OWAMP.

На рисунке 4 показан тестовый пакет TWAMP с полем UDP Checksum Complement (TTL означает Time to Live — время жизни, а MBZ — MUST be zero — должно быть 0 [IPPMIPsec]).

 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        |           MBZ                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Receive Timestamp                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Sender Sequence Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sender Timestamp                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sender Error Estimate    |           MBZ                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sender TTL   |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
.                                                               .
.                         Packet Padding                        .
.                                                               .
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     Checksum Complement       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Checksum Complement в тестовом пакете TWAMP.

Размер поля Packet Padding в тестовых пакетах анонсируется при организации сессии через поле <Padding Length> в сообщении Request-Session [OWAMP] или Request-TW-Session [TWAMP].

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

В OWAMP размер заполнения составляет не менее 2 октетов, что позволяет отправителю внедрить Checksum Complement в последние 2 октета заполнения.
В TWAMP размер заполнения составляет не менее 29 октетов в режиме без аутентификации и не менее 58 в режиме с аутентификацией. Дополнительное заполнение требуется потому, что заголовок тестовых пакетов рефлектора больше заголовка тестовых пакетов отправителя. Различие размеров этих заголовков составляет 27 октетов в режиме без аутентификации и 56 октетов при использовании аутентификации. Таким образом, заполнение в тестовых пакетах рефлектора короче заполнения в тестовых пакетах отправителя. Использование не менее 29 октетов заполнения (58 в режиме authenticated) в тестовых пакетах отправителя позволяет отправителю и рефлектору использовать 2-октетное поле Checksum Complement. Отметим, что при невыполнении этого требования рефлектор не может использовать Checksum Complement в отражённых тестовых пакетах, но отправителю можно включать Checksum Complement в передаваемые тестовые пакеты.
В [TWAMP-Reflect] определены два необязательных свойства TWAMP: отражение октетов (octet reflection) и симметричный размер. При включении хотя бы одной из этих возможностей сообщение Request-TW-Session содержит поле <Padding Length>, а также поле <Length of padding to reflect>. В этом случае оба поля должны иметь достаточно большие значения, чтобы использовалось не менее 2 октетов заполнения у отправителя и рефлектора тестовых пакетов. В частности, при включённом отражении октетов должны быть определены два поля Length так, чтобы заполнение занимало хотя бы 2 последних октета после отражённых октетов.

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

3.2.1. Передача OWAMP/TWAMP с Checksum Complement

Передатчик тестового пакета OWAMP/TWAMP может включать поле Checksum Complement в последние 2 октета заполнения.

Передатчик, включающий Checksum Complement в свои исходящие пакеты, должен включать в эти пакеты поле Packet Padding, размер которого должен позволять включение Checksum Complement. Размер поля Packet Padding согласуется при организации сессии, как указано в параграфе 3.2.

3.2.2. Промежуточное обновление OWAMP/TWAMP с Checksum Complement

Промежуточный элемент, получающий и изменяющий тестовый пакет OWAMP/TWAMP, может изменить поле UDP Checksum или поле Checksum Complement для обеспечения корректности значения UDP Checksum.

3.2.3. Приём OWAMP/TWAMP с Checksum Complement

Этот документ не задаёт дополнительных требований к приёму тестовых пакетов OWAMP/TWAMP.

Уровень UDP на приёмной стороне проверяет значение UDP Checksum в полученных пакетах, а уровню OWAMP/TWAMP следует считать Checksum Complement частью заполнения.

3.3. Совместимость с имеющимися реализациями

Поведение, заданное в этом документе, не вносит дополнительных требований к поведению при получении тестовых пакетов OWAMP/TWAMP. Стек протоколов принимающего хоста выполняет обычную проверку UDP Checksum, т. е. с его точки зрения наличие поля Checksum Complement не заметно. Поэтому функциональность, описанная в этом документе, позволяет взаимодействовать с узлами, соответствующими [OWAMP] или [TWAMP].

3.4. Применение Checksum Complement с аутентификацией и без неё

Протоколы OWAMP и TWAMP могут использовать аутентификацию или шифрование в соответствии с [OWAMP] и [TWAMP].

3.4.1. Checksum Complement в режиме Authenticated Mode

Подлинность тестовых пакетов OWAMP и TWAMP можно проверять с использованием HMAC (Hashed Message Authentication Code). Код HMAC охватывает некоторые поля заголовка тестового пакета, не учитывая поля Timestamp и Packet Padding.

Checksum Complement можно использовать при включённой аутентификации. В этом случае промежуточный элемент может внедрить метку времени и обновить поле Checksum Complement без изменения HMAC.

3.4.2. Checksum Complement в режиме Encrypted Mode

При работе OWAMP и TWAMP в режиме шифрования поле Timestamp также шифруется.

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

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

Примечание. Хотя протоколы [OWAMP] и [TWAMP] имеют встроенные механизмы защиты, они могут использовать дополнительные меры, такие как [IPPMIPsec]. По причинам, указанным выше, применять Checksum Complement в таких случаях не следует.

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

Этот документ описывает использование расширения Checksum Complement для обеспечения корректности UDP Checksum.

Целью этого расширения является упрощение реализации модулей точных временных меток, как показано на рисунке 1. Расширение предназначено для внутреннего использования узлами с поддержкой OWAMP/TWAMP и не рассчитано на промежуточные коммутаторы или маршрутизаторы между отправителем и получателем (рефлектором). Любое изменение тестового пакета промежуточным коммутатором или маршрутизатором следует рассматривать как вредоносную MITM-атаку (man-in-the-middle).

Описанная в документе концепция предназначена лишь для применения в режиме unauthenticated или authenticated. Как указано в параграфе 3.4.2, Checksum Complement в режиме encrypted не упрощает реализацию по сравнению с использованием традиционных контрольных сумм, поэтому применять Checksum Complement в этом режиме не следует.

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

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

[Checksum] Rijsinghani, A., Ed., «Computation of the Internet Checksum via Incremental Update», RFC 1624, DOI 10.17487/RFC1624, May 1994, <http://www.rfc-editor.org/info/rfc1624>.

[IPv6] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

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

[OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, DOI 10.17487/RFC4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.

[TWAMP] 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, <http://www.rfc-editor.org/info/rfc5357>.

[TWAMP-Reflect] Morton, A. and L. Ciavattone, «Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features», RFC 6038, DOI 10.17487/RFC6038, October 2010, <http://www.rfc-editor.org/info/rfc6038>.

[UDP] Postel, J., «User Datagram Protocol», STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, <http://www.rfc-editor.org/info/rfc768>.

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

[IEEE1588] IEEE, «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.

[IPPMIPsec] Pentikousis, K., Ed., Zhang, E., and Y. Cui, «IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)», RFC 7717, DOI 10.17487/RFC7717, December 2015, <http://www.rfc-editor.org/info/rfc7717>.

[RFC7821] Mizrahi, T., «UDP Checksum Complement in the Network Time Protocol (NTP)», RFC 7821, DOI 10.17487/RFC7821, March 2016, <http://www.rfc-editor.org/info/rfc7821>.

Приложение A. Пример использования Checksum Complement

Рассмотрим сессию между отправителем и получателем OWAMP, где отправитель передаёт тестовые пакеты получателю.

Программный уровень отправителя генерирует тестовый пакет OWAMP с временной меткой T и UDP Checksum = U. Значение U является контрольной суммой заголовка и данных UDP, а также псевдозаголовка. Таким образом,

                        U = Const + checksum(T)                      (1)

где Const — контрольная сумма всех охватываемых полей, за исключением T.

                  checksum(C) = checksum(T) - checksum(T')           (2)

Когда модуль временных меток отправителя передаёт пакет, значение контрольной суммы U остаётся прежним

      U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
          checksum(T') = Const + checksum(T') + checksum(C)          (3)

Таким образом, после обновления метки времени модулем меток значение U в пакете остаётся корректным.

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

Автор признателен Al Morton, Greg Mirsky, Steve Baillargeon, Brian Haberman, Spencer Dawkins за полезные замечания.

Адрес автора

Tal Mizrahi

Marvell

6 Hamada St.

Yokneam, 20692

Israel

Email: talmi@marvell.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)

Опубликовано 18.02.2016 автором Nikolai Malykh

Документ признан устаревшим и заменен RFC 7935.

Рубрика: RFC | Комментарии отключены

RFC 7803 Changing the Registration Policy for the NETCONF Capability URNs Registry

Опубликовано 09.02.2016 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                          B. Leiba
Request for Comments: 7803                           Huawei Technologies
BCP: 203                                                   February 2016
Updates: 6241
Category: Best Current Practice
ISSN: 2070-1721

Changing the Registration Policy for the NETCONF Capability URNs Registry

Изменение политики регистрации для реестра NETCONF Capability URNs

PDF

Аннотация

Политика регистрации для реестра «Network Configuration Protocol (NETCONF) Capability URNs», заданная RFC 6241, оказалась излишне строгой. Этот документ заменяет процедуру регистрации на «IETF Review», разрешающую регистрировать значения на основе получивших положительные отзывы экспериментальных (Experimental) RFC в дополнение к Standards Track RFC.

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

Документ относится к категории Internet Best Current Practice.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о BCP можно найти в разделе 2 в RFC 5741.

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

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

1. Введение

Реестр «Network Configuration Protocol (NETCONF) Capability URNs» [RFC6241] был создан с политикой регистрации «Standards Action» [RFC5226], позволяющей регистрацию лишь на основе Standards Track RFC. Это требует тщательного анализа спецификаций, запрашивающих регистрацию NETCONF Capability URN. На практике оказалось желательным выделять URN возможностей также для некоторых экспериментальных RFC при условии тщательного рецензирования спецификаций. Существующая политика регистрации оказалась излишне строгой, и требовала обработки исключительно в IESG. Данный документ меняет процедуру регистрации на «IETF Review», что позволяет регистрировать значения из некоторых, получивших положительные рецензии экспериментальных (Experimental) RFC или, например, исправлять ошибки в реестре на основе информационных (Informational) RFC с рецензией и согласием IETF.

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

Агентство IANA сменило политику регистрации в реестре «Network Configuration Protocol (NETCONF) Capability URNs» на «IETF Review» и добавило этот документ в поле ссылок реестра.

Регистрации на основе RFC, не относящихся к категории Standards Track, требуют тщательной проверки с использованием процедуры «IETF Last Call» и консультаций с соответствующими рабочими группами, такими как NETCONF. Руководителям направлений по операциям и управлению (Operations and Management Area Director) следует подтверждать получение документом соответствующих отзывов в процессе оценки IESG.

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

Этот документ является процедурным и не связан с вопросами безопасности.

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

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[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, <http://www.rfc-editor.org/info/rfc6241>.

Адрес автора

Barry Leiba

Huawei Technologies

Phone: +1 646 827 0648

Email: barryleiba@computer.org

URI: http://internetmessagingtechnology.org/

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

Рубрика: RFC | Комментарии отключены

RFC 7750 Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)

Опубликовано 06.02.2016 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                          J. Hedin
Request for Comments: 7750                                     G. Mirsky
Updates: 5357                                            S.  Baillargeon
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                            February 2016

Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP)

Мониторинг DSCP и ECN в TWAMP

PDF

Аннотация

Этот документ описывает необязательное расширение для протокола двухсторонних активных измерений (Two-Way Active Measurement Protocol или TWAMP), позволяющее отслеживать поля DSCP и ECN в протоколе TWAMP-Test.

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

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

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

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

1. Введение

Протокол OWAMP [RFC4656] определяет поле Type-P Descriptor и согласует его значение через протокол OWAMP-Control. В протоколе TWAMP [RFC5357] указано, что лишь значение кода DSCP (см. [RFC2474], [RFC3168], [RFC3260]) может быть задано в Type-P Descriptor и согласованное значение должны использовать как Session-Sender, так и Session-Reflector. В спецификации TWAMP также указано, что это же значение DSCP (из пакета Session-Sender) должно применяться а пакетах, отраженных Session-Reflector. Однако протокол TWAMP-Test не задаёт какого-либо метода обнаружения и информирования при смене значения DSCP или применении отличного от ожидаемого значения в прямом или обратном направлении. Перемаркировка DSCP (смена значения) возможна в сетях IP и часто выполняется политикой дифференцированного обслуживания на одном из узлов пути IP. Во многих случаях смена кода DSCP говорит о непреднамеренных или ошибочных действиях. В лучшем случае Session-Sender может обнаружить смену DSCP в обратном направлении, предполагая, что такое обнаружение действительно возможно.

В этом документе описана необязательная функция TWAMP, называемая DSCP and ECN Monitoring. Она позволяет отправителю Session-Sender знать фактическое значение DSCP, полученное на стороне Session-Reflector. Кроме того, эта функция отслеживает значение ECN (см. [RFC2474], [RFC3168], [RFC3260]), полученное Session-Reflector. Это полезно для определения работы ECN и фактического обнаружения перегрузки в прямом направлении узлом ECN.

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

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

DSCP

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

ECN

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

IPPM

IP Performance Metrics — показатели производительности IP.

TWAMP

Two-Way Active Measurement Protocol — двухсторонний протокол активных измерений.

OWAMP

One-Way Active Measurement Protocol — односторонний протокол активных измерений.

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

2. Расширения TWAMP

Организация соединения TWAMP выполняется по процедуре, заданной в параграфе 3.1 и [RFC4656] и параграфе 3.1 [RFC5357], где поле Modes служит для указания и выбора конкретных свойств взаимодействия. В то же время, поле Modes считается и применяется как механизм расширения [RFC6038]. Для новой функции требуется новый флаг для указания способности Session-Reflector возвращать полученные значения полей DSCP и ECN отправителю Session-Sender и поддержки нового формата пакетов Session-Reflector в протоколе TWAMP-Test (см. раздел 3).

2.1. Установка отслеживания DSCP и ECN в соединении

Server устанавливает флаг отслеживания DSCP и ECN в поле Modes сообщения Server Greeting для индикации своей возможности и желания отслеживать эти поля. Если клиент Control-Client согласен отслеживать DSCP и ECN для всех или некоторых тестовых сессий, организованных в этом соединении, он должен установить флаг мониторинга DSCP и ECN в поле Modes сообщения Setup Response.

2.2. Расширение TWAMP-Test

Отслеживание DSCP и ECN требует поддержки со стороны Session-Reflector и смены формата тестовых пакетов в исходных режимах (unauthenticated, authenticated, encrypted). Отслеживание DSCP и ECN не меняет тестовые пакеты Session-Sender, но требуется учесть некоторые соображения при восприятии этого режима вместе с режимом Symmetrical Size [RFC6038].

2.2.1. Формат пакета Session-Reflector для отслеживания DSCP и ECN

Когда Session-Reflector поддерживает отслеживание DSCP и ECN, он создаёт поля S-DSCP и S-ECN (S-DSCP-ECN), показанные на рисунке 1, для каждого тестового пакета, передаваемого отправителю Session-Sender, как указано ниже.

6 младших битов поля Differentiated Service должны копироваться из полученного тестового пакета от Session-Sender в поле Sender DSCP (S-DSCP);
два бита поля ECN должны копироваться из полученного тестового пакета от Session-Sender в поле Sender ECN (S-ECN).

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|         S-DSCP        | S-ECN |
+---+---+---+---+---+---+---+---+

Рисунок 1. Формат полей DSCP и ECN у отправителя.

Формат тестовых пакетов, которые Session-Reflector передаёт в режимах unauthenticated, authenticated, encrypted, задан в параграфе 4.2.1 [RFC5357]. Для Session-Reflector с поддержкой отслеживания DSCP и ECN формат таких пакетов показан на рисунках 2 и 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                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Error Estimate         |             MBZ                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Receive Timestamp                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Sender Sequence Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Sender Timestamp                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Error Estimate      |             MBZ               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL    |  S-DSCP-ECN   |             MBZ               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Packet Padding                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат тестового пакета Session-Reflector с полем мониторинга в режиме Unauthenticated.

Значения DSCP и ECN values (часть Type-P Descriptor [RFC4656]) можно задать через TWAMP-Control или иными средствами (командный интерфейс CLI или центральный контроллер). Эти значения зачастую копируются в отражённые пакеты текущими реализациями TWAMP без протокола TWAMP-Control. С расширением мониторинга DSCP и ECN рефлектор Session-Reflector обрабатывает DSCP, как показано ниже.

Session-Reflector должен извлечь DSCP и ECN из принятого пакета и должен использовать их для заполнения поля S-DSCP-ECN в соответствующем отражённом пакете.
Session-Reflector должен передавать каждый отражённый тестовый пакет с полученным значением DSCP.
Если предоставленное значение DSCP неизвестно (например, TWAMP Light), выбор DSCP зависит от реализации. Например, Session-Reflector может копировать DSCP из полученного тестового пакета и установить в поле DSCP отражённого пакета. Как вариант, Session-Reflector может установить DSCP = CS0 (0) [RFC2474].
Если предоставленное значение ECN, в поле ECN следует установить Not-ECT [RFC3168]. В остальных случаях нужно применять заданное для сессии значение ECN.

Session-Reflector в режиме отслеживания DSCP и ECN не анализирует и не влияет на значение ECN, полученное в тестовом пакете TWAMP, поэтому рефлектор игнорирует состояние перегрузки в сети. Предполагается, что скорость передачи достаточно мала, поскольку опыт развёртывания TWAMP показывает с момента публикации базового протокола TWAMP (RFC 5357, 2008 г.), что игнорирование индикации перегрузки не вносит в неё значимого вклада.

 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          |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Receive Timestamp                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       MBZ (8 октетов)                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Sender Sequence Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      MBZ (12 октетов)                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sender Timestamp                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sender Error Estimate      |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                         MBZ (6 октетов)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL    |  S-DSCP-ECN   |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
|                         MBZ (14 октетов)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        HMAC (16 октетов)                      |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Packet Padding                          ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Формат тестового пакета Session-Reflector с полем мониторинга в режиме Authenticated или Encrypted.

2.2.2. Отслеживание DSCP и ECN с расширениями из RFC 6038

В [RFC6038] заданы два расширения TWAMP — одно для обмена между Session-Sender и Session-Reflector пакетами TWAMP-Test одного размера, другое для задания числа октетов, отражаемых Session-Reflector. Если согласованы режимы DSCP and ECN Monitoring и Symmetrical Size и/или Reflects Octets между Server и Control-Client в режиме Unauthenticated, значению Padding Length следует быть не меньше 28 октетов для поддержки процесса отсечки TWAMP, рекомендованного в параграфе 4.2.1 [RFC5357], поскольку поля S-DSCP и S-ECN увеличивают размер неаутентифицируемого пакета Session-Reflector на 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                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
|                         MBZ (28 октетов)                      |
|                                                               |
+                             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             |                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 +
|                                                               |
.                                                               .
.                        Packet Padding                         .
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат тестового пакета Session-Sender с полем мониторинга в режиме и Symmetrical Test в режиме Unauthenticated.

2.2.3. Соображения по режиму TWAMP Light

В Приложении I к [RFC5357] не указано явно, как значение Type-P Descriptor синхронизируется между Session-Sender и Session-Reflector и считаются ли разные значения ошибкой, о которой следует сообщать. Авторы предполагают, что Session-Sender и Session-Reflector в данной сессии TWAMP-Test каким-либо способом информируются для использования одного значения DSCP. Те же средства, например, конфигурацию, можно применять для оповещения Session-Reflector о поддержке отслеживания DSCP и ECN путём копирования данных из полученных тестовых пакетов TWAMP. Тогда Session-Sender может узнать о необходимости использования поля S-DSCP-ECN в отражённых тестовых пакетах TWAMP.

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

В реестр TWAMP-Modes, заданный [RFC5618], агентство IANA внесло новую функцию DSCP and ECN Monitoring Capability, как показано ниже.

Таблица 1. Новая возможность временных меток.

Битовая позиция	Описание	Семантика	Документ
8	DSCP and ECN Monitoring Capability	Раздел 2	RFC 7750

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

Отслеживание DSCP и ECN не создаёт дополнительных угроз безопасности для хостов, взаимодействующих с TWAMP в соответствии с [RFC5357] и имеющимися расширениями [RFC6038]. В параграфах 3.2, 4, 4.1.2, 4.2, 4.2.1 [RFC5357] рассмотрены режимы unauthenticated, authenticated и encrypted с разным уровнем детализации. Соображения безопасности при любых активных измерениях в действующих сетях применимы и здесь. См. разделы «Вопросы безопасности» в [RFC4656] и [RFC5357].

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

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

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

[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, <http://www.rfc-editor.org/info/rfc2474>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, «A One-way Active Measurement Protocol (OWAMP)», RFC 4656, DOI 10.17487/RFC4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.

[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, <http://www.rfc-editor.org/info/rfc5357>.

[RFC5618] Morton, A. and K. Hedayat, «Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)», RFC 5618, DOI 10.17487/RFC5618, August 2009, <http://www.rfc-editor.org/info/rfc5618>.

[RFC6038] Morton, A. and L. Ciavattone, «Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features», RFC 6038, DOI 10.17487/RFC6038, October 2010, <http://www.rfc-editor.org/info/rfc6038>.

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

[RFC3260] Grossman, D., «New Terminology and Clarifications for Diffserv», RFC 3260, DOI 10.17487/RFC3260, April 2002, <http://www.rfc-editor.org/info/rfc3260>.

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

Авторы признательны Bill Cerveny, Christofer Flinta, Samita Chakrabarti за рецензии и ценные замечания.

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

Jonas Hedin

Ericsson

Email: jonas.hedin@ericsson.com

Greg Mirsky

Ericsson

Email: gregory.mirsky@ericsson.com

Steve Baillargeon

Ericsson

Email: steve.baillargeon@ericsson.com

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

Рубрика: RFC, Измерения и тестирование | Оставить комментарий

RFC 7680 A One-Way Loss Metric for IP Performance Metrics (IPPM)

Опубликовано 09.01.2016 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                          G. Almes
Request for Comments: 7680                                     Texas A&M
STD: 82                                                     S. Kalidindi
Obsoletes: 2680                                                     Ixia
Category: Standards Track                                   M. Zekauskas
ISSN: 2070-1721                                                Internet2
                                                          A. Morton, Ed.
                                                               AT&T Labs
                                                            January 2016

A One-Way Loss Metric for IP Performance Metrics (IPPM)

Метрика односторонних потерь для производительности IP (IPPM)

PDF

Аннотация

Этот документ определяет метрику потерь пакетов в одном направлении на путях Internet. Документ основан на понятиях, введённых и описанных в документе «Framework for IP Performance Metrics» (RFC 2330). Предполагается знакомство читателя с этим документом. Данный документ заменяет RFC 2680.

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

Этот документ относится к категории проектов стандартов (Internet Standards Track).

Документ является результатом работы IETF¹ и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG². Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

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

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

1. Введение

Документ определяет метрику потери пакетов в одном направлении на путях через Internet. Документ основан на понятиях, введённых и описанных в документе IPPM Framework [RFC2330]. Предполагается знакомство читателя с этим документом и его обновлённым вариантом [RFC7312].

Этот документ имеет структуру, аналогичную документу по измерению задержки пакетов (A One-Way Delay Metric for IP Performance Metrics (IPPM)) [RFC7679]. Предполагается, что читатель знаком с этим документом.

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

Когда в этом документе первый раз используется термин из IPPM Framework, он помечается звёздочкой в конце. Например, term* указывает термин term, определённый в IPPM Framework.

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

Вводится одиночный (singleton*) аналитический показатель Type-P-One-way-Packet-Loss для однократного наблюдения потерь в одном направлении.
С использованием этого показателя определяется выборка (sample*) Type-P-One-way-Packet-Loss-Poisson-Stream для последовательности измерений односторонних потерь в соответствии с выборкой Пуассона, определённой в параграфе 11.1.1 [RFC2330].
С использованием выборки определяется и рассматривается статистика (statistics*).

Такой переход от одиночных измерений через выборки к статистике с их чётким разделением имеет важное значение.

1.1. Мотивация

Знать односторонние потери пакетов Type-P* от хоста-источника (host*) к хосту-получателю полезно по нескольким причинам.

Некоторые приложения не работают хорошо (или совсем), если сквозные потери между хостами превышают определённый порог.
Избыточные потери осложняют или делают невозможной поддержку некоторых приложений, работающих в реальном масштабе времени (порог избыточности зависит от приложения).
Чем больше потери, тем сложнее протоколам транспортного уровня поддерживать высокую пропускную способность.
Чувствительность приложений в реальном масштабе времени и транспортных протоколов к потере пакетов становится особенно важной, когда требуется поддержка путей в высоким значением произведения задержки на пропускную способность (delay*bandwidth).

Измерение потерь в одном направлении вместо круговых обусловлено указанными ниже причинами.

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

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

1.2. Общие вопросы, связанные со временем

{Комментарий. Приведённые ниже термины отличаются от определённых в документах ITU-T (например, G.810 «Definitions and terminology for synchronization networks» и I.356 «B-ISDN ATM layer cell transfer performance»), но согласуются с документом IPPM Framework. В общем случае различия обусловлены разным происхождением — документы ITU-T исторически связаны с телефонией, а авторы этого документа (и документов IPPM Framework) имеют опыт работы с компьютерными системами. Хотя определённые ниже термины не имеют прямых эквивалентов в определениях ITU-T, ниже приводится их «грубое» сопоставление. Следует отметить возможную путаницу — термин «часы» (clock) здесь относится к времени в операционной системе обозначает, а в ITU-T — к опорной частоте.}

При упоминании в документе времени (т. е. момента в истории) имеется в виду значение в секундах (и долях) для часового пояса UTC.

Как описано в документе IPPM Framework, есть 4 разных, но связанных понятия неопределённости часов (времени).

synchronization* — синхронизация

Степень согласованности часов в части текущего времени. Например, часы одного хоста могут опережать часы другого на 5,4 мсек. {Комментарий. Грубым эквивалентом ITU-T является «ошибка времени» (time error).}

accuracy* — точность

Степень соответствия данных часов времени UTC. Например, часы хоста могут отставать от UTC на 27,1 мсек. {Комментарий. Грубым эквивалентом ITU-T является «отклонение времени от UTC» (time error from UTC).}

resolution* — разрешение (дискретность)

Наименьшая единица, на которую могут изменяться показания часов. Это определяет нижнюю граничу неточности часов. Например, часы в старых системах Unix могут «тикать» лишь каждые 10 мсек, поэтому они будут иметь дискретность 10 мсек. {Комментарий. Грубым эквивалентом ITU-T является «период выборки» (sampling period).}

skew* — перекос

Мера изменения точности или синхронизации с течением времени. Например, часы хоста могут отставать на 1,3 мсек за час и отставать на 27,1 мсек от UTC в данный момент, а через час они будут отставать от UTC лишь на 25,8 мсек. В этом случае мы говорим, что часы данного хоста имеют перекос в 1,3 за час относительно UTC в плане точности. Можно также говорить о перекосе одних часов относительно других в плане синхронизации. {Комментарий. Грубым эквивалентом ITU-T является «дрейф часов» (time drift).}

2. Определение одиночного измерения потерь в одном направлении

2.1. Имя показателя

Type-P-One-way-Packet-Loss

2.2. Параметры метрики

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

Время.

Tmax

Время ожидания, по истечении которого пакет считается потерянным.

2.3. Единицы измерения

Значением показателя Type-P-One-way-Packet-Loss является 0 (успешная передача пакета) или 1 (пакет потерян).

2.4. Определение

Нулевое значение Type-P-One-way-Packet-Loss при передаче от Src к Dst в момент времени T означает, что хост Src передал первый бит пакета Type-P хосту Dst в момент времени в линии (wire-time*) T и хост Dst получил этот пакет.

Значение 1 для Type-P-One-way-Packet-Loss от Src к Dst в момент T означает, что хост Src передал первый бит пакета Type-P по адресу Dst в момент времени в линии T, но пакет не пришел к Dst (в интервале Tmax).

2.5. Обсуждение

Type-P-One-way-Packet-Loss имеет значение 0, когда задержка Type-P-One-way-Delay имеет конечное значение, и 1 при неопределённой (бесконечной) задержке Type-P-One-way-Delay.

На практике могут возникать указанные ниже проблемы.

Методика должна включать способ определения, является потерей пакетов и очень большой (но конечной) задержкой. Как отметили Mahdavi и Paxson [RFC2678], можно использовать простую верхнюю границу (например, теоретическое ограничение срока существования пакетов IP в 255 секунд [RFC791]). Но на практике требуется понимать сроки существования пакетов.

{Комментарий. Отметим, что для многих применений этого показателя негативное влияние трактовки очень большой задержки как потери, может отсутствовать или быть совсем незначительным. Например, голосовой пакет, полученный после момента его воспроизведение, можно считать потерянным. В параграфе 4.1.1 [RFC6703] приведено обсуждение необычных задержек пакетов и оценка производительности приложения.}
Если пакет прибывает повреждённым, он считается потерянным.

{Комментарий. Возникает искушение считать повреждённые пакеты полученными, поскольку повреждение и потеря пакета — связанные, разные события. Однако при повреждении заголовка IP нет уверенности в IP-адресах отправителя и получателя и, следовательно, в том, что это именно тестовый пакет. Если при других повреждениях можно сопоставить повреждённый пакет с отправленным тестовым пакетом и считать его полученным, это приведёт к несогласованности.}

В разделе 15 [RFC2330] определён пакет «стандартного формата», который применим для всех показателей. Отметим, что на момент определения пакетами стандартного формата считались лишь пакеты IPv4 (см. [IPPM-UPDATES]).
Если пакет дублируется в пути (путях) и к получателю приходит несколько неповреждённых копий, пакет считается полученным.
Если пакет фрагментирован и по какой-то причине сборка не выполняется, пакет считается потерянным.

2.6. Методики

Как и для иных показателей Type-P-*, конкретная методика будет зависеть от Type-P (например, номера протокола, порта UDP/TCP, размера, поля дифференцированного обслуживания (DS) [RFC2780]).

Выполняется синхронизация Src и Dst, чтобы их часы указывали достаточно близкое и точное время. Точность синхронизации является параметром метода и связана с порогом определения потерь (см. ниже).
На хосте Src выбираются IP-адреса Src и Dst и создаётся тестовый пакет Type-P с этими адресами.
На хосте Dst организуется приём пакета.
На хосте Src в подготовленный пакет Type-P помещается временная метка и пакет передаётся в направлении Dst (в идеале с минимальной задержкой отправки).
Если пакет прибывает в течение разумного интервала времени, считается Type-P-One-way-Packet-Loss = 0 (временная метка берётся при получении пакета как можно скорее).
Если пакет не прибывает в течение разумного интервала времени Tmax, считается Type-P-One-way-Packet-Loss = 1. Отметим, что значение «разумного интервала» здесь является параметром методики.

{Комментарий. Определение разумного интервала осознанно является нестрогим и обозначает значение Th, достаточно большого для того, чтобы любое значение из интервала [Th-delta, Th+delta] было эквивалентно порогу потери. Значение delta здесь учитывает ошибку синхронизации часов, а также получения и назначения временных меток на пути измерения. Если имеется одно значение Tmax, по достижении которого пакет должен считаться потерянным, снова вводится необходимость синхронизации часов как при измерении односторонней задержки. Если требуется мера потери пакетов, параметризованная конкретным (не чрезмерно большим) значением «разумного интервала» ожидания, можно измерить одностороннюю задержку и посмотреть, какая часть пакетов данного потока выходит за этот интервал. Это подробно рассмотрено в [RFC6703], включая предпочтения назначения неопределённой задержки для пакетов, которые не могут быть доставлены из-за сложностей, связанных с неформальным назначением «бесконечной задержки» и оценку верхней границы ожидания находящихся в сети пакетов. Кроме того, применение конкретного постоянного времени ожидания для сохранённых одиночных измерений (singleton) односторонней задержки согласуется с этой спецификацией и может позволить использовать результаты разных измерений.}

Такие вопросы, как формат пакета, способы, с помощью которых Dst узнает, когда следует ждать тестовый пакет, а также способы синхронизации Src и Dst выходят за рамки этой спецификации. {Комментарий. Планируется более подробно документировать методы реализации работы авторов в другом документе и другим также рекомендуется делать это.}

2.7. Ошибки и погрешности

В описание любого конкретного метода измерения следует включать учёт и анализ различных источников ошибок и погрешностей. В документе IPPM Framework даны общие рекомендации по этим вопросам, а здесь отмечены:

синхронизация часов на хостах Src и Dst;
пороговое значение фиксации потери (связано с синхронизацией часов);
ограничения ресурсов сетевого интерфейса и программ на приёмном оборудовании.

Первые два источника ошибок связаны между собой и могут приводить к признанию потерянным тестового пакета с конечной задержкой. Type-P-One-way-Packet-Loss = 1, если тестовый пакет не приходит или приходит с разницей временных меток Src и Dst, превышающей «разумный интервал» или порог потерь. Если часы не синхронизированы точно, порог потерь может оказаться «неразумным», т. е. фактическое время доставки пакета будет существенно меньше определённого из метки Src. Если установлен слишком низкий порог потерь, многие пакеты будут сочтены потерянными. Порог потерь должен быть достаточно большим, а синхронизация — достаточно точной, чтобы прибывшие пакеты не считались потерянными слишком часто (см. обсуждение в двух предыдущих параграфах).

Поскольку определение потери пакетов менее чувствительно к неточности синхронизации, нежели измерение задержки, читателям рекомендуется обратиться к обсуждению ошибок синхронизации при измерении односторонней задержки [RFC2330].

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

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

2.8. Отчёты об измерениях

Калибровка и контекст выполнения измерений должны тщательно рассматриваться и их следует включать в отчёт вместе с измеренными значениями. Далее представлены 4 элемента, которые следует включать в отчёт: Type-P для тестовых пакетов, порог бесконечной задержки (при наличии), калибровка ошибок и путь, по которому проходят пакеты. Список не является исчерпывающим и следует включать в отчёт любые дополнительные сведения, которые могут быть полезны при интерпретации показателей (в [RFC6703] обсуждается подготовка отчётов для разных аудиторий).

2.8.1. Type-P

Как указано в разделе 13 IPPM Framework [RFC2330], значение показателя может зависеть от типа пакетов IP, применяемых для измерений — Type-P. Значение Type-P-One-way-Delay может меняться при смене протокола (UDP или TCP), номера порта, размера пакетов или особых условий (например, поле предпочтений IP, специальная обработка, такая как поле IP DS [RFC2780], явное уведомление о перегрузке (ECN) [RFC3168] или RSVP). Могут также применяться другие различия пакетов, которые будут заданы в будущих расширениях Type-P. В отчёт должно включаться точное указание Type-P при измерениях.

2.8.2. Пороговое значение потерь

В отчёт должно включаться пороговое значение Tmax для различия конечной задержки и потери (или указание иного метода).

2.8.3. Результаты калибровки

В отчёте должна указываться точность синхронизации часов Src и Dst. По возможности следует включать в отчёт условия, при которых тестовый пакет с конечной задержкой указывается как потерянный в результате нехватки ресурсов на измерительном хосте.

2.8.4. Путь

В отчёте следует по возможности указывать путь, по которому проходят пакеты. В общем случае сложно узнать точный путь, по которому данный пакет прошёл через сеть. Точный путь может быть известен для некоторого Type-P на коротком и стабильном участке. Если Type-P включает опцию записи маршрута (или loose-source route) в заголовке IP, путь достаточно короток и все маршрутизаторы (router*) на пути поддерживают опцию source route (или loose-source route), путь будет записан точно. Это непрактично, поскольку требует достаточно короткого пути, многие маршрутизаторы не поддерживают опцию записи маршрута (или она отключена), а применение этого свойства зачастую снижает производительность за счёт исключения пакетов из общего потока обработки. Однако частичные сведения о пути обеспечивают значимый контекст. Например, если хост может выбирать между двумя каналами (link*) и, следовательно, двумя разными маршрутами от Src к Dst, используемый канал обеспечивает значимый контекст. {Комментарий. Например в Merit NetNow Src, являющийся одной из точек доступа в сеть (Network Access Point — NAP), может достичь Dst в другой точке NAP по любой из сетевых магистралей.}

3. Определение выборки для односторонних потерь

На основе одиночной (singleton) метрики Type-P-One-way-Packet-Loss определим конкретную выборку таких одиночных измерений. Идея выборки (sample) заключается в отборе конкретной связки параметров Src, Dst, Type-P и определении выборки значений параметра T. Способ определения значений T состоит в выборе начального (T0) и конечного (Tf) времени, а также средней частоты lambda и последующем задании псевдослучайного процесса Пуассона со скоростью lambda в интервале от T0 до Tf. Интервал времени между последовательными значениями T имеет среднее значение 1/lambda.

Отметим, что выборка Пуассона является лишь одним из вариантов выборки. Преимуществом её является ограничение смещения (bias), но в других ситуациях могут оказаться лучше иные методы выборки. Например, распределение Пуассона с отсечкой может потребоваться для предотвращения реактивной смены состояния сети в интервалах отсутствия активности (см. параграф 4.6 в [RFC7312]). Иногда целью являются выборки с известным смещением и в [RFC3432] описан метод периодической выборки со случайным временем начала.

3.1. Имя показателя

Type-P-One-way-Packet-Loss-Poisson-Stream

3.2. Параметры метрики

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

Время (начала).

Время (завершения).

Tmax

Время ожидания, по истечении которого пакет считается потерянным.

lambda

Число измерений в секунду.

3.3. Единицы измерения

Последовательность пар (T, L), где T указывает время, а L имеет значение 0 или 1. Значения T в последовательности измерений возрастают монотонно. Отметим, что параметры T и L действительны также для метрики Type-P-One-way-Packet-Loss.

3.4. Определение

На основе T0, Tf и lambda рассчитывается псевдослучайный процесс Пуассона, начинающийся не позже T0, включающий среднюю частоту прибытия пакетов lambda и завершающийся не раньше Tf. Значения времени выборки относятся к диапазону от T0 до Tf. В каждый из выбранных моментов измеряется одно значение Type-P-One-way-Packet-Loss. Значением выборки является последовательность пар (время, потери). Если таких пар нет, последовательность имеет размер 0 и выборка считается пустой.

3.5. Обсуждение

Читателю следует ознакомиться с углублённым обсуждением выборки Пуассона в документе IPPM Framework [RFC2330], где рассмотрены методы расчёта и проверки псевдослучайных пуассоновских процессов.

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

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

Выборка определяется как пуассоновский процесс, чтобы избежать самосинхронизации и обеспечить выборку, статистически наиболее достоверную (unbiased). Пуассоновский процесс служит для планирования измерений задержки. Тестовые пакеты в общем случае не будут приходить на Dst в соответствии с распределением Пуассона, поскольку сеть оказывает влияние на их доставку. Каналы с временными интервалами (time-slot), описанные в параграфе 3.4 [RFC7312] могут существенно изменять характеристики выборки. Основной проблемой является то, что несмещенные (unbiased) потоки пакетов со случайными межпакетными интервалами будут приводиться к иному распределению в канале с временными интервалами, которое может оказаться строго периодическим.

{Комментарий. Конечно не принимается допущений о том, что реальный трафик Internet прибывает в соответствии с распределением Пуассона.

Важно отметить, что в отличие от данной метрики, частота потерь, фиксируемая транспортными соединениями, не отражает несмещенные (unbiased) выборки. Например, для передач TCP (1) характерны пики трафика, которые могут вызывать потери, не наблюдающиеся в других ситуациях и (2) скорость изменяется в попытке минимизировать возникающие в соединении потери.}

Все одиночные (singleton) показатели Type-P-One-way-Packet-Loss в последовательности измерений будут иметь одни значения Src, Dst, Type-P.

Отметим также, что данная выборка с момента T0 до Tf и субпоследовательность от T0′ до Tf’, где T0 <= T0′ <= Tf’ <= Tf, также будет действительной выборкой Type-P-One-way-Packet-Loss-Poisson-Stream.

3.6. Методики

Методика включает указанные ниже действия.

Выбор конкретных значений времени измерения с использованием заданного процесса Пуассона для прибытия.
Методика, рассмотренная для одиночного (singleton) измерения Type-P-One-way-Packet-Loss.

Следует корректно обрабатывать нарушения порядка прибытия тестовых пакетов. Src может передать тестовый пакет в момент TS[i], а затем передать следующий в момент TS[i+1], при этом Dst может получить сначала второй пакет в момент TR[i+1], а позднее — первый в момент TR[i]. Показатели разупорядочения описаны в [RFC4737].

3.7. Ошибки и погрешности

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

{Комментарий. Цель состоит в передаче тестовых пакетов «достаточно близко» к планированию Пуассона без возникновения периодической отправки.}

3.8. Отчёты об измерениях

Калибровка и контекст для одиночных измерений должны указываться в отчёте (см. 2.8. Отчёты об измерениях).

4. Определения статистики для односторонних потерь

На основе выборки Type-P-One-way-Packet-Loss-Poisson-Stream предлагается несколько вариантов статистики. Описание статистики служит в основном для иллюстрации того, что можно сделать. В [RFC6703] рассматривается статистика для разных аудиторий.

4.1. Type-P-One-way-Packet-Loss-Ratio

Для данной выборки Type-P-One-way-Packet-Loss-Poisson-Stream усредняются значения L в потоке. Кроме того, Type-P-One-way-Packet-Loss-Ratio будет неопределённым для пустой выборки.

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

   Stream1 = <
   <T1, 0>
   <T2, 0>
   <T3, 1>
   <T4, 0>
   <T5, 0>
   >

Среднее значение составит 0,2.

Отметим, что «здоровые» пути Internet должны иметь потери меньше 1% (особенно при высоких значениях произведения задержки на пропускную способность (delay-bandwidth)), поэтому могут потребоваться выборки большого размера. Например, для определения потерь в доли процента с течение минуты может потребоваться несколько сотен выборок в минуту. Это ведёт к большим значениям lambda.

Хотя порог потерь следует устанавливать так, чтобы минимизировать ошибки при учёте потерь, возможны случаи, когда прибывшие пакеты будут считаться потерянными в результате нехватки ресурсов. Если такие «потери» велики, измерение Type-P-One-way-Packet-Loss-Ratio теряет смысл.

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

Проведение измерений в Internet создаёт проблемы безопасности и приватности. Этот документ не задаёт реализацию показателей, поэтому он напрямую не влияет на безопасность Internet и приложений Internet. Однако при реализации измерений требуется учитывать вопросы безопасности и приватности.

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

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

В части приватности участников измерения или тех, чей трафик измеряется, возможность раскрытия деликатных сведений посторонним существенно ограничена при использовании активных методов, которым посвящён этот документ. Пассивные наблюдения пользовательского трафика для измерений создают множество проблем приватности. Читателям рекомендуется обратиться к документу «Large Scale Measurement of Broadband Performance (LMAP) Framework» [RFC7594], где рассмотрены активные и пассивные методы измерений.

Сбор и использование результатов измерений для зондирования с целью организации атак на системы достаточно распространены. Доступ к результатам измерений и контроль над измерительными системами для зондирования следует тщательно оберегать. В разделе 7 [RFC7594] (Security Considerations of the LMAP Framework) рассмотрены системные требования, помогающие предотвратить компрометацию измерительных систем.

6. Отличия от RFC 2680

Приведённый выше текст является пересмотром RFC 2680, имеющего статус Internet Standard.

В [RFC7290] представлен план тестирования и результаты, поддерживающие продвижение [RFC2680] в процессе Standards Track в соответствии с процедурой [RFC6576]. Выводы [RFC7290] включают 4 указанных ниже изменения.

В параграфе 6.2.3 [RFC7290] отмечено, что допущение о постобработке для обеспечения постоянного порога времени ожидания разумно и это следует включить в текст RFC. Применимость постобработки добавлена в последний абзац параграфа 2.6.
В параграфе 6.5 [RFC7290] указано, что статистику Type-P-One-way-Packet-Loss-Average чаще называют Packet Loss Ratio и она была переименована в этом документе (это незначительное несоответствие не влияет на процесс стандартизации). Переименование статистики указано в параграфе 4.1.
В IETF достигнуто соглашение о рекомендациях по отчётам о показателях [RFC6703] и этот документ указан здесь для учёта при необходимости недавнего опыта. Ссылка добавлена в последние абзацы параграфов 2.6, 2.8 и раздела 4.
Имеется сообщение об ошибке со статусом Verified (EID 1528) для [RFC2680] и соответствующий пересмотр включён в раздел 1 и параграф 2.7.

Ряд обновлений [RFC2680] реализован в приведённом выше тексте ссылками на ключевые IPPM RFC, одобренные после [RFC2680] (см. параграфы 3 и 3.6), и учётом комментариев в почтовой конференции IPPM, описывающих текущие условия и опыт применения.

В конце параграфа 1.1 обновлён пример сети, использующей ATM, с разъяснение влияния TCP на занятость очередей, и обсуждается важность измерения односторонней задержки.
Разъяснено определение термина resolution в параграфе 1.2.
В параграфах 2.2, 2.4 и 3.2 явно включён входной параметр максимального времени ожидания для отражения принятия этого параметра в более поздних RFC и ITU-T Recommendation Y.1540.
Добавлены ссылки на RFC 6703 при обсуждении времени существования пакетов и тайм-аутов приложений в параграфе 2.5.
Термин «предпочтения» (precedence) заменён современным термином DS Field в параграфах 2.6 и 2.8.1 (со ссылкой).
Добавлены заключённые в скобки рекомендации по минимизации интервала между получением временной метки и отправкой пакета в параграфе 2.6. Кроме того, в тексте сейчас различается процесс получения временной метки и практическое измерение системой задержки и потерь (что требует параметра максимального времени ожидания Tmax).
Добавлена ссылка на RFC 3432 в части периодической выборки наряду с выборкой Пуассона а разделе 3, а также указано, что распределение Пуассона с отсечкой может потребоваться в современных сетях, как сказано в обновлении IPPM Framework [RFC7312].
Отмечено, что канала в временными интервалами, описанные в [RFC7312] могут существенно менять характеристики выборки (параграф 3.5).
Добавлена ссылка на RFC 4737, связанная с метрикой разупорядочения, при обсуждении методик (параграф 3.6).
Расширен и обновлён материал по приватности и добавлены предупреждения об использовании инструментов для зондирования (разведки) в разделе «5. Вопросы безопасности».

В параграфе 5.4.4 [RFC6390] предложен базовый шаблон для показателей производительности, частично выведенный из предшествующих RFC IPPM и рабочей группы BMWG (Benchmarking Methodology Working Group) с добавлением некоторых элементов. Учтены все нормативные части [RFC6390], но с некоторыми изменениями названий параграфов и ориентации. Учтены также несколько информационных частей. Поддержка стиля документов IPPM достаточно важна и минимизирует различия между пересмотренным RFC и современными, а также будущими IPPM RFC.

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

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

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.

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

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, DOI 10.17487/RFC2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.

[RFC2678] Mahdavi, J. and V. Paxson, «IPPM Metrics for Measuring Connectivity», RFC 2678, DOI 10.17487/RFC2678, September 1999, <http://www.rfc-editor.org/info/rfc2678>.

[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Packet Loss Metric for IPPM», RFC 2680, DOI 10.17487/RFC2680, September 1999, <http://www.rfc-editor.org/info/rfc2680>.

[RFC2780] Bradner, S. and V. Paxson, «IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers», BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, <http://www.rfc-editor.org/info/rfc2780>.

[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, «Network performance measurement with periodic streams», RFC 3432, DOI 10.17487/RFC3432, November 2002, <http://www.rfc-editor.org/info/rfc3432>.

[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, «IP Performance Metrics (IPPM) Standard Advancement Testing», BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, <http://www.rfc-editor.org/info/rfc6576>.

[RFC7312] Fabini, J. and A. Morton, «Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)», RFC 7312, DOI 10.17487/RFC7312, August 2014, <http://www.rfc-editor.org/info/rfc7312>.

[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., «A One-Way Delay Metric for IP Performance Metrics (IPPM)», STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <http://www.rfc-editor.org/info/rfc7679>.

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

[IPPM-UPDATES] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, «Updates for IPPM’s Active Metric Framework: Packets of Type-P and Standard-Formed Packets», Work in Progress, draft-morton-ippm-2330-stdform-typep-02³, December 2015.

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, «Packet Reordering Metrics», RFC 4737, DOI 10.17487/RFC4737, November 2006, <http://www.rfc-editor.org/info/rfc4737>.

[RFC6390] Clark, A. and B. Claise, «Guidelines for Considering New Performance Metric Development», BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.

[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, «Reporting IP Network Performance Metrics: Different Points of View», RFC 6703, DOI 10.17487/RFC6703, August 2012, <http://www.rfc-editor.org/info/rfc6703>.

[RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, «Test Plan and Results for Advancing RFC 2680 on the Standards Track», RFC 7290, DOI 10.17487/RFC7290, July 2014, <http://www.rfc-editor.org/info/rfc7290>.

[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, «A Framework for Large-Scale Measurement of Broadband Performance (LMAP)», RFC 7594, DOI 10.17487/RFC7594, September 2015, <http://www.rfc-editor.org/info/rfc7594>.

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

Применительно к [RFC2680] Matt Mathis за поддержку этой работы и привлечение внимания к вопросам измерения потерь пакетов. Спасибо Vern Paxson за ценные комментарии к ранним вариантам документа, а также Garry Couch и Will Leland за полезные предложения.

Применительно к этому документу спасибо Joachim Fabini, Ruediger Geib, Nalini Elkins, Barry Constantine за предоставление их опыта измерения как части отзывов. Brian Carpenter и Scott Bradner представили полезные отклики на IETF Last Call.

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

Guy Almes

Texas A&M

Email: almes@acm.org

Sunil Kalidindi

Ixia

Email: skalidindi@ixiacom.com

Matt Zekauskas

Internet2

Email: matt@internet2.edu

Al Morton (редактор)

AT&T Labs

200 Laurel Avenue South

Middletown, NJ 07748

United States

Phone: +1 732 420 1571

Fax: +1 732 368 1192

Email: acmorton@att.com

URI: http://home.comcast.net/~acmacm/

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3Документ не был завершён, а впоследствии взамен был выпущен RFC 8468. Прим. перев.

Рубрика: RFC, Измерения и тестирование | Оставить комментарий

RFC 7679 A One-Way Delay Metric for IP Performance Metrics (IPPM)

Опубликовано 03.01.2016 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                          G. Almes
Request for Comments: 7679                                     Texas A&M
STD: 81                                                     S. Kalidindi
Obsoletes: 2679                                                     Ixia
Category: Standards Track                                   M. Zekauskas
ISSN: 2070-1721                                                Internet2
                                                          A. Morton, Ed.
                                                               AT&T Labs
                                                            January 2016

A One-Way Delay Metric for IP Performance Metrics (IPPM)

Метрика односторонней задержки для IPPM

PDF

Аннотация

Этот документ определяет метрику односторонней задержки пакетов на путях Internet. Документ основан на понятиях, введённых и описанных в документе «Framework for IP Performance Metrics» (RFC 2330). Предполагается знакомство читателя с этим документом. Данный документ заменяет RFC 2679.

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

Этот документ относится к категории проектов стандартов (Internet Standards Track).

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

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

1. Введение

Документ определяет метрику односторонней задержки пакетов на путях через Internet. Документ основан на понятиях, введённых и описанных в документе IPPM Framework [RFC2330]. Предполагается знакомство читателя с этим документом и его обновлённым вариантом [RFC7312].

Этот документ имеет структуру, аналогичную документу по измерению потерь пакетов (A One-way Packet Loss Metric for IPPM) [RFC7680].

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

Вводится одиночный (singleton*) аналитический показатель Type-P-One-way-Delay для однократного наблюдения задержки в одном направлении.
С использованием этого показателя определяется выборка (sample*) Type-P-One-way-Delay-Poisson-Stream для последовательности измерений односторонней задержки в соответствии с выборкой Пуассона, определённой в параграфе 11.1.1 [RFC2330].
С использованием выборки определяется и рассматривается статистика (statistics*). Такой переход от одиночных измерений через выборки к статистике с их чётким разделением имеет важное значение.

1.1. Мотивация

Знать одностороннюю задержку пакетов Type-P* от хоста-источника (host*) к хосту-получателю полезно по нескольким причинам.

Некоторые приложения не работают хорошо (или совсем), если сквозная задержка между хостами превышает определённый порог.
Меняющиеся вариации задержки осложняют или делают невозможной поддержку многих приложений, работающих в реальном масштабе времени.
Чем больше задержка, тем сложнее протоколам транспортного уровня поддерживать высокую пропускную способность.
Минимальное значение этого параметра указывает задержку, связанную лишь с передачей и распространением.
Минимальное значение этого параметра указывает задержку, которая вероятно возникает при прохождении слабо загруженного пути (path*).
Значение параметра выше минимального указывают наличие перегрузки на пути.

Измерение односторонней задержки вместо круговой обусловлено указанными ниже причинами.

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

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

2. Общие вопросы, связанные со временем

Как описано в документе IPPM Framework, есть 4 разных, но связанных понятия неопределённости часов (времени).

synchronization* — синхронизация

accuracy* — точность

resolution* — разрешение (дискретность)

skew* — перекос

3. Определение одиночного измерения односторонней задержки

3.1. Имя показателя

Type-P-One-way-Delay — односторонняя задержка пакетов Type-P.

3.2. Параметры показателя

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

Время.

Tmax

Время ожидания порога потерь.

3.3. Единицы измерения

Значение Type-P-One-way-Delay является действительным числом, либо неопределённым (неформально, бесконечным) числом секунд.

3.4. Определение

Для действительного числа dT, «задержка Type-P-One-way-Delay от Src до Dst в момент T равна dT» означает, что Src передаёт первый бит пакета Type-P получателю Dst в момент времени в линии (wire time*) T, а Dst принимает последний бит этого пакета в момент времени в линии T+dT.

«Задержка Type-P-One-way-Delay от Src до Dst в момент времени T не определена (неформально, бесконечна)» означает, что Src передаёт первый бит пакета Type-P получателю Dst в момент времени в линии T, а Dst не получает этот пакет (в интервале ожидания порога потерь Tmax).

Предложения о включении значений метрики в отчёт приводятся в параграфе 3.8 после обсуждения метрики, методики измерения и анализа ошибок.

3.5. Обсуждение

Type-P-One-way-Delay представляет собой относительно простую аналитическую метрику, для которой предполагается возможность использовать эффективные методы измерения.

На практике могут возникать указанные ниже проблемы.

Значения реальной задержки положительны, поэтому не имеет смысла включать в отчёт отрицательные значения. Однако отдельные нулевые или отрицательные задержки могут быть полезны как часть потока при попытке найти распределение потока значений задержки.
Поскольку значения задержки зачастую находятся в диапазоне от 100 мксек до 10 мсек, важна точная синхронизация часов Src и Dst. Система глобального позиционирования (Global Positioning System или GPS) позволяет синхронизировать часы с погрешностью порядка десятков микросекунд. Обычное применение NTP может обеспечить точность синхронизации в несколько миллисекунд, но зависит от стабильности и симметрии параметров задержки в используемых агентах NTP, а именно такие задержки и требуется измерять. Сочетание некоторых серверов NTP, привязанных к GPS, и аккуратно (консервативно) разработанных и развёрнутых серверов NTP должно обеспечить хорошие результаты. Это было протестировано в работе [RFC6808], где результаты измерений системы GPS сравнивались с результатами синхронизированной от GPS системы NTP для межконтинентального пути.
Методика должна включать способ определения, является значение очень большим (пакет ещё не прибыл в Dst) или оно бесконечно. Как отметили Mahdavi и Paxson [RFC2678], можно использовать простую верхнюю границу (например, теоретическое ограничение срока существования пакетов IP в 255 секунд [RFC791]). Но на практике требуется понимать сроки существования пакетов. {Комментарий. Отметим, что для многих применений этого показателя негативное влияние трактовки очень большой задержки как бесконечной, может отсутствовать или быть совсем незначительным. Например, пакет данных TCP, полученный после нескольких периодов RTT, можно считать потерянным. Влияние необычных задержек на оценку производительности приложений рассмотрено в параграфе 4.1.1 [RFC6703].}
Если пакет дублируется в пути (путях) и к получателю приходит несколько неповреждённых копий, пакет считается полученным и одностороннюю задержку определяет приём первой копии.
Если пакет фрагментирован и по какой-то причине сборка не выполняется, пакет считается потерянным.
Методика будет включать способ проверки стандартного формата пакетов, соответствия всем принятым по умолчанию критериям для всех определений показателей, заданным в разделе 15 [RFC2330], считая не соответствующие пакеты потерянными. Отметим, что в настоящее время проверка стандартного формата применима лишь к пакетам IPv4 (см. также [IPPM-UPDATES]).

3.6. Методики

Как и для всех иных показателей Type-P-*, конкретная методика будет зависеть от Type-P (например, номера протокола, порта UDP/TCP, размера, поля дифференцированных услуг (Differentiated Services или DS) [RFC2780]).

В общем случае для данного Type-P методика будет действовать, как указано ниже.

Выполняется синхронизация Src и Dst, чтобы их часы указывали достаточно близкое и точное время.
На хосте Src выбираются IP-адреса Src и Dst и создаётся тестовый пакет Type-P с этими адресами. Дополняющую часть пакета (padding), служащую для создания нужного размера тестового пакета, следует заполнять случайными битами, чтобы предотвратить сжатие пакетов в пути, которое может повлиять на измерение задержки (см. также параграф 3.1.2 в [RFC7312]).
На хосте Dst организуется приём пакета.
На хосте Src в подготовленный пакет Type-P помещается временная метка и пакет передаётся в направлении Dst (в идеале с минимальной задержкой отправки).
Если пакет прибывает в течение разумного интервала времени, как можно скорее берётся временная метка момента получения пакета. Вычитая значение одной метки из значения другой, можно рассчитать задержку одностороннего пути. При анализе ошибок реализации метода следует учитывать точность синхронизации часов Src и Dst. Если известна разница между временной меткой Src и фактическим временем передачи пакета, это значение можно вычесть из полученной величины задержки. Неопределённость разницы времени генерации метки и отправки пакета должна учитываться при анализе ошибок. Точно так же при известной разнице времени приёма пакета и создания временной метки Dst её можно вычесть из значения задержки. Неопределённость этой разницы должна учитываться при анализе ошибок. Дополнительные сведения приведены в параграфе 3.7. Ошибки и погрешности.
Если пакет не прибыл в разумные сроки, значение Tmax для односторонней задержки считается неопределенным (неформально, бесконечным). Отметим, что разумный срок является параметром метрики. Эти аспекты подробно рассмотрены в [RFC6703], включая предпочтения при анализе для назначения неопределённой задержки пакетам из-за трудностей, связанных с неформальным определением «бесконечной задержки» и оценкой верхнего предела ожидания пакетов, находящихся в сети. Задание постоянного времени ожидания для сохранённых одиночных измерений односторонней задержки согласуется с данной спецификацией и может позволить обрабатывать результаты измерений из нескольких источников.

3.7. Ошибки и погрешности

ошибки и погрешности часов на хостах Src и Dst;
ошибки и погрешности, связанные с разницей времени в линии (wire time) и на хосте (host time).

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

3.7.1. Ошибки и погрешности, связанные с часами

Погрешности измерения односторонней задержки связаны отчасти с погрешностями часом на хостах Src и Dst. Далее часы, используемые для фиксации момента отправки с хоста Src называются часами источника, а часы для фиксации времени получения пакета хостом Dst — часами получателя. Время, наблюдавшееся при отправке пакета по часам источника, обозначается Tsource, а время, наблюдавшееся при получении пакета по часам получателя — Tdest. В предположении синхронизации часов с учётом их точности, дискретности и перекоса отметим указанное ниже.

Любая ошибка синхронизации часов источника и получателя вносит вклад в ошибку измерения задержки. Будем говорить, что между часами источника и получателя имеется ошибка синхронизации Tsynch, если часы источника опережают часы получателя на Tsynch. Таким образом, при точной известной ошибке Tsynch можно скорректировать расхождение часов, прибавив Tsynch к разности Tdest — Tsource.
Точность часов важна для определения момента измерения задержки. Сама по себе, точность часов не влияет на точность измерения задержки. При вычислении задержек важна лишь разница значений, а не сами значения времени.
Разрешение (дискретность) часов добавляет погрешность к любому измерению времени этими часами. Таким образом, если часы источника имеют разрешение 10 мсек, это добавит погрешность в 10 к любому времени, измеренному этими часами. Разрешение часов источника будет обозначать Rsource, получателя — Rdest.
Перекос часов является не столько дополнительной проблемой, сколько реализацией того, что Tsynch зависит от времени. Таким образом, при попытке измерить или ограничить (привязать) Tsynch, это нужно делать периодически. В течение некоторого времени эту функцию можно аппроксимировать как линейную с некоторыми членами более высокого порядка. В таких случаях одним из вариантов является использование значения линейной составляющей для корректировки часов. При использовании такой корректировки остаточное значение Tsynch становится меньше, но остаётся источником погрешности, которая должна учитываться. Будем использовать функцию Esynch(t) для обозначения верхней границы погрешности синхронизации. Таким образом, |Tsynch(t)| <= Esynch(t).

С учётом отмеченного выше укажем, что естественный расчёт Tdest — Tsource будет давать погрешность Tsynch(t) +/- (Rsource + Rdest). используя понятие Esynch(t), отметим, что проблемы, связанные с часами, вносят общую погрешность Esynch(t) + Rsource + Rdest. Эту оценку связанной с часами общей погрешности следует включать в анализ ошибок и погрешностей любой реализации измерения.

3.7.2. Ошибки и погрешности, связанные с временем в линии и на хосте

В соответствии с определением односторонней задержки нужно измерить время между выходом тестового пакета из сетевого интерфейса Src и его прибытием (полностью) на сетевой интерфейс Dst — это называется временем в линии (wire time). Однако измерение времени выполняется программами на хостах Src и Dst, которые могут лишь фиксировать время между созданием (получением) временной метки на Src перед отправкой пакета и на Dst после получения тестового пакета — это называется временем хоста.

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

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

Неопределённость различия времени между хостом и линией должна учитываться при анализе погрешности измерения для данного метода. Обозначим верхнюю границу этой неопределённости на хосте Src как Hsource, а на Dst — как Hdest. Совместно они вносят погрешность Hsource + Hdest. Эту оценку общей погрешности разницы времени на хосте и в линии обычно следует включать в анализ ошибок и погрешностей любой реализации измерения.

3.7.3. Калибровка ошибок и погрешностей

В общем случае измеренное значение можно представить в форме

   измеренное значение = истинное значение + систематическая ошибка + случайная ошибка

Если систематическую ошибку (постоянное отклонение измеряемых значений) можно определить, можно компенсировать её в получаемых (reported) результатах.

   полученный результат = измеренное значение - систематическая ошибка

Из этого следует, что

   полученный результат = истинное значение + случайная ошибка

Целью калибровки является определение систематических и случайных ошибок, вносимых хостами, как можно более подробно. Как минимум следует найти границу (e), указывающую, что полученное значение находится в диапазоне от (истинное значение — e) до (истинное значение + e) не менее 95% времени. Будем называть «e» ошибкой калибровки для измерений. Эта ошибка представляет степень повторяемости значений, создаваемых измерительным хостом, т. е. близость полученных значений к реальным. {Комментарий. Значение 95% выбрано потому, что (1) желательно иметь некий уровень доверия для удаления выбросов, которые могут возникать при измерении любого физического свойства, (2) нужно указать определённый уровень доверия для возможности сравнения результатов независимых измерений и (3) даже с прототипом реализации на пользовательском уровне значение 95% позволяет исключить выбросы.}

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

   Esynch(t) + Rsource + Rdest + Hsource + Hdest

Разумные границы неопределённостей, связанных с часами (первые 3 члена выражения) и хостом (2 последних члена), можно оценить, тщательно подбирая методику и калибруя хосты с использованием известной сети в лабораторных условиях.

Например, связанные с часами погрешности существенно снижаются при использовании времени от GPS. Сумма Esynch(t) + Rsource + Rdest будет мала и ограниченна в интервале измерений в результате привязки к глобальной системе точного времени.

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

Если тестовые пакеты малы, такое соединение будет вносить очень малую задержку, которую можно аппроксимировать значением 0. Поэтому измеряемая задержка будет включать лишь систематические и случайные ошибки на измерительных хостах. «Среднее значение» повторяющихся измерений будет определять систематическую ошибку, а вариации — случайную.

Одним из способов рассчитать систематическую ошибку и случайную ошибку с уровнем доверия 95% является многократное повторение измерений (по меньшей мере сотни раз). Систематическая ошибка будет определяться медианой, а случайную ошибку можно определить, исключив систематическую из полученных значений. Доверительный интервал 95% будет диапазоном процентилей от 2,5 до 97,5 для отклонений от истинного значения. Ошибкой калибровки (e) можно считать большее абсолютное значение из этих двух с добавлением погрешности, связанной с часами. {Комментарий. Как указано выше, эта привязка является относительно слабой, поскольку погрешности складываются и используется абсолютное значение большего отклонения. Пока полученное значение не составляет значимую часть измеряемых значений, это будет разумной границей. Если же значение погрешности составляет существенную часть измеряемых величин, требуются более точные методы расчёта ошибок калибровки.}

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

Отметим ещё раз, что эта статистическая трактовка относится к калибровке хоста и определяет степень соответствия результатов измерений реальным значениям.

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

3.8. Отчёты об измерениях

3.8.1. Type-P

Как указано в разделе 13 документа IPPM Framework [RFC2330], значение показателя может зависеть от типа пакетов IP, применяемых для измерений — Type-P. Значение Type-P-One-way-Delay может меняться при смене протокола (UDP или TCP), номера порта, размера пакетов или особых условий (например, поле IP DS [RFC2780], явное уведомление о перегрузке (Explicit Congestion Notification или ECN) [RFC3168], RSVP).

Будут применимы также дополнительные различия пакетов, задаваемые будущими расширениями определения Type-P. В отчёт должно включаться точное указание Type-P при измерениях.

3.8.2. Пороговое значение потерь

В отчёт должно включаться пороговое значение (или метод) для различия конечной задержки и потери.

3.8.3. Результаты калибровки

Если систематическую ошибку можно определить, её следует исключить из измеренных значений.
Следует указывать в отчёте ошибку калибровки e так, чтобы истинным значением было указанное в отчёте значение плюс-минус e с уровнем доверия 95%.
По возможности следует включать в отчёт условия, при которых тестовый пакет с конечной задержкой указывается как потерянный в результате нехватки ресурсов на измерительном хосте.

3.8.4. Путь

В отчёте следует по возможности указывать путь, по которому проходят пакеты. В общем случае сложно узнать точный путь, по которому данный пакет прошёл через сеть. Точный путь может быть известен для некоторого Type-P на коротком и стабильном участке. Если Type-P включает опцию записи маршрута (или loose-source route) в заголовке IP, путь достаточно короток и все маршрутизаторы (router*) на пути поддерживают опцию source route (или loose-source route), путь будет записан точно. Это непрактично, поскольку требует достаточно короткого пути, многие маршрутизаторы не поддерживают опцию записи маршрута (или она отключена), а применение этого свойства зачастую снижает производительность. Однако частичные сведения о пути обеспечивают значимый контекст. Например, если хост может выбирать между двумя каналами (link*) и, следовательно, двумя разными маршрутами от Src к Dst, используемый канал обеспечивает значимый контекст. {Комментарий. Например в Merit NetNow Src, являющийся одной из точек доступа в сеть (Network Access Point — NAP) может достичь Dst в другой точке NAP по любой из сетевых магистралей.}

4. Определение выборки для односторонней задержки

На основе одиночной (singleton) метрики Type-P-One-way-Delay определим конкретную выборку таких одиночных измерений. Идея выборки (sample) заключается в отборе конкретной связки параметров Src, Dst, Type-P и определении выборки значений параметра T. Способ определения значений T состоит в выборе начального (T0) и конечного (Tf) времени, а также средней частоты lambda и последующем задании псевдослучайного процесса Пуассона со скоростью lambda в интервале от T0 до Tf. Интервал времени между последовательными значениями T имеет среднее значение 1/lambda.

4.1. Имя показателя

Type-P-One-way-Delay-Poisson-Stream

4.2. Параметры показателя

Src

IP-адрес хоста (источника).

Dst

IP-адрес хоста (получателя).

Время (начала).

Время (завершения).

Tmax

Время ожидания порога потерь.

lambda

Число измерений в секунду (или параметры иного распределения).

4.3. Единицы измерения

Последовательность пар (T, dT), где T указывает время, а dT является действительным числом или неопределённым числом секунд. Значения T в последовательности измерений возрастают монотонно. Отметим, что параметры T и dT действительны также для метрики Type-P-One-way-Delay.

4.4. Определение

На основе T0, Tf и lambda рассчитывается псевдослучайный процесс Пуассона, начинающийся не позже T0, включающий среднюю частоту прибытия пакетов lambda и завершающийся не раньше Tf. Значения времени выборки относятся к диапазону от T0 до Tf. В каждый из выбранных моментов измеряется одно значение Type-P-One-way-Delay. Значением выборки является последовательность пар (время, задержка). Если таких пар нет, последовательность имеет размер 0 и выборка считается пустой.

4.5. Обсуждение

Выборка определяется как пуассоновский процесс, чтобы избежать самосинхронизации и обеспечить выборку, статистически наиболее достоверную (unbiased). {Комментарий. Конечно не принимается допущений о том, что реальный трафик Internet прибывает в соответствии с распределением Пуассона.} Пуассоновский процесс служит для планирования измерений задержки. Тестовые пакеты в общем случае не будут приходить на Dst в соответствии с распределением Пуассона, поскольку сеть оказывает влияние на их доставку.

Все одиночные (singleton) показатели Type-P-One-way-Delay в последовательности измерений будут иметь одни значения Src, Dst, Type-P.

Отметим также, что данная выборка с момента T0 до Tf и субпоследовательность от T0′ до Tf’, где T0 <= T0′ <= Tf’ <= Tf, также будет действительной выборкой Type-P-One-way-Delay-Poisson-Stream.

4.6. Методики

Методика включает указанные ниже действия.

Выбор конкретных значений времени измерения с использованием заданного процесса Пуассона для прибытия.
Методика, рассмотренная для одиночного (singleton) измерения Type-P-One-way-Delay.

4.7. Ошибки и погрешности

В дополнение к ошибкам и погрешностям, связанным с методом одиночных измерений, входящих в выборку, необходимо тщательно проанализировать точность процесса Пуассона в части времени в линии при отправке тестовых пакетов. Проблемы в этом процессе могут быть связаны с несколькими обстоятельствами, включая метод генерации псевдослучайных чисел для процесса Пуассона и вариации значения Hsource (рассмотрено выше для одиночных измерений). В документе IPPM Framework показано, как использовать тест Anderson-Darling для проверки точности пуассоновского процесса в коротких интервалах времени. {Комментарий. Цель состоит в передаче тестовых пакетов «достаточно близко» к планированию Пуассона без возникновения периодической отправки.}

4.8. Отчёты об измерениях

Калибровка и контекст для одиночных измерений должны указываться в отчёте (см. 3.8. Отчёты об измерениях).

5. Определения статистики для односторонней задержки

На основе выборки Type-P-One-way-Delay-Poisson-Stream предлагается несколько вариантов статистики. Описание статистики служит в основном для иллюстрации того, что можно сделать. Дополнительное рассмотрение статистики для разных аудиторий приведено в [RFC6703].

5.1. Type-P-One-way-Delay-Percentile

Для данной выборки Type-P-One-way-Delay-Poisson-Stream и значения X от 0% до 100% — это X-й процентиль от всех значений dT в потоке. При расчёте процентиля неопределённые значения считаются бесконечно большими. Это означает, что процентиль также может быть неопределенным (неформально, бесконечным). Кроме того, Type-P-One-way-Delay-Percentile будет неопределённым для пустой выборки.

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

   Stream1 = <
   <T1, 100 msec>
   <T2, 110 msec>
   <T3, undefined>
   <T4, 90 msec>
   <T5, 500 msec>
   >

50-й процентиль будет иметь значение 110 мсек, поскольку 90 и 100 мсек меньше, а 500 мсек и undefined больше него. Расчёт процентилей описан в параграфе 11.3 [RFC2330].

Отметим, что при наличии вероятности того, что пакет с конечной задержкой, указанный как потерянный, является значимым, высокий процентиль (90-й или 95-й) можно указать как бесконечный вместо конечного.

5.2. Type-P-One-way-Delay-Median

Для данной выборки Type-P-One-way-Delay-Poisson-Stream — это медиана всех значений dT в потоке. При расчёте медианы неопределённые значения считаются бесконечно большими. Как и Type-P-One-way-Delay-Percentile, медиана Type-P-One-way-Delay-Median не определена для пустой выборки.

Как указано в документе IPPM Framework, медиана отличается от 50-го процентиля только для выборов с сетным числом значений (в этом случае используется среднее значение двух «центральных» измерений.

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

   Stream1 = <
   <T1, 100 msec>
   <T2, 110 msec>
   <T3, undefined>
   <T4, 90 msec>
   >

Медиана будет иметь значение 105 мсек (среднее между 100 и 110 мсек).

5.3. Type-P-One-way-Delay-Minimum

Для данной выборки Type-P-One-way-Delay-Poisson-Stream — это минимальное значение dT в потоке. При расчёте неопределённые значения считаются бесконечно большими. Это означает, что минимум также может быть неопределенным (неформально, бесконечным), если все значения dT являются неопределёнными. Значение Type-P-One-way-Delay-Minimum будет неопределённым для пустой выборки.

В приведённом выше примере минимальное значение составляет 90 мсек.

5.4. Type-P-One-way-Delay-Inverse-Percentile

Примечание. Эта статистика отменена данным документом по причине её редкого применения.

Для данной выборки Type-P-One-way-Delay-Poisson-Stream и порога продолжительности часть всех значений dT в потоке будет не выше порога. Значение может быть от 0% (все значения dT выше порога) до 100%. Значение Type-P-One-way-Delay-Inverse-Percentile будет неопределённым для пустой выборки.

В приведённом выше примере Inverse-Percentile для 103 мсек составляет 50%.

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

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

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

7. Отличия от RFC 2679

Приведённый выше текст является пересмотром RFC 2679³, имеющего статус Internet Standard. Здесь перечислены отличия от [RFC2679].

В [RFC6808] представлен план тестирования и результаты, поддерживающие продвижение [RFC2679] в процессе Standards Track в соответствии с процедурой [RFC6576]. Выводы [RFC6808] включают 4 указанных ниже изменения.

В параграфе 6.2.3 [RFC6808] отмечено, что допущение о постобработке для обеспечения постоянного порога времени ожидания разумно и это следует включить в текст RFC. Применимость постобработки добавлена в последний абзац параграфа 3.6.
В параграфе 6.5 [RFC6808] указано, что статистика Type-P-One-way-Delay-Inverse-Percentile была проигнорирована в обоих реализациях, поэтому она была кандидатом на удаление или отмену в этом документе (это незначительное несоответствие не влияет на процесс стандартизации). Статистика была отменена в параграфе 5.4.
В IETF достигнуто соглашение о рекомендациях по отчётам о показателях [RFC6703] и этот документ указан здесь для учёта при необходимости недавнего опыта. Ссылка добавлена в последние абзацы параграфов 3.6, 3.8 и раздела 5.
Имеется сообщение об ошибке со статусом Held for Document Update (EID 398) для [RFC2679] и соответствующий пересмотр и дополнительный текст включены в параграф 5.1.

Ряд обновлений [RFC2679] реализован в приведённом выше тексте ссылками на ключевые IPPM RFC, одобренные после [RFC2679], и учётом комментариев в почтовой конференции IPPM, описывающих текущие условия и опыт применения.

В конце параграфа 1.1 обновлён пример сети, использующей ATM, с разъяснение влияния TCP на занятость очередей, и обсуждается важность измерения односторонней задержки.
В параграфах 3.2 и 4.2 явно включён входной параметр максимального времени ожидания для отражения принятия этого параметра в более поздних RFC и ITU-T Recommendation Y.1540.
Добавлены ссылки на RFC 6703 при обсуждении времени существования пакетов и тайм-аутов приложений в параграфе 3.5.
Добавлена ссылка на принятое по умолчанию требование (стандартный формат пакетов) из RFC 2330 в качестве элемента списка в параграфе 3.5.
Для NTP на основе GPS в параграфе 3.5 был исключён статус «для проверки» (to be tested).
Предпочтения (precedence) заменены более современным термином DS Field в параграфах 3.6 и 3.8.1(со ссылкой).
Добавлены заключённые в скобки рекомендации по минимизации интервала между получением временной метки и отправкой пакета в параграфе 3.6.
В параграфе 3.7.2 отмечено, что некоторые современные системы устанавливают временные метки на оборудовании сетевого интерфейса.
Термин «инструмент» (instrument) заменён определенным термином «хост» (host) в параграфах 3.7.3 и 3.8.3.
Добавлена ссылка на RFC 3432 в части периодической выборки наряду с выборкой Пуассона а разделе 4, а также указано, что распределение Пуассона с отсечкой может потребоваться в современных сетях, как указано в обновлении IPPM Framework [RFC7312].
Добавлена ссылка на RFC 4737, связанная с метрикой разупорядочения, при обсуждении методик (параграф 4.6).
Изменён формат примера в параграфе 5.1 для соответствия оригиналу (преобразование в XML).
Уточнены заключения о двух связанных аспектах нарушения измерений (распознавание измерительного трафика с непредусмотренной трактовкой трафика измерений и имитирующего его злонамеренного трафика) в разделе «6. Вопросы безопасности».
Расширен и обновлён материал по приватности и добавлены предупреждения об использовании инструментов для зондирования (разведки) в разделе «6. Вопросы безопасности».

В [RFC6921] предложена область, для которой может потребоваться изменение этого документа. В сетях FTL (Faster-Than-Light) могут возникать отрицательные задержки и изменение порядка пакетов, однако оба этих обстоятельства учитываются в спецификации и не требуют её пересмотра (отметим, что [RFC6921] является первоапрельским).

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

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

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.

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

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, «Framework for IP Performance Metrics», RFC 2330, DOI 10.17487/RFC2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.

[RFC2678] Mahdavi, J. and V. Paxson, «IPPM Metrics for Measuring Connectivity», RFC 2678, DOI 10.17487/RFC2678, September 1999, <http://www.rfc-editor.org/info/rfc2678>.

[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, «A One-way Delay Metric for IPPM», RFC 2679, DOI 10.17487/RFC2679, September 1999, <http://www.rfc-editor.org/info/rfc2679>.

[RFC7680] Almes, G., Kalidini, S., Zekauskas, M., and A. Morton, Ed., «A One-Way Loss Metric for IP Performance Metrics (IPPM)», RFC 7680, DOI 10.17487/RFC7680, January 2016, <http://www.rfc-editor.org/info/rfc7680>.

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

[RFC6390] Clark, A. and B. Claise, «Guidelines for Considering New Performance Metric Development», BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.

[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, «Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track», RFC 6808, DOI 10.17487/RFC6808, December 2012, <http://www.rfc-editor.org/info/rfc6808>.

[RFC6921] Hinden, R., «Design Considerations for Faster-Than-Light (FTL) Communication», RFC 6921, DOI 10.17487/RFC6921, April 2013, <http://www.rfc-editor.org/info/rfc6921>.

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

Применительно к [RFC2679] спасибо Vern Paxson из Lawrence Berkeley Labs за полезные комментарии по погрешности часов и статистике. Спасибо также Garry Couch, Will Leland, Andy Scherrer, Sean Shapira, Roland Wittig за полезные предложения.

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

Guy Almes

Texas A&M

Email: almes@acm.org

Sunil Kalidindi

Ixia

Email: skalidindi@ixiacom.com

Matt Zekauskas

Internet2

Email: matt@internet2.edu

Al Morton (редактор)

AT&T Labs

200 Laurel Avenue South

Middletown, NJ 07748

United States

Phone: +1 732 420 1571

Fax: +1 732 368 1192

Email: acmorton@att.com

URI: http://home.comcast.net/~acmacm/

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.

3В оригинале ошибочно указано RFC 2769. Прим. перев.

Рубрика: RFC, Измерения и тестирование | Оставить комментарий

RFC 7729 Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management

Опубликовано 19.12.2015 автором Nikolai Malykh

Internet Engineering Task Force (IETF)                     B. Khasnabish
Request for Comments: 7729                                  ZTE TX, Inc.
Category: Standards Track                                  E. Haleplidis
ISSN: 2070-1721                                     University of Patras
                                                      J. Hadi Salim, Ed.
                                                       Mojatatu Networks
                                                           December 2015

Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management

Дополнительное управление логическими блоками ForCES LFB

PDF

Аннотация

Опыт развертывания показал значение архитектуры ForCES¹ для управления ресурсами, не относящимися напрямую к пересылке пакетов. При таком разделении менеджер элементов пересылки (FEM²) моделируется путем создания логического функционального блока (LFB³) для представления его функциональности. Эти LFB называют SM⁴ LFB. Элемент управления CE (Control Element) , контролирующий ресурсы элементов пересылки FE (Forwarding Element), может также управлять их конфигурацией через SM LFB. Этот документ вводит класс SM LFB и класс LFB, задающий параметры конфигурации FE. Конфигурационные параметры включают загрузку нового класса LFB и ассоциацию с CE, а также обеспечивают операции механизмов отладки с атрибутами общего назначения для описания конфигурационной информации.

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

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

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

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

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

1. Введение

Опыт развертывания систем показал важность использования архитектуры ForCES для управления ресурсами, не относящимися к пересылке пакетов. В этом ключе менеджер элементов пересылки (FEM) моделируется путем создания логического функционального блока (LFB) для представления его функциональности. Этот блок LFB назван SM LFB. Элемент управления (CE), контролирующий ресурсы элемента пересылки (FE), может также управлять конфигурацией FE через SM LFB. Этот документ вводит класс SM LFB и блок LFB, задающий конфигурационные параметры FE.

На работающем FE приложение CE может обновить рабочую конфигурацию FE через экземпляр SM LFB.

                        Элемент сети ForCES 
                       +-------------------------------------+
                       |         +---------------------+     |
                       |         |Управляющ. приложение|     |
                       |         +--+--------------+---+     |
                       |            |              |         |
                       |            |              |         |
--------------   Fc    | -----------+--+      +-----+------+ |
| Менеджер CE|---------+-|     CE 1    |------|    CE 2    | |
--------------         | |             |  Fr  |            | |
      |                | +-+---------+-+      +------------+ |
      | Fl             |   |         | Fp        /           |
      |                |   |         +--------+ /            |
      |                |   | Fp               |/             |
      |                |   |                  |              |
      |                |   |         Fp      /|----+         |
      |                |   |       /--------/      |         |
--------------     Ff  | ---+----------      --------------  |
| Менеджер FE|---------+-|     FE 1   |  Fi  |     FE 2   |  |
--------------         | |            |------|            |  |
                       | --------------      --------------  |
                       |   |  |  |  |          |  |  |  |    |
                       ----+--+--+--+----------+--+--+--+-----
                           |  |  |  |          |  |  |  |
                           |  |  |  |          |  |  |  |
                             Fi/f                   Fi/f
Fp: интерфейс CE-FE
Fr: интерфейс CE-CE
Fc: интерфейс между CE и менеджером CE
Ff: интерфейс между FE и менеджером FE
Fl: интерфейс между менеджерами CE и FE
Fi/f: внешний интерфейс FE

Рисунок 1. Архитектурная схема ForCES.

На рисунке 1 показано управляющее приложение, манипулирующее в процессе работы конфигурацией FE через элемент управления SM LFB. Представляется, что это управляющее приложение играется роль части менеджера FE и передает сообщения для Ff (интерфейс между FEM и FE) через стандартный уровень Fp. Однако SM LFB описывает подмножество операций, которые могут быть выполнены через Ff, и не предлагает уходить от интерфейса Ff.

Класс SM LFB описывает конфигурационные параметры FE, а именно — классы LFB, которые следует загрузить, CE, с которым следует организовать ассоциации, а также соответствующие IP-адреса CE. В дополнение к этому SM LFB обеспечивает определение атрибута общего назначения для описания конфигурационной информации, а также возможности манипуляций с механизмом ведения журнала отладки.

Этот документе предполагает, что элементы FE уже загружены. Конфигурация FE может быть обновлена во время работы через SM LFB с целью настройки рабочей конфигурации. Документ не задает и не стандартизует интерфейс FEM-FE (Ff), описанный в [RFC3746]. Данный документ описывает механизм, с помощью которого CE может инструктировать SM в части управления FE по протоколу ForCES.

В этой работе не принимается допущений о физической или виртуальной природе ресурсов FE. Фактически представленная здесь библиотека LFB применима к обоим вариантам. Таким образом, она может быть полезна для управления виртуальными FE, где отдельные FEM могут создавать, настраивать и управлять ресурсами таких виртуальных FE внутри физического элемента FE.

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

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

1.2. Определения

Этот документ использует перечисленные ниже термины, которые определены в [RFC3654], [RFC3746], [RFC5810] и [RFC5812]. В частности, предполагается знакомство читателя с приведенными ниже требованиями.

Logical Functional Block (LFB) — логический функциональный блок;
Forwarding Element (FE) — элемент пересылки;
Control Element (CE) — элемент управления;
ForCES Network Element (NE) — элемент сети ForCES;
FE Manager (FEM) — менеджер FE;
CE Manager — менеджер CE;
ForCES Protocol — протокол ForCES;
ForCES Protocol Layer (ForCES PL) — уровень протокола ForCES;
ForCES Protocol Transport Mapping Layer (ForCES TML) — уровень транспортного отображения ForCES.

2. Варианты применения

В этом разделе представлены варианты применения, иллюстрирующие необходимость и пользу SM LFB.

Во всех примерах предполагается, что элемент FE уже загружен и связан хотя бы с одним CE. Управляющее приложение может удалить CE из таблицы CE элемента FE, инструктируя FE разорвать соединение с удаляемым CE. Аналогично, управляющее приложение через первичный элемент CE инструктирует FE организовать ассоциацию ForCES с новым CE, добавляя его в свою таблицу элементов CE.

2.1. Высокая доступность (HA)

Предположим, что FE связан с одним CE. Во время работы управляющее приложение CE может в целях резервирования связать FE с другим элементом CE в качестве резервного. Для этого управляющее приложение CE указывает идентификатор элемента управления (CEID⁷) для нового резервного CE (уникальный в рамках NE) и IP-адрес этого CE (IPv4 или IPv6).

2.2. Расширяемость

Предположим кластер NE, где элементы FE связаны с множеством CE, возможно с активным резервированием. Затем предположим, что обнаружилась «пробка» на отдельном CE. Можно загрузить новый CE и перенести на него некоторые FE. Для этого управляющее приложение CE запросит у FE сначала подключиться к новому CE, а затем сделать его основным, как описано в [RFC7121].

2.3. Добавление новых ресурсов к NE

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

2.4. Установка нового класса LFB

CE может узнать через возможность DynamicLFBLoading в SM LFB о способности FE загружать новые классы LFB. При поддержке FE загрузки новых классов LFB элемент CE может запросить установку и поддержке FE нового LFB.

Для загрузки класса LFB на FE элемент CE будет предоставлять следующие параметры:

LFB class — идентификатор класса LFB;
LFB version — версия класса LFB;
LFB class name — (необязательно) имя LFB;
Parameters — дополнительные параметры, которые могут зависеть от реализации (например, путь к классу).

Поле параметров должно быть описано в документации и зависит от реализации. Например, это может быть указание места установки класса LFB и/или механизма для загрузки класса. Детали описания зависят от реализации и выходят за рамки этого документа. Однако эта библиотека LFB предоставляет возможность SupportedParameters, которая будет служить для всех стандартизованных параметров.

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

2.5. Механизм системного журнала

Класс SM LFB также поддерживает манипуляции с уровнями записи в системный журнал (log-level). Опыт показывает, что CE может потребоваться снизить или повысить уровень отладочной информации в отдельных частях FE, будь это LFB, части LFB или базовый код обработки (все это называется модулями). Детализация модулей зависит от реализации и здесь не рассматривается. Уровни отладки берутся из реестра «syslog Message Severities» <http://www.iana.org/assignments/syslog-parameters>, определенного в [RFC3164].

2.6. Определение атрибута общего назначения

Опыт показывает, что пары «имя-значение» базовых атрибутов полезны для описания конфигурационной информации. Данный класс LFB определяет такие базовые атрибуты как таблицу пар «имя-значение». Эти пары зависят от реализации и на момент написания этого документа ни одна из них не была стандартизована. В качестве примера рассмотрим коммутаторы, имеющие одинаковые классы LFB и возможности, но применяемые в разных ролях. Это могут быть например коммутаторы Spine или ToR⁸ в ЦОД. Атрибут, определяющий роль коммутатора, может быть получен от FE и будет определять настройку и управление этим коммутатором. Однако, как в случае параметров загрузки LFB, данная библиотека классов LFB предоставляет в качестве заменителя возможность SupportedArguments, которая будет содержать любые стандартизованные аргументы. Данный документ такие аргументы не стандартизует. Предполагается, что CE прочитает возможность SupportedArguments, чтобы знать, как атрибуты модно применять.

3. Заявление о применимости

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

3.1. Интегрированный FE

Может использоваться лишь один класс SM LFB, напрямую связанный с FE.

3.2. Виртуальный FE

В случае программ FE с иерархией виртуальных FE может существовать множество классов SM LFB, по одному на виртуальный FE.

4. Библиотека SM

4.1. Определения кадров

Этот класс LFB не определяет каких-либо кадров.

4.2. Определения типов данных

Определяемые библиотекой типы данных перечислены в таблице.

Имя типа данных	Тип	Описание
loglevels	Перечисляемый неделимы тип данных на основе символов.	Возможные уровни отладки, полученные из syslog.
LogRowType	Структура, содержащая 3 компоненты — LogModule (string), необязательное имя файла ModuleFilename (string) и необязательный уровень отладки DebugLevel (одно из значений loglevels)	Строка модуля записи в системный журнал.
CERow	Структура, содержащая 3 компоненты — семейство адресов CE IP (uchar), IP-адрес CE (octetstring[16]), идентификатор CE (uint32).	Структура, определяющая строку таблицы CE.
LCRowtype	Структура, содержащая 4 компоненты — идентификатор класса LFB (uint32), версию LFB (string[8]), необязательное имя LFB (string) и значение атрибута (string).	Определение конфигурации класса LFB.
NameVal	Структура, содержащая 2 компоненты — имя атрибута (string) и его значение (string).	Произвольная структура «имя-значение».

4.3. Определения метаданных

Этот блок LFB не содержит определений метаданных.

4.4. SM

Subsidiary Mechanism LFB представляет собой LFB, стандартизующий настройку параметров конфигурации FE.

4.4.1. Обработка данных

SM LFB не обрабатывает пакетов, а лишь обеспечивает CE возможность изменения параметров конфигурации во время работы.

4.4.2. Компоненты

Этот класс LFB включает 4 компоненты, описанных ниже.

Компонента Debug (ID 1) представляет собой таблицу для поддержки изменения уровней отладки модуля FE. Изменения строк таблицы отладки FE будут менять уровень отладки соответствующего модуля.

Компонента LFBLoad (ID 2) является таблицей классов LFB, которые загружает FE. Добавление новых строк в эту таблицу инструктирует FE загружать новые классы LFB, а удаление строк будет приводить к выгрузке, если это возможно. Эти два аспекта будут менять таблицу возможностей SupportedLFBs в FEObject LFB [RFC5812]. Каждая такая строка должна обеспечивать (и это задано данной библиотекой) идентификатор класса LFB. Может также указываться идентификатор класса LFB и FE должен предполагать использование версии 1.0 по умолчанию.

Компонента AttributeValues (ID 3) является таблицей AttributeValues с базовыми парами «атрибут-значение».

CEs (ID 4) представляет собой таблицу CE, к которым мы просим подключаться элемент FE. Добавляя строку в эту таблицу, CE инструктирует FE поддерживать возможность подключения к указанному CE. Удаляя строку из таблицы, CE инструктирует FE разорвать соединение с CE. Взаимодействие FE с новыми CE зависит от операций, описанных в [RFC7121].

Следует отметить, что базовые пары «атрибут-значение», параметры LFBload и информация модуля представляются строками (string). Для корректной работы с размерами строк приложение CE может извлекать информацию из свойств компонент, как указано в [RFC5812].

4.4.3. Возможности

Этот блок LFB обеспечивает 3 возможности. DynamicLFBLoading определяет поддержку элементом FE динамической загрузки новых классов LFB. SupportedParameters является заменителем для хранения всех параметров загружаемого класса LFB. SupportedAttributes также служит заменителем для хранения всех поддерживаемых атрибутов таблицы пар attribute-value.

4.4.4. События

В этом блоке LFB задан 4 события. Два события отражают добавление CE и сообщают CE о добавленной или удаленной записи для другого CE. В обоих случаях уведомление о событии указывает содержимое добавленной или удаленной строки. Еще два события отражают загрузку классов LFB и уведомляют о добавлении или удалении класса.

5. XML для SM LFB

   <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" provides="SM">
     <!-- XXX  -->
     <dataTypeDefs>
       <dataTypeDef>
         <name>loglevels</name>
         <synopsis>Возможные уровни отладки для журнала (из syslog).
         </synopsis>
         <atomic>
           <baseType>char</baseType>
           <specialValues>
             <specialValue value="-1">
               <name>DEB_OFF</name>
               <synopsis>Запись в системный журнал отключена</synopsis>
             </specialValue>
             <specialValue value="0">
               <name>DEB_EMERG</name>
               <synopsis>Уровень Emergency</synopsis>
             </specialValue>
             <specialValue value="1">
               <name>DEB_ALERT</name>
               <synopsis>Уровень Alert</synopsis>
             </specialValue>
             <specialValue value="2">
               <name>DEB_CRIT</name>
               <synopsis>Уровень Critical</synopsis>
             </specialValue>
             <specialValue value="3">
               <name>DEB_ERR</name>
               <synopsis>Уровень Error</synopsis>
             </specialValue>
             <specialValue value="4">
               <name>DEB_WARNING</name>
               <synopsis>Уровень Warning</synopsis>
             </specialValue>
             <specialValue value="5">
               <name>DEB_NOTICE</name>
               <synopsis>Уровень Notice</synopsis>
             </specialValue>
             <specialValue value="6">
               <name>DEB_INFO</name>
               <synopsis>Уровень Info</synopsis>
             </specialValue>
             <specialValue value="7">
               <name>DEB_DEBUG</name>
               <synopsis>Уровень Debug</synopsis>
             </specialValue>
           </specialValues>
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
         <name>LogRowtype</name>
         <synopsis>Строка модуля системного журнала</synopsis>
         <struct>
           <component componentID="1">
             <name>lmodule</name>
             <synopsis>Имя модуля LOG</synopsis>
             <typeRef>string</typeRef>
           </component>
           <component componentID="2">
             <name>filename</name>
             <synopsis>Имя файла модуля системного журнала</synopsis>
             <optional/>
             <typeRef>string</typeRef>
           </component>
           <component componentID="3">
             <name>deblvl</name>
             <synopsis>Уровень отладки</synopsis>
             <optional/>
             <typeRef>loglevels</typeRef>
           </component>
         </struct>
       </dataTypeDef>
       <dataTypeDef>
         <name>CERow</name>
         <synopsis>Строка таблицы CE</synopsis>
         <struct>
           <component componentID="1">
             <name>AddressFamily</name>
             <synopsis>Семейство адресов</synopsis>
             <atomic>
               <baseType>uchar</baseType>
               <specialValues>
                 <specialValue value="2">
                   <name>IFA_AF_INET</name>
                   <synopsis>IPv4</synopsis>
                 </specialValue>
                 <specialValue value="10">
                   <name>IFA_AF_INET6</name>
                   <synopsis>IPv6</synopsis>
                 </specialValue>
               </specialValues>
             </atomic>
           </component>
           <component componentID="2">
             <name>CEIP</name>
             <synopsis>Адрес CE IPv4 или IPv6 (задан семейством)</synopsis>
             <typeRef>octetstring[16]</typeRef>
           </component>
           <component componentID="3">
             <name>CEID</name>
             <synopsis>Идентификатор CE</synopsis>
             <optional/>
             <typeRef>uint32</typeRef>
           </component>
         </struct>
       </dataTypeDef>
       <dataTypeDef>
         <name>LCRowtype</name>
         <synopsis>Определение конфигурации класса LFB</synopsis>
         <struct>
           <component componentID="1">
             <name>LFBClassID</name>
             <synopsis>Идентификатор класса LFB</synopsis>
             <typeRef>uint32</typeRef>
           </component>
           <component componentID="2">
             <name>LFBVersion</name>
             <synopsis>Версия класса LFB</synopsis>
             <optional/>
             <typeRef>string</typeRef>
           </component>
           <component componentID="3">
             <name>LFBName</name>
             <synopsis>Имя класса LFB</synopsis>
             <optional/>
             <typeRef>string</typeRef>
           </component>
           <component componentID="4">
             <name>Parameters</name>
             <synopsis>Необязательные параметры, такие как место 
             размещение LFB</synopsis>
             <optional/>
             <typeRef>string</typeRef>
           </component>
         </struct>
       </dataTypeDef>
       <dataTypeDef>
         <name>NameVal</name>
         <synopsis>Произвольная структура Name-Value</synopsis>
         <struct>
           <component componentID="1">
             <name>AttrName</name>
             <synopsis>Имя атрибута</synopsis>
             <typeRef>string</typeRef>
           </component>
           <component componentID="2">
             <name>AttrVal</name>
             <synopsis>Значение атрибута</synopsis>
             <typeRef>string</typeRef>
           </component>
         </struct>
       </dataTypeDef>
     </dataTypeDefs>
     <LFBClassDefs>
       <LFBClassDef LFBClassID="19">
         <name>SM</name>
         <synopsis>Subsidiary Management LFB</synopsis>
         <version>1.0</version>
         <components>
           <component componentID="1" access="read-write">
             <name>Debug</name>
             <synopsis>Таблица для поддержки смены уровней отладки
             </synopsis>
             <array type="variable-size">
               <typeRef>LogRowtype</typeRef>
             </array>
           </component>
           <component componentID="2" access="write-only">
             <name>LFBLoad</name>
             <synopsis>Класс LFB для загрузки</synopsis>
             <array type="variable-size">
               <typeRef>LCRowtype</typeRef>
             </array>
           </component>
           <component componentID="3" access="read-write">
             <name>AttributeValues</name>
             <synopsis>Таблица значений базовых атрибутов SM</synopsis>
             <array type="variable-size">
               <typeRef>NameVal</typeRef>
             </array>
           </component>
           <component componentID="4" access="write-only">
             <name>CEs</name>
             <synopsis>Таблица CE, с которыми просят связаться FE
             </synopsis>
             <array type="variable-size">
               <typeRef>CERow</typeRef>
             </array>
           </component>
         </components>
         <!---->
         <capabilities>
           <capability componentID="10">
             <name>DynamicLFBLoading</name>
            <synopsis>Эта возможность указывает поддержку FE
              динамической загрузки новых LFB</synopsis>
             <typeRef>boolean</typeRef>
           </capability>
           <capability componentID="11">
             <name>SupportedParameters</name>
             <synopsis>Эта возможность содержит все
              поддерживаемые параметры</synopsis>
             <array type="variable-size">
               <typeRef>string</typeRef>
             </array>
           </capability>
           <capability componentID="12">
             <name>SupportedAttributes</name>
             <synopsis>Эта возможность содержит имена всех
              поддерживаемых атрибутов</synopsis>
             <array type="variable-size">
               <typeRef>string</typeRef>
             </array>
           </capability>
         </capabilities>
         <events baseID="20">
           <event eventID="1">
             <name>CEAdded</name>
             <synopsis>CE для добавления</synopsis>
             <eventTarget>
               <eventField>CEs</eventField>
             </eventTarget>
             <eventCreated/>
             <eventReports>
               <eventReport>
                 <eventField>CEs</eventField>
                 <eventSubscript>_CEIDsrowid_</eventSubscript>
               </eventReport>
             </eventReports>
           </event>
           <event eventID="2">
             <name>CEDeleted</name>
             <synopsis>CE для удаления</synopsis>
             <eventTarget>
               <eventField>CEs</eventField>
               <eventSubscript>_CEIDsrowid_</eventSubscript>
             </eventTarget>
             <eventDeleted/>
             <eventReports>
               <eventReport>
                 <eventField>CEs</eventField>
                 <eventSubscript>_CEIDsrowid_</eventSubscript>
               </eventReport>
             </eventReports>
           </event>
           <event eventID="3">
             <name>LFBLoaded</name>
             <synopsis>LFB для загрузки</synopsis>
             <eventTarget>
               <eventField>LFBLoad</eventField>
             </eventTarget>
             <eventCreated/>
             <eventReports>
               <eventReport>
                 <eventField>LFBLoad</eventField>
                 <eventSubscript>_LFBLoadrowid_</eventSubscript>
               </eventReport>
             </eventReports>
           </event>
           <event eventID="4">
             <name>LFBUnloaded</name>
             <synopsis>CE для выгрузки (отключения)</synopsis>
             <eventTarget>
               <eventField>LFBLoad</eventField>
               <eventSubscript>_LFBLoadrowid_</eventSubscript>
             </eventTarget>
             <eventDeleted/>
             <eventReports>
               <eventReport>
                 <eventField>LFBLoad</eventField>
                 <eventSubscript>_LFBLoadrowid_</eventSubscript>
               </eventReport>
             </eventReports>
           </event>
         </events>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>

Рисунок 2. Библиотека LFB FEM

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

Этот документ не меняет модель ForCES [RFC5812] или протокол ForCES [RFC5810]. Поэтому он не оказывает влияния на безопасность модели и протокола. Документ просто определяет рабочие параметры и возможности LFB, которыми управляет SM для загрузки LFB и создания новых соединений между FE и CE.

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

менеджер FE, отвечающий за управление элементами FE;
CE, с которым уже установлена связь.

В обоих случаях, элемент, создающий соединения, уже должен быть доверенным в части таких действий. Если такой элемент оказывается дефектным, мошенническим или взломанным, у FE нет возможности узнать об этом и он выполнит действие, запрошенное CE. По этой причине данный документ не пытается анализировать вопросы безопасности, которые могут быть связаны с недопустимым использованием SM LFB. Любая из таких проблем, при ее возникновении и стратегия смягчения отдается на откуп разработчикам SM, а не решается базовым механизмом.

Читателю также следует обратиться к модели ForCES [RFC3746] (раздел 8), где рассматриваются возможные угрозы при использовании ForCES и способы решения проблем в архитектуре безопасности ForCES.

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

7.1. Имена и идентификаторы классов LFB

Классы LFB, определенные в этом документе, относятся к LFB, определяемым в Standards Track RFC. Процедура регистрации Standards Action применяется для значений от 0 до 65535, выделение в порядке поступления запросов (First Come First Served) при наличии спецификации с открытым доступом для идентификаторов больше 65535 [RFC5226]. Данная спецификация регистрирует приведенные ниже имя и идентификатор класса LFB в реестре «Logical Functional Block (LFB) Class Names and Class Identifiers».

Идентификатор класса LFB	Имя класса LFB	Версия LFB	Описание	Документ
19	SM	1.0	SM LFB для стандартизации дополнительного управления элементами ForCES FE	RFC 7729

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, <http://www.rfc-editor.org/info/rfc2119>.

[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, «Forwarding and Control Element Separation (ForCES) Protocol Specification», RFC 5810, DOI 10.17487/RFC5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.

[RFC5812] Halpern, J. and J. Hadi Salim, «Forwarding and Control Element Separation (ForCES) Forwarding Element Model», RFC 5812, DOI 10.17487/RFC5812, March 2010, <http://www.rfc-editor.org/info/rfc5812>.

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

[RFC3164] Lonvick, C., «The BSD Syslog Protocol», RFC 3164, DOI 10.17487/RFC3164, August 2001, <http://www.rfc-editor.org/info/rfc3164>.

[RFC3654] Khosravi, H., Ed. and T. Anderson, Ed., «Requirements for Separation of IP Control and Forwarding», RFC 3654, DOI 10.17487/RFC3654, November 2003, <http://www.rfc-editor.org/info/rfc3654>.

[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, «Forwarding and Control Element Separation (ForCES) Framework», RFC 3746, DOI 10.17487/RFC3746, April 2004, <http://www.rfc-editor.org/info/rfc3746>.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

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

Авторы признательны Damascene Joachimpillai, Joel Halpern, Chuanhuang Li и многим другим за помощь и плодотворные дискуссии.

Авторы благодарны Joel Halpern за руководство подготовкой документа, Alia Atlas за спонсорскую помощь, Juergen Schoenwaelder за оперативное управление и Алексею Мельникову за обзор безопасности.

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

Bhumip Khasnabish

ZTE TX, Inc.

55 Madison Avenue, Suite 160

Morristown, New Jersey 07960

United States

Phone: +001-781-752-8003

Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com

URI: http://tinyurl.com/bhumip/

Evangelos Haleplidis

University of Patras

Department of Electrical and Computer Engineering

Patras 26500

Greece

Email: ehalep@ece.upatras.gr

Jamal Hadi Salim (editor)

Mojatatu Networks

Suite 200, 15 Fitzgerald Road

Ottawa, Ontario K2H 9G1

Canada

Email: hadi@mojatatu.com

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

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

nmalykh@protokols.ru

1Forwarding and Control Element Separation — разделение элементов управления и пересылки.

2Forwarding Element Manager.

3Logical Functional Block.

4Subsidiary Mechanism — дополнительный механизм.

5Internet Engineering Task Force.

6Internet Engineering Steering Group.

7Control Element ID.

8Top-of-Rack — коммутатор стойки.

Рубрика: RFC | Комментарии отключены