На выходных, помимо всего прочего нужного/важного/полезного почитал про очередную попытку нортела прорваться на рынок магистральных технологий. На этот раз это называется PBT - Provider Backbone Transport.

В чем идея? Идея - оторовать у ethernet'а все, что можно оторвать и приделать кое-что другое. А именно:
1) Оторвать learining (туда и дорога)
2) Оторвать unknown unicast flooding, broadcast и multicast (we won't miss you)
3) Оторвать *STP (вздохи облегчения)
4) Использовать 802.1ah, который MAC-in-MAC

А приделать заместо этого явное программирование форвардинговых таблиц на свитчах централизованной системой управления. Таким образом они собираются строить трафик-инжиниринговые пути точка-точка в бриджованной сети. Называются эти пути ESP - Ethernet Switched Path.

Ничего не напоминает? Правильно! Это ж T-MPLS. Только вместо MPLS-метки - пара (B-VID, B-DA). Ну, почти T-MPLS: эта "метка" не меняется на протяжении всего ESP, что позволяет использовать самый обычный ethernet'ный forwarding plane.

Кому и зачем нужен T-MPLS я понимаю.

Он нужен старым carrier'ам, которые не умеют, не понимают и не хотят понимать сигналинг, но хотят иметь пакетный транспорт. Они боятся всех этих OSPF, LDP, RSPV, BGP и прочей фигни, которую напридумывали разгильдяи из IETF (действительно, что хорошего могут придумать люди, которые не заседают годами в комитетах и пишут спецификации понятным английским языком?!).

Эти carrier'ы хотят управлять своей пакетной сетью точно так же, как они управляли своей SDH сетью - через централизованную систему управления, которая придет на каждый узел и отпрограммирует его как надо. Они хотят иметь простые, понятные двунаправленные VC, которые идут только по одному пути безо всякого equal cost multipath. Но только пакетные, а не TDM'ные. Они хотят чтобы это все было одобрено Священными Рекомендациями Великого ИтуТи, Который Ажно Часть Самого ООН.

У этих carrier'ов вложены огромные деньги в эти системы управления, обучены люди, отработаны процедуры. Они не хотят с этим всем расставаться. И я их прекрасно понимаю.

Что сделал Священный ИтуТи? Взял MPLS, оторвал от него control plane, оторвал несколько фич на forwarding plane, Одобрил Рекомендацию и сказал: "нате, дорогие carrier'ы, пользуйтесь". По пути, правда, потерялись некоторые полезности, которые есть в обычном MPLS, но это никого в данном контексте не расстраивает. Получилось нечто, что вполне может встроиться в legacy инфраструктуру операторов как в части управления, так и в части имеющихся каналов, благо это честный layer 2.5, которому пофигу, что под ним: ethernet, SDH с GFP или что еще другое.

Кому нужен PBT? Не понимаю. Если T-MPLS - это компромиссная технология, предназначенная для вписывания в имеющуюся инфраструктуру, то PBT явно предназначен для свежих rollout'ов.

Нет, я понимаю конечно, что ежели есть нужда, то можно ethernet'ный транк можно обернуть в тот же GFP, положить в SDH'ную VC, на том конце выдернуть и подать в свитч. Но это как-то жирно получается.

Иными словами, не ясно позиционирование.

Тем операторам, на которых нацелен T-MPLS, этот PBT не нужен, благо T-MPLS им подходит лучше.

Новым, растущим из IP-шного мира, для которых IETF'ная архитектура родная, им этот PBT вообще нафиг не сдался, ибо управлять им надо совсем не как всем остальным, что у них есть. Этим операторам обычный, честный, некастрированный MPLS - родной.

Сторонники PBT утверждают, что самая главная фишка - в простоте и дешевизне. Мол, используются самые обычные ethernet свитчи, которые нынче дешевле грязи, а у MPLS'ников - уууу, дорогущие роутеры.

На самом деле, сам по себе форвардинг стоит примерно одинаково: что ethernet switching, что label switching - сложность ASIC'а примерно та же самая. Да, label switching предполагает переписывание метки и TTL, а ethernet switching оставляет все как есть. Но влияет это не сильно.

Сложность же, а следовательно и стоимость, находится в control plane. И сложность эта никуда не делась, а только переместилась. Control plane'а нет, зато есть жутко умный management plane.

Все. На сегодня хватит. Спать пойду. Завтра, если не заленюсь, напишу, что будет, если строить сеть чисто на PBT. А именно, про восстановление, масштабируемость и реализацию сервисов.

Начало здесь.

Я, конечно, маханул вчера, когда сказал, что ASIC, делающий MPLS forwarding, так же прост, как ASIC, делающий ethernet forwarding.

MPLS'ный LSR (label switching router) умеет делать три операции:
* label push - добавить одну или несколько меток к пакету, который уже имеет какие-то метки или нет;
* label swap - заменить верхнюю метку стека на другую
* label pop - убрать метку или несколько сверху стека.
Ну и после этого уменьшить TTL и перекинуть пакет в нужный интерфейс.

