mcast
"When you see a bunch of engineers standing around congratulating themselves for solving some particularly ugly problem in networking, go up to them, whisper "multicast", jump back, and watch the fun begin..."
-- draft-irtf-routing-reqs-groupa
В принципе, мультикаст у нас как бы есть. Но предела совершенству не существует, и попытки улучшить жизнь не прекращаются, благо есть куда. В частности, многие хотят скрестить мультикаст с MPLS. Собственно, от такого сожительства хочется получить три вещи:
1) Изоляция. L3 VPN, но с мультикастом.
2) Защита. Не в смысле security, а в смысле protection. Т.е. чтобы, ежели что поломается в сети, у нас все быстренько восстановилось.
3) Масштабируемость. Нынешний подход к мультикасту (с PIM в разных вариантах и позах), он создает в ядре сети состояния, которые в принципе могут довольно часто меняться. А у core router'ов control plane не резиновый: они умеют кидать трафик быстро и далеко, а вот задрачивать их всякой сигнализацией - этого надо избегать, ну, или хотя бы стараться.
Подходов тут масса, драфтов понаписана туева хуча. Я, признаться, прочел далеко не все - уж слишком их много. Есть draft-rosen-vpn-mcast, который решает только проблему 1. Есть набор драфтов про multipoint LSP, которые должны вылечить все и всех (судя по всему, это и есть наше светлое, но отдаленное будущее). Есть попытки мультикастить через VPLS, для чего этот бедный VPLS обставляется неприличным количеством костылей и подпорок, с драфтом на каждую из них, разумеется. Ну и куча гибридных вариантов, которые я не могу даже перечислить, не говоря уж о том, чтобы изложить идеи.
Сегодня за ужином я подумал о том, как бы схалявить и решить проблему 2 хотя бы частично, но без сильных изменений.
Сейчас сходимость мультикаста напрямую зависит от сходимости IGP. Собственно, для того, чтобы приблизить сходимость мультикаста к сходимости IGP сделаны две вещи: 1) пересчитывать RPF [почти] сразу, как сойдется IGP; 2) дать рукоятку для выкручивания query interval, чтоб designated router переизбрался побыстрее. "Почти" - это потому что по есть такой таймерок (по крайней мере есть у циски), называется rpf backoff, нужен он "чтобы два раза не бегать", действует он так: произошли изменения в IGP, запускаем таймер, и если все тихо, пересчитываем RPF, если опять какая-то фигня, то запускаем удвоенный и так до некоторого верхнего предела. Равен этот таймер 500мсек по умолчанию, рукоятка для его выкручивания есть. Если учесть, что на сегодняшний день OSPF или IS-IS реально затюнить до сходимости в ~300мсек, то получить сходимость мультикаста в пределах секунды тоже можно. В принципе, это уже неплохо, но хочется лучше. Скажем, в IPTV картинка от этого сильно портится.
Что можно было бы сделать?
Есть такой подход к развертыванию MPLS TE FRR. Называется он one-hop. Применяют его в тех случаях, когда нужен только link protection, а node protection - нет. Между соседними роутерами строится TE тоннель по unconstrained path, который, естественно, лежит через линк их соединяющий. Также строятся nhop bypass'ы, которые защищают эти линки. При этом, благодаря penultimate hop popping, пакеты в штатной ситуации идут без лишних меток. Деплоится это легко, число тоннелей не велико - по два на каждый линк. А выгода получается довольно существенная.
Примерно то же самое можно было бы вытворить и с мультикастом. Оставляем всякую PIM-сигнализацию как есть: все эти RP, все эти (*, G) и (S, G), и всю прочую ботву. В штатной ситуации, когда защита не активна, форвардинг тоже остается без изменений. А когда произошло страшное, берем пакет, вешаем на него юникастную метку нашего bypass'а и отправляем по запасному пути. Вот тут возникает засада. Поскольку пакет приехал по обходному пути, у нас обломается RPF check. Что делать? Надо как-то понимать, что пакет свалился по обходному пути не просто так, а посредством bypass'а. Для этого достаточно, чтобы он приходил с меткой, т.е. надо 1) чтобы в нашем bypass'е не работал PHP; 2) чтобы по этой метке можно было понять, с какого интерфейса пакет должен был бы придти при неактивной защите, для этого надо эту метку аллоцировать не из platform label space, а из interface label space. После того, как пакет с меткой пришел к на nhop router и прошел RPF check, меточку снимаем и делаем L3 forwarding как обычно. В принципе, на платформах типа 7600 это означает рециркуляцию, ну да и фиг с ней. Думается, что добавить в RSVP опцию, которая попросила бы у tail end'а описанное назначение меток, не сложно, благо RSVP протокол хорошо расширяемый.
Разумеется, это все касается только link protection. При падении узлов сходимость будет IGP'шная.
Есть вариант как сделать похожую вещь прямо сейчас без изменений софта и протоколов, но он мне не нравится. Можно сделать one hop GRE тоннели и запустить PIM в них, а сами эти GRE тоннели защитить обычным FRR. Не нравится мне тут много чего: оверхед, необходимость бороться с RPF в этих тоннелях (если мы хотим, чтобы юникаст у нас шел как обычно, а мультикаст через GRE, то тут будут проблемы). В общем, это будет жуткий гемор как в развертывании, так и в эксплуатации. Зато защита. Пожалуй, на неделе я это отыграю в лабе, но думаю, что после отыгрывания вариант с GRE мне понравится еще меньше, чем сейчас.
-- draft-irtf-routing-reqs-groupa
В принципе, мультикаст у нас как бы есть. Но предела совершенству не существует, и попытки улучшить жизнь не прекращаются, благо есть куда. В частности, многие хотят скрестить мультикаст с MPLS. Собственно, от такого сожительства хочется получить три вещи:
1) Изоляция. L3 VPN, но с мультикастом.
2) Защита. Не в смысле security, а в смысле protection. Т.е. чтобы, ежели что поломается в сети, у нас все быстренько восстановилось.
3) Масштабируемость. Нынешний подход к мультикасту (с PIM в разных вариантах и позах), он создает в ядре сети состояния, которые в принципе могут довольно часто меняться. А у core router'ов control plane не резиновый: они умеют кидать трафик быстро и далеко, а вот задрачивать их всякой сигнализацией - этого надо избегать, ну, или хотя бы стараться.
Подходов тут масса, драфтов понаписана туева хуча. Я, признаться, прочел далеко не все - уж слишком их много. Есть draft-rosen-vpn-mcast, который решает только проблему 1. Есть набор драфтов про multipoint LSP, которые должны вылечить все и всех (судя по всему, это и есть наше светлое, но отдаленное будущее). Есть попытки мультикастить через VPLS, для чего этот бедный VPLS обставляется неприличным количеством костылей и подпорок, с драфтом на каждую из них, разумеется. Ну и куча гибридных вариантов, которые я не могу даже перечислить, не говоря уж о том, чтобы изложить идеи.
Сегодня за ужином я подумал о том, как бы схалявить и решить проблему 2 хотя бы частично, но без сильных изменений.
Сейчас сходимость мультикаста напрямую зависит от сходимости IGP. Собственно, для того, чтобы приблизить сходимость мультикаста к сходимости IGP сделаны две вещи: 1) пересчитывать RPF [почти] сразу, как сойдется IGP; 2) дать рукоятку для выкручивания query interval, чтоб designated router переизбрался побыстрее. "Почти" - это потому что по есть такой таймерок (по крайней мере есть у циски), называется rpf backoff, нужен он "чтобы два раза не бегать", действует он так: произошли изменения в IGP, запускаем таймер, и если все тихо, пересчитываем RPF, если опять какая-то фигня, то запускаем удвоенный и так до некоторого верхнего предела. Равен этот таймер 500мсек по умолчанию, рукоятка для его выкручивания есть. Если учесть, что на сегодняшний день OSPF или IS-IS реально затюнить до сходимости в ~300мсек, то получить сходимость мультикаста в пределах секунды тоже можно. В принципе, это уже неплохо, но хочется лучше. Скажем, в IPTV картинка от этого сильно портится.
Что можно было бы сделать?
Есть такой подход к развертыванию MPLS TE FRR. Называется он one-hop. Применяют его в тех случаях, когда нужен только link protection, а node protection - нет. Между соседними роутерами строится TE тоннель по unconstrained path, который, естественно, лежит через линк их соединяющий. Также строятся nhop bypass'ы, которые защищают эти линки. При этом, благодаря penultimate hop popping, пакеты в штатной ситуации идут без лишних меток. Деплоится это легко, число тоннелей не велико - по два на каждый линк. А выгода получается довольно существенная.
Примерно то же самое можно было бы вытворить и с мультикастом. Оставляем всякую PIM-сигнализацию как есть: все эти RP, все эти (*, G) и (S, G), и всю прочую ботву. В штатной ситуации, когда защита не активна, форвардинг тоже остается без изменений. А когда произошло страшное, берем пакет, вешаем на него юникастную метку нашего bypass'а и отправляем по запасному пути. Вот тут возникает засада. Поскольку пакет приехал по обходному пути, у нас обломается RPF check. Что делать? Надо как-то понимать, что пакет свалился по обходному пути не просто так, а посредством bypass'а. Для этого достаточно, чтобы он приходил с меткой, т.е. надо 1) чтобы в нашем bypass'е не работал PHP; 2) чтобы по этой метке можно было понять, с какого интерфейса пакет должен был бы придти при неактивной защите, для этого надо эту метку аллоцировать не из platform label space, а из interface label space. После того, как пакет с меткой пришел к на nhop router и прошел RPF check, меточку снимаем и делаем L3 forwarding как обычно. В принципе, на платформах типа 7600 это означает рециркуляцию, ну да и фиг с ней. Думается, что добавить в RSVP опцию, которая попросила бы у tail end'а описанное назначение меток, не сложно, благо RSVP протокол хорошо расширяемый.
Разумеется, это все касается только link protection. При падении узлов сходимость будет IGP'шная.
Есть вариант как сделать похожую вещь прямо сейчас без изменений софта и протоколов, но он мне не нравится. Можно сделать one hop GRE тоннели и запустить PIM в них, а сами эти GRE тоннели защитить обычным FRR. Не нравится мне тут много чего: оверхед, необходимость бороться с RPF в этих тоннелях (если мы хотим, чтобы юникаст у нас шел как обычно, а мультикаст через GRE, то тут будут проблемы). В общем, это будет жуткий гемор как в развертывании, так и в эксплуатации. Зато защита. Пожалуй, на неделе я это отыграю в лабе, но думаю, что после отыгрывания вариант с GRE мне понравится еще меньше, чем сейчас.