Лекция 5. OFDPA vs NetConf YANG

Два альтернативных подхода куправлению SDN коммутаторами:OFDPA vs NetConf/YANGМатематический спецкурс“Программно Конфигурируемые Сети”к.ф.-м.н., м.н.с., Шалимов А.В.ashalimov@lvk.cs.msu.su@alex_shali@arccnnewsКакие бывают OpenFlowкоммутаторы?••••FGPANPUHybrid на традиционных chip от Broadcom и MarvellX86 с программной начинкойПрограммно-Конфигурируемые СетиШалимов А.В.2Какой самый популярныйпроизводитель сетевых чипсетов?• Конечно, Broadcom!• Обрабатывает 99.98% всего интернет трафика.• Практически все вендоры (NEC, Extreme, HP, Cisco,Juniper) используют чипсеты от Broadcom.• ЦОД, корпоративный сегмент, провайдерыПрограммно-Конфигурируемые СетиШалимов А.В.3OF-DPA 2.0• Broadcom OpenFlow Data Plane Abstraction• Набор программных компонент для чипсетов по трансляции правилOpenFlow в абстракции и конвейер Broadcom чипсетов.– SDK, OF-DPA Driver, OF-DPA OpenFlow Agent• OpenFlow 1.3.4• Полная поддержка всех features от чипсета: L2/L3 bridging, VXLAN,NVGRE, ACL (drop, rewrite), QoS, queues и т.д.• Что описывает?– Какие таблицы есть, какие поля есть, какие действия, в каких таблицахвозможны– Experimental значения, чтобы разрешить специфичекуюфункциональность• Что получаем?– Возможность программировать существующие устройства (послеперепрошивки, да)– Высокая скорость системыПрограммно-Конфигурируемые СетиШалимов А.В.4OF-DPA 2.0• Broadcom OpenFlow Data Plane Abstraction• Набор программных компонент для чипсетов по трансляции правилOpenFlow в абстракции и конвейер Broadcom чипсетов.– SDK, OF-DPA Driver, OF-DPA OpenFlow Agent• OpenFlow 1.3.4• Полная поддержка всех features от чипсета: L2/L3 bridging, VXLAN,NVGRE, ACL (drop, rewrite), QoS, queues и т.д.• Что описывает?– Какие таблицы есть, какие поля есть, какие действия, в каких таблицахвозможны– Experimental значения, чтобы разрешить специфичекуюфункциональность• Что получаем?– Возможность программировать существующие устройства (послеперепрошивки, да)– Высокая скорость системыПрограммно-Конфигурируемые СетиШалимов А.В.5Архитектура реализацииOF-DPA 2.0Программно-Конфигурируемые СетиШалимов А.В.6Пример открытого программногостека OF-DPA 2.0Программно-Конфигурируемые СетиШалимов А.В.7Несколько деталей OF-DPA 2.0• У таблиц и правил появляется семантика• Есть несколько типов правил:– Стандартные - мы– Built-in - зашиты– Automatic – добавляются автоматически• Ограничения на групповые таблицы– L3 ECMP, как SELECT– L2/L3 broadcast, как ALL• Можно конфигурировать Switch и на самом OF-DPASDK.

Т.е. самому специфицировать Pipeline безиспользования SDN/OpenFlow.Программно-Конфигурируемые СетиШалимов А.В.8Bridging and Routing OF-DPA 2.0Программно-Конфигурируемые СетиШалимов А.В.9Программно-Конфигурируемые СетиШалимов А.В.10Тра• Курсы по Операционным системам учатфундаментальным принципам:– Примитивы синхронизации, потоки, исключения,файловая система и т.д.– Новые языки программирования, операционныесистемы• Курса по Сетевым технология учат куче протоколов– TCP, UDP, ARP, MPLS, GRE, BGP, OSPF, IS-IS, LDP, RSVP, PIM,….– Отсутствие фундаментальных принципов, толькоруководства по эксплуатации сетей– Алгоритмы маршрутизации одни и теже много лет,управление сетью примитивноПрограммно-Конфигурируемые СетиШалимов А.В.11Абстракция• Курсы по Операционным системам учатфундаментальным принципам:– Примитивы синхронизации, потоки, исключения,файловая система и т.д.– Новые языки программирования, операционныесистемы• Курса по Сетевым технология учат куче протоколов– TCP, UDP, ARP, MPLS, GRE, BGP, OSPF, IS-IS, LDP, RSVP, PIM,….– Отсутствие фундаментальных принципов, толькоруководства по эксплуатации сетей– Алгоритмы маршрутизации одни и теже много лет,управление сетью примитивноПрограммно-Конфигурируемые СетиШалимов А.В.12OF-TTP 1.0(15/08/2014)Table Type PatternTTP Introduction• Lifecycle of development, deployment and operation of OpenFlownetworks• To better accommodate heterogeneity of existing hardware switches• Enable future innovation in hardware switches• Enable precise communication between app/controller developers andswitch vendors• Enable automated communication between app/controllers and switchesTTP frameworkBefore sending OpenFlow messages between controller and switch we need:••••Agree on specific TTP (configured a priory or negotiated)Multiply Flow Tables description (particularly device are ASIC based)JSON based syntaxesIncludes a powerful mechanism Based on OF-CONFIG Protocol forsynchronizing controller and switch TTP contextsThe basic Lifecycle of TTPs in an OpenFlow Network1.

