Daniel Ginsburg (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} dbg) wrote,@ 2007-01-08 18:56:00 |
|
Мутант-переросток, часть 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, и еще немного на эту тему будет в частях про восстановление и реализацию сервисов.
Поскольку 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? Это так, да не совсем. См. следующую часть.