Ethernet'ный switch, особенно в рамках архитектуры PBT, туп необычайно. Он умеет только сделать lookup в своих таблицах и выплюнуть фрейм в нужный провод, ничего во фрейме не меняя. Lookup там 60-битный: VID (Vlan Id) - 12 бит, DA (Destination Address) - 48 бит.

На границах PBT домена должна происходить инкапсуляция и декапсуляция клиентского фрейма (или Q-in-Q фрейма - без разницы) в MAC-in-MAC фрейм, что добавляет требований к интеллекту граничных свитчей.

К слову, поскольку промежуточные свитчи в PBT-домене не добавляют и не убавляют заголовков, и декапсуляцию MAC-in-MAC выполняет именно конечный свитч, то этот свитч обязан посмотреть на фрейм дважды: когда он пришел в виде MAC-in-MAC виде, а потом еще раз на декапсулированный клиентский фрейм, чтобы понять в какой из клиентских портов его передавать. Это означает, что там должен быть реализован либо честный двойной lookup, либо двойной lookup через рециркуляцию. Что либо усложняет логику, либо бьет по производительности.

Но сказанное не меняет моего тезиса. MPLS форвардинг несколько сложнее, но основная сложность не в нем, а в control/maganement plane. И даже на forwarding plane принятие решения о выходящем интерфейсе - не самое трудное, тот же queueing, например, - штука тонкая и сложная, а реализовывать его придется все равно.

Часть III будет после обеда.

Начало здесь и здесь.

Итак, масштабируемость.

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

Поскольку PBT по своей природе основан на TE-туннелях точка-точка, то характеристики масштабируемости в отношении объема forwarding state у него должны быть такими же, как у MPLS TE.

А именно. Пусть у нас есть два [EL]SP к одному узлу D от узлов S1 и S2. На всем протяжении этих путей, даже если у них есть общий линк, у S1->D и S2->D будут разные метки, т.к. после этого общего линка эти два пути могут опять разойтись.

Нарисую картинку, чтобы проиллюстрировать:


Пути от узла 1 (желтенький) и узла 4 (зелененький) к узлу 7 имеют общий линк N5-N6. Может ли быть у них на этом линке общая метка? Нет. Если б метка была бы общая, узел 6 не смог бы их разделить и направить дальше по разными линкам. Можно ли сэкономить и слить два [EL]SP, если начиная с какого-то момента, пути идут по одним и тем же узлам и линками, как показано на рисунке?
.

В принципе, можно. Однако, если, например, [EL]SP может продолжиться за границу домена, то сливать нельзя, а при вычислении пути внутри домена в общем случае не известно, будет ли путь продолжен. Я предполагаю, что PBT будет предусматиривать interdomain TE, и, следовательно, слияния ESP не будет.

Таким образом, общее количество записей в форвардинговых таблицах свитчей PBT-домена будет пропорционально количеству путей в домене, которое, в свою очередь, есть O(N^2) для полносвязной сети из N узлов.

Чем это отличается от MPLS, если в MPLS TE то же самое? А тем, что MPLS не означает автоматически TE. Есть LDP, который по сути дела строит multipoint-to-point дерево с корнем в узле назначения. В этом случае, количество записей в форвардинговых таблицах LSR'ов пропорционально количеству узлов в первой степени, а не во второй. Ну, на самом деле не узлов, а IGP префиксов, но при правильном дизайне сети это одно и то же.

А как же защита? Ведь защита означает, что мы должны использовать RSVP-TE? Это так, да не совсем. См. следующую часть.

Начало здесь, здесь и здесь.

Восстановление

Материалы по PBT обещают восстановление за магические 50 миллисекунд. Как это у них реализуется?

Во-первых, у них есть только path protection. Это означает, что для каждого защищенного пути создается запасной, и при сбое head end туннеля переключает трафик на запасной путь.

Хорошо это или плохо? На мой взгляд, это очевидно хуже, чем локальное восстановление.

Path protection означает распухание forwarding state. В случае path protection количество путей удваивается. А в случае локального восстановления в стиле facility backup количество дополнительных тоннелей пропорционально количеству защищаемых линков между узлами.

Может ли PBT реализовать локальную защиту а-ля MPLS FRR? Нет.

Реализация защиты в стиле one-to-one (в терминологии RFC4090 - detours) основана на том, что MPLS метка меняется на каждом хопе, а в PBT пара (B-VID, B-DA) всегда остается неизменной.
Реализация защиты в стиле facility backup (в терминологии RFC4090 - bypasses) требует возможности на промежуточном узле, являющемся PLR (Point of Local Recovery) добавить дополнительную метку. В архитектуре PBT такая возможность не предусматривается.

Есть ли еще какие-то приемущества у MPLS в плане восстановления? Да. Гибкость. В PBT мы можем либо защить туннель, либо не защитить туннель.