Something Prompts a New TTP• The network architecture identifies the types of network elements(“logical switch” - defined as various shapes).• Application providers (Vendors or network operators can conceivea various switch behaviors for solution architectures that theydevelop• To get things started the ONF will define a small number of TTPs2. Describing a TTP• Abstract switch model build on existing OpenFlow protocolversion• TTP is described as a proper subset of an OpenFLow multitable logical switch• Include Metadata (naming, authority, the Negotiabledatapath model (NDM )type), name and version• Includes a set of flow tables, flow mod messages types thatmust supported in specific flow tables, and the groupentries required in the group table• Define valid flow_mod and group_mod messages for agivvenlogical switch• Effectively specifies “table graph” of the TTP3.

Sharing a TTP description• ONF-developed TTPS– Once stable, fully public• Sharing will be accomplished by posting at the ONF website• Note that TTPs are not intended to be “standards”. Instead, TTPsare “common practices”, and ONF-developed TTPs will not hold anyspecial distinction with respect to TTPs developed by others• ONF Member-developed open TTPs– Application, controller and switch providers who are ONFmembers can develop a TTP and share it• Partnerships of members can also co-develop and share TTPs• Sharing of member TTPs will be supported on the ONF website, butcan be accomplished in other way as well• ONF Member-developed private TTPs– Market participants can also develop TTPs and keep them“under wraps”, either temporarily during development orfor more extended periods.

This might be handled in ways:• Fully hidden TTPS• Partially hidden TTPs (TTPs with Open IDs)– Private TTPs may, at the discretion of the controlling parties,be made open over time.4. Build support for TTP• Third party TTPs may be supported byboth controller and switch in similartimeframe• For TTPs provided by switch vendors andsupported by their products, support canbe added later by controller developerswishing to support this products in app.• Hardware suppliers are adding support fora TTP :– Need to release typical hardware schedule– Be able to decouple TTP support from theirmain OS release, and offer shortertimescales for supporting new TTPs.5. Go on Market• Explicitly declaring support forapplicable TTP gives customerconfidence that controller from onevendor will interoperate with a switchfrom another vendor• A very large network operator maydefine their own TTPs (own apps orcontrollers).

May require support forthis TTPs from their switch vendors6. Connect & Pick TTP• Discovery of available switch-supportedTTPs, based on well-known TTP identifiers• Simple activation of a desired TTP usingdefault parameters• An optional mechanism for the OFCP tonegotiate the switch for preferred TTPparameters– Switches that support parametersnegotiation must support an RPC extensiondefined within the NETCONF framework7. Run-time messaging with TTP• Table Features messages will not beallowed to alter table attributes• The switch may reject a messageusing a new error message if thecontroller attempts to exceedfeatures defined by the TTP8.

TTP-based testing• Product (both controller and switch) with built-in TTPawareness can be independently tested to assessconformance with specific TTPs.– TTPs are precise and unambiguous; if both ends conform to aTTP, interoperability is more easily achieved• TTPs can be used as test profiles, even when the productslack build-in TTP awareness– The Testing and Interoperability WG has expressed a need forunambiguous test profiles– TTP Descriptions allow various market participants to defineTTPs and, thus, test profiles• TTP descriptions may in future include test information, toencourage self-testing of TTP conformance– As a TTP gains market traction, 3-rd party testing of that TTPwill be increasingly likely– For new TTPs, self-testing provides a mechanism to buildadoption until 3-rd party testing becomes available.Example TTP Description: L2-L3-ACls• Example provide both MAC forwarding (unicast, multicast) andIP forwarding (unicast only).

Conforms to common standardsand practices for MAC Bridging and IP forwardingJSON sampleTable Type Patterns FAQIf our device supports most of themessages of a TTP, can we claimsupport for the TTP?• To legitimately claim support for a TTP, a switch mustimplement all non-optional functionality described bythe TTP. As mentioned above, a TTP may describesome functionality that is optional.