Лекция 5. OFDPA vs NetConf YANG (1185626), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Support for the TTPcan be fairly claimed even if the optional functions arenot supported, though product documentation shouldmake clear what is and is not supported. (Forconsistency in the marketplace, documentation ofoptional functionality support should refer to theOptFunc parameter values that are or are notsupported. (See the OF-TTP specification andexample TTPs for OptFunc details.)Are TTPs intended to describe aparticular chip pipeline?• TTPs were conceived and developed as a way to describe “implementationindependent” switch behavior (a use case), and thus TTP were intended todescribe an abstract switch architecture rather than specific physicalarchitecture. Such abstract architecture TTPs can be mapped ontodifferent physical switch architectures. The expectation is that an abstractTTP that maps onto many physical devices will have an advantage inadoption.

Application architects should therefore seek to develop suchTTPs• Nevertheless, TTPs can be written to cater to a particular physical devicepipeline. Shortly before the TTP standard was approved, Broadcomintroduced their OF-DPA effort, based on the TTP framework but focusedon their switch architecture. (As of this writing, the TTP that representsOF-DPA capabilities is still in development, likely to complete within a fewmore weeks.)• If a particular switch vendor’s TTP gains an adoption advantage, onepossible outcome is that other vendors may be motivated to support thatTTP, which would represent a form of market-driven functionalconvergence at the device level.

In this way, TTPs can support an evolutiontoward a long-promised SDN reality.Are TTP files sent over the wire?• No. The current TTP framework does not describeany situation where OpenFlow products wouldpass TTP descriptions "over the wire". However,there will likely be scenarios in the future wheresuch transfer will become interesting. For now,experimenter extensions to the OFSwitchprotocol offer one way to implement thecapability for providers that have interest infeatures that could benefit from over-the-wireTTP transfer.Do a controller and a switch need tosynchronize with each other to useTTPs?• When TTP support is integrated into products (controllersand switches), then it is necessary to synchronize the twoendpoints to enable TTP-related functionality.

This can bedone by configuration or during OF Switch initialization. Atthis time, the config-based approach would either use theOF-Config-based NDM Sync mechanism (see the NDM syncspec) or some proprietary (out-of-scope) mechanism ofconfiguration such as CLI commands at both ends. The OFSwitch-based mechanism would use an OF-Switchextension mechanism that is, at the time this is written,under development as an experimenter extension by theForwarding Abstractions WG.Заключение• OF-DPA огромный шаг Broadcom на встречуSDN/OpenFlow– Описывает pipeline чипсета в терминахOpenFlow• NETCONF/YANG хитрый (но логичный шаг)CISCO к управлению своим оборудованиемhttp://arccn.ru/ashalimov@lvk.cs.msu.suПрограммно-Конфигурируемые СетиШалимов А.В.@alex_shali@arccnnews32Программно-Конфигурируемые СетиШалимов А.В.33.

Характеристики

Список файлов лекций