Мы можем использовать разные способы развертывания защиты в MPLS сети:
* Например, one-hop туннели, которые я как-то упоминал в одном из своих постов.
*Во-вторых, мы можем (вернее, сможем в недалеком будущем, если наконец некоторые вендоры прекратят спать за штурвалом) использовать иерархические туннели, которые сильно помогут масштабируемости RSVP-TE.
* И в-третьих, совсем скоро мы сможем делать защиту вообще без RSVP-TE - это называется IPFRR. IPFRR пока только в разработке, но работы продвигаются с хорошей скоростью. а там, глядишь, и вендоры подтянутся со своими реализациями. Следите за драфтами и пинайте вендоров :)

А как в PBT обнаруживаются сбои? Раз между узлами нет никакой сигнализации, то единственный способ обнаруживать непроходимость трафика - это запустить какой-нибудь постоянный мониторинг end-to-end. PBT для этого использует Connectivity Fault Management (802.1ag_. Логично? Логично. Если есть механизм, то почему бы его не использовать?

Что это означает на практике? На практике это означает, что для каждого PBT-туннеля есть возвратный, который идет точно по тому же пути и несет возвратные CFM-фреймы. Как я понял из описания, этот туннель не рабочий, и полезный трафик по нему не идет. Что из этого следует? Правильно. Из этого следует, что мы еще раз удвоили forwarding state.

Что это означает еще? Это означает серьезную нагрузку на CPU как head end'а, так и tail end'а. Чтобы получить переключение в пределах 50мс, мы должны проверять прохождение трафика примерно каждые 10мс. Причем мониторить надо как первичный, так и защитного путь. В защищенной full mesh сети из, скажем, 1000 узлов, head end должен генерировать, а tail end принимать 200000 пакетов в секунду. Что совсем не мало.

Интересно, доберусь я сегодня до сервисов?

Начало здесь, здесь, здесь и здесь.

Кратенько про сервисы.

1) L2 VPN точка-точка

Тут все понятно.

2) L2 VPN многоточка, он же VPLS

Тут в принципе тоже все ясно. Те же туннели между PE свитчами, что в обычном VPLS, тот же лернинг на границе, тот же split horizon forwarding. Все то же самое. То же самое и в части мультикаста. А именно чудовищно неэффективная репликация на ingress node. Когда бродкастного/мультикастного трафика мало, то и фиг с ним. А от видео эта конструкция двинет кони.

Есть, конечно, выход. PBT может жить бок о бок с обычным *STP - некоторые VID используются для установки PBT-путей, а некоторые живут, как жили раньше, т.е. с STP. Можно взять один vlan, запустить в нем мультикаст, который будет фладиться человеческим образом, а на PE-свитче MVR'ом реплицировать его клиентам. Можно. Но это шаг назад. У нас опять возникает ненавистное дерево. Ясно, что это решение никак не тянет на Provider Backbone Transport.

Другого способа побороть проблему мультикаста в этой среде я не вижу. Фокус а-ля аткателевкий daisy chained VPLS здесь не пройдет. Никакого multipoint LSP, как в MPLS мире, здесь не предвидится. В общем, грустно.

3) L3 VPN

Вендоры, которые не умеют ничего умнее ethernet'а очень любят глубокомысленно говорить: "Over 95 percent of all data traffic originates and terminates on Ethernet ports." Они скромно молчат о том, что 99.99% of all data traffic travels the networks in IP packets. ;)

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

Что здесь предлагает PBT? А ничего.

Хочешь, бери обставляй свой PBT'шный "backbone" роутерами по кругу и запускай на них MPLS/BGP VPN. Хорошо? Абсолютно ничего хорошего.

Хочешь, стягивай клиентов L2 point-to-point туннелями к паре роутеров, которые и исполняют L3 VPN. Хорошо? Да тоже ничего приятного.

Хочешь, выстраивай полноценный MPLS домен, а PBT используй для агрегации. Уже теплее. Только это уже не backbone transport, а совсем даже aggregation. Если б оно еще управлялось по человечески - сигнализацией. ;)

4) Трипельплей и прочий новомодный IPTV

См. пункт 2 про мультикаст.

Все. Хватит. Надо закруглять.

Итак. Что такое этот PBT? По своей сути, это такой недо-MPLS. С неясным позиционированием, с недостатками в области масштабирования, в области восстановления, в области сервисов.

Единственный плюс этого PBT - это более низкая стоимость компонентов forwarding plane. Однако, если довести функциональность PBT'шного forwarding plane до той степени, что он сможет избавиться от своих недостатков, этот forwarding plane станет стоить ничуть не дешевле MPLS'ного, а думается, что и дороже.

Может быть, PBT найдет свое место в сети агрегации, подтягивая клиентов к сети. Однако, непонятно, что делать с мультикастом - уж больно не хочется назад к *STP. Однако IEEE с некоторых пор разрабатывает 802.1aq - shortest path bridging как замену *STP в ethernet сетях. Это, на мой взгляд, выглядит привлекательней для сети агрегации, чем PBT.