Просто представьте, во что мы себя уже втянули. Какова сложность архитектурной композиции из костылей, которую мы сооружаем?
Сначала мы ушли от технологий с коммутацией каналов к коммутации по ячейкам, чтобы более оптимально использовать полосу пропускания.
Потом оказалось, что строить заранее канал для ячеек тоже неудобно — негибко, ненадёжно.
Мы создали Ethernet, который в самом своём начале задумывался как протокол только для локальных сетей. Никому и в голову не могло прийти, что он может стать канальной технологией уровня города. Мы создали монстра, лишившего нас сна своими широковещательными штормами. При этом связка Ethernet+IP от рождения не предназначена для транспортировки старых протоколов, не может изолировать трафик разных клиентов друг от друга, даже элементарно управлять путём, которым пойдёт трафик мы не можем.
О, мой Лейбниц! А чего стоит рекурсивный поиск наиболее точного маршрута в таблице маршрутизации, отъедавший на заре IP драгоценные секунды процессорного времени? Пришлось выдумать MPLS, чтобы маршрутизаторы смотрели только на метку, что должно было происходить гораздо быстрее. В итоге мы опять вернулись к построению заранее определённых каналов, лишившись однако такой важной вещи, как гарантированное качество сервиса — то ли дойдёт пакет до получателя, то ли нет. Для этого были изобретены монструозные механизмы классификации трафика, токен-бакетов, аппаратных очередей QoS, управления перегрузками. А с появлением TCAM и FIB, быстрых процессоров и дешёвой памяти, чистый MPLS стал шпилем на уродливой башне из подпорок. К слову, TCAM — самый дорогой и горячий компонент современного оборудования.
И что мы имеем в итоге? Канал без гарантированного качества, который строится как случай на душу положит, а под собой несёт все проблемы Ethernet.
И тут появляется MPLS Traffic Engineering. Который делает что? Правильно: IntServ QoS и возможность строить маршруты так, как этого хочет оператор, а не IGP. При этом вручную задаются узлы по пути, где можно строить туннель, где нельзя, требования по ширине, задержкам, вариациям.
И тут нужно задать себе и окружающим вопрос: а туда ли мы идём?

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

• Полоса занята, даже если абоненты томно молчат в трубку, пытаясь придумать тему для разговора.
• Количество абонентов, которые могут использовать линию строго ограничено, соответственно никакой переподписки и высочайшая цена.
• Если вдруг кот погрыз радиоволну, то всё ваше телевидение испорчено. Не все технологии прошлого умели в резервирование. А те, что умели (тот же SDH восстанавливался за 50мс) стоили неприлично.

