Осадка конуса гост: ГОСТ 10181-2000 Смеси бетонные. Методы испытаний / 10181 2000

Испытания бетонной смеси. Часть 8. Самоуплотняющийся бетон. Испытание смеси на расплыв – РТС-тендер

  • Обозначение: ГОСТ Р 58002-2017

  • Статус: действующий

  • Название русское: Испытания бетонной смеси. Часть 8. Самоуплотняющийся бетон. Испытание смеси на расплыв

  • Название английское: Testing fresh concrete. Part 8. Self-compacting concrete. Slump-flow test

  • Дата актуализации текста: 01.06.2022

  • Дата актуализации описания: 01.01.2023

  • Дата издания: 09.12.2019

  • Дата введения в действие: 01.08.2018

  • Дата завершения срока действия: 14. 01.2020

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

  • Опубликован: Официальное издание. М.: Стандартинформ, 2018 год

  • Утверждён в: Росстандарт

Закупки с Испытания бетонной смеси. Часть 8. Самоуплотняющийся бетон. Испытание смеси на расплыв


ГОСТ Р 58002-2017/EN 12350-8:2010

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ОКС 91.100.30

Дата введения 2018-08-01

1 ПОДГОТОВЛЕН структурным подразделением Акционерного общества «Научно-исследовательский центр «Строительство» (АО «НИЦ «Строительство») — Научно-исследовательский, проектно-конструкторский и технологический институт бетона и железобетона им.

А.А.Гвоздева (НИИЖБ им.А.А.Гвоздева) на основе официального перевода на русский язык немецкоязычной версии указанного в пункте 4 европейского стандарта, который выполнен Федеральным государственным унитарным предприятием «Российский научно-технический центр информации по стандартизации, метрологии и оценке соответствия» (ФГУП «СТАНДАРТИНФОРМ»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 465 «Строительство»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 24 ноября 2017 г. N 1842-ст

4 Настоящий стандарт идентичен европейскому стандарту EN 12350-8:2010* «Испытания свежего бетона. Часть 8. Самоуплотняющийся бетон. Испытание подвижной бетонной смеси осадкой конуса» (EN 12350-8:2010 » von Frischbeton — Teil 8: Selbstverdichtender Beton — «, IDT).

________________

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

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

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.

gost.ru)

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

В настоящем стандарте использованы нормативные ссылки на следующие европейские стандарты*:

________________

* Таблицу соответствия национальных стандартов международным см. по ссылке. — Примечание изготовителя базы данных.

EN 12350-1, von Frischbeton — Teil 1: Probenahme (Испытания бетонной смеси. Часть 1. Отбор проб; Testing fresh concrete — Part 1: Sampling)

EN 12350-2, von Frischbeton — Teil 2: (Испытания бетонной смеси. Часть 2. Испытание осадкой конуса; Testing fresh concrete — Part 2: Slump)

В настоящем стандарте применены следующие обозначения:

SF — расплыв;

— наибольший диаметр распространения расплыва, мм;

— распространение расплыва под углом 90° к , мм.

Требования изложены в ЕН 12350-1.

Расплыв и время используют для оценки подвижности и текучести самоуплотняющейся бетонной смеси при отсутствии препятствий. Они основываются на испытаниях путем измерения осадки конуса, описанных в ЕН 12350-2. Результаты являются показателем заполняющей способности самоуплотняющейся бетонной смеси. Время — показатель скорости растекания и относительной вязкости самоуплотняющейся бетонной смеси.

Бетонную смесь заливают в конус, как это делают в испытаниях осадкой конуса по ЕН 12350-2. После снятия конуса измеряют время от момента начала движения конуса вверх до растекания бетонной смеси до диаметра 500 мм, то есть это и есть время . Затем измеряют самый большой диаметр расплыва и другой диаметр, перпендикулярный ему. Среднее значение является расплывом.

Методы определения подвижности — Техинформатор

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

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

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

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

Таблица 1 — Классификация цементных сухих смесей, кроме прочих параметров 

по  на смеси
способу нанесения механизированного (с помощью специализированного механического оборудования, например, способом торкретирования) и ручного нанесения
наибольшей крупности зёрен заполнителя (Д
з max)

растворные – имеют Дз max не более 5 мм

тонкодисперсные  Дз max до 0,2 мм
дисперсные  Дз max до 0,63 мм
мелкозернистые  Дз max до 1,25 мм
крупнозернистые Дз max до 5 мм
бетонные – имеютДз max не более 20 мм  мелкозернистого бетона 
бетонные (см.
ГОСТ 26633) 
функциональному назначению1)     литьевые2) – обладающие способностью к самостоятельному (под действием силы тяжести) растеканию
ремонтные – поверхностные, чаще всего, тиксотропные – способные при повторяющихся динамических воздействиях временно увеличивать, а после прекращения воздействия восстанавливать начальную подвижность,
и инъекционные (применение которых осуществляется методом инъектирования растворной смеси внутрь конструкции)
гидроизоляционные – поверхностные (под шпатель или под кисть), инъекционные и проникающие (ГОСТ Р 56703)

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

2) Литьевые (или как их ещё называют производители сухих смесей, подливочные, наливного типа) смеси ГОСТ 31189 не выделяет в отдельную группу и на них нет нормативного документа в области стандартизации, смеси такого типа выпускают по техническим нормативным документам предприятия-изготовителя.

Таблица 2 — Методики для контроля и оценки подвижности растворных и бетонных смесей на цементном вяжущем установлены ГОСТ 31357

 Область применения     НД на методику определения      Характеристика
для бетонных смесей ГОСТ 10181
по осадке конуса, см
по расплыву конуса, см 		ГОСТ 7473
Марка по осадке конуса П1 … П5
Марка по расплыву конуса Р1 … Р6   
для растворных смесей ГОСТ 5802
по погружению конуса, мм 		ГОСТ 28013
Марка по подвижности ПК1 … ПК4
для дисперсных смесей ГОСТ 310. 4
по расплыву конуса, мм 		НД и/или ТУ на конкретные ССС
Подвижность (расплыв конуса), мм
для дисперсных самовыравнивающихся смесей   ГОСТ 31356
по расплыву кольца, мм 		ГОСТ 31358
Марка по подвижности РК1 … РК5

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

Выбор методики контроля подвижности осуществляется на основе указаний ГОСТ 31357 с учётом конкретных условий применения смеси, требований проекта, особенностей производства работ.

Пример 1. В описании сухой смеси «КТтрон-4 Л600» указано, что по функциональному назначению она является литьевой, по крупности заполнителя – дисперсной, а подвижность характеризуется маркой по погружению конуса ПК4. Это говорит только о том, что смесь растворная и имеет большую подвижность, но никак не характеризует её способность к растеканию. Было бы целесообразно характеризовать подвижность литьевой смеси маркой по расплыву кольца РК.

Пример 2. В техническом описании на ремонтную смесь «КТтрон-Торкрет С» для нанесения методом торкретирования указана марка по подвижности ПК1. Такая оценка достаточна для растворной смеси с заполнителем крупностью до 5 мм. Если по крупности заполнителя смесь относится к дисперсным, то было бы логичнее оценивать её подвижность по расплыву конуса на встряхивающем столике. Эта методика позволяет оценить и тиксотропность смеси.

Пример 3. Смесь с заполнителем крупностью до 5 мм «КТтрон-9 ЗР5,0» может быть отнесена как к растворным крупнозернистым, так и к бетонным (мелкозернистого бетона) смесям. В таких случаях при выборе методики определения подвижности (удобоукладываемости) необходимо исходить из требований проекта. Если в проекте указана бетонная смесь с маркой по подвижности П или Р, то определяют по ГОСТ 10181 осадку или расплыв конуса, соответственно, и результат оценивают по ГОСТ 7473. Если в проекте указан раствор, то определяют подвижность по погружению конуса ГОСТ 5802, оценку результат проводят по ГОСТ 28013.

Таблица 3 — Примерное соотношение характеристик подвижности готовых смесей, определённых различными методами

Растворные смеси Методика определения подвижности 

ГОСТ 5802

ГОСТ 310.4

ГОСТ 31356

Марка по погружению конуса ПК

Расплыв конуса, мм

Марка по расплыву кольца РК
Литьевые 

ПК4
(12 – 14) см

Не определяется, т. к. смесь стекает со встряхивающего 

РК4– РК5
(18-22) см – (22-26) см

Инъекционные и проникающие Не определяется, т.к. конус погружается до дна ёмкости

РК4-РК5

Под кисть и под шпатель

Рк3
(15-18) см

Тиксотропные для ручного нанесения

ПК2
(4 – 8) см

120-150

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

ПК1
(1 – 4) см

110-120

ПК2

120-150

Бетонные смеси  

ГОСТ 10181

Марка по осадке конуса

Марка по расплыву конуса

Литьевые

П5
(25-26) см

Р4-Р6

(49-55) см – (56-62) см и более 62 см

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

В настоящее время сухие строительные смеси некоторых отечественных производителей составляют серьёзную конкуренцию импортным аналогам. В связи с этим в российские стандарты, устанавливающие методы испытаний, как и в европейские, постепенно вносятся изменения с целью «приведения к общему знаменателю» существующих методик испытаний. Например, в предисловии к ГОСТ 10181-2014 указано, что «Настоящий стандарт соответствует следующим европейским региональным стандартам:

  • EN 12350-2:2009 Testing fresh concrete — Part 2: Slump test (Испытание свежеприготовленной бетонной смеси. Часть 2. Определение осадки конуса) в части общих требований к методу определения осадки конуса;

  • EN 12350-5:2009 Testing fresh concrete — Part 5: Flowtable test (Испытание свежеприготовленной бетонной смеси. Часть 5. Определение расплыва) в части метода определения расплыва».

Но оценка полученных результатов по европейским стандартам и по отечественным остаётся разной. Так, по немецким стандартам реологические свойства некоторых типов растворных смесей характеризуются марками «устойчивая» или «жёсткая», «пластичная» и «жидкая».

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

RFC 7837 — Вариант назначения IPv6 для выявления перегрузки (ConE (RFC7837)


[Указатель RFC | Часто задаваемые вопросы о Usenet | Веб-Часто задаваемые вопросы | Документы | Города | Документы SEC | Архив форума ]

Целевая группа по проектированию Интернета (IETF) С. Кришнан
Запрос комментариев: 7837 Ericsson
Категория: Экспериментальный М. Кюлевинд
ISSN: 2070-1721 ETH Цюрих
                                                              Б. Бриско
                                              Исследовательская лаборатория Simula
                                                                К.  Ралли
                                                              Телефоника
                                                                май 2016 г.
        Вариант назначения IPv6 для выявления перегрузки (ConEx)
Абстрактный
   Congestion Exposure (ConEx) — это механизм, с помощью которого отправители информируют
   сеть о перегрузке, с которой столкнулись пакеты ранее в
   тот же поток. В этом документе указан параметр назначения IPv6.
   который способен нести маркировку ConEx в дейтаграммах IPv6.
Статус этого меморандума
   Этот документ не является спецификацией Internet Standards Track; это
   опубликованы для изучения, экспериментальной реализации и
   оценка.
   Этот документ определяет экспериментальный протокол для Интернета.
   сообщество. Этот документ является продуктом Internet Engineering
   Целевая группа (IETF). Он представляет собой консенсус IETF
   сообщество. Он прошел общественное обсуждение и был одобрен для
   публикация Руководящей группы Internet Engineering (IESG).  Нет
   все документы, одобренные IESG, являются кандидатами на любой уровень
   Стандарт Интернета; см. раздел 2 RFC 5741.
   Информация о текущем статусе этого документа, любых опечатках,
   и как предоставить отзыв о нем можно получить на
   http://www.rfc-editor.org/info/rfc7837.
Уведомление об авторских правах
   Copyright (c) 2016 IETF Trust и лица, указанные в качестве
   авторы документа. Все права защищены.
   Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
   Положения, касающиеся документов IETF
   (http://trustee.ietf.org/license-info) действует на дату
   публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
   внимательно, так как они описывают ваши права и ограничения в отношении
   к этому документу. Компоненты кода, извлеченные из этого документа, должны
   включить текст упрощенной лицензии BSD, как описано в Разделе 4.e
   Доверительные юридические положения и предоставляются без гарантии, поскольку
   описан в Упрощенной лицензии BSD. 
Оглавление
   1. Введение  . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Условные обозначения, используемые в этом документе. . . . . . . . . . . . . . 3
   3. Требования к кодированию ConEx в IPv6. . . . . . . . 4
   4. Вариант назначения ConEx (CDO). . . . . . . . . . . . . . . 5
   5. Внедрение в Fast Path маршрутизаторов с поддержкой ConEx. . . 8
   6. Обработка туннеля. . . . . . . . . . . . . . . . . . . . . . 8
   7. Совместимость с использованием IPsec. . . . . . . . . . . . . . . 98. Противодействие флуд-атакам с помощью предпочтительного сброса. . . 9
   9. Вопросы безопасности. . . . . . . . . . . . . . . . . . . 11
   10. Соображения IANA. . . . . . . . . . . . . . . . . . . . . 11
   11. Ссылки. . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . 11
     11.2. Информативные ссылки. . . . . . . . . . . . . . . . . 12
   Благодарности. . . . . . . . . . . . . . . . . . . . . . . . 13
   Адреса авторов.  . . . . . . . . . . . . . . . . . . . . . . 13
1. Введение
   Congestion Exposure (ConEx) [RFC7713] — это механизм, с помощью которого отправители
   информировать сеть о перегрузке, с которой столкнулись пакеты
   ранее в том же потоке. Этот документ определяет IPv6
   вариант назначения [RFC2460], который можно использовать для выполнения ConEx
   маркировки в дейтаграммах IPv6.
   Этот документ определяет проводной протокол ConEx в IPv6. КонЭкс
   информация может быть использована любым сетевым элементом на пути к
   например, управлять трафиком или контролировать исходящий трафик. Кроме того,
   эта информация потенциально может быть использована аудиторской службой, которая
   проверяет целостность сигнализации отправителя. Далее каждый
   транспортный протокол, поддерживающий сигнализацию ConEx, должен
   точно указать, когда транспорт устанавливает маркировку ConEx (например,
   поведение для TCP указано в [RFC7786]).
   Этот документ определяет ConEx только для IPv6. Из-за пространства
   ограничения в заголовке IPv4 и риск опций, которые могут быть
   удален промежуточным блоком в IPv4, основная цель работы
   группа должна была указать ConEx в IPv6 для экспериментов. 
   Эта спецификация является экспериментальной и позволяет IETF оценить
   является ли решение о реализации ConEx Signal в качестве пункта назначения
   Вариант соответствует требованиям, изложенным в этом документе, а также
   оценить предлагаемое кодирование сигналов ConEx, как описано
   в [RFC7713].
   Ожидается, что продолжительность этого эксперимента составит не менее двух
   лет после публикации этого документа, поскольку необходима инфраструктура
   установить, чтобы определить результат этого эксперимента.
   Для экспериментов с ConEx требуется трафик IPv6. Несмотря на то,
   объем трафика IPv6 растет, смешанный трафик передается через IPv6
   по-прежнему сильно отличается от IPv4. Поэтому может потребоваться
   дольше, чтобы найти подходящий тестовый сценарий, в котором используется только трафик IPv6.
   управляется с помощью ConEx.
2. Условные обозначения, используемые в этом документе
   Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
   "СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ДОПОЛНИТЕЛЬНО" в этом
   документ должны интерпретироваться, как описано в [RFC2119]. 
3. Требования к кодированию ConEx в IPv6
   Набор требований к идеальному конкретному проводному протоколу ConEx:
   приведено в [RFC7713]. Рабочая группа ConEx признала, что она
   трудно найти кодировку в IPv6, удовлетворяющую всем
   требования. Выбор в этом документе для реализации ConEx
   информация в пункте назначения направлена ​​на удовлетворение тех,
   требования, ограничивающие размещение информации ConEx:
   R-1: Механизм маркировки должен быть виден всем, кто поддерживает ConEx.
         узлы на пути.
   R-2: Механизм должен иметь возможность проходить узлы, которые не
         понять маркировку. Это необходимо для обеспечения того, чтобы ConEx
         могут быть постепенно развернуты через Интернет.
   Р-3: Наличие маркировочного механизма не должно существенно
         изменить обработку пакета. Это необходимо для обеспечения
         что пакеты с ConEx-Marked не сталкиваются с неоправданными задержками или отбрасываниями
         из-за неудачно выбранного механизма.
   R-4: Маркировка должна быть неизменной после установки отправителем.  В
         по крайней мере, любое вмешательство должно быть обнаружено.
   Исходя из этих требований, четыре решения для реализации ConEx
   информация в заголовке IPv6 была исследована: hop-by-hop
   параметры, параметры назначения, используя биты заголовка IPv6 (из потока
   label) и новые заголовки расширений. После оценки различных
   решения, рабочая группа ConEx пришла к выводу, что использование
   Вариант назначения лучше всего отвечает этим требованиям.
   Варианты hop-by-hop были бы лучшим решением для перевозки
   Маркировка ConEx, если она соответствует требованию R-3. В настоящее время есть
   некоторая работа продолжается в рабочей группе 6MAN для решения этой очень
   выпуск [HBH-HEADER]. Это новое поведение касается R-3 и
   сделать пошаговые варианты предпочтительным решением для перевозки ConEx
   маркировка.
   Выбор варианта назначения не обязательно удовлетворяет
   требование видимости на пути, потому что оно может быть инкапсулировано
   дополнительные заголовки IP.  Таким образом, сетевые устройства, поддерживающие ConEx,
   включая политики или устройства аудита, возможно, придется следовать цепочке
   (extension-) во внутренние заголовки IP, чтобы найти информацию ConEx.
   Этот выбор был компромиссом между быстродействием ConEx-
   осведомленные сетевые узлы и видимость, как обсуждалось в разделе 5.
   Обратите внимание, что спецификация IPv6 [RFC2460] не требует и не
   ожидать, что промежуточные узлы будут проверять параметры назначения, такие как
   Вариант назначения ConEx (CDO). Это означает, что ConEx-осведомленный
   промежуточные узлы, следующие этой спецификации, нуждаются в обновлении
   код обработки заголовка расширения, чтобы иметь возможность прочитать пункт назначения
   параметры.
4. Вариант назначения ConEx (CDO)
   CDO — это параметр назначения, который может быть включен в IPv6.
   дейтаграммы, отправленные отправителями, поддерживающими ConEx, для информирования
   ConEx-осведомленные узлы на пути о перегрузке, с которой столкнулись
   пакеты ранее в том же потоке или ожидаемый риск встречи
   заторы в будущем.  CDO не имеет выравнивания
   требования.
    0 1 2
    0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Тип опции | Опция Длина |X|L|E|C| разрешение |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Рис. 1. Схема выбора пункта назначения ConEx
   Тип опции
      8-битный идентификатор типа опции. Установите значение 30
      (0x1E) выделен для экспериментальной работы.
   Длина опции
      8-битное целое без знака. Длина опции в октетах
      (исключая поля «Тип опциона» и «Длина опциона»). Установите на
      значение 1.
   X бит
      Когда этот бит установлен, транспортный отправитель использует ConEx с
      этот пакет. Если он не установлен, отправитель не использует ConEx с
      этот пакет.
   L бит
      Когда этот бит установлен, транспортный отправитель испытывает потерю.
   Е бит
      Когда этот бит установлен, транспортный отправитель
      о перегрузке сообщается с помощью Explicit Congestion Notification (ECN)
      [RFC3168]. 
   Бит С
      Когда этот бит установлен, транспортный отправитель создает
      кредит перегрузки в функции аудита.
   Зарезервировано (рез.)
      Эти четыре бита не используются в текущей спецификации. Они
      обнуляются отправителем и игнорируются получателем.
   Все пакеты, отправленные через TCP-соединение с поддержкой ConEx или принадлежащие
   тот же поток с поддержкой ConEx ДОЛЖЕН нести CDO. Бит chg (т.
   бит третьего старшего разряда) в поле CDO Option Type устанавливается равным нулю,
   это означает, что опция CDO неизменна. Сетевые устройства с
   Функции, поддерживающие ConEx, считывают флаги, но все сетевые устройства ДОЛЖНЫ
   переслать CDO без изменений.
   CDO ДОЛЖЕН быть размещен в качестве первого варианта в пункте назначения.
   Заголовок опции перед AH [RFC4302] и/или инкапсуляцией безопасности
   Полезная нагрузка (ESP) [RFC4303] (если имеется). Аутентификация IPsec
   Заголовок (AH) МОЖЕТ использоваться для проверки того, что CDO не был изменен.
   Если бит X равен нулю, все остальные три бита не определены и, следовательно,
   ДОЛЖЕН игнорироваться и пересылаться без изменений сетевыми узлами.  Бит X
   установленный в ноль означает, что соединение поддерживает ConEx, но это
   пакет НЕ ДОЛЖЕН учитываться при определении информации ConEx в
   функция аудита. Это может иметь место, если нет обратной связи о перегрузке.
   (в настоящее время) доступны, например, в TCP, если одна конечная точка была
   получает данные, но не отправляет ничего, кроме чистых ACK (без пользовательских данных) для
   когда-то. Это связано с тем, что чистые ACK не продвигают последовательность
   число, поэтому конечная точка TCP, получающая их, не может достоверно определить
   были ли потеряны какие-либо из-за перегрузки. Чистые TCP ACK не могут
   иметь ECN-маркировку [RFC3168].
   Если бит X установлен, любой из трех других битов (L, E или C) может
   быть установлен. Всякий раз, когда один из этих битов установлен, число байтов
   переносимый этим IP-пакетом (включая IP-заголовок, который непосредственно
   инкапсулирует CDO и все, что инкапсулирует заголовок IP)
   СЛЕДУЕТ учитывать для определения перегрузки или кредитной информации.  В
   IPv6 количество байтов можно легко рассчитать, добавив
   число 40 (длина заголовка IPv6 в байтах) к существующему значению
   в поле «Длина полезной нагрузки» в заголовке IPv6.
   Кредитный сигнал представляет потенциал для перегрузки. Если
   происходит перегрузка, расходуется соответствующая сумма кредита
   как указано в [RFC7713]. Поэтому отправителю с поддержкой ConEx СЛЕДУЕТ:
   сигнализировать о достаточном кредите до любого события перегрузки, чтобы покрыть
   (оценочное максимальное) количество потерянных или помеченных CE байтов, которые могут
   произойти в таком случае перегрузки. Эта оценка зависит от
   используемые эвристики и агрессивность отправителя при принятии
   соответствующую скорость отправки (управление перегрузкой). Обратите внимание, что максимальная
   риск перегрузки заключается в том, что все пакеты в пути теряются или маркируются знаком СЕ;
   следовательно, это будет самая консервативная оценка для
   риск заторов. После события перегрузки, если отправитель намеревается
   рискнуть еще раз, просто нужно заменить израсходованное
   кредит как неиспользованный кредит не истекает.  В случае TCP,
   это подробно описано в [RFC7786].
   Если установлен бит L или E, сигнал о перегрузке в виде потери
   или отметка ECN, соответственно, ранее была испытана тем же самым
   связь.
   В принципе, все эти три бита (L, E или C) могут быть установлены в
   тот самый пакет. В этом случае размер пакета ДОЛЖЕН учитываться один раз.
   для каждого соответствующего счетчика информации ConEx.
   Если сетевой узел извлекает информацию ConEx из соединения,
   ожидается, что эта информация будет храниться в байтах, например, сравнение
   общее количество байтов, отправленных с количеством байтов, отправленных с помощью ConEx
   метки перегрузки (L или E) для определения текущего всего пути
   уровень заторов. Таким образом, узел с поддержкой ConEx, который обрабатывает
   CDO ДОЛЖЕН использовать поле Payload Length предыдущего заголовка IPv6.
   для подсчета байтов. Когда отношение измерено и равновелико
   пакетов можно предположить, считая количество пакетов (вместо
   количество байтов) должен дать тот же результат.  Но аудит
   функция должна знать, что эта оценка может быть совершенно неправильной, если
   например, отправляются упаковки разного размера; таким образом, это не
   надежный.
   Все оставшиеся биты в CDO зарезервированы для будущего использования (которые
   в настоящее время последние четыре бита восьмибитного пространства опций). КонЭкс
   отправитель ДОЛЖЕН установить зарезервированные биты в CDO равными нулю. Другие узлы
   ДОЛЖНЫ игнорировать эти биты, и промежуточные узлы, поддерживающие ConEx, ДОЛЖНЫ
   пересылать их без изменений, какими бы ни были их значения. Они МОГУТ регистрировать
   наличие ненулевого поля Reserved.
   CDO применим только к одноадресным или произвольным пакетам (для
   рассуждения, см. примечание относительно пункта J о многоадресной рассылке в конце
   Раздел 3.3 [RFC7713]). Отправитель ConEx НЕ ДОЛЖЕН отправлять пакет
   с CDO на многоадресный адрес. Сетевые узлы с поддержкой ConEx
   ДОЛЖЕН обрабатывать многоадресный пакет с установленным флагом X так же, как
   эквивалентный пакет без CDO, и они ДОЛЖНЫ переслать его
   без изменений. 
   Как указано в [RFC7713] (см. Раздел 3.3, пункт N о сетевом уровне).
   требования), спецификации протокола должны описывать любые предупреждения или ошибки
   сообщения, относящиеся к кодировке. Предупреждений и ошибок нет
   сообщения, связанные с CDO.
5. Внедрение в Fast Path маршрутизаторов с поддержкой ConEx
   Информация ConEx кодируется в параметре назначения, поэтому
   что это не влияет на производительность пересылки в не поддерживающих ConEx
   узлы на пути. Поскольку варианты назначения обычно не
   обрабатывается маршрутизаторами, наличие CDO не влияет на
   быстрая обработка дейтаграммы на маршрутизаторах, не поддерживающих ConEx,
   т. е. они не выталкиваются на медленный путь к управлению
   плоскости для обработки исключений.
   Узлы, поддерживающие ConEx, по-прежнему должны обрабатывать CDO без особых усилий.
   влияющие на переадресацию. Чтобы это стало возможным, ConEx-осведомленный
   маршрутизаторы должны быстро установить наличие CDO и обработать
   опция, если она есть.  Для эффективного выполнения этого CDO
   должен быть размещен в довольно детерминированном месте. Для того, чтобы
   облегчить переадресацию на маршрутизаторах с поддержкой ConEx, отправителях с поддержкой ConEx
   которые отправляют дейтаграммы IPv6 с CDO, ДОЛЖНЫ поместить CDO в качестве
   первый вариант назначения в заголовке Destination Option.
6. Обработка туннеля
   Как и в случае с любым вариантом назначения, конечная точка входящего туннеля не будет
   обычно копируют CDO при добавлении инкапсулирующего внешнего IP-заголовка.
   Как правило, входной туннель НЕ ДОЛЖЕН копировать CDO во внешний
   заголовок, так как это изменит количество байтов, которые будут
   подсчитано. Однако он МОЖЕТ скопировать CDO во внешний заголовок, чтобы
   для облегчения видимости последующими функциями ConEx на пути, если
   конфигурация входа в туннель и узлов ConEx
   скоординировано. Это компрометирует производительность функций ConEx.
   по сравнению с туннельной обработкой.
   Конечная точка выходного туннеля ДОЛЖНА игнорировать любой CDO во внешнем заголовке. 
   при декапсуляции внешнего IP-заголовка. Информация в любом внутреннем
   CDO всегда будет считаться правильным, даже если он отличается от любого
   внешний CDO. Следовательно, декапсулятор может удалить внешний CDO.
   без сравнения с внутренним. Декапсулятор МОЖЕТ сравнить два
   и МОЖЕТ зарегистрировать любой случай, когда они отличаются. Однако пакет ДОЛЖЕН быть
   пересылается независимо от любой такой аномалии, если внешний CDO
   только оптимизация производительности.
   Сетевому узлу, который оценивает информацию ConEx, СЛЕДУЕТ искать
   инкапсулированные заголовки IP, пока не будет найден CDO. При любом конкретном
   расположение в сети, максимальная необходимая глубина поиска, скорее всего,
   быть одинаковым для всех пакетов между заданным набором конечных точек туннеля.
7. Совместимость с использованием IPsec
   Сетевой злоумышленник может изменить информацию ConEx, чтобы обмануть
   функция аудита в нисходящей сети для отбрасывания пакетов. Если
   конечные точки используют заголовок аутентификации IPsec (AH)
   [RFC2460] для обнаружения изменения заголовков IP на пути, AH будет
   также обнаруживать изменение заголовка CDO.  Тем не менее, защита AH
   редко будет нуждаться в внедрении для ConEx, потому что атаки по одному
   сеть на другую редки, если они прослеживаемы. Другие известные
   атаки из одной сети на другую, такие как атаки с истечением TTL,
   больше вреда для невиновной сети (поскольку аудит ConEx
   сбрасывает молча) и менее отслеживаемыми (поскольку TTL предназначен для
   измениться, а CDO - нет).
   Раздел 4 указывает, что CDO помещается в вариант назначения.
   перед заголовками AH и/или ESP, чтобы информация ConEx
   остается открытым, если ESP используется для шифрования других
   передаваемая информация в транспортном режиме [RFC4301]. В общем,
   Заголовок Destination Option внутри пакета IPv6 может быть размещен в двух
   возможные позиции, либо перед заголовком Routing, либо после
   Заголовки ESP/AH, как описано в разделе 4.1 [RFC2460]. Если CDO
   был помещен в последнюю позицию, и заголовок ESP использовался с
   шифрование, промежуточные узлы, поддерживающие ConEx, не смогут просматривать
   и интерпретировать CDO, фактически делая его бесполезным. 
   Архитектура протокола IPv6 в настоящее время не обеспечивает механизма
   чтобы новые заголовки копировались во внешний заголовок IP. Следовательно, если
   Шифрование IPsec используется в туннельном режиме, информация ConEx не может быть
   доступ на протяжении туннеля ESP.
   Стек IP-адресов назначения обычно не обрабатывает CDO; поэтому,
   отправитель может отправить CDO, не проверяя, будет ли получатель
   понимать это. CDO ДОЛЖЕН быть перенаправлен на IP-адрес назначения.
   стек, потому что пункт назначения может проверить целостность всего
   пакет, независимо от того, понимает ли он ConEx.
8. Смягчение атак флуда с помощью предпочтительного сброса
   Идеи в этом разделе носят желательный характер и не являются необходимыми для
   использование ConEx для более общего управления дорожным движением. Однако однажды
   Присутствует информация CDO, заголовок CDO также может быть опционально
   используется в плоскости данных любого узла пересылки, поддерживающего IP, для смягчения
   наводнения атаки. 
   Обратите внимание, что ConEx является экспериментальным протоколом и что любой
   механизма, который реагирует на информацию, предоставленную ConEx
   Протокол также должен быть оценен в экспериментах. Это
   также верно или особенно верно для механизма предпочтительного сброса
   описано ниже.
   Предпочтительно отбрасывать пакеты, которые не поддерживают ConEx или не
   иметь метку ConEx может быть полезно для смягчения атак наводнения, поскольку
   Можно предположить, что пакеты с маркировкой ConEx уже ограничены
   Ограничитель входа ConEx, как описано в [RFC7713]. Поэтому,
   предлагается следующая схема предпочтительного отбрасывания на основе ConEx:
   Если очередь маршрутизатора испытывает очень высокую нагрузку, поэтому она должна
   прибывающих пакетов, он МОЖЕТ предпочтительно отбрасывать пакеты в пределах одного и того же
   DiffServ Per-Hop Behavior (PHB) с использованием порядка предпочтения, указанного в
   Таблица 1 (1 означает падение первым). Кроме того, если маршрутизатор реализует
   предпочтительное удаление на основе ConEx, оно ДОЛЖНО также поддерживать маркировку ECN. 
   Несмотря на то, что предпочтительное отбрасывание может быть трудно реализовать на
   некоторое оборудование, если нигде больше, маршрутизаторы на выходе из сети
   СЛЕДУЕТ реализовать льготный сброс на основе маркировки ConEx (сильнее
   чем МАЙ выше).
                 +------------------------------------+--+
                 | | предпочтение |
                 +---------------------------------------------------+--+
                 | Not-ConEx или отсутствие CDO | 1 (бросьте первым) |
                 | X (но не L, E или C) | 2 |
                 | X и L, E или C | 3 |
                 +---------------------------------------------------+--+
                Таблица 1: Предпочтение отбрасывания пакетов ConEx
   Атака переполнения по своей сути связана с перегрузкой ресурса. Как
   нагрузка сосредотачивается на жертве, очереди вверх по течению растут, требуя честных
   источники для предварительной загрузки пакетов с более высокой долей отметок ConEx.
   Если маркировка ECN поддерживается нижестоящими очередями, предпочтительно
   отбрасывание обеспечивает наибольшие преимущества, потому что, если очередь такая
   перегружен, что он пропускает трафик, он будет иметь маркировку CE 100% любого
   перенаправленный трафик.  Поэтому честные источники будут отправлять 100%
   Пакеты с маркировкой ConEx E (и подлежат ограничению скорости на входе).
   полицейский).
   Отправители, находящиеся под злонамеренным контролем, могут делать то же самое, что и честные
   источники и быть ограниченными по скорости при входе, или они могут занижать
   перегрузки и не установить бит E.
   Если для очередей реализован предпочтительный ранжирование отбрасывания, эти
   очереди будут резервировать трафик с пометкой E/L до последнего. Итак, трафик
   из вредоносных источников будут автоматически удалены в первую очередь.
   В любом случае, вредоносные источники не могут отправлять больше, чем честные источники.
   Следовательно, предпочтительное отбрасывание на основе ConEx, как описано выше.
   дискриминирует атакующий трафик, если это делается как часть общего
   структура контроля, как описано в [RFC7713].
9. Вопросы безопасности
   [RFC7713] описывает общую структуру аудита для обеспечения того, чтобы
   Маркировка ConEx действительно отражает фактическую загруженность пути и [CONEX-AUDIT]
   содержит дополнительные сведения об обработке сигналов аудита.  Этот
   раздел посвящен исключительно безопасности кодировки, выбранной для
   Маркировка ConEx.
   Тип опции CDO определяется битом chg, установленным в ноль, как
   описано в Разделе 4. Если используется IPsec AH, нулевой бит chg вызывает
   AH, чтобы покрыть вариант CDO, чтобы его сквозная целостность могла быть
   проверено, как описано в разделе 4.
   В этом документе указывается, что поле Reserved в CDO должно быть
   игнорируется и пересылается без изменений, даже если он не содержит всех
   нули. Поле «Зарезервировано» также необходимо, чтобы находиться за пределами
   Инкапсуляция полезной нагрузки безопасности (ESP), по крайней мере, в транспортном режиме (см.
   Раздел 7). Это позволяет отправителю использовать зарезервированное поле в качестве
   Скрытый канал с пропускной способностью 4 бита на пакет для отправки информации по пути
   узел вне контроля IPsec. Однако только скрытый канал
   беспокойство, если он может обойти IPsec в туннельном режиме и, в
   В случае туннельного режима ESP закроет скрытый канал, как описано в
   Раздел 7. 
10. Соображения IANA
   Вариант назначения ConEx IPv6 используется для передачи ConEx.
   маркировка. В этом документе используется экспериментальный тип опции 0x1E (как
   назначено в «Опциях назначения и промежуточных пунктах» IANA
   реестра) с битами действия, установленными на 00, и битом chg, установленным на 0 для
   реализации этого варианта. Никаких дополнительных действий по распределению не требуется
   IANA в настоящее время.
11. Ссылки
11.1. Нормативные ссылки
   [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания
              Уровни требований», BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, март 1997 г.,
              .
   [RFC2460] Диринг, С. и Р. Хинден, "Протокол Интернета, версия 6
              (IPv6) Спецификация", RFC 2460, DOI 10.17487/RFC2460,
              Декабрь 1998 г., .
   [RFC3168] Рамакришнан К., Флойд С. и Д. Блэк, «Дополнение
              явного уведомления о перегрузке (ECN) для IP»,
              RFC 3168, DOI 10. 17487/RFC3168, сентябрь 2001 г.,
              .
   [RFC4301] Кент С. и К. Сео, "Архитектура безопасности для
              Интернет-протокол», RFC 4301, DOI 10.17487/RFC4301,
              Декабрь 2005 г., .
   [RFC4302] Кент, С., «Заголовок IP-аутентификации», RFC 4302,
              DOI 10.17487/RFC4302, декабрь 2005 г.,
              .
   [RFC4303] Кент, С., "IP-инкапсуляция полезной нагрузки безопасности (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, декабрь 2005 г.,
              .
   [RFC7713] Матис, М. и Б. Бриско, «Воздействие перегрузки (ConEx)
              Концепции, абстрактный механизм и требования», RFC 7713,
              DOI 10.17487/RFC7713, декабрь 2015 г.,
              .
11.2. Информативные ссылки
   [КОНЭКС-АУДИТ]
              Вагнер, Д. и М. Кюлевинд, «Аудит перегрузок». 
              Сигналы экспозиции (ConEx)», «Выполняется работа»,
              draft-wagner-conex-audit-02, апрель 2016 г.
   [HBH-ЗАГОЛОВОК]
              Бейкер, Ф., «Заголовок расширения параметров IPv6 Hop-by-Hop»,
              Работа в процессе, draft-ietf-6man-hbh-header-handling-03,
              Марси 2016.
   [RFC7786] Kuehlewind, M., Ed. и Р. Шеффенеггер, "TCP
              Модификации воздействия перегрузки (ConEx)", RFC 7786,
              DOI 10.17487/RFC7786, май 2016 г.,
              .
Благодарности
   Авторы благодарят Дэвида Вагнера, Марсело Баньюло,
   Ингемар Йоханссон, Джоэл Халперн, Джон Лесли, Мартин Штимерлинг,
   Роберт Спаркс, Рон Боника, Брайан Хаберман, Кэтлин Мориарти, Боб
   Хиндену, Оле Троану и Брайану Карпентеру за обсуждения, которые сделали
   этот документ лучше.
Адреса авторов
   Суреш Кришнан
   Эрикссон
   8400 бульвар Декари
   Город Маунт-Рояль, Квебек
   Канада
   Электронная почта: Suresh.krishnan@ericsson. com
   Мирья Кюлевинд
   Высшая техническая школа Цюриха
   Электронная почта: [email protected]
   Боб Бриско
   Исследовательская лаборатория Simula
   Электронная почта: [email protected]
   URI: http://bobbriscoe.net/
   Карлос Ралли Усендо
   Телефоника
   Электронная почта: [email protected]

Предыдущий: RFC 7836 — Руководство по криптографическим алгоритмам, сопровождающим использование стандартов ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012

  

Далее: RFC 7838 — альтернативные службы HTTP

 

[Указатель RFC | Часто задаваемые вопросы о Usenet | Веб-Часто задаваемые вопросы | Документы | Города | Инспекции ресторана ]


небо | МОРКОВЬ КВИНН

/ carrot quinn / 7 комментариев

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

/ carrot quinn / 6 комментариев

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

/ carrot quinn / 2 комментария

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

/ морковный куинн / 13 комментариев

Здравствуйте! Возможно, вы читали ранний набросок этой истории о прошлогоднем поджоге Дакабуша по ссылке на сайте, посвященном туризму. Этот ранний черновик был опубликован без моего разрешения и фактически нарушает мое издательское соглашение с Amazon и может доставить мне массу неприятностей. Если ты тот самый… Продолжить чтение Заколдованная долина и вещи, которые не случаются

/ carrot quinn / 6 Комментарии

Весь день шел проливной дождь — сегодня утром мы отвели собак в парк Келли-Пойнт, место суперфонда, где металлическая Колумбия встречается с заполненным сточными водами Уилламетт, и как только мы вышли из машины, на нас начали сыпаться большие холодные капли. Мы шли по тропинке через лес, бросая мячик Эми перед тем, как… Проливные дожди и спорное королевство Протиста

/ carrot quinn / 2 комментария

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

/ carrot quinn / 4 комментариев

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

/ carrot quinn / 6 комментариев

Это был март, и мы с Симусом только начали встречаться. Дождевые тучи, все еще черно-серые, сбрасывавшие вниз потоки воды, теперь, через мгновенье, разбивались пятнами великолепного густого желтого света — парного северо-западного солнца, выходящего обнаженным из своей длинной, интроспективной сауны. Шеймус и я решили поехать в Олимпию для … Продолжить чтение Короткая чудесная жизнь Сонни Риккобоно

/ carrot quinn / 3 комментария

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

/ carrot quinn / 3 комментария

В последнее время мои сны были такими великолепными. Представьте себе: это конец света. Низменности заполнены чистой водой. Вся твоя одежда красного цвета. Тепло, и кто-то идет за тобой. Вы должны плавать. Вы должны спрятаться. Вы должны пересечь узкие эстакады, которые блестят в лунном свете. … Продолжить чтение вода, сны, кексы, океанское дно

Адрес электронной почты:

Присоединяйтесь к 7071 другим подписчикам

facebook.com/carrotquinnhikes/»> вы также можете найти меня на моей общедоступной странице в Facebook
  • Поход со мной в Нью-Мексико в мае! 2 марта 2023 г.
  • Совершите поход со мной в хребте Брукс на Аляске в августе 2023 года! 26 января 2023 г.
  • Знаете ли вы, что у меня есть информационный бюллетень 20 января 2023 г.
  • Походы в пустыню и писательский ретрит 2023 года! 20 октября 2022 г.
  • Зины в продаже! 16 февраля 2022 г.
Искать: архив Выберите месяц Март 2023 (1) Январь 2023 (2) Октябрь 2022 (1) Февраль 2022 (1) Декабрь 2021 (14) Ноябрь 2021 (17) Октябрь 2021 (13) Июль 2021 (2) Октябрь 2020 (3) Апрель 2020 ( 1) март 2020 г. (1) январь 2020 г. (1) декабрь 2019 г. (9) ноябрь 2019 г. (5) октябрь 2019 г. (1) август 2019 г. (1) июнь 2019 г. (2) май 2019 г. (21) апрель 2019 г. (16) январь 2019 г.(1) октябрь 2018 г. (2) сентябрь 2018 г. (2) август 2018 г. (10) июль 2018 г. (8) июнь 2018 г. (9) май 2018 г. (3) апрель 2018 г. (3) март 2018 г. (1) февраль 2018 г. (1) январь 2018 г. (1) декабрь 2017 г. (8) сентябрь 2017 г. (9) август 2017 г. (2) июль 2017 г. (5) май 2017 г. (2) апрель 2017 г. (1) март 2017 г. (1) февраль 2017 г. (1) ноябрь 2016 г. (1) октябрь 2016 г. (1) август 2016 г. (2) июль 2016 г. (2) июнь 2016 г. (3) май 2016 г. (22) апрель 2016 г. (28) март 2016 г. (11) январь 2016 г. (3) ноябрь 2015 г. (2) сентябрь 2015 г. (20) август 2015 г. (32) июль 2015 г. (29)) Июнь 2015 г. (23) Май 2015 г. (25) Апрель 2015 г. (4) Март 2015 г. (4) Февраль 2015 г. (4) Январь 2015 г. (4) Декабрь 2014 г. (9) Ноябрь 2014 г. (3) Октябрь 2014 г. (2) Сентябрь 2014 г. (4) ) август 2014 г. (25) июль 2014 г. (28) июнь 2014 г. (30) май 2014 г. (30) апрель 2014 г. (9) март 2014 г. (8) февраль 2014 г. (4) январь 2014 г. (9) декабрь 2013 г. (23) ноябрь 2013 г. (16) ) октябрь 2013 (34) сентябрь 2013 (5) август 2013 (12) июль 2013 (28) июнь 2013 (23) май 2013 (30) апрель 2013 (16) март 2013 (23) февраль 2013 (9)) Январь 2013 г. (6) Декабрь 2012 г.