Есть мнение, что XFP отличается от SFP+ в т.ч. наличием модуля CDR. SFP+ в "базовой" комплектации просто выполняет оптоэлектронное преобразование. Выделение синхропоследовательности находится уже на плате маршрутизатора/коммутатора. А XFP в базе идет с CDR. Поэтому XFP идет как основной модуль для регенераторов в DWDM, потому что умеет в 3R. Но тут нужны конечно специалисты по железной части
Нет, профили 8275.2 и 8275.1 дополняют друг друга и используются в разных ситуациях. У каждого есть плюсы и минусы. Невозможно на современных сетях прогнать все по 8275.1.
В схеме R1-R2-R3-БС прекрасно отработает 1 профиль.
Добавляем в схему свич/релейку/аренду без поддержки 1 профиля R1-R2-РРЛ-R3-аренда-БС - и праздник заканчивается. Между R2 и R3, а также R3 и БС 1 профиль никак не пролезет.
Чтобы решить эту проблему придумали 2 профиль. Ничего не мешает на R2 по Eth пригнать 1 профиль, а на выходные порты выдать 2 профиль по IP, которому до промежуточной трансмиссии дела нет. На Boundary Clock источник и получатель синхронизации между собой не связаны никакими протоколами и условностями (ну кроме того, что если порт в режиме Slave/Master, то он может работать только на одном профиле). И тогда схема будет.
Дополнить 2 профиль QoS'ом, правильным шейпером и он пролезет практически везде (ну кроме аренды) с приемлемым качеством.
Если говорить о том, что было описано в статье, то реализована схема условно
R1---G.8275.2 ATR---БС
Т.е. мы всю сеть представили в виде аренды и вперед считать джиттер.
Фактически G.8275.2 может работать точно также, как G.8275.1, передавая фазу между двумя соседними железками. А может в режиме ATR (adaptive time recovery) - это когда по дороге есть хоть одна железка, которая не поддерживает PTPv2. По сути 1 и 2 профиль это просто транспортный заголовок для PTPv2. Железка анализирует содержимое PTPv2, а не Eth- или IP.
Плюсом 1 профиля, например, можно назвать возможность корректно работать в лагах, чтобы избегать разности в задержках на линках разной длины.
Все что вам рассказывали - правда. Так в стандарте написано. Но рассказали не все. Вот про режим ATR вам не рассказали, а он как раз чтобы пригнать фазу, если из подручных материалов есть только мох и шишки) В т.ч. через MPLS. Статья собственно о том, как прогнать фазу через MPLS и почему это может заработать. Или не заработать.
Ну а касаемо заработало или нет - заработало. Базы лочатся, абоненты интернет качают и далее по списку. Другое дело, что это все не от хорошей жизни. В хорошей будет 8275.1 в связке с ATR
Да, была такая мысль учесть сериализацию при расчете буферизации. Например, средний размер пакета на порту 1200Б. Если пакет уже начал передаваться, то мы попадаем в легкую неизвестность, сколько байт уже передалось и как долго еще ждать. Одно дело, если осталось передать 8Б, другое если 1100Б. Наверное, для такого случая можно взять среднее по больнице 600Б. Посчитать время сериализации 600Б пакета для 10Г линка, это 0,48мск. И подумать с какой вероятностью этот пакет вообще возникнет. Самым примитивным образом я бы сделал это так. Допустим на линке трафика 6Г, значит вероятность, что на порту что-то уже передается 60%. И вот дальше не знаю насколько законно будет время сериализации 0,48мкс умножить 0,6 (на вероятность того, что это событие вообще произойдет). Получим 0,288мкс. Соответственно, чем ниже загрузка линка, тем меньше вероятность того, что мы попадем в очередь из-за того, что порт кем-то занят и тем меньше нужно вносить поправку.
Есть мнение, что XFP отличается от SFP+ в т.ч. наличием модуля CDR. SFP+ в "базовой" комплектации просто выполняет оптоэлектронное преобразование. Выделение синхропоследовательности находится уже на плате маршрутизатора/коммутатора. А XFP в базе идет с CDR. Поэтому XFP идет как основной модуль для регенераторов в DWDM, потому что умеет в 3R. Но тут нужны конечно специалисты по железной части
Статья шикардная, читать одно удовольствие)
а можно в паре слов узнать про особенности передачи SyncE и OTN с т.з. модулей? Информация в интернете на эту тему у меня не ищется
Великолепный материал!
Классная статья. Очень похоже на Opt. A,B,C в mpls. Да собственно это он и есть, только адаптированное для VXLAN
Отличная статья написанная живым языком, а не вот это вот академическое перепечатывание RFC)
Нет, профили 8275.2 и 8275.1 дополняют друг друга и используются в разных ситуациях. У каждого есть плюсы и минусы. Невозможно на современных сетях прогнать все по 8275.1.
В схеме R1-R2-R3-БС прекрасно отработает 1 профиль.
Добавляем в схему свич/релейку/аренду без поддержки 1 профиля R1-R2-РРЛ-R3-аренда-БС - и праздник заканчивается. Между R2 и R3, а также R3 и БС 1 профиль никак не пролезет.
Чтобы решить эту проблему придумали 2 профиль. Ничего не мешает на R2 по Eth пригнать 1 профиль, а на выходные порты выдать 2 профиль по IP, которому до промежуточной трансмиссии дела нет. На Boundary Clock источник и получатель синхронизации между собой не связаны никакими протоколами и условностями (ну кроме того, что если порт в режиме Slave/Master, то он может работать только на одном профиле). И тогда схема будет.
R1---G.8275.1---R2---G.8275.2---R3---G.8275.2---БС
Дополнить 2 профиль QoS'ом, правильным шейпером и он пролезет практически везде (ну кроме аренды) с приемлемым качеством.
Если говорить о том, что было описано в статье, то реализована схема условно
R1---G.8275.2 ATR---БС
Т.е. мы всю сеть представили в виде аренды и вперед считать джиттер.
Фактически G.8275.2 может работать точно также, как G.8275.1, передавая фазу между двумя соседними железками. А может в режиме ATR (adaptive time recovery) - это когда по дороге есть хоть одна железка, которая не поддерживает PTPv2. По сути 1 и 2 профиль это просто транспортный заголовок для PTPv2. Железка анализирует содержимое PTPv2, а не Eth- или IP.
Плюсом 1 профиля, например, можно назвать возможность корректно работать в лагах, чтобы избегать разности в задержках на линках разной длины.
Все что вам рассказывали - правда. Так в стандарте написано. Но рассказали не все. Вот про режим ATR вам не рассказали, а он как раз чтобы пригнать фазу, если из подручных материалов есть только мох и шишки) В т.ч. через MPLS. Статья собственно о том, как прогнать фазу через MPLS и почему это может заработать. Или не заработать.
Ну а касаемо заработало или нет - заработало. Базы лочатся, абоненты интернет качают и далее по списку. Другое дело, что это все не от хорошей жизни. В хорошей будет 8275.1 в связке с ATR
Да, была такая мысль учесть сериализацию при расчете буферизации. Например, средний размер пакета на порту 1200Б. Если пакет уже начал передаваться, то мы попадаем в легкую неизвестность, сколько байт уже передалось и как долго еще ждать. Одно дело, если осталось передать 8Б, другое если 1100Б. Наверное, для такого случая можно взять среднее по больнице 600Б. Посчитать время сериализации 600Б пакета для 10Г линка, это 0,48мск. И подумать с какой вероятностью этот пакет вообще возникнет. Самым примитивным образом я бы сделал это так. Допустим на линке трафика 6Г, значит вероятность, что на порту что-то уже передается 60%. И вот дальше не знаю насколько законно будет время сериализации 0,48мкс умножить 0,6 (на вероятность того, что это событие вообще произойдет). Получим 0,288мкс. Соответственно, чем ниже загрузка линка, тем меньше вероятность того, что мы попадем в очередь из-за того, что порт кем-то занят и тем меньше нужно вносить поправку.
Т.е. опять же, широкий линк лучше узкого)