Интеграция систем адресации Е. 164 и DNS на основе enum

Одной из проблем современной IP-телефонии является сложность установления соеди­нения, когда инициировавший вызов абонент использует обычный телефонный аппарат, подключенный к традиционной телефонной сети, а вызываемый абонент — компьютер или IP-телефон, соединенный с Интернетом или частной IP-сетью. Сложность подобного соединения связана с применением в общедоступных телефонных сетях и Интернете раз­ных схем адресации — системы телефонных номеров на основе международного стандарта Е.164 и системы имен DNS. И если пользователю компьютера или цифрового IP-телефона не составляет труда набрать телефонный номер для вызова абонента, то представить себе набор DNS-имени с помощью обычного аналогового аппарата довольно сложно.

Для преодоления пропасти между этими видами общедоступных услуг необходимо либо выбрать единую схему идентификации абонентов, либо разработать метод трансляции одной схемы в другую. Предложения ENUM (Е.164 NUmber Mapping — отображение адресов стандарта Е.164) рабочей группы IETF решают задачу вторым способом, и пока этот вариант наиболее близок к немедленной реализации. Подход ENUM, описанный в RFC 3761 (ftp://ftp.rfc-editor.org/in-notes/rfc3761.txt), состоит в назначении всем абонентам IP-телефонии, подключенным к Интернету или частной IP-сети, идентификаторов еще одного типа — телефонных номеров стандарта Е.164. Однако на конечных узлах и даже сетях, в которых вызов терминируется, эти телефонные номера не используются — они нужны только для идентификации вызываемого абонента стороной-инициатором, приме­няющей обычный телефон, и маршрутизации вызова в пределах традиционной телефонной сети. Затем телефонные номера преобразуются в имена Интернета с помощью хорошо известной и отлично зарекомендовавшей себя службы — системы доменных имен (DNS). Используемый при этом подход подобен тому, который применяется для решения об­ратной задачи — нахождению имени узла по его IP-адресу. С этой целью предлагается создать новую зону е164.агра, куда будут входить территории, соответствующие цифрам телефонного номера, например, зоны верхнего уровня 1, 7, 33, 44 для номеров, принад­лежащих абонентам Североамериканского региона, России, Франции и Великобритании соответственно. Домен верхнего уровня arpa традиционно отводится для решения обратной задачи — нахождение имени по адресу с помощью зоны in-addr.arpa.

Для преобразования телефонного номера в DNS-имя используется специальный тип за­писи — Naming Athority Pointer (NAPTR). Изначально данная запись предназначалась для перечисления сервисов, которые поддерживает организация, администрирующая данный домен (RFC 2915). Примером такой записи может служить строка sip:Petrov@firma. ru, сообщающая о том, что с абонентом можно связаться, направив ему вызов по протоколу SIP на имя [e-mail]. Очевидно, что такие записи будут находиться только в зонах самого нижнего уровня, где располагается база номеров, которую провайдер получил для обслуживания конечных абонентов. Зоны же верхнего уровня будут содержать только обычные ссылки на серверы имен зон более низкого уровня. Итак, если имени Petrov@firma. ru соответствует телефонный номер [phone], то связанная с этим абонентом запись, возможно, содержится в зоне 8.5.7.5.9.0.7.е164.агра (обратный порядок записи цифр телефон­ного номера согласуется с принятым в DNS правилом расположения старшей части имени справа, а не слева, как в телефонии). Запись может находиться и в зоне 3.8.5.7.5.9.0.7.е164. arpa, если все номера диапазона +7 095 758 Зххх переданы еще более мелкому провайдеру (в предыдущем примере предполагалось, что все номера +7 095 758 хх хх принадлежали одному провайдеру). Деление телефонного номера на зоны производится по цифрам в пол­ном соответствии с административной ответственностью каждой конкретной организации за отображение телефонных номеров на DNS-имена (точнее, на URL-адреса, которые в дополнение к DNS-имени имеют префикс, указывающий на протокол доступа к ресурсу). Чем больше уровней подчиненности провайдеров IP-телефонии, тем больше составных компонентов в имени зоны.

Протокол передачи файлов

До появления службы WWW сетевая файловая служба на основе протокола FTP (File Transfer Protocol — протокол передачи файлов), описанная в спецификации RFC 959, долгое время была самой популярной службой доступа к удаленным данным в Интернете и корпоративных IP-сетях. FTP-серверы и FTP-клиенты имеются практически в каждой ОС, кроме того, для доступа ко все еще популярным FTP-архивам используются FTP-клиенты, встроенные в браузеры.

Протокол FTP позволяет целиком переместить файл с удаленного компьютера на локаль­ный, и наоборот. FTP также поддерживает несколько команд просмотра удаленного ката­лога и перемещения по каталогам удаленной файловой системы. Поэтому FTP особенно удобно использовать для доступа к тем файлам, данные которых нет смысла просматривать удаленно, а гораздо эффективней целиком переместить на клиентский компьютер (напри­мер, файлы исполняемых модулей приложений).

В протокол FTP встроены примитивные средства авторизации удаленных пользователей на основе передачи по сети пароля в открытом виде. Кроме того, поддерживается аноним­ный доступ, не требующий указания имени пользователя и пароля; такой способ доступа часто рассматривается как более безопасный, так как он не подвергает пароли пользова­телей угрозе перехвата.

Основные модули службы FTP

FTP-клиент состоит из трех основных функциональных модулей.

§ User Interface (аналог агента пользователя) — пользовательский интерфейс, прини­мающий от пользователя команды и отображающий состояние FTP-сеанса на экране. Пользовательский интерфейс зависит от программной реализации FTP-клиента. Наряду с традиционными клиентами, работающими в символьном режиме, имеются и графические оболочки, не требующие от пользователя знания символьных команд. Символьные клиенты обычно поддерживают следующий основной набор команд:

o open имя_хоста — открытие сеанса с удаленным сервером;

o bye — завершение сеанса с удаленным хостом и завершение работы утилиты ftp;

o close — завершение сеанса с удаленным хостом, утилита ftp продолжает работать;

o 1s (d i г) — печать содержимого текущего удаленного каталога;

o get имя_файла — копирование удаленного файла на локальный хост;

o put имя_файла — копирование удаленного файла на удаленный сервер.

§ User-PI — интерпретатор команд пользователя. Этот модуль взаимодействует с моду­лем Server-PI FTP-сервера.

§ User-DTP — модуль, осуществляющий передачу данных файла по командам, полу­чаемым от модуля User-PI по протоколу клиент-сервер. Этот модуль взаимодействует с локальной файловой системой клиента.

FTP-сервер включает два модуля.

§ Server-PI — модуль, который принимает и интерпретирует команды, передаваемые по сети модулем User-PI.

§ Server-DTP — модуль, управляющий передачей данных файла по командам от модуля Server-PI. Взаимодействует с локальной файловой системой сервера.