CC BY
267
ОБ УРОВНЯХ УПРАВЛЕНИЯ В ПРОГРАММНО-КОНФИГУРИРУЕМОЙ СЕТИ (SDN)
Логинов Сергей Сергеевич,
аспирант, Санкт-Петербургский государственный
университет телекоммуникаций
им. проф. М.А.Бонч-Бруевича, Санкт-Петербург, Россия,
ss7loginov@gmail.com
Ключевые слова: программно-конфигурируемая сеть SDN, уровень управления, сетевая операционная система, сетевые программы управления операционными системами, сетевые политики, сетевая логика, сетевые приложения.
Несмотря на распространенность, современные сети, основанные на стеке IP/TCP, не отвечают растущим требованиям по скорости ввода в эксплуатацию и скорости внесения изменений в конфигурацию сети. Появление программно-конфигурируемых сетей должно изменить положение вещей. Главным отличием таких сетей является удаление управляющей логики из маршрутизаторов и свитчей, появление логически централизиро-ванного управления сетью, а также возможность программирования сети. Приводится краткая терминология SDN, а также описание уровня управления (control plane) сети SDN. Рассматриваются составляющие управляющего уровня. Сначала приводится описание сетевых программ управления операционными системами (Hypervisor), которые позволяет различным виртуальным машинам находится на одной аппаратной платформе, а также приводится сравнение существующих реализаций: FlowVisor, AutoSlice, FlowN и Network Virtualization Platform (NVP). Затем рассматриваются понятия сетевой операционной системы/контроллера, а также отличия между централизованным и распределенным контроллером, приводятся функции контроллера и общее описание Southbound, Eastbound и Westbound API. Именно они отвечают за возможность взаимодействия программных и аппаратных изделий разных поставщиков. Необходимо отметить преимущества данного подхода перед существующими сетями. Основными идеями SDN являются появление динамически программируемых направляющих устройств посредством открытых southbound интерфейсов, разделение управляющего уровня и уровня данных, а также получения общей картины сети посредством логической централизации "сетевого мозга". Приложения, осуществляющие сетевую логику, запускаются поверх контроллера, их значительно легче разработать и ввести в эксплуатацию, чем в обычных сетях. При наличии общей картины, проще установить последовательные сетевые политики. SDN представляет существенное изменение в развитии и эволюции сетей, а также реализации новых типов услуг, например, облачных сервисов сеть-как-сервис (networkas-a-service cloud computing paradigm) и программно-конфигурируемые среды (software-defined environments, SDE).
Для цитирования:
Логинов С.С. Об уровнях управления в программноОконфигурируемой сети (SDN) // T-Comm: Телекоммуникации и транспорт. 2017. Том 11. №3. С. 50-55.
For citation:
Loginov S.S. (2017). Control plane in software defined networks. T-Comm, vol. 11, no.3, рр. 50-55. (in Russian)
Введение
Появление еети Интернет привело к созданию цифрового общества, в котором (почти) все устройства сообщаются между собой и доступны из любой точки мира. Однако, несмотря на свою распространенность, сети IP имеют сложную структуру, и ими довольно сложно управлять. Такую сеть сложно сконфигурировать для достижения выбранной сетевой политики, а также реконфигурировать в соответствии с выявленными недостатками и изменением нагрузки и структуры. К усложнению ситуации приводит и то, что существующие сети являются вертикально интегрированными: уровень управления сетью и уровень потока данных соединены в один. Программно-конфигурируемая сеть (SDN) — это развивающийся концепт, который дает надежду на изменение ситуации. В такой сети происходит отказ от вертикальной интеграции, вынос контрольной логики за пределы Свитчей и роутеров, а также привносится возможность программировать сеть. SDN облегчает процесс создания и внедрения новых сетевых абстракций, при этом упрощая управление сетью, и содействует эволюции сети.
Чтобы описать желаемые высокоуровневые политики сети, операторам сети приходится кон фигу ¡тировать каждое устройство отдельно, используя низкоуровневые команды, которые часто отличаются в зависимости от производителя. Кроме этого, сетевые структуры должны выдерживать меняющиеся неисправности и приспосабливаться к изменениям уровня нагрузки. Механизмов автоматической реконфигурации практически не существует при текущем состоянии IP сетей. Из-за этого усложняется внедрение сетевых политик в такой постоянно изменяющейся среде.
Современные еети также вертикально интегрированы, что только усложняет сложившуюся ситуацию. Уровень управления (который принимает решения по обработке сетевого трафика) и уровень данных (который направляет трафик согласно решениям уровням управления) связаны внутри сетевых устройств, что уменьшает гибкость и препятствует инновациям и эволюции сетевой инфраструктуры.
Программно-конфигурируемая сеть является развивающейся концепцией, которая дает надежду на изменение ограничений современных сетевых структур. Во-первых, она разбивает вертикальную интеграцию, т.е. отделяет управляющую логику (управляющий уровень) от нижележащих маршрутизаторов и свитчей, которые направляют график (уровень данных). Во-вторых, с разделением этих уровней, свитчи становятся простыми маршрутизирующими устройствами, а управление сосредоточено в логически централизованном контроллере (т.н. сетевая операционная система), что упрощает введение сетевых политик, реконфигурацию сети и ее эволюцию. Упрощенный вид такой архитектуры показан на рис, 1, Стоит отметить, что логически центральная программная модель не означает физически централизованную систему [2]. Па самом деле, для обеспечения соответствующих уровней быстродействия, масштабирования и надежности, от таких решений следует отказаться. Вместо этого, рабочие SDN сети опираются на физически распределенные управляющие уровни [2], [3].
Разделение двух этих уровней является ключом к достижению желаемой гибкости сети, одновременно разбивая проблему управления сетью на легкообрабатываемые задачи и упрощая введение новых абстракций.
Network Application!:)
,.i Open northbound API Controller Platform
Рис, 1, Упрощенный вид архитектуры SDN
Целью данной статьи является представление широкому кругу специалистов проблематики проектирования уровня управления сети SDN, с приведением различных примеров по реализации технологий сетевых программ управления операционными системами и самих сетевых операционных систем. Ч и тате л [о будет представлен краткий обзор достигнутых сегодня разработчиками результатов, и предложен для более подробного знакомства современный подход к проектированию перспективных сетей SDN, в которых происходит разделение уровня управления и уровня данных.
1. Определение программно-конфигурируемой сети
Термин программно-конфигурируемая сеть (Software-Defined Networking) изначально использовался для описания работы вокруг OpcnFlow в Стэвдфордском Университете [4]. По первоначальному определению, SDN определяет сетевую архитектуру, в которой состояние продвижения трафика на уровне данных находится под контролем полностью независимого уровня управления.
Мы дадим определение SDN как сетевой архитектуры с четырьмя особенностями:
1) Уровни управления и данных разъединены. Функции управления удалены из сетевых устройств, которые становятся простыми направляющими элементами.
2) Используется маршрутизация с учетом свойств потока, а не конечного узла назначения. Поток, в широком смысле, это набор определенных значений в заголовке пакета, который служит для выбора отдельных пакетов из общего трафика и составления для них соответствующих инструкций. В контексте SDN/Open F low, поток - это последовательность пакетов между источником и получателем. Все пакеты одного потока получают одинаковый сервис, соответствующий сетевым политикам на маршрутизирующих устройствах [5].
3) Логика управления перенесена в отдельный внешний объект, гак называемый контроллер SDN или Сетевая операционная система (Network Operating System). NOS представляет собой программную платформу, которая запускается на бюджетных серверах (commodity server technology) и предоставляет основные ресурсы для облегчения программирования маршрутизирующих устройств, основываясь на логически централизованном, абстрактном плане сети.
T-Comm Vol. 1 1. #3-201 7
7Т>
4) Сеть является программируемой с помощью приложений, запущенных поверх NOS, которые взаимодействуют с нижележащими устройствами уровня данных. Это является основной характеристикой SDN, считающейся ее главным достоинством,
2. Обзор архитектуры SDN
Архитектура SDN может быть представлена как ряд уровней (рис. 26). У каждого уровня есть свои специфические функции.
Уровень данных (Data Plañe): направляющие устройства объединены по беспроводному или проводному каналу связи. Сетевая инфраструктура содержит в себе взаимосвязанные направляющие устройства, которые представляют собой уровень данных.
Уровень управления (Control Plañe): направляющие устройства про1раммируются элементами управляющего уровня посредством South bound Inte г face. Уровень управления может пониматься под "мозгами сети". Вся логика управления находится в приложениях и контроллерах, которые формируют уровень управления.
Уровень менеджмента (Management Plañe): этот уровень представляет собой набор приложений, которые выполняют функции, предлагаемые Northbomd Inter face для обеспечения управления сетью. Такие приложения включают в себя маршрутизацию, файерволы, распределители нагрузки, мониторинг и др. По существу, приложения менеджмента определяют политики, которые в конечном счете интерпретируются как инструкции для southbound
Рассмотрим составляющие управляющего уровня.
2.1. Сетевые программы управления операционными системами (Hypervisor)
В современных компьютерах технология виртуализации не нова. Быстрый рост производительности в последнее десятилетне сделал виртуализацию компьютерных платформ общепринятой. Основываясь на недавних исследованиях, число виртуальных серверов уже превысило число физических [6].
Hypervisor позволяет различным виртуальным машинам находится на одной аппаратной платформе. В облачной infrastructure-as-a-service, каждый пользователь получает свои собственные виртуальные ресурсы на обработку и хранение данных. Виртуальные машины можно достаточно просто переносить на другую аппаратную платформу, создавать или удалять по запросу. К сожалению, виртуализация только отчасти реализована на практике. Несмотря на преимущест-
ва такого подхода, сеть все еще конфигурируется статически
[7].
Для обеспечения полной виртуализации сеть должна обеспечивать одинаковые качества для уровня приложений [7]. Сетевая инфраструктура должна поддерживать произвольные сетевые топологии и адресные схемы. Каждый клиент должен иметь возможность одновременно конфигурировать как вычислительные, так и сетевые элементы. Миграция сервера должна автоматически приводить к миграции соответствующих портов виртуальной сети.
Существуют различные подходы к виртуализации сети.
Одна из ранних технологий для виртуализации SDN -FlowVisor. Г лавная идея заключается в том, что несколько логически разделенный сетей используют ресурсы одной OpenFlow инфраструктуры. С этой целью FlowVisor предоставляет абстрактный слой, который позволяет разделить уровень данных на несколько кусков, реализуя сосуществование нескольких различных сетей.
Другая технология виртуализации SDN - AutoSlice. В отличие от FlowVisor, он сосредоточен на автоматизированном развертывании и эксплуатации vSDN (виртуальной SDN) топологий с минимальным участием сетевого оператора,
FiowN основан на другой идее. Он работает по аналогии с виртуализацией на базе контейнеров (container-based virtu-alization). FlowN разрабатывался в первую очередь для облачных платформ. Он разработан с учетом требований масштабируемости и позволяет использовать один контроллер для менеджмента нескольких доменов в облаке.
Ни один из предыдущих подходов не разрабатывался с учетом всех потребностей дата-центров. Например, клиент хочет перенести корпоративное решение в облако, при этом не изменяя текущую конфигурацию домашней сети.
Существующие сетевые технологии не могут ответить на требования как клиентов, так и поставщиков услуг.
VMWare предложила платформу сетевой виртуализации network virtualization platform (NVP), которая обеспечивает необходимые абстракции для создания независимых виртуальных сетей.
В качестве вывода можно отметить, что уже существует несколько решений сетевых hypervisor, использующих возможности SDN. Существует, однако, несколько проблем. Среди них улучшение схемы перехода между виртуальным и физическим уровнями, определение уровня детализации, необходимого логическому уровню и поддержка вложенной виртуализации. Можно ожидать, что данное направление будет быстро развиваться в ближайшем будущем, гак как виртуализация сети будет играть ключевую роль в будущих виртуальных системах, подобно расцвету виртуальных вычислений,
2.2. Сетевая операционная система/контроллеры
Традиционные операционные системы обеспечивают абстракции (например, высокоуровневое API для программирования) для доступа к низкоуровневым устройствам, управляя сопутствующим доступом к нижележащим ресурсам (напр., жесткий диск, сетевой адаптер, ЦПУ, память), и механизмы защиты.
Напротив, сети до сих пор управлялись и конфигурировались е помощью низкоуровневых инструкций, уникальных для каждого устройства, и практически полностью закрытых операционных систем (напр., Cisco IOS и Juniper JunOS).
Из-за этого сетевым специалистам приходилось решать одни и те же задачи снова и снова. SDN должна способствовать упрощению сетевого менеджмента и облегчать решение сетевых проблем с помощью логически-централизованного контроля NOS [5]. Разработчику не нужно больше волноваться о низкоуровневых деталях при распределении данных между маршрутизирующими элементами при использовании NOS.
NOS (или контроллер) является критическим элементом в SDN архитектуре. Она необходима контрольной логике (приложениям) для создания сетевой конфигурации, основанной на политиках, определяемых оператором.
С точки зрения архитектуры контроллеры могут быть разделены на централизованные и распределенные.
Централизованный контроллер - это единый объект, который управляет всеми направляющими устройствами в сети. Конечно, он представляет собой единую точку отказа и может иметь ограничения по масштабируемости. Единого контроллера может быть недостаточно, чтобы управлять сетью с большим числом элементов уровня данных.
Распределенная сетевая операционная система может масштабироваться для соответствия требованиям любой сети от маленькой до большой. Распределенный контроллер представляет собой централизованный кластер нодов, или физически распределенный набор элементов, В то время как первый вариант может повысить пропускную способность плотно загруженных дата-центров, второй может быть более устойчив к логическим и физическим сбоям. Поставщик облачных услуг, который работает с несколькими дата-центрам и, соединенными по WAN, может использовать гибридный подход - контролирующие кластеры, находящиеся внутри каждого дата-центра, и распределенные контроллеры на местах [3],
Одно из свойств, присущее распределенным контроллерам - это отказоустойчивость. При отказе одного узла, соседний должен взять на себя его обязанности. Пока, несмотря на то, что некоторые контроллеры устойчивы к полному отказу оборудования, они не могут засечь условные сбои, т.е. любой узел с ненормальным поведением не будет заменен на «правильный».
Функции контроллера
Контроллер должен предлагать несколько основных сетевых функций. Например, приложения могут использовать
функции топологии, статистики, уведомлений и управления устройствами, а также поиска кратчайшего пути и механизмов безопасности. Например, менеджер уведомлений должен получать, отправлять и обрабатывать информацию о событиях [8].
Southbound
На нижнем уровне контрольной платформы, southbound APis можно рассматривать как уровень драйверов устройств. Они предлагают общий интерфейс верхним уровням, в то же время позволяя использовать различные southbound APIs (например, OpenFlow, OVSDB, ForCES). Это необходимо для обратной совместимости и гетерогенности, т.е. для работы разнородных протоколов и device management connectors.
Eastbound and Westbound
Eastbound и westbound API, как показано на рис 6, специальные интерфейсы для распределенных контроллеров. В настоящее время, у каждого контроллера есть собственные east/westbound API. Их функции включают импорт/экспорт данных между контроллерами, алгоритмы связности и возможности для мониторинга/уведомлений. Для взаимосвязи различных контроллеров необходимо иметь стандартные east/westbound interfaces.
При установке нескольких доменов, east/westbound APIs могут потребовать более конкретного протокола для взаимодействия контроллеров доменов SDN [9]. Некоторые основные функции таких протоколов — это координация потоков от приложений, обмен информации о возможности доступа внутри SDN и др.
В заключение можно сказать, что контролирующая платформа необходима для успеха SDN. Одна из главных задач -возможность взаимодействия программных и аппаратных изделий разных поставщиков. Довольно интересно, что именно это было первоначальной проблемой, которую пытается решить southbound APIs {напр, OpenFlow), Например, в то время как WiFi и LTE нуждается в специализированных контрольных платформах (MobileFIow или Soft RAN), специфические требования дата-центров поддерживаются (Onix [6] и Open Day light). По этой причине в системах, где используются различные виды сетевых инфраструктур, взаимодействие контроллеров очень важно. Для разрешения этих проблем необходимо создание стандартизированного API.
Routing Load Security Network Network Attack
Protocols Balancers ACLs Visualization Monitoring Detection
Programming Languages
Management Applications
Northbound Interfaces
M Westbound Mechanisms A Protocols
Ea s t/wes I bo und Abstraction Layer
Shortest Path Forwarding Notification Manager Security Mechanisms
Topology Manager
Stats Manager
Device Ménager
Southbound Abstraction Layer
Controller Platform
Common Interfaces
ForCES CECE
OpenFlow
Southbound Interfaces
Hardware-based Forwarding Devices
Software-based Forwarding Devices
Data Plane Elements
Рие. 3. Контрольные платформы SDN: элементы, сервисы и интерфейсы
■
S3
г
SON Controller Node
SDN Controller Node
Onit 1
ON OS
»int
Westbound/ Eastbound APIs
f .
г 0DL
Floodlight
Рис. 4. Распределенные контроллеры east/westbound API
Заключение
Традиционные сети имеет сложную структуру, и ими сложно управлять. Одна из причин - вертикальное интегрирование уровня данных и уровня управления, а также их зависимость от производителей оборудования. Каждый производитель может создавать свои собственные инструменты для конфтурации и управления, недоступные другим устройствам, затягивая процесс обновления ПО или аппаратной части устройств. Из-за этого появились проблемы привязки сети к определенному производителю, что накладывает ограничения на изменения и инновации в сети.
Подводя итоги аналитического обзора современного состояния и перспектив развития сети SDN, необходимо отметить преимущества данного подхода перед существующими сетями. Основными идеями SDN являются появление динамически программируемых направляющих устройств посредством открытых southbound интерфейсов, разделение управляющего уровня и уровня данных, а также получения общей картины сети посредством логической централизации «сетевого мозга». Элементы уровня данных становятся простыми направляющими элементами с отсутствием логики, а элементы уровня управления теперь представлены единым объектом — контроллером или сетевой операционной системой. Приложения, осуществляющие сетевую логику, запускаются поверх контроллера, их значительно легче разработать и ввести в эксплуатацию, чем в обычных сетях. При наличии общей картины, проще установить последовательные сетевые политики. SDN представляет существенное изменение в развитии и эволюции сетей.
SDN удалось пробить себе дорогу в сетях следующего поколения, создавая среду для инноваций, содействуя про-
грессу в разработке свитчей и контроллеров, увеличению масштабируемости и быстродействия устройств и архитектур, обеспечивая безопасность и надежность.
В ближайшем будущем мы увидим обширную деятельность вокруг SDN, Многие вновь открывшиеся области требуют дальнейших исследований, например, пути перехода на SDN, перенос SDN в транспортные сети, реализация облачных сервисов сеть-как-сервис networkas-a-service cioud computing paradigm и программно-конфигурируемые среды, software-defined environments (SDR).
Литература
1. B. Raghavan, M, Casado. T. Koponen. S, Ratnasamy, A. Ghodsi, and S. Shenker, "Software-defined internet architecture: Decoupling architecture from infrastructure," in Proceedings of the I Ith ACM Workshop on Hot Topics in Networks, ser, HotNets-Xl. New York, NY, USA: ACM, 2012, pp. 43-48.
2. T. Koponen. M. Casado. N. Gude. J. Strihling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. ¡noue. T. Huma, and S. Shenker, "Onix: a distributed control platform for large-scale production networks," in Proceedings of the 9th USENIX conference on Operating systems design and implementation, ser. OSDl'lO. Berkeley, CA, USA: USENIX Association, 2010, pp. 1-6.
3. S. Jain, A. Kumar, S. Mandai. J. Ong. L, Poutievski, A. Singh, S. Venkata, J. Wanderer. J. Zhou. M. Zhu, J. ZoUa, U. H " olzle. S. Sluari, and A. Talidat, "B4: experience with a globally-deployed software defined wan," in Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, ser. SIGCOMM '13. New York, NY, USA: ACM, 2013, pp. 3-14.
4. K. Greene, "MIT Tech Review 10 Breakthrough Technologies: Software-defined Networking," hup://www2.technologyreview.com/ a rt ic 1 e/412194/t r 10- so ft wa re- d efi n ed -ne t work i ng/, 2009.
5. N. Gude. T. Koponen. J. Pettit. B. Pfaff. M. Casado, N. McKeown. and S. Shenker, 1LNOX: towards an operating system for networks," Comp. Comm. Rev., 2008.
6. T.J. Bittman, G.J. Weiss. M.A. Margevicius, and P. Dawson, "Magic Quadrant for x86 Server Virtualization Infrastructure," Gartner, Tech. Rep., June 2013.
7. N.M.K. Chowdhury and R. Boutaba, "A survey of network visualization," Computer Networks, vol. 54, no. 5, pp. 862-876, 2010.
8. ONF, "Open F low notifications framework OpenFlow management," October 2013. https://www.opcnnetworking.org/images/storics/ do w n I oads/sdn resou rc es/on f-s pec i ficat ions/open flow - co n fig/o f-notificationsframework-l.O.pdf
9. W. Stallings, "Software-defined networks and OpenFlow," The Internet Protocol Journal, vol. 16, no. 1,2013.
w
Y
COMPUTER SCIENCE
CONTROL PLANE IN SOFTWARE DEFINED NETWORKS
Sergey S. Loginov, Bonch-Bruevich Saint Petersburg State University of Telecommunications, St. Petersburg, Russia, ss7loginov@gmail.com
Abstract
Despite their widespread adoption, modern IP/TCP networks are still hard to build and manage. Software Defined Networks should change the current state of affairs. It will separate the network's control logic from the underlying routers and switches, promoting (logical) centralization of network control, and introducing the ability to program the network. In this paper, brief SDN terminology is presented as well as description of SDN control plane. Firstly, we describe part of the control plane called hypervisor. It allows several virtual machines to coexist in one physical platform. Also we compare several implementations of the technology such as FlowVisor, AutoSlice, FlowN and Network Virtualization Platform (NVP). Then we describe definitions of Network Operation System/Controller. In addition, we discuss differences between centralized and distributed controllers. We give the description of controller functions and Southbound, Eastbound u Westbound API. The main concepts of SDN are dynamically programmable forwarding devices, separation of manage and data layers and obtaining an overview of the network by logically centralized "network brain". Application for network logic are executed over the controller that makes them easy to create and implement in real life networks. By creating a picture for whole network, it is easier to implement network policies. SDN presents significant shift in network development. For example, it makes possible the creation of network-as-a-service cloud computing paradigm and software-defined environments, SDE.
Keywords: SDN, management layer, Network Operation System, Hypervisors, network policies, network application. References
1. Raghavan B., Casado M., Koponen T., Ratnasamy S., Ghodsi A. and Shenker S. (2012). Software-defined internet architecture: Decoupling architecture from infrastructure. Proceedings of the 1 1th ACM Workshop on Hot Topics in Networks, ser. HotNets-XI. New York, NY, USA: ACM, pp. 43-48.
2. Koponen T., Casado M., Gude N., Stribling J., Poutievski L., Zhu M., Ramanathan R., Iwata Y., Inoue H., Hama T. and Shenker S. (2010). Onix: a distributed control platform for large-scale production networks. Proceedings of the 9th USENIX conference on Operating systems design and implementation, ser. OSDI'10. Berkeley, CA, USA: USENIX Association, pp. 1-6.
3. Jain S., Kumar A., Mandal S., Ong J., Poutievski L., Singh A., Venkata S., Wanderer J., Zhou J., Zhu M., Zolla J., Holzle U., Stuart S. and Vahdat A. (2013). B4: experience with a globally-deployed software defined wan. Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, ser. SIGCOMM '13. New York, NY, USA: ACM, pp. 3-14.
4. Greene K. (2009). MIT Tech Review 10 Breakthrough Technologies: Software-defined Networking. http://www2.technologyreview.com/ article/4l2l94/trl0-software-defined-networking/, 2009.
5. Gude N., Koponen T., Pettit J., Pfaff B., Casado M., McKeown N. and Shenker S. (2008). NOX: towards an operating system for networks. Comp. Comm. Rev., 2008.
6. Bittman T. J., Weiss G. J., Margevicius M. A. and Dawson P. (2013). Magic Quadrant for x86 Server Virtualization Infrastructure. Gartner, Tech. Rep.
7. Chowdhury N. M. K. and Boutaba R. (2010). A survey of network virtualization. Computer Networks, vol. 54, no. 5, pp. 862-876.
8. ONF, "OpenFlow notifications framework OpenFlow management," October 2013. https://www.opennetworking.org/images/stories/ downloads/sdnresources/onf-specifications/openflow-config/of-notificationsframework-l.0.pdf
9. Stallings W. (2013). Software-defined networks and OpenFlow. The Internet Protocol Journal, vol. 16, no. 1.