Вызов первых двух проблем приняло следующее поколение технологий — ATM. Была введена концепция ячеек. Стало лучше, стало легче — у клиентов по прежнему было гарантированное качество, но при этом их (клиентов) можно было подключить больше.
А вот с резервированием беда — АТМ по-прежнему был очень инертным и негибким, кроме экзотических реализаций IP over ATM.
А кроме того, появилась и новая идея — LAN — локальные компьютерные сети — все прежние технологии приходили в мир со стороны телефонных компаний и телефонных же стандартизирующих организаций. А там всё просто — инпут=оутпут, битрейт всегда плюс-минус одинаковый — чего хочет абонент, понятно.
LAN же ставил, можно сказать, противоположные задачи. АТМ потерпел сокрушительное поражение в схватке с Ethernet+IP.
Подход с коммутацией пакетов оказался очень гибким.
IP — обеспечил связность любых двух компьютеров в мире. А учитывая, что каждый маршрутизатор самостоятельно принимает решение, как поступить с каждым пакетом, резервирование стало очень простым и переключение в случае поломки происходило практически без перерыва сервиса.
Ethernet прекрасно справлялся с задачами локальной сети с минимальной настройкой — дошло до смешного — воткнул кабель в свитч — и всё работает. АТМ вместе с ISDN грустно утирают слезу.
Купить же себе бухту витухи, пару коммутаторов и собрать простую локалку мог позволить себе любой студент.
Да, пришлось пожертвовать гарантированным качеством сервиса. Однако Ethernet+IP, реализующий плавающий битрейт и открывающий широкие возможности для переподписки, оказался очень дешёвым по сравнению не только с ATM/E1, но и с SDH/SONET, поэтому вытеснил все другие технологии из локальных сетей, а сейчас вовсю и из магистральных вытесняет (прощай, SDH!).
А вопрос качества сервиса был адресован новаторскому механизму — PHB — DiffServ QoS, когда каждый маршрутизатор должен самостоятельно управлять трафиком. Концепция приоритезаци пакетов блестяще проявила себя, позволяя важному трафику выдать максимум ресурсов. В результате, по сравнению с моделью качества сервиса в старых технологиях Ethernet+IP оказался более или менее на уровне.
Но новые стандарты не заменяли старые — они использовались на новых сетях, а АТМы и SDH жили на старых. И долгое время они едва пересекались. У нас были отдельно сети для телефонии, отдельно для ШПД, отдельно для телевидения.
Единственная серьёзная проблема IP была в Control Plane’е — очень уж ресурсоёмкой процедурой был поиск нужной строчки в таблице маршрутизации. И этот вопрос был адресован молодой технологии MPLS, разработчики которой решили взять лучшее от ATM, избавиться к чертям от его канальной функции и внедрить её в связку Ethernet+IP, аккурат между ними. Да, странная вставка L2,5 между L2 и L3 выглядит неорганично, но кому какое дело до этой модели OSI (спросите об этом Иннокентия в чате linkmeup)?
Первоначально MPLS был призван упростить процедуру коммутации пакетов. То есть connectionless IP сначала находит все маршруты в сети, а поверх них натягиваются MPLS-туннели, которые с одной стороны являются каналами между двумя точками, но с другой автоматические и опираются на IP. В итоге MPLS-пакет приходил на MPLS-маршрутизатор, тот проверял его метку, менял её и отправлял дальше. В его таблицах было чёткое соответствие — пакет с такой меткой нужно отправить в такой-то интерфейс, а с меткой сделать то-то и то-то. Никаких многократных переглядывалок с таблицей маршрутизации.
Но в этом плане MPLS прискорбно опоздал — микроэлектроника тоже не топталась на месте и подставила ему подножку — появились TCAM, которые за фиксированное время возвращали нужный маршрут, появилась концепция FIB — когда все необходимые параметры для действий с IP-пакетами были в близком доступе — в том самом TCAM, выросли процессорные мощности, а гигабайты оперативки можно было купить вместе с луком на рынке.
И вот тут хотелось сесть и заплакать — всё зря. Мы создали 11-й стандарт вместо того, чтобы свести 10 предыдущих к одному.
И вдруг какая-то светлая голова обнаружила, что MPLS-инкапусляция скрывает для транзитных маршрутизаторов внутренности пакета. То есть происходит туннелирование, как, например, в GRE. А почему бы нам внутрь MPLS-пакета закинуть не IP, а какой-нибудь E1?
Ну в самом деле, технологиям PDHoverEthernet или PDHoverIP сто лет в обед — просто это было неудобно. А тут уже есть есть автоматически созданные туннели — нужно только направить в них E1.
Как словом, так и делом, AToM через сеть MPLS может передать любые существующие протоколы канального уровня. Это MPLS L2VPN.
Можно подключить пару клиентов по Ethernet и, изолировав их друг от друга MPLS-метками, обеспечить им виртуальную локальную сеть — это MPLS VPLS, MPLS VPWS, EVPN и другие.
А ещё можно всё тот же IP прятать, но разными MPLS-метками обозначать разных клиентов и предоставлять им IP-связность. Это MPLS L3VPN.
И это немного больше, чем просто дополнительные сервисы — это огромный скачок в направлении конвергентных сетей. Теперь MPLS-сеть провайдера может использоваться для предоставления услуг ШПД, телефонии, телевещания, L3VPN и L2VPN одновременно.
Это уже серьёзный удар по классическим телефонным компаниям, которым пришлось скинуть путы старых стандартов и свои сети тоже переводить на Ethernet+MPLS+IP. Не удалось им почивать на лаврах фиксированной телефонии вечно.

Следующее поколение конвергентных сетей — FMC — Fixed-Mobile Convergence. Одна и та же сеть теперь может использоваться для всего перечисленного выше плюс являться транспортной сетью для мобильной сети.
В самом деле — базовые станции LTE подключаются только по Ethernet, 3G — частично по Ethernet, частично по ATM, 2G могут быть Ethernet или E1. И для всего этого есть MPLS.
И концепция DiffServ вместе с приоритезацией пакетов в целом неплохо справляется с таким потоком данных. Например, служебные протоколы MPLS-сети имеют приоритет 6-7, данные 2G и IP-телефонии могут идти с приоритетом 5, 3G — 4, LTE — 3, real-time video — 3, сёрфинг — 2, FTP, почта — 1 а торренты — 0.
Вместо инсталляции из палок, скреплённых жвачкой, перед нами прекрасная пирамида, которая медленно эволюционировала долгие годы.

И вот он — Traffic Engineering — самое неоднозначное применение MPLS.
…