Операторам не придется менять свою инфраструктуру IPv4 для пропуска трафика приложений IPv6, если они перейдут на использование технологии MPLS
Незадолго до открытия последней выставки Networld + Interop инженеры Advanced Internetworking Initiative компании iLabs совместно с сотрудниками лаборатории межсетевого взаимодействия фирмы Isocor развернули реальную сеть MPLS (Multi-Protocol Label Switching) в целях тестирования технологий VPN на базе коммутации по меткам и некоторых современных механизмов интеграции протоколов IPv6, IPv4 и MPLS. Основные участники тестирования — Хедж Тровшик, Раджив Папнеджа и Джим Мартин — рассказали о результатах испытаний редактору американского еженедельника Network World Джиму Даффину.
Джим Даффин (ДД): Какие основные цели преследовало тестирование?
Раджив Папнедж (РП): Мы стремились подтвердить возможность работы со сложными корпоративными приложениями, используя мощное ядро сети на основе протокола MPLS. Уникальность нынешних испытаний заключается в том, что они продемонстрировали готовность технологии MPLS к поддержке пользователей шестой версии протокола IP без каких-либо специальных модификаций сетевых устройств и уж тем более — замены маршрутизаторов, установленных в сети оператора и рассчитанных на работу по протоколу IPv4. Другими словами, корпоративные заказчики могут смело внедрять устройства, поддерживающие IPv6, и при этом сохранять прозрачные соединения с сетевой инфраструктурой на базе IPv4.
ДД: К чему относились тестировавшиеся сервисы — к граничным устройствам, магистральному оборудованию или к тому и другому?
РП: Прежде всего нас интересовали сервисы и приложения, реализованные на периферии сети. В ходе испытаний мы попытались показать, какие преимущества сулит корпоративным пользователям тот или иной вариант технологии MPLS. Более того, пользователи могут без особого труда реализовать в среде MPLS собственные сервисы, скажем, сформировать сети VPN на втором и третьем уровнях, организовать туннельную передачу трафика IPv6 либо транспортировку многоадресного трафика поверх мультипротокольной среды. Одновременно мы протестировали некоторые функции ядра сети, включая ускоренную перемаршрутизацию пакетов в опорной сети, поддерживающей механизмы QoS, и приоритизацию трафика.
Граничный сервис VPN Layer 2 подразумевает организацию соединений как «точка — точка», так и «точка — много точек», в том числе при формировании виртуальных частных локальных сетей. Услуги VPN Layer 3 основываются на спецификации RFC 2547bis консорциума IETF, а ускоренная перемаршрутизация — непосредственно на коммутации по меткам и расширениях протокола RSVP (Resource Reservation Protocol).
Джим Мартин (ДМ): В одних случаях многоадресная передача IP-трафика базировалась непосредственно на механизмах ядра MPLS, в других не имела к ним отношения.
В первом случае речь шла о попытке реализовать транспорт IP Multicast поверх виртуальных частных сетей, основанных на протоколе BGP (Border Gateway Protocol). Проект соответствующей спецификации IETF позволяет формировать многовещательные домены для транспортировки данных по ядру сети MPLS, сохраняя большинство (если не все) преимуществ многоадресной рассылки, в том числе отсутствие повторных передач одного и того же потока через данное соединение.
Во втором случае мы создавали сети VPN на втором уровне модели OSI и непосредственно использовали протоколы многоадресной рассылки в соответствующих соединениях. Такое решение неизбежно вызывает повторную трансляцию потоков. Важность этой части испытаний трудно переоценить, поскольку многие предприятия применяют многоадресную передачу в интересах бизнеса, прежде всего — для организации взаимосвязи между территориально разнесенными офисами.
В лабораторных условиях был смоделирован сценарий, в рамках которого на периферии сети работало оборудование только одного производителя, а ее магистральная часть содержала продукты нескольких компаний. На выставке ситуация еще более усложнилась: в качестве граничных были установлены устройства разных фирм, и нас интересовала их способность взаимодействовать друг с другом. Подобная смесь продуктов представляет особый интерес, поскольку проект спецификации BGP/VPN обладает недостатком, свойственным всем современным стандартам: он регламентирует три разных набора правил обработки пакетов и два варианта инкапсуляции трафика. Таким образом, допустимы шесть сценариев, каждый из которых полностью соответствует требованиям данного документа. Получается, что в совместимости продуктов разных фирм заранее уверенным быть нельзя.
ДД: Сколько производителей было охвачено тестированием и сколько платформ — граничных маршрутизаторов (LER) и коммутирующих маршрутизаторов (LSR), поддерживающих работу с метками, — использовалось на разных концах высокоскоростных соединений?
Хедж Тровшик (ХТ): Непосредственными участниками испытаний стали 24 компании, а еще десять обеспечили их поддержку. Из них около 15 — производители маршрутизаторов, а три фирмы выпускают оборудование для тестирования, которое выступало у нас в роли устройств LER, обеспечивая работу с пакетами IPv6 и многоадресную рассылку. В сети были установлены четыре магистральных маршрутизатора и 25 граничных устройств (хотя некоторые отвечали за обработку пакетов IPv6 и многоадресного трафика, но не поддерживали протокол MPLS). Наконец, к тестированию были привлечены поставщики анализаторов трафика, средств формирования правил его обработки и оптимизации маршрутов передачи.
ДД: Какие сервисы — TDM, ATM, IP, frame relay, Ethernet, видео и т. д. — могут быть реализованы в сети MPLS? В какой мере каждый из них выигрывает от поддержки сетью технологии MPLS?
РП: Для сетей VPN второго уровня на основе имевшегося оборудования мы смогли сформировать соединения по принципу «каждый с каждым». Например, на одном конце соединения может находиться локальная сеть с физическими портами Ethernet, а на другом, удаленном, — виртуальная ЛС с виртуальными портами Ethernet. Другой вариант — передача по MPLS-магистрали трафика ATM, идентифицируемого по паре меток VPI/VCI, или frame relay c идентификатором DLCI. В сети, состоящей из разных маршрутизаторов и оборудования многочисленных производителей, было необходимо выбрать несколько широко используемых типов интерфейсов. В ядре сети в их качестве выступали Gigabit Ethernet и OC-12/OC-48.
ДД: Не могли бы сформулировать цели тестирования, имевшие отношение к контрактам об уровне обслуживания (SLA)? Какие специфические проблемы возникают при попытке согласовать механизмы QoS между границей и ядром сети, а также увязать их со средствами обхода отказавших соединений в этих двух частях сетевой среды?
РП: В процессе демонстрации мы попытались показать работу механизмов QoS на уровне ядра сети, поддерживающего приоритизацию трафика. Для этого было сформировано несколько маршрутов на основе меток (LSP), которые соответствовали «золотому», «серебряному» и «бронзовому» сервисам. Соблюдались все ограничения спецификации RFC 2702. Нам удалось продемонстрировать способность граничных устройств ставить высокоприоритетный трафик в соответствие маршрутам LSP, предназначенным для реализации «золотого» сервиса.
ДД: Что проверялось применительно к протоколу IPv6 и к средствам интеграции протоколов IPv4 и IPv6 с технологией MPLS?
РП: Мы стремились продемонстрировать разные транспортные механизмы, которые позволяют мгновенно вывести инфраструктуру IPv4 на качественно новый уровень и по этой причине представляют несомненный интерес для операторов. Прежде всего, речь идет о поддержке клиентов, которые по тем или иным причинам переходят или планируют перейти к использованию сервисов на базе IPv6. Результаты испытаний оказались весьма обнадеживающими, но в этой области еще предстоит поработать.
ДМ: Сочетание MPLS и IPv6 дает корпоративным пользователям очень удобный способ формирования распределенной инфраструктуры с поддержкой IPv6, который не требует от оператора кардинального обновления своей сети. Основываясь на положительных результатах тестирования средств передачи трафика IPv6 поверх сети BGP/VPN, мы намерены протестировать новые устройства и решения, дабы подтвердить их функциональность и способность к взаимодействию.
Наши долгосрочные планы связаны с прояснением текущего состояния технологии многоадресной передачи трафика IPv6. Ее поддержка с самого начала была одной из базовых возможностей данного протокола, но по мере разработки других его составных частей оказалась на вторых ролях. Предстоит выяснить, какие производители сетевого оборудования и оконечных устройств поддерживают такую передачу и в какой мере их продукты способны взаимодействовать друг с другом.
ДД: Не намеревались ли вы оценить, способствует ли использование MPLS повышению продуктивности и снижению операционных расходов сетевых администраторов? Позволяет ли эта технология органично объединить несколько сервисов на уровне одного соединения между удаленными офисами, гарантируя для каждого из них специфические параметры QoS?
РП: Ответ на ваш вопрос зависит от конкретного бизнес-сценария, от намерений оператора, внедряющего поддержку MPLS. Какие-то общие рекомендации для всей индустрии сформулировать невозможно. Но, проанализировав истории успеха Internet-провайдеров, которые перешли на конвергентную магистральную инфраструктуру на базе MPLS, вы обнаружите, что все они извлекли из такого шага определенные преимущества. Технология MPLS действительно помогает операторам интегрировать разрозненные сети при помощи общего ядра IPv4 с поддержкой MPLS, а это в свою очередь позволяет снизить эксплуатационные расходы и упростить управление сетью. Наше тестирование наглядно продемонстрировало, каким образом MPLS помогает операторам реализовать множество сервисов в единой транспортной среде, соединяющей несколько удаленных офисов.