Маршрутизатор индивидуальной точки доступа к сети для соединения провайдеров интернет-маршрутов
Формула / Реферат
1. Способ симметричной маршрутизации пакетов между индивидуальными точками доступа к сети (ИТДС) и, по крайней мере, двумя провайдерами, включающий в себя следующие шаги:
а) создание файлов конфигурации маршрутизатора, использующих значения локальных приоритетов для того, чтобы ИТДС маршрутизировала трафик на пользователей провайдеров ИТДС по сетям этих провайдеров и маршрутизировала по сетям предварительно выбранных провайдеров трафик на пользователей, не подключенных к ИТДС, или пользователей провайдеров, подключенных к более чем трем провайдерам ИТДС, а также использующих длину маршрута ИТДС для маршрутизации трафика пользователей провайдеров, не подключенных к ИТДС, по сетям предварительно выбранного провайдера ИТДС;
б) задание значений локальных приоритетов провайдера ИТДС для того, чтобы провайдер ИТДС выбирал маршрутизацию трафика непосредственно на ИТДС;
в) загрузка файлов конфигурации в маршрутизатор;
г) инструктирование маршрутизатора на получение маршрутов от провайдера ИТДС;
д) инструктирование маршрутизатора на применение указанных файлов конфигурации для провайдеров к их маршрутам.
2. Способ симметричной маршрутизации пакетов по протоколу управления передачей/межсетевому протоколу (ПУП/МП) между ИТДС и любым получателем сети Интернет таким образом, что если получатель подключен к любому из провайдеров ИТДС, то прямой и обратный маршруты пакетов будут проходить через данного провайдера, а во всех остальных случаях прямой и обратный маршруты будут проходить через предварительно выбранного провайдера, включающий в себя следующие шаги:
а) создание файлов конфигурации маршрутизатора, использующих значения локальных приоритетов для того, чтобы ИТДС маршрутизировала трафик на пользователей провайдеров ИТДС по сетям этих провайдеров и маршрутизировала по сетям предварительно выбранных провайдеров трафик на пользователей, не подключенных к ИТДС, или пользователей провайдеров, подключенных к более чем трем провайдерам ИТДС, а также использующих длину маршрута ИТДС для маршрутизации трафика пользователей провайдеров, не подключенных к ИТДС, по сетям предварительно выбранного провайдера ИТДС;
б) задание значений локальных приоритетов провайдера ИТДС для того, чтобы провайдер ИТДС выбирал маршрутизацию трафика непосредственно на ИТДС;
в) загрузка файлов конфигурации в маршрутизатор;
г) инструктирование маршрутизатора на получение маршрутов от провайдера ИТДС;
д) инструктирование маршрутизатора на применение указанных файлов конфигурации для провайдеров к их маршрутам.
3. Способ обеспечения того, чтобы маршрутизация пакетов ПУП/МП между ИТДС и любым получателем в Интернет-пространстве осуществлялась симметрично через провайдера указанного получателя, если ИТДС подключена к указанному провайдеру, а во всех остальных случаях через предварительно выбранного провайдера, включающий в себя следующие шаги:
а) создание файлов конфигурации маршрутизатора, использующих значения локальных приоритетов для того, чтобы ИТДС маршрутизировала трафик на пользователей провайдеров ИТДС по сетям этих провайдеров и маршрутизировала по сетям предварительно выбранных провайдеров трафик на пользователей, не подключенных к ИТДС, или пользователей провайдеров, подключенных к более чем трем провайдерам ИТДС, а также использующих длину маршрута ИТДС для маршрутизации трафика пользователей провайдеров, не подключенных к ИТДС, по сетям предварительно выбранного провайдера ИТДС;
б) задание значений локальных приоритетов провайдера ИТДС для того, чтобы провайдер ИТДС выбирал маршрутизацию трафика непосредственно на ИТДС;
в) загрузка файлов конфигурации в маршрутизатор;
г) инструктирование маршрутизатора на получение маршрутов от провайдера ИТДС;
д) инструктирование маршрутизатора на применение указанных файлов конфигурации для провайдеров к их маршрутам.
4. Способ обеспечения того, чтобы маршрутизация пакетов ПУП/МП между ИТДС и любым получателем в Интернет-пространстве осуществлялась симметрично через провайдера ИТДС указанного получателя, если ИТДС подключена к указанному провайдеру, а во всех остальных случаях через предварительно выбранного провайдера ИТДС, включающий в себя следующие шаги:
а) выбор значения аттрибута ЛОКАЛ ПРЕФ предпочтения локальных провайдеров для маршрутизации провайдера по умолчанию таким образом, что для получателей, не подключенных к провайдеру ИТДС, выбирается наиболее предпочтительный провайдер, а если этот провайдер недоступен, то выбирается следующий за ним по приоритету и так далее по всему списку провайдеров;
б) создание файлов конфигурации маршрутизатора, использующих значения локальных приоритетов для того, чтобы ИТДС маршрутизировала трафик на пользователей провайдеров ИТДС по сетям этих провайдеров и маршрутизировала по сетям предварительно выбранных провайдеров трафик на пользователей, не подключенных к ИТДС, или пользователей провайдеров, подключенных к более чем трем провайдерам ИТДС, а также использующих длину маршрута ИТДС для маршрутизации трафика пользователей провайдеров, не подключенных к ИТДС, по сетям предварительно выбранного провайдера ИТДС;
в) задание значений локальных приоритетов провайдера ИТДС для того, чтобы провайдер ИТДС выбирал маршрутизацию трафика непосредственно на ИТДС;
г) загрузка файлов конфигурации в маршрутизатор;
д) инструктирование маршрутизатора на получение маршрутов от провайдера ИТДС;
е) инструктирование маршрутизатора на применение указанных файлов конфигурации для провайдеров к их маршрутам.
5. Система ИТДС, включающая:
а) устройство управления маршрутизацией пакетов;
б) частного пользователя ИТДС, подключенного к одной стороне указанного устройства управления маршрутизацией пакетов;
в) множество провайдеров сетевых услуг, подключенных ко второй стороне указанного устройства управления маршрутизацией пакетов, причем указанное устройство управления маршрутизацией пакетов направляет пакеты данных, посланные указанными частными пользователями ИТДС, на первую сторону указанного устройства управления маршрутизацией пакетов и маршрутизирует их напрямую на одного выбранного провайдера из указанного множества провайдеров сетевых услуг, указанный выбранный провайдер сетевых услуг обслуживает сеть, с которой частный пользователь ИТДС желает установить связь, а устройство управления маршрутизацией пакетов направляет пакет данных, пришедший в ответ от сети адресата, обратно на отправителя, являющегося частным пользователем ИТДС, в точности по тому же маршруту, что обеспечивает симметричную маршрутизацию.
6. Система ИТДС по п.5, отличающаяся тем, что указанные провайдеры сетевых услуг имеют такие значения локальных приоритетов, чтобы указанные провайдеры сетевых услуг осуществляли прямую маршрутизацию с помощью указанного устройства управления маршрутизацией пакетов для того, чтобы ответные пакеты данных маршрутизировались в точности по тем же маршрутам, что и пакеты, идущие от отправителя по прямым маршрутам.
7. Способ осуществления связи с использованием системы ИТДС, включающий:
а) направление пакетов, отправленных частным пользователем ИТДС, на устройство управления маршрутизацией пакетов;
б) маршрутизацию пакетов непосредственно на провайдера, в сетях которого находится получатель;
в) маршрутизацию ответного пакета от указанной сети получателя назад на частного пользователя ИТДС в точности по такому же маршруту.
8. Способ по п.7, отличающийся тем, что он дополнительно включает:
г) задание значений локальных приоритетов провайдера таким образом, чтобы провайдер выбирал прямую маршрутизацию назад на устройство управления маршрутизацией пакетов.
9. Устройство управления маршрутизацией пакетов, включающее:
а) средства направления пакетов, отправленных частным пользователем ИТДС, на устройство управления маршрутизацией пакетов;
б) средства маршрутизации входящих пакетов непосредственно на провайдера, в сетях которого находится получатель;
в) средства маршрутизации ответного пакета от указанной сети получателя назад на частнюую пользователя ИТДС в точности по такому же маршруту.
10. Устройство управления маршрутизацией пакетов по п.9, отличающееся тем, что оно дополнительно включает:
г) средства задания значений локальных приоритетов провайдера таким образом, чтобы провайдер выбирал прямую маршрутизацию назад на устройство управления маршрутизацией пакетов.
11. Способ осуществления симметричной маршрутизации пакетов информации по выбранным прямым и обратным маршрутам в общей сети, включающей множество сетей передачи данных, причем указанная общая сеть включает общественные ТДС и ИТДС, указанное множество сетей передачи данных включает провайдеров, не подключенных к ИТДС, и провайдеров ИТДС, и каждая из указанных сетей передачи данных имеет ассоциированные с ней номера АС, причем данный способ включает
создание списка всех номеров АС провайдеров данной ИТДС;
создание списка номеров АС, имеющих пиринговые отношения на общественных ТДС, но не являющихся номерами АС, связанными с указанными провайдерами ИТДС;
создание для каждого провайдера общего массива всех номеров АС провайдеров и всех номеров АС, подключенных к общественной ТДС, и удаление из него номеров АС, подключенных к текущему провайдеру;
задание значений локальных приоритетов провайдеров ИТДС таким образом, чтобы провайдеры ИТДС выбирали прямую маршрутизацию на ИТДС;
загрузку файлов конфигурации в маршрутизаторы, связанные с каждым провайдером ИТДС; и
инструктирование маршрутизатора на применение файлов конфигурации соответствующего провайдера ИТДС к номерам АС, полученным от каждого провайдера.
12. Устройство для осуществления симметричной маршрутизации пакетов информации по выбранным прямым и обратным маршрутам в общей сети, включающей множество сетей передачи данных, причем указанная общая сеть включает общественные ТДС и ИТДС, указанное множество сетей передачи данных включает провайдеров, не подключенных к ИТДС, и провайдеров ИТДС, и каждая из указанных сетей передачи данных имеет ассоциированные с ней номера АС, причем данное устройство включает
средства создания списка всех номеров АС провайдеров данной ИТДС;
средства создания списка номеров АС, имеющих пиринговые отношения на общественных ТДС, но не являющихся номерами АС, связанными с указанными провайдерами ИТДС;
средства создания общего массива всех номеров АС провайдеров и всех номеров АС, подключенных к общественной ТДС, и удаления из него номеров АС, подключенных к текущему провайдеру;
средства модификации указанного списка АС для текущего провайдера;
средства задания значений локальных приоритетов провайдеров ИТДС таким образом, чтобы провайдеры ИТДС осуществляли прямую маршрутизацию на ИТДС;
средства загрузки файлов конфигурации в маршрутизаторы, связанные с каждым провайдером ИТДС;
средства инструктирования маршрутизатора на применение файлов конфигурации провайдера ИТДС к номерам АС, полученным от данного провайдера.
13. Способ осуществления симметричной маршрутизации пакетов данных по выбранным прямому и обратному маршрутам в общей сети, включающей множество сетей передачи данных, причем указанная общая сеть включает общественные ТДС и индивидуальные ТДС (ИТДС), указанное множество сетей передачи данных разделено на две группы, первая из которых состоит из провайдеров, не подключенных к ИТДС, а вторая состоит из провайдеров ИТДС, каждая из указанных сетей передачи данных имеет один или более номер АС, связанный с ними, причем указанный способ включает следующие шаги:
создание списка всех номеров АС провайдеров ИТДС;
создание списка номеров АС, имеющих пиринговые отношения на общественных ИТДС, но не являющихся одной из АС, связанных с указанными провайдерами ИТДС;
создание для каждого провайдера общего массива всех номеров АС провайдеров и всех номеров АС, подключенных к общественной ТДС, и удаление из него номеров АС, подключенных к текущему провайдеру;
маркировку всех номеров АС, не соответствующих списку отрицаний, тэгами значений первичного приоритета, связанными с провайдером;
маркировку всех номеров АС, соответствующих списку отрицаний, тэгами значений вторичного приоритета, связанными с провайдером;
использование значений первичного приоритета для инструктирования маршрутизатора на маршрутизацию трафика на получателей в сетях провайдеров ИТДС через сети этих провайдеров;
использование значений вторичного приоритета для инструктирования маршрутизатора на маршрутизацию трафика на получателей за пределами сетей провайдеров ИТДС через сети предварительно выбранного провайдера ИТДС;
изменение длин маршрутов АС, заявляемых ИТДС всем провайдерам ИТДС, для того, чтобы провайдеры, не подключенные непосредственно к ИТДС, использовали того же предварительно выбранного провайдера ИТДС, через которого ИТДС посылает трафик на указанных провайдеров;
задание значений локальных приоритетов провайдеров ИТДС таким образом, чтобы провайдеры ИТДС осуществляли прямую маршрутизацию на ИТДС;
загрузку файлов конфигурации в маршрутизаторы, связанные с каждым провайдером ИТДС;
инструктирование маршрутизатора на применение файлов конфигурации провайдера ИТДС к номерам АС, полученным от данного провайдера.
14. Система ИТДС, включающая:
а) устройство управления маршрутизацией пакетов;
б) частного пользователя ИТДС, подключенного к первой стороне указанного устройства управления маршрутизацией пакетов;
в) множество провайдеров сетевых услуг ИТДС, напрямую подключенных ко второй стороне указанного устройства управления маршрутизацией пакетов;
г) по крайней мере, одного провайдера сетевых услуг, не подключенного к ИТДС и не подключенного напрямую к указанному устройству управления маршрутизацией пакетов, причем указанное устройство управления маршрутизацией пакетов направляет пакеты, посланные указанным частным пользователем ИТДС, на первую сторону указанного устройства управления маршрутизацией пакетов, указанное устройство управления маршрутизацией пакетов маршрутизирует пакеты данных, отправленные на получателя, подключенного к сетям указанных провайдеров сетевых услуг, не подключенных к ИТДС, на заранее выбранного провайдера сетевых услуг из указанного множества провайдеров сетевых услуг, указанный выбранный провайдер сетевых услуг из указанного множества провайдеров сетевых услуг включает маршрут на сеть получателя, не подключенную к ИТДС, с которой частный пользователь ИТДС желает установить связь, а устройство управления маршрутизацией пакетов направляет ответный пакет, посланный с получателя, на частного пользователя ИТДС в точности по тому же маршруту, обеспечивая тем самым симметричную маршрутизацию.
15. Система ИТДС по п.14, отличающаяся тем, что указанное множество провайдеров сетевых услуг ИТДС имеют такие значения локальных приоритетов, что указанные провайдеры сетевых услуг ИТДС выбирают прямую маршрутизацию на указанное устройство управления маршрутизацией пакетов для того, чтобы ответные пакеты данных маршрутизировались в точности по такому же маршруту, что и пакет, полученный по прямому маршруту.
16. Способ осуществления связи с использованием системы ИТДС, включающий:
а) направление пакетов, посланных частным пользователем ИТДС, на устройство управления маршрутизацией пакетов;
б) маршрутизацию входящих пакетов, адресованных на получателя, находящегося в сети провайдера сетевых услуг, не подключенного к ИТДС, на предварительно выбранного провайдера из множества провайдеров сетевых услуг ИТДС, который включает маршрут на получателя, не подключенного напрямую к ИТДС;
в) направление ответного пакета, посланного от получателя, обратно на частного пользователя ИТДС в точности по тому же маршруту.
17. Способ по п.16, отличающийся тем, что он также включает:
г) задание значений локальных приоритетов провайдеров сетевых услуг ИТДС таким образом, чтобы провайдеры сетевых услуг ИТДС выбирали прямую маршрутизацию обратно на устройство управления маршрутизацией пакетов.
18. Устройство управления маршрутизацией пакетов, включающее:
а) средсттр направления пакетов, посланных частным пользователем ИТДС, на устройство управления маршрутизацией пакетов;
б) средства маршрутизации входящих пакетов, адресованных на получателя, находящегося в сети провайдера сетевых услуг, не подключенного к ИТДС, на предварительно выбранного провайдера из множества провайдеров сетевых услуг ИТДС, который включает маршрут на получателя, не подключенного напрямую к ИТДС;
в) средства направления ответного пакета, посланного от получателя, обратно на частного пользователя ИТДС в точности по тому же маршруту.
19. Устройство управления маршрутизацией пакетов по п.18, отличающееся тем, что оно дополнительно включает следующий элемент:
г) средства задания значений локальных приоритетов провайдеров сетевых услуг ИТДС таким образом, чтобы провайдеры сетевых услуг ИТДС выбирали прямую маршрутизацию обратно на устройство управления маршрутизацией пакетов.
20. Устройство, включающее ИТДС, провайдера, имеющего соединение с указанной ИТДС, причем указанный провайдер обслуживает сети, в пределах которых находится получатель, причем данное устройство симметрично маршрутизирует пакеты данных от/на получателя в пределах сетей провайдера через соединения указанного провайдера с ИТДС.
21. Способ симметричной маршрутизации пакетов данных от/на получателя в пределах сетей провайдера ИТДС через соединения указанного провайдера с ИТДС, включающий шаги загрузки файлов конфигурации в маршрутизаторы, связанные с сетями провайдеров ИТДС, и инструктирования маршрутизаторов применять эти файлы конфигурации к маршрутам, полученным от каждого провайдера.
22. Устройство, включающее ИТДС, провайдера, имеющего соединение с указанной ИТДС, провайдера, не подключенного к указанной ИТДС, причем указанные провайдеры обслуживают собственные сети, в пределах сети провайдера, не подключенного к ИТДС, находится получатель, причем данное устройство симметрично маршрутизирует пакеты данных от/на получателя в пределах сетей провайдера, не подключенного к ИТДС, через соединения выбранного провайдера ИТДС с ИТДС.
23. Способ осуществления симметричной маршрутизации от и на получателей в сетях провайдеров, не подключенных к ИТДС, через выбранного провайдера ИТДС и его соединение с ИТДС, причем указанный способ включает в себя шаги загрузки файлов конфигурации в маршрутизаторы, связанные с сетями провайдеров ИТДС, и инструктирования маршрутизаторов применить файлы конфигурации к маршрутам, полученным от каждого из провайдеров.
24. Устройство, включающее ИТДС, причем первый и второй провайдеры подключены к указанной ИТДС, указанные первый и второй провайдеры обслуживают собственные сети, указанные сети провайдеров содержат получателя трафика, причем указанное устройство служит для симметричной маршрутизации от и на получателей в пределах сетей первого провайдера ИТДС через соединение второго провайдера ИТДС, в случае, если соединение первого провайдера в данный момент отсутствует.
25. Способ осуществления симметричной маршрутизации от и на получателей в сетях провайдеров ИТДС через наилучшее соединение провайдера ИТДС в случае, если соединение провайдера, в сетях которого находится получатель, в данный момент отсутствует.
26. Топология сети, включающая двух или более провайдеров сетевых услуг и одного или более пользователей и используемая для осуществления обмена пакетами данных от/на получателя на/от провайдеров симметричным образом.
27. Топология сети, включающая двух или более провайдеров сетевых услуг и одного или более пользователей и используемая исключительно для осуществления симметричного обмена пакетами данных между пользователем и провайдером сетевых услуг.
28. Топология сети по п.27, отличающаяся тем, что сетевые услуги предоставляются для осуществления симметричного обмена пакетами данных между частным пользователем и провайдером сетевых услуг.
29. Устройство управления маршрутизацией пакетов, служащее для осуществления симметричной маршрутизации пакетов данных, включающее:
а) средства определения политики симметричной маршрутизации на ИТДС;
б) средства создания и обслуживания конфигураций маршрутизаторов в соответствии с указанной политикой маршрутизации;
в) средства инструктирования провайдеров ИТДС задавать свои значения приоритетов таким образом, чтобы предпочтение отдавалось их соединению с ИТДС через их подключения;
г) средства инструктирования других провайдеров отдавать предпочтение их соединению с ИТДС в соответствии с указанной политикой симметричной маршрутизации.
30. Способ управления маршрутизацией пакетов, служащий для осуществления симметричной маршрутизации пакетов данных, включающий:
а) определение политики симметричной маршрутизации на ИТДС;
б) создание и обслуживание конфигураций маршрутизаторов в соответствии с указанной политикой маршрутизации;
в) инструктирование провайдеров ИТДС задавать свои значения приоритетов таким образом, чтобы предпочтение отдавалось их соединению с ИТДС через их подключения;
г) инструктирование других провайдеров отдавать предпочтение их соединению с ИТДС в соответствии с указанной политикой симметричной маршрутизации.
31. Устройство для управления маршрутизацией пакетов для осуществления симметричной маршрутизации пакетов, включающее:
а) средства определения порядка ЛОКАЛ ПРЕФ, который должен быть использован в случае, если сеть получателя не подключена к провайдеру ИТДС или сеть получателя в данный момент недоступна через своего провайдера ИТДС или подключена к нескольким провайдерам;
б) средства определения того, какие АС напрямую связаны с каждым провайдером ИТДС, и сохранения номеров этих АС в базе данных АС провайдера;
в) средства определения того, какие АС имеют пиринговые отношения на общественной ИТДС, и сохранения номеров этих АС в базе данных АС провайдера;
г) средства определения номеров АС других провайдеров, посланных пользователем системе, и сохранения номеров этих АС в базе данных АС провайдера;
д) средства проверки трафика от ИТДС на провайдеров ИТДС и обновления баз данных;
е) средства проверки трафика, идущего от провайдеров ИТДС на ИТДС, и генерации соответствующих уведомлений;
ж) средства создания файлов базовой конфигурации маршрутизаторов;
з) средства добавления таких команд конфигурации ЛОКАЛ ПРЕФ в указанные файлы базовой конфигурации маршрутизатора, чтобы пакеты, посланные от ИТДС на получателя в пределах сетей провайдеров ИТДС, проходили через соединение данного провайдера с ИТДС;
и) средства добавления таких команд конфигурации ЛОКАЛ ПРЕФ в указанные файлы базовой конфигурации маршрутизатора, чтобы пакеты, посланные от ИТДС на получателя за пределами сетей провайдеров ИТДС, проходили через соединение провайдера ИТДС, имеющего наиболее высокий приоритет;
к) вычислительные средства для определения необходимых добавлений длин маршрутов (идентификатор АС ПАСС) к маршрутам, посылаемым от ИТДС каждому провайдеру ИТДС, и хранения этих добавлений в базе данных АС ПАСС (УВ) провайдера;
л) средства добавления команд конфигурации АС ПАСС (УВ) в указанные файлы базовой конфигурации маршрутизатора с использованием указанной базы данных АС ПАСС (УВ);
м) средства достижения того, чтобы другие провайдеры выбирали связь с ИТДС через сеть приоритетного провайдера ИТДС;
н) средства загрузки указанных конфигурационных файлов конфигурации в маршрутизаторы, соединенные с каждым провайдером ИТДС;
о) средства инструктирования каждого маршрутизатора на получение полных маршрутов от каждого провайдера;
п) средства инструктирования каждого маршрутизатора на применение указанных конфигураций маршрутизатора к указанным полным маршрутам.
32. Способ управления маршрутизацией пакетов для осуществления симметричной маршрутизации пакетов, включающий:
а) определение порядка ЛОКАЛ ПРЕФ провайдеров, который должен быть использован в случае, если сеть получателя не подключена к провайдеру ИТДС или сеть получателя в данный момент недоступна через своего провайдера ИТДС или подключена к нескольъшь провайдерам;
б) определение того, какие АС напрямую связаны с каждым провайдером ИТДС, и сохранение номеров этих АС в базе данных АС провайдера;
в) определение того, какие АС имеют пиринговые отношения на общественной ИТДС, и сохранение номеров этих АС в базе данных АС провайдера;
г) определение номеров АС других провайдеров, посланных пользователем системе, и сохранение номеров этих АС в базе данных АС провайдера;
д) проверку трафика от ИТДС на провайдеров ИТДС и обновления баз данных;
е) проверку трафика от провайдеров ИТДС на ИТДС и генерации соответствующих уведомлений;
ж) создание файлов базовой конфигурации маршрутизаторов;
з) добавление таких команд конфигурации ЛОКАЛ ПРЕФ в указанные файлы базовой конфигурации маршрутизатора, чтобы пакеты, посланные от ИТДС на получателя в пределах сетей провайдеров ИТДС, проходили через соединение данного провайдера с ИТДС;
и) добавление таких команд конфигурации ЛОКАЛ ПРЕФ в указанные файлы базовой конфигурации маршрутизатора, чтобы пакеты, посланные от ИТДС на получателя за пределами сетей провайдеров ИТДС, проходили через соединение провайдера ИТДС, имеющего наиболее высокий приоритет;
к) определение необходимых добавлений АС ПАСС к маршрутам, посылаемым от ИТДС каждому провайдеру ИТДС, и хранение этих добавлений в базе данных АС ПАСС (УВ) провайдера;
л) добавление команд конфигурации АС ПАСС (УВ) в указанные файлы базовой конфигурации маршрутизатора с использованием указанной базы данных АС ПАСС (УВ);
м) инструктирование других провайдеров выбирать связь с ИТДС через сеть приоритетного провайдера ИТДС;
н) загрузку указанных конфигурационных файлов конфигурации в маршрутизаторы, соединенные с каждым провайдером ИТДС;
о) инструктирование каждого маршрутизатора на получение полных маршрутов от каждого провайдера;
п) инструктирование каждого маршрутизатора на применение указанных конфигураций маршрутизатора к указанным полным маршрутам.
33. Устройство для определения порядка значений ЛОКАЛ ПРЕФ провайдеров ИТДС в случае, если сеть получателя не подключена к провайдеру ИТДС или сеть получателя в данный момент недоступна через своего провайдера ИТДС или подключена к нескольким провайдерам, включающее следующие шаги:
а) средства создания первого набора (первичных) значений ЛОКАЛ ПРЕФ, расположенных в порядке убывания, по одному для каждого из провайдеров ИТДС, таким образом, чтобы наибольшее значение ЛОКАЛ ПРЕФ соответствовало провайдеру с наивысшим приоритетом;
б) средства создания второго набора значений ЛОКАЛ ПРЕФ по одному для каждого из провайдеров ИТДС, расположенных в том же порядке убывания, таким образом, чтобы наибольшее значение ЛОКАЛ ПРЕФ из второго набора было меньше наименьшего значения ЛОКАЛ ПРЕФ из первого набора.
34. Способ определения порядка значений ЛОКАЛ ПРЕФ провайдеров ИТДС в случае, если сеть получателя не подключена к провайдеру ИТДС или сеть получателя в данный момент недоступна через своего провайдера ИТДС или подключена к нескольким провайдерам, включающий следующие шаги:
а) создание первого набора (первичных) значений ЛОКАЛ ПРЕФ, расположенных в порядке убывания, по одному для каждого из провайдеров ИТДС, таким образом, чтобы наибольшее значение ЛОКАЛ ПРЕФ соответствовало провайдеру с наивысшим приоритетом;
б) создание второго набора (вторичных) значений ЛОКАЛ ПРЕФ по одному для каждого из провайдеров ИТДС таким образом, чтобы наибольшее значение ЛОКАЛ ПРЕФ из второго набора было меньше наименьшего значения ЛОКАЛ ПРЕФ из первого набора.
35. Устройство для определения тех АС, которые напрямую связаны с каждым из провайдеров ИТДС, включающее:
а) средства инициализации базы данных АС провайдера в виде пар <АС, провайдер> на основе номеров АС, напрямую подключенных к каждому провайдеру;
б) средства загрузки существующей базы данных АС провайдера в виде пар <АС, провайдер>;
в) средства поиска по всем АС с использованием механизма ИНФУДАС, определяющего, продолжает ли данная АС соответствовать данному провайдеру;
г) средства удаления всех АС из базы данных АС провайдера, которые были определены как более не соответствующие их провайдеру;
д) средства загрузки и обработки полной базы данных маршрутов каждого провайдера в виде списка атрибутов АС ПАСС каждого маршрута;
е) вычислительные средства, использующие указанный список значений АС ПАСС для определения дополнительных номеров АС, связанных с каждым провайдером ИТДС, и сохраняющие пары <АС, провайдер> в базе данных АС провайдера;
ж) вычислительные средства, использующие указанные списки АС ПАСС для определения номеров АС, связанных с другими провайдерами, представленными пользователем, и сохраняющие пары <АС, провайдер> в базе данных АС провайдера.
36. Способ определения тех АС, которые напрямую связаны с каждым из провайдеров ИТДС, включающий:
а) инициализацию базы данных АС провайдера в виде пар <АС, провайдер> на основе номеров АС, напрямую подключенных к каждому провайдеру;
б) загрузку существующей базы данных АС провайдера в виде пар <АС, провайдер>;
в) поиск по всем АС с использованием механизма получения информации об удаленной АС (ИНФУДАС), определяющего, продолжает ли данная АС соответствовать данному провайдеру;
г) удаление всех АС из базы данных АС провайдера, которые были определены как более не соответствующие их провайдеру;
д) загрузку и обработку полной базы данных маршрутов каждого провайдера в виде списка значений АС ПАСС каждого маршрута;
е) использование указанного списка значений АС ПАСС для определения дополнительных номеров АС, связанных с каждым провайдером ИТДС, и сохранение пар <АС, провайдер> в базе данных АС провайдера;
ж) использование указанных списков значений АС ПАСС для определения номеров АС, связанных с другими провайдерами, представленными пользователем, и сохранение пар <АС, провайдер> в базе данных АС провайдера.
37. Устройство для использования списка маршрутов АС ПАСС для определения дополнительных номеров АС, связанных с каждым провайдером ИТДС и тех номеров АС, которые связаны с провайдерами, представленными данным пользователем, включающее:
а) средства движения слева направо по маршруту в пределах АС ПАСС для каждой АС;
б) средства определения того, является ли данная АС первой на маршруте и, если это так, поиск данной АС в базе данных АС провайдера с целью определения провайдера, заявляющего данный маршрут АС ПАСС, и сохранение параметров данного провайдера для последующего добавления в базу данных АС провайдера;
в) средства использования программы ИНФУДАС для поиска информации по АС для любого последующего номера АС;
г) средства определения того, соответствует ли информация по АС тому провайдеру, который заявляет данный АС ПАСС, и, если это так, добавления данной пары <АС, провайдер> в базе данных АС;
д) средства остановки программы при достижении такой АС, информация о которой не соответствует тому провайдеру, который заявляет данный АС ПАСС;
е) средства определения того, соответствует ли информация по АС провайдеру, представленному данным пользователем, и, если это так, добавления данной пары <АС, провайдер, представленный пользователем> в базе данных АС в конце программы;
ж) средства увеличения счетчика тех номеров АС, информация о которых не соответствует провайдеру, который заявляет данный АС ПАСС, или провайдеру, представленному данным пользователем.
38. Способ использования списка маршрутов АС ПАСС для определения дополнительных номеров АС, связанных с каждым провайдером ИТДС, и тех номеров АС, которые связаны с провайдерами, представленными данным пользователем, включающий:
а) движение слева направо по маршруту в пределах АС ПАСС для каждой АС;
б) определение того, является ли данная АС первой на маршруте и, если это так, поиск данной АС в базе данных АС провайдера с целью определения провайдера, заявляющего данный маршрут АС ПАСС, и сохранение параметров данного провайдера фыя последующего добавления в базу данных АС провайдера;
в) использование программы ИНФУДАС для поиска информации по АС для любого последующего номера АС;
г) определение того, соответствует ли информация по АС тому провайдеру, который заявляет данный АС ПАСС, и, если это так, добавления данной пары <АС, провайдер> в базу данных АС;
д) остановку программы при достижении такой АС, информация о которой не соответствует тому провайдеру, который заявляет данный АС ПАСС;
е) определение того, соответствует ли информация по АС провайдеру, представленному данным пользователем, и, если это так, добавления данной пары <АС, провайдер, представленный пользователем> в базу данных АС в конце программы;
ж) увеличение счетчика тех номеров АС, информация о которых не соответствует провайдеру, который заявляет данный АС ПАСС, или провайдеру, представленному данным пользователем.
39. Устройство для использования списка маршрутов АС ПАСС для определения дополнительных номеров АС, связанных с каждым провайдером ИТДС, и тех номеров АС, которые связаны с провайдерами, представленными данным пользователем, включающее:
а) средства определения первой АС в маршруте при поиске АС в базе данных АС провайдера с целью определения провайдера, заявляющего данный маршрут АС ПАСС, и сохранения параметров этого провайдера для последующего добавления в базу данных АС провайдера;
б) средства просмотра маршрута справа налево для каждой АС в данном маршруте АС ПАСС;
в) средства использования программы ИНФУДАС для поиска информации по АС для любого последующего номера АС;
г) средства определения того, соответствует ли информация по АС тому провайдеру, который заявляет данный маршрут АС ПАСС, и, если это так, добавления данной пары <АС, провайдер> в базе данных АС;
д) средства остановки программы при достижении окончания АС ПАСС;
е) средства определения того, соответствует ли информация по АС провайдеру, представленному данным пользователем, и, если это так, добавления данной пары <АС, провайдер, представленный пользователем> в базе данных АС в конце программы;
ж) средства увеличения счетчика тех номеров АС, информация о которых не соответствует провайдеру, который заявляет данный АС ПАСС, или провайдеру, представленному данным пользователем.
40. Способ использования списка маршрутов АС ПАСС для определения дополнительных номеров АС, связанных с каждым провайдером ИТДС, и тех номеров АС, которые связаны с провайдерами, представленными данным пользователем, включающий:
а) определение первой АС в маршруте при поиске АС в базе данных АС провайдера с целью определения провайдера, заявляющего данный маршрут АС ПАСС, и сохранения параметров этого провайдера для последующего добавления в базу данных АС провайдера;
б) просмотр маршрута справа налево для каждой АС в данном маршруте АС ПАСС;
в) использование программы ИНФУДАС для поиска информации по АС для любого последующего номера АС;
г) определение того, соответствует ли информация по АС тому провайдеру, который заявляет данный маршрут АС ПАСС, и, если это так, добавление данной пары <АС, провайдер> в базе данных АС;
д) остановку программы при достижении окончания АС ПАСС;
е) определение того, соответствует ли информация по АС провайдеру, представленному данным пользователем, и, если это так, добавления данной пары <АС, провайдер, представленный пользователем> в базе данных АС в конце программы;
ж) увеличение счетчика тех номеров АС, информация о которых не соответствует провайдеру, который заявляет данный АС ПАСС, или провайдеру, представленному данным пользователем.
41. Устройство для определения того, какие АС имеют пиринговые отношения на общественных ИТДС, включающее:
а) средства определения номеров АС, счетчик которых больше 3;
б) средства добавления указанных АС в базу данных исключений АС.
42. Способ определения того, какие АС имеют пиринговые отношения на общественных ИТДС, включающий шаги:
а) определения номеров АС, счетчик которых больше 3;
б) добавления указанных АС в базу данных исключений АС.
43. Устройство для проверки трафика, идущего от ИТДС на провайдеров ИТДС, и обновления баз данных в случае отрицательных результатов проверки, включающее:
а) средства обнаружения сервера отслеживания маршрута (программа СЛЕМ) в пределах каждой сети провайдеров ИТДС;
б) средства для запуска дополнительной версии СЛЕМ (СЛЕМ-Д) для каждого сервера отслеживания маршрута провайдеров ИТДС, в результате чего создается упорядоченный список номеров АС для каждого провайдера ИТДС;
в) средства проверки каждого списка АС, полученного в результате программы СЛЕМ-Д, на предмет наличия в нем более одного провайдера ИТДС, а также проверки того, существует ли связь с такими провайдерами в данный момент;
г) средства просмотра списка АС от АС получателя до АС ИТДС (справа налево) с целью выявления первого из остальных провайдеров ИТДС;
д) средства проверки базы данных исключений АС такой АС, которая является следующей слева (предшествующей) от первого из остальных провайдеров ИТДС в списке, и удаления такой АС из списка, поскольку ее добавление было необоснованным;
е) средства посылки сообщения по электронной почте заинтересованным сторонам в случае, если АС, которая является следующей слева, или предшествующей, от первого из остальных провайдеров ИТДС в списке, существует, но не включена в базу данных исключений АС.
44. Способ проверки трафика от ИТДС на провайдеров ИТДС и обновления баз данных в случае отрицательных результатов проверки, включающий:
а) обнаружение сервера отслеживания маршрута в пределах каждой сети провайдеров ИТДС;
б) запуск программы СЛЕМ-Д для каждого сервера отслеживания маршрута провайдеров ИТДС, в результате чего создается упорядоченный список номеров АС для каждого провайдера ИТДС;
в) проверку каждого списка АС, полученного в результате программы СЛЕМ-Д, на предмет наличия в нем более одного провайдера ИТДС, а также проверку того, действует ли связь таких провайдеров в данный момент;
г) просмотр списка АС от АС получателя до АС ИТДС (справа налево) с целью выявления первого из остальных провайдеров ИТДС;
д) проверку базы данных исключений АС такой АС, которая является следующей слева (предшествующей) от первого из остальных провайдеров ИТДС в списке, и удаления такой АС из списка, поскольку ее добавление было необоснованным;
е) посылку по электронной почте сообщения заинтересованным сторонам в случае, если АС, которая является следующей слева (предшествующей) от первого из остальных провайдеров ИТДС в списке, существует, но не включена в базу данных исключений АС.
45. Устройство для проверки трафика, идущего от провайдеров ИТДС на ИТДС, и генерации соответствующих уведомлений в случае отрицательных результатов проверки, включающее:
а) средства обнаружения сервера отслеживания маршрута в пределах сети каждого из провайдеров ИТДС;
б) средства запуска программы СЛЕМ от каждого сервера обратно до ИТДС и обработки результата данной программы модифицированной программой СЛЕМ-Д, в результате чего создается упорядоченный список номеров АС для каждого провайдера ИТДС;
в) средства проверки каждого списка АС, полученного в результате программы СЛЕМ-Д, на предмет наличия в нем более одного провайдера ИТДС, а также проверки того, существует ли связь с такими провайдерами в данный момент;
г) средства посылки уведомления о каждом отклонении от нормального процесса маршрутизации.
46. Способ проверки трафика, идущего от провайдеров ИТДС на ИТДС, и генерации соответствующих уведомлений в случае отрицательных результатов проверки, включающий:
а) обнаружение сервера отслеживания маршрута в пределах сети каждого из провайдеров ИТДС;
б) запуск программы СЛЕМ от каждого сервера обратно до ИТДС и обработки результата данной программы модифицированной программой СЛЕМ-Д, в результате чего создается упорядоченный список номеров АС для каждого провайдера ИТДС;
т) проверку каждого списка АС, полученного в результате программы СЛЕМ-Д, на предмет наличия в нем более одного провайдера ИТДС, а также проверки того, существует ли связь с такими провайдерами в данный момент;
г) посылку уведомления о каждом отклонении от нормального процесса маршрутизации.
47. Устройство для создания базовых файлов конфигурации маршрутизатора для провайдеров ИТДС, включающее:
а) средства создания команды, описывающей сетевые адреса и номер АС провайдера ИТДС;
б) средства создания команды, описывающей 4-ю версию Протокола маршрутизации Интернет (ПМИ);
в) средства создания команды, описывающей базовый механизм присоединения значений ЛОКАЛ ПРЕФ к маршрутам, полученным от провайдера ИТДС;
г) средства создания команды, описывающей базовый механизм присоединения дополнительных номеров АС к маршрутам ИТДС, посылаемым провайдеру ИТДС.
48. Способ создания базовых файлов конфигурации маршрутизатора для провайдеров ИТДС, включающий:
а) создание команды, описывающей сетевые адреса и номер АС провайдера ИТДС;
б) создание команды, описывающей 4-ю версию ПМИ;
в) создание команды, описывающей базовый механизм присоединения значений ЛОКАЛ ПРЕФ к маршрутам, полученным от провайдера ИТДС;
г) создание команды, описывающей базовый механизм присоединения дополнительных номеров АС к маршрутам ИТДС, посылаемым провайдеру ИТДС.
49. Устройство для добавления команд конфигурации ЛОКАЛ ПРЕФ к базовым файлам конфигурации маршрутизатора таким образом, чтобы пакеты данных, посланные от ИТДС получателю, находящемуся в сети провайдера ИТДС, проходили через соединение этого провайдера с ИТДС, включающее:
а) средства проверки того, создан ли для каждого из провайдеров ИТДС список других провайдеров ИТДС;
б) средства поиска в базе данных АС провайдера номеров АС всех других провайдеров ИТДС и объединения их с номерами АС, содержащимися в базе данных исключений АС;
в) средства создания фильтра, запрещающего получение маршрутов, содержащих каждый из указанных номеров АС, и разрешающего получение всех других маршрутов;
г) средства применения значений ЛОКАЛ ПРЕФ к разрешенным маршрутам, взятым из первичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера;
д) средства создания фильтра, разрешающего все ранее запрещенные маршруты;
е) средства применения указанного значения ЛОКАЛ ПРЕФ к указанным разрешенным маршрутам, взятым из вторичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера.
50. Способ добавления команд конфигурации ЛОКАЛ ПРЕФ к базовым файлам конфигурации маршрутизатора таким образом, чтобы пакеты данных, посланные от ИТДС получателю, находящемуся в сети провайдера ИТДС, проходили через соединение этого провайдера с ИТДС, включающий:
а) проверку того, создан ли для каждого из провайдеров ИТДС список других провайдеров ИТДС;
б) поиск в базе данных АС провайдера номеров АС всех других провайдеров ИТДС и объединения их с номерами АС, содержащимися в базе данных исключений АС;
в) создание фильтра, запрещающего получение маршрутов, содержащих каждый из указанных номеров АС, и разрешающего получение всех других маршрутов;
г) применение значений ЛОКАЛ ПРЕФ к разрешенным маршрутам, взятым из первичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера;
д) создание фильтра, разрешающего все ранее запрещенные маршруты;
е) применение указанного значения ЛОКАЛ ПРЕФ к указанным разрешенным маршрутам, взятым из вторичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера.
51. Устройство для добавления команд конфигурации ЛОКАЛ ПРЕФ в базовые файлы конфигурации маршрутизатора таким образом, чтобы пакеты данных, посланные от ИТДС получателю, находящемуся за пределами сети провайдера ИТДС, проходили через сеть провайдера ИТДС с наивысшим приоритетом, включающее следующие шаги:
а) средства проверки того, создан ли для каждого из провайдеров ИТДС список других провайдеров ИТДС;
б) средства поиска в базе данных АС провайдера номеров АС всех других провайдеров ИТДС и объединения их с номерами АС, содержащимися в базе данных исключений АС;
в) средства создания фильтра, запрещающего получение маршрутов, содержащих каждый из указанных номеров АС, и разрешающего получение всех других маршрутов;
г) средства применения значения ЛОКАЛ ПРЕФ к указанным разрешенным маршрутам, взятым из первичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера;
д) средства создания фильтра, разрешающего все ранее запрещенные маршруты;
е) средства применения указанного значения ЛОКАЛ ПРЕФ к указанным разрешенным маршрутам, взятым из вторичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера.
52. Способ добавления команд конфигурации ЛОКАЛ ПРЕФ в базовые файлы конфигурации маршрутизатора таким образом, чтобы пакеты данных, посланные от ИТДС получателю, находящемуся за пределами сети провайдера ИТДС, проходили через сеть провайдера ИТДС с наивысшим приоритетом, включающий следующие шаги:
а) проверка того, создан ли для каждого из провайдеров ИТДС список других провайдеров ИТДС;
б) поиск в базе данных АС провайдера номеров АС всех других провайдеров ИТДС и объединения их с номерами АС, содержащимися в базе данных исключений АС;
в) создание фильтра, запрещающего получение маршрутов, содержащих каждый из указанных номеров АС, и разрешающего получение всех других маршрутов;
г) применение значения ЛОКАЛ ПРЕФ к указанным разрешенным маршрутам, взятым из первичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера;
д) создание фильтра, разрешающего все ранее запрещенные маршруты;
е) применение указанного значения ЛОКАЛ ПРЕФ к указанным разрешенным маршрутам, взятым из вторичного списка значений ЛОКАЛ ПРЕФ для каждого провайдера.
53. Способ определения АС ПАСС, которые должны быть добавлены к маршрутам, заявляемым ИТДС ее провайдерам и сохранение этих добавлений в базе данных АС ПАСС (УВ) провайдера, включающий следующие шаги:
а) получение от общественной ТДС образца маршрута ИТДС и связанных с ним АС ПАСС для каждого провайдера ИТДС и сохранение длины указанного АС ПАСС в базе данных АС ПАСС (УВ) провайдера;
б) получение длины АС ПАСС (величина ДЛИНА0) для каждого провайдера ИТДС из базы данных АС ПАСС (УВ);
в) получение для каждого другого провайдера ИТДС, длина АС ПАСС которого никогда не была связана с ДЛИНА0, его длины АС ПАСС (величина ДЛИНА1) из базы данных АС ПАСС (УВ);
г) сравнение ДЛИНА0 с ДЛИНА1 и, если ДЛИНА0 больше или равно ДЛИНА1, увеличение ДЛИНА1 на единицу (1) и сохранение нового значения в базе данных АС ПАСС (УВ);
д) продолжение такого сравнения по всем провайдерам ИТДС (ДЛИНА1);
е) продолжение такого сравнения по всем провайдерам ИТДС (ДЛИНА0).
54. Способ добавления команд конфигурации АС ПАСС (УВ) в базовые файлы конфигурации маршрутизатора, включающий:
а) получение для каждого провайдера ИТДС длины АС ПАСС из базы данных АС ПАСС (УВ);
б) создание команды конфигурации маршрутизатора, увеличивающее длину маршрутов, заявляемых каждому провайдеру ИТДС, на величину, полученную из базы данных АС ПАСС (УВ).
55. Способ определения АС ПАСС, которые должны быть добавлены к маршрутам, заявляемым ИТДС ее провайдерам, и сохранение этих добавлений в базе данных АС ПАСС (УВ) провайдера, включающий следующие шаги:
а) получение от общественной ТДС образца маршрута ИТДС и связанных с ним АС ПАСС для каждого провайдера ИТДС и сохранение длины указанного АС ПАСС в базе данных АС ПАСС (УВ) провайдера;
б) получение длины АС ПАСС (ДЛИНА0) для каждого провайдера ИТДС из базы данных АС ПАСС (УВ);
в) получение для каждого другого провайдера ИТДС, длина АС ПАСС которого никогда не была связана с ДЛИНА0, его длины АС ПАСС (ДЛИНА1) из базы данных АС ПАСС (УВ);
г) сравнение ДЛИНА0 с ДЛИНА1 и, если ДЛИНА0 больше или равно ДЛИНА1, увеличение ДЛИНА1 на единицу (1) и сохранение нового значения в базе данных АС ПАСС (УВ);
д) продолжение такого сравнения по всем провайдерам ИТДС (ДЛИНА1);
е) продолжение такюую сравнения по всем провайдерам ИТДС (ДЛИНА0).
56. Устройство для добавления команд конфигурации АС ПАСС (УВ) в базовые файлы конфигурации маршрутизатора, включающее:
а) средства получения для каждого провайдера ИТДС длины АС ПАСС из базы данных АС ПАСС (УВ);
б) средства создания команды конфигурации маршрутизатора, увеличивающие длину маршрутов, заявляемых каждому провайдеру ИТДС, на величину, полученную из базы данных АС ПАСС (УВ).
57. Способ добавления команд конфигурации АС ПАСС (УВ) в базовые файлы конфигурации маршрутизатора, включающий следующие шаги:
а) получения для каждого провайдера ИТДС длины АС ПАСС из базы данных АС ПАСС (УВ);
б) создания команды конфигурации маршрутизатора, увеличивающее длину маршрутов, заявляемых каждому провайдеру ИТДС, на величину, полученную из базы данных АС ПАСС (УВ).
58. Система управления маршрутизацией пакетов, включающая:
а) ИТДС для создания конфигураций маршрутов;
б) провайдера сетевых услуг, соединенного с указанной ИТДС;
в) указанную ИТДС, маршрутизирующую пакеты между пользователем ИТДС и получателем пакета в сетях указанного провайдера через указанное соединение с указанной ИТДС, причем указанная маршрутизация осуществляется симметрично по прямому и обратному маршрутам.
59. Способ управления маршрутизацией пакетов, включающий следующие шаги:
а) создание ИТДС для облегчения конфигураций маршрутов;
б) соединение провайдера сетевых услуг с указанной ИТДС;
в) маршрутизация пакетов между пользователем ИТДС и получателем пакета в сетях указанного провайдера через указанное соединение с указанной ИТДС, причем указанная маршрутизация осуществляется симметрично по прямому и обратному маршрутам.
Текст
1 Область изобретения Настоящее изобретение относится к области маршрутизации на сетевом уровне в сетях,где реализован протокол управления передачей/межсетевой протокол (ПУП/МП; англ.TCP/IP), таких, как Интернет, в частности, к методам симметричной маршрутизации информационных пакетов на выбранных прямых и обратных маршрутах в сети, состоящей из множества сетей передачи трафика. На современной стадии развития Интернет пакеты данных маршрутизируются между отправителями и получателями через множество обширных сетей национального масштаба, операторы которых обычно называются Национальными провайдерами Интернет-услуг (National Service Provider, NSP). NSP - провайдер Интернет-услуг, имеющий сеть национального масштаба со скоростью передачи данных 44,736 Мбит/с или выше и представленный как минимум в пяти общедоступных точках доступа к сети (ТДС). В настоящее время в США существует не менее 15-20 таких сетей национального масштаба, многие из которых принадлежат крупным телефонным компаниям и эксплуатируются ими. Некоторые из общеизвестных Национальных провайдеров - MCI, Sprint, WorldCom/UUNet, ANS, AGIS, Netcom и PSI. До начала широкого коммерческого использования сети Интернет существовал только один Национальный провайдер, а именно Национальный научный фонд США (National Scientific Foundation, NSF), который предоставлял услуги в сети общенационального масштаба,известной под названием NSFNet. Если два конечных пользователя этой сети хотели установить связь друг с другом, то им приходилось подключаться напрямую или опосредованно(через регионального провайдера) к NSFNet. Со временем некоторые из коммерческих провайдеров создали свои собственные сети национального масштаба, которые предоставляли те же услуги, что и NSFNet, но уже коммерческому сектору. Когда NSF решил отказаться отNSFNet и, таким образом, сделать весь Интернет коммерческим, ожидалось, что возникнет еще большее количество коммерческих инфраструктур национального масштаба, которые станут точками связи Интернет для всех конечных пользователей либо напрямую, либо опосредованно (через региональных провайдеров). Два конечных пользователя, подсоединенных к одной и той же сети национального масштаба,могли бы связаться друг с другом через эту сеть,однако, был необходим метод, позволивший бы производить обмен трафиком между различными сетями национального масштаба для того,чтобы конечные пользователи, подключенные к различным сетям, могли также соединяться друг с другом. Данная проблема была решена путем создания точек доступа к сети (ТДС), англ. Network Access Point (NAP). 2 Общедоступная ТДС является общественной инфраструктурой, эксплуатируемой частными структурами (операторами ТДС) и служащей нейтральной точкой, в которой осуществляется обмен пакетным трафиком ПУП/МП между любыми двумя провайдерами, подключенными к ТДС, при условии, что эти провайдеры имеют действующее соглашение об обмене трафиком (так называемое пиринговое соглашение, или соглашение о равноправном информационном обмене). В настоящее время в США существует пять основных ТДС. Две из них расположены в районе побережья СанФранциско, одна в Вашингтоне (штат Колумбия), одна в Нью-Йорке и одна в Чикаго. Оператор ТДС взимает плату за пользование точкой со всех провайдеров, подключенных к ТДС, а пиринговые соглашения между провайдерами формируют стратегию возмещения их издержек за обмен трафиком (если таковые имеются). Несмотря на то, что архитектура ТДС казалась вполне жизнеспособной на момент ее создания, опыт показал, что она не способна идти в ногу с развитием Интернет. Это произошло по нескольким причинам. Во-первых,поскольку протокол маршрутизации Интернет,совместно используемый провайдерами в ТДС(протокол Border Gateway версии 4, или ПМИ 4),не предоставляет возможности автоматического и равномерного распределения трафика между ТДС, большинство мирового обмена трафиком происходит на лишь нескольких из общего числа ТДС, так как провайдеры сами вручную определяют те точки, которые должны быть использованы для передачи трафика. В результате те ТДС, на которые приходится самый значительный трафик, оказываются перегруженными,и пакеты данных, идущие через них, могут прерываться. Следует отметить, что протокол ПУП/МП может успешно восстанавливать прерванные пакеты данных благодаря его системе подтверждений получения данных, но это значительно увеличивает время, необходимое для обмена информацией между двумя конечными пользователями и в конечном итоге создает препятствия в их работе. Во-вторых, отсутствие быстрого технического прогресса в технологиях локальных и городских вычислительных сетейNetwork, LAN/MAN) делает проблему расширения ТДС все более насущной. Асинхронный режим передачи (Asynchronous Transfer Mode,ATM) и его возможности скоростной передачи данных не подходят для трафика ПУП/МП. Технология FDDI (Fiber Distributed Data Interface, или распределенный интерфейс передачи данных по волоконно-оптическим каналам),позволяющая осуществлять передачу данных со скоростью до 100 Мбит/с и являющаяся единственной из существующих стабильной технологией локальных вычислительных сетей (ЛВС),уже недостаточна для оперирования объемами 3 данных в существующей модели. Наконец,вследствие того, что инфраструктуры ТДС управляются операторами ТДС, а места соединения с ТДС контролируются самими провайдерами, существует постоянное несоответствие между пропускной способностью инфраструктуры ТДС и суммарной пропускной способностью линий, подключаемых провайдерами к ТДС, которое приводит к дополнительным потерям данных. Таким образом, существует необходимость обходить ТДС стороной там, где это возможно,путем создания новой модели соединения, которая управляла бы процессом маршрутизации трафика ПУП/МП между ТДС и пользователями. Раскрытие изобретения Настоящее изобретение представляет собой метод обхода трафиком ПУП/МП общедоступных точек доступа в сеть Интернет путем осуществления прямых связей с набором Национальных провайдеров Интернет-услуг и использования соединения провайдера для маршрутизации только тех пакетов данных в протоколе ПУП/МП, которые посланы на или от пользователей данного провайдера. В соответствии с принципами настоящего изобретения предполагается создание индивидуальных точек доступа к сети, или ИТДС(англ. Private Network Access Point, P-NAP). ИТДС - локальная сеть, соединенная с большим количеством Национальных провайдеров и обеспечивающая доступ в сеть Интернет любым другим провайдерам, которым необходим прямой доступ к этим Национальным провайдерам,к их пользователям и ко всей сети Интернет. ИТДС оснащена программным обеспечением, которое осуществляет контроль маршрутизации данных в протоколе ПУП/МП по эвристическому методу, при котором трафик, посланный на Национального провайдера, подключенного к ИТДС, служит, в большинстве случаев, только для осуществления обмена данными в пределах этого Национального провайдера. В свою очередь, трафик, полученный от подключенного Национального провайдера,служит, в большинстве случаев, только для посылки данных на получателя в пределах Национального провайдера, осуществляющего переписку с пользователем ИТДС. Этот метод, известный как симметричная маршрутизация, поскольку прямой и обратный маршруты трафика проходят через одну и ту же сеть Национального провайдера, является основой для обхода ТДС. В большинстве случаев трафик никогда не посылается на Национального провайдера, который будет должен возвратить этот трафик на другого Национального провайдера через ТДС. Верно и обратное: в большинстве случаев Национальные провайдеры не будут посылать трафик, адресованный на ИТДС, на других На 003155 4 циональных провайдеров через ТДС, если у них будет собственная прямая связь с ИТДС. В случае разрыва связи ИТДС с одним из Национальных провайдеров метод контроля маршрутизации, используемый в настоящем изобретении, использует заранее выбранного Национального провайдера (по умолчанию) для маршрутизации трафика на получателей,подключенных к Национальному провайдеру,связь с которым разорвана. Если первичный Национальный провайдер по умолчанию недоступен, трафик будет послан на вторичного провайдера по умолчанию. Если будет недоступен и второй, то трафик будет адресован на третьего и так далее по всем доступным Национальным провайдерам в заранее заданном порядке. Такие Национальные провайдеры по умолчанию также используются (в том же порядке и при тех же условиях) при маршрутизации трафика на получателей, не подключенных ни к одному из Национальных провайдеров, с которыми данная ИТДС имеет связь, что является случаем, аналогичным разрыву связи ИТДС с одним из Национальных провайдеров. Во всех случаях использования провайдеров по умолчанию обход ТДС отсутствует, но трафик, адресованный на или от провайдеров по умолчанию, остается симметричным. Таким образом, ИТДС в соответствии с настоящим изобретением представляет собой метод контроля маршрутизации трафика между пользователями ИТДС и Национальным провайдерами Интернет-услуг без хаотического переключения маршрутов, без асимметричной маршрутизации и с возможностью обхода общедоступных ТДС. Краткое описание изобретения Для более полного понимания настоящего изобретения в заявке использованы ссылки на сопроводительные фигуры в процессе последующего детального описания предпочтительного способа использования изобретения. На фиг. 1 представлена диаграмма, показывающая на очень высоком уровне связь множества Национальных провайдеров Интернетуслуг друг с другом через общедоступные ТДС,а также несимметричную маршрутизацию пакетов данных, которая является результатом такой связи. На фиг. 2 представлена диаграмма, показывающая на очень высоком уровне ИТДС в соответствии с настоящим изобретением, подключенную ко множеству провайдеров и пользователей ИТДС, а также симметричную маршрутизацию пакетов данных, которая является результатом такой связи. На фиг. 3 представлен вид спереди на коммуникационное оборудование, используемое для реализации ИТДС и располагаемое на четырех стойках. На фиг. 4 представлена блок-диаграмма,частично показывающая способ соединения 5 центральных маршрутизаторов для осуществления соединения между ИТДС и Национальными провайдерами во внешней сети Интернет. На фиг. 5 приведена упрощенная блокдиаграмма, показывающая связь серверов пользователей с ИТДС в соответствии с настоящим изобретением по выделенной ЛВС. На фиг. 6 представлена блок-диаграмма,показывающая многочисленные выделенные ЛВС, присоединенные к ИТДС в соответствии с настоящим изобретением. На фиг. 7 представлена блок-диаграмма,показывающая подключение серверов пользователей к ИТДС в соответствии с настоящим изобретением по схеме коллективного доступа. На фиг. 8 представлена блок-диаграмма,показывающая удаленное соединение ИТДС в соответствии с настоящим изобретением через линии Т 1 с серверами пользователей, расположенными на площадях этих пользователей. На фиг. 9 представлена блок-диаграмма,показывающая удаленное соединение ИТДС в соответствии с настоящим изобретением через линии Е 3 с серверами пользователей, расположенными на площадях этих пользователей. На фиг. 10 представлена схематическая диаграмма маршрутизации ИТДС и ее подключений к провайдерам ИТДС с обозначением методов обмена пакетами данных в прямом и обратном направлениях между узлами А и В. На фиг. 11 представлена блок-схема в соответствии с принципами настоящего изобретения, показывающая шаги, которые необходимо реализовать для достижения симметричной маршрутизации через ИТДС в сети Интернет способом, подобным проиллюстрированному на фиг. 10. На фиг. 12 представлена блок-схема в соответствии с принципами настоящего изобретения, показывающая шаги процесса верификации маршрута в сети Интернет способом, подобным проиллюстрированному на фиг. 10. На фиг. 13 и 14 представлена блок-схема,показывающая шаги, составляющие принцип функционирования программы ASsimilator ИТДС в соответствии с принципами настоящего изобретения. На фиг. 15 представлена блок-схема в соответствии с принципами настоящего изобретения, иллюстрирующая процесс определения соответствующих длин маршрутов АС ПАСС для каждого провайдера ИТДС. На фиг. 16 представлена блок-схема в соответствии с принципами настоящего изобретения, иллюстрирующая процесс определения значений ЛОКАЛ ПРЕФ (LOCALPREF), используемых в рамках ИТДС для характеристики предпочтений каждого провайдера ИТДС. На фиг. 17 представлена блок-схема, показывающая шаги, необходимые для использования баз данных, созданных программой ASsimilator ИТДС и алгоритмом верификации 6 маршрута, для конфигурации параметров ЛОКАЛ ПРЕФ маршрутизатора ИТДС по каждому провайдеру. На фиг. 18 представлена блок-схема, показывающая шаги, необходимые для использования базы данных, созданной в процессе работы алгоритма определения длины маршрута АС ПАСС (ASPATH), для конфигурации маршрутизатора по каждому провайдеру. Предпочтительный способ использования изобретения Актуальность изобретения Помимо того, что ТДС не успевают в своем развитии за развитием сети Интернет и вследствие этого постоянно подвергаются перегрузкам, существуют дополнительные аспекты современной архитектуры сети Интернет, еще более обостряющие данную проблему. Во-первых, 4-ая версия протокола маршрутизации Интернет (ПМИ) (англ.: BGP4) осуществляет одинаковый контроль конфигурации протокола для всех провайдеров, производящих обмен маршрутизируемой информацией. Таким образом, без сотрудничества между этими провайдерами ни один из них сам по себе не способен в большей степени контролировать процесс собственной маршрутизации, чем какой-либо иной провайдер может контролировать свой. А поскольку большинство провайдеров являются конкурентами, у них нет практически никакой заинтересованности в осуществлении такого сотрудничества, помимо лишь равноправного обмена информацией (пиринга). А с учетом еще и того, что Национальные провайдеры не имеют экономических договоренностей друг с другом относительно обмена трафиком в ТДС, получается, что Национальные провайдеры имеют и экономическую, и технологическую заинтересованность в том, чтобы как можно скорее перевести трафик на ближайшую к себе ТДС, к которой подключен Национальный провайдер получателя, а не в том, чтобы переправить его по своим собственным сетям на другую ТДС. То же самое происходит, когда Национальный провайдер получателя возвращает пакет информации на Национальный провайдер отправителя. На фиг. 1 приведена упрощенная схема обмена Интернет-трафиком, существовавшая до момента настоящего изобретения. На ней показаны пять общедоступных ТДС, а именно PacBell (Сан-Франциско) (403), MAE-West (СанФранциско) (404), MAE-East (Штат Колумбия)(405), NY (Нью-Йорк) (406) и Ameritech (Чикаго) (407), а также множество Национальных провайдеров, подключенных к ним, таких, какMCI (401), UUNet (402) и других (410). Если отправитель (408), являющийся пользователем провайдера MCI (401), желает установить двустороннюю связь с получателем В (409), являющимся пользователем провайдера UUNet(402), то при современной архитектуре сети Ин 7 тернет трафик от отправителя А (408) будет проходить до получателя В (409) по маршруту(411), а обратный трафик от В (409) до А (408) пойдет по другому маршруту (412). Каждый маршрут трафика подразделяется на три подмаршрута. На вышеуказанном маршруте (411) провайдер MCI (401) заинтересован в том, чтобы как можно скорее вывести трафик за пределы своей сети и, таким образом, сначала отправитель А (408) посылает трафик по подмаршруту (411 а) своему провайдеру MCI (401), этот провайдер MCI (401) посылает трафик по второму подмаршруту (411b) на ближайшую ТДС(404, где происходит обмен трафиком с провайдером UUNet (402) и, наконец, провайдерUUNet (402) проводит трафик через свои сети на получателя В (409) по подмаршруту (411 с). На маршруте (412), так же, как и в случае маршрута (411), провайдер UUNet (402) аналогичным образом заинтересован в том, чтобы как можно скорее вывести трафик за пределы своей сети и, таким образом, сначала отправитель В(409) посылает трафик по подмаршруту (412 а) своему провайдеру UUNet (402), провайдерUUNet (402) посылает трафик по второму подмаршруту (412b) на ближайшую ТДС (в данном примере MAE-East (Сан-Франциско) (405, где происходит обмен трафиком с провайдеромMCI (401), а провайдер MCI (401) проводит трафик через свои сети на отправителя А (408) по подмаршруту (412 с). Этот способ прохождения трафика в сети Интернет известен под названием асимметричной маршрутизации. Данное название происходит от того, что прямой и обратный трафик при любом двустороннем соединении проходит по разным маршрутам, которые в точности противоположны друг другу в направлении от отправителя к получателю и наоборот. В прямом направлении трафик проходит от отправителя(402), который доставляет трафик получателю(409). В обратном направлении трафик проходит от получателя (409) к провайдеру UUNet(402), затем к ближайшей ТДС (404), а затем к провайдеру MCI (401), который доставляет трафик отправителю (408). Этот механизм в английской тематической литературе известен под названием Hot potato, что дословно перевести как горячая картошка: каждый из Национальных провайдеров старается как можно скорее избавиться от нее, передав другому, то есть вывести трафик, идущий по двустороннему маршруту, за пределы своих основных сетей путем сливания как можно большего количества трафика на ближайшую ТДС. Сама по себе асимметричная маршрутизация не является особой проблемой, однако, она создает ситуацию, при которой трафик вынужден проходить через четыре различных узла, 003155 8 над которыми ни у отправителя, ни у получателя трафика нет практически никакого контроля,а именно через провайдеров MCI (401), UUNet(402), а также две разные ТДС (404) и (405). Отправитель А (408) может иметь некоторую возможность контролировать провайдера MCI(401), поскольку является его пользователем, и то же верно для отношений получателя В (409) с его провайдером UUNet (402). Однако ни отправитель (408), ни получатель В (409) не могут контролировать ни других Национальных провайдеров, ни ТДС (404) и (405), через которые проходит их трафик. Следовательно, отправитель (408) и получатель (409) практически не имеют возможности вынудить ТДС (404) и (405) и других Национальных провайдеров предоставлять им более качественные услуги. Во-вторых, существующая архитектура ТДС создает проблемы в ситуации, когда два провайдера в одном городе или регионе пытаются установить связь друг с другом, будучи,однако, подключенными к разным Национальным провайдерам. Обратимся снова к фиг. 1. Когда и отправитель А (408), подключенный к провайдеру MCI (401), и получатель С (417),подключенный к провайдеру UUNet (402), находятся в г. Сиэтл (штат Вашингтон) и желают установить связь, их трафик проходит от отправителя А (408) до получателя С (417) через ТДС в Сан-Франциско, например ТДС Рас Bell (403). Таким образом, чтобы попасть в буквальном смысле слова на другую сторону улицы, трафик вынужден не только проходить через перегруженную ТДС (403), но и проделывать путь в тысячи километров по телефонным сетям. Наконец, протокол ПМИ 4 не осуществляет автоматической маршрутизации трафика, идущего на и от получателя по уже установленной прямой связи, если отправитель подключен к многочисленным основным Национальным провайдерам, таким как MCI и UUNet. Если провайдер подключен к более чем одному Национальному провайдеру по протоколу ПМИ 4 без использования технологии и соответствующих конфигураций протокола в соответствии с настоящим изобретением, то пакетная маршрутизация может происходить в беспорядочном режиме. Следует помнить о том, что Национальные провайдеры используют большое число маршрутизаторов и большое число сетей,соединенных через них. Сети соединяют получателей информации,имеющих собственные сетевые адреса (IPадреса). Маршрутизатор имеет большое числоIP-адресов, идентифицирующих его, для каждой из сетей, непосредственно подключенных к нему. При использовании протокола ПМИ 4 группирование сетей в пределах одного Национального провайдера называется автономной системой (Autonomous System) или АС. Маршрутизаторы посылают заявки о своих непосредственно подключенных сетях другим маршрутизаторам, 9 а те, в свою очередь, распространяют их между другими маршрутизаторами в сети. Со стороны маршрутизаторов, пославших свои заявки, путь,проделываемый трафиком в сети, может оцениваться в единицах так называемых прыжков,которые необходимо осуществить для достижения получателя. В случае протокола ПМИ 4 прыжок - это каждая АС, которую трафик прошел на пути от отправителя до его текущего местоположения. Счет прыжков при использовании протокола ПМИ 4 от отправителя до получателя информации включает в себя все АС,через которые проходит маршрут трафика от исходного до текущего местоположения. Таким образом, сеть получателя может оказаться либо ближе, либо дальше от отправителя, в зависимости от количества прыжков, о которых можно судить по количеству полученных заявок от различных Национальных провайдеров. Протокол ПМИ 4 устроен так, что маршрутизатор может посылать пакеты данных только по заявленному маршруту. Таким образом, маршрутизатор не может посылать пакеты на того же получателя по двум разным заявленным маршрутам. Для обеспечения того, что в любой момент времени используется только один маршрут,были разработаны различные виды так называемых прерывателей каналов (tie breakers),которые позволяют при наличии двух или более предположительно эквивалентных маршрута автоматически выбирать один. Протокол ПМИ 4 имеет несколько атрибутов (одним из которых является вышеупомянутая система измерения длины маршрута в прыжках), и для каждого атрибута существует набор прерывателей каналов. Если после применения всех атрибутов остаются два или более маршрутов, рассматриваемых как эквивалентные, протокол ПМИ 4 использует так называемый прерыватель последней надежды. Выбранный метод состоит в том, что маршрут, идущий от заявляющего о себе маршрутизатора, считается предпочтительным, если IP-адрес этого маршрутизатора больше. Это вносит значительную долю хаотичности в процесс выбора наилучшего маршрута протоколом ПМИ 4, если один и тот же маршрут заявляется несколькими Национальными провайдерами. Таким образом, провайдер, подключающийся к нескольким различным провайдерам с использованием протокола ПМИ 4, не может гарантировать, что при попытке доставить трафик получателю на провайдере MCI он не пошлет его сначала на UUNet с тем, чтобы UUNet послал трафик на MCI, таким образом заставляя трафик проходить через ТДС. Это свойственно не только данному протоколу маршрутизации,но и архитектуре, в соответствии с которой различные Национальные провайдеры конфигурируют свои сети. Раскрытие изобретения Для решения проблемы производительности сетей, актуальной для существующей моде 003155 10 ли обмена трафика через ТДС, необходимо разработать способ обхода ТДС путем предоставления отправителям и получателям прямого доступа друг к другу без необходимости подключения их к одному и тому же Национальному провайдеру Интернет-услуг. Следовательно,необходимо разработать технологию, поддерживающую инфраструктуру, подключенную ко множеству национальных провайдеров, так называемую ИТДС, позволяющую пользователям сетей соединяться с данной инфраструктурой,причем инфраструктура должна во всех возможных случаях обеспечивать, что трафик от ее отправителей направляется только на соответствующего национального провайдера, к которому подключен получатель. Эта технология должна также обеспечивать, что трафик, идущий от получателя обратно к отправителю, проходит через то же соединение. Этот принцип известен под названием симметричной маршрутизации, которая, как описано выше, не поддерживается протоколом ПМИ 4. Рассмотрим фиг. 2, где показана схема ИТДС (100), соединенной с семью Национальными провайдерами, а именно MCI (420),UUNet (421), Sprint (422), ANS (423), AGIS(424), Netcom (425) и PSI (426), называемыми совместно Провайдерами ИТДС (420)-(426), а также с одним из их пользователей, а именно отправителем (427). Также для ясности на фиг. 2 показана одна из пяти ТДС (432) и соединения с ней, осуществляемые всеми национальными провайдерами. Если отправитель А (427), подключенный к ИТДС (100) в Сиэтле, желает установить связь с получателем В (428), подключенным к провайдеру MCI (420) и также находящемуся в Сиэтле, то ИТДС (100) посылает трафик напрямую от его соединения (430) на провайдера MCI (420). Получатель В (428) будет посылать трафик назад на отправителя А(427) через то же самое соединение с MCI (430). Это наглядно показывает дополнительные преимущества ИТДС с точки зрения локализации,поскольку в этом случае трафик, которым обмениваются отправитель А (427) и получатель В(428), остается в Сиэтле и не должен проходить через ТДС в другом регионе. Аналогичная схема прохождения трафика(без локализации) осуществляется для отправителя А (427), подключенного в ИТДС (100) в Сиэтле, и получателя С (429), подключенного к провайдеру UUNet (421) в Атланте. Отправитель А (427) посылает пакетный трафик на ИТДС (100), а ИТДС (100), в свою очередь, посылает трафик напрямую на провайдера UUNet(421), который проводит трафик через свои сети на получателя С (429). Получатель С (429) посылает трафик обратно отправителю А (427) в точности по тому же маршруту. Формально, ИТДС (100) может быть представлена в виде двух половин. Одна из них соединения ИТДС (100) с ее пользователями, 11 например отправителем А (427), которые желают иметь прямой симметричный доступ к провайдерам ИТДС (420)-(426), а вторая - ее соединения с самими провайдерами ИТДС (420)(426). Использование инфраструктуры ИТДС и симметричной маршрутизации доступно только для пользователей ИТДС. Таким образом, провайдеры ИТДС (420)-(426) не используют инфраструктуру ИТДС для обмена трафиком друг с другом. Провайдеры ИТДС (420)-(426) обмениваются трафиком с ИТДС (100) только в целях его маршрутизации на или от пользователя ИТДС, такого как отправитель А (427). Вследствие того, что ИТДС (100) соединена с многочисленными провайдерами (420)(426), ИТДС (100) с симметричной маршрутизацией устойчива к ошибкам по своей сути. В случае разрыва связи с одним из провайдеров ИТДС (420)-(426) или если получатель не подключен к одному из провайдеров ИТДС (420)(426), технология симметричной маршрутизации позволяет ИТДС (100) осуществлять маршрутизацию трафика на получателя симметрично через провайдера по умолчанию. Провайдер по умолчанию - это набор провайдеров ИТДС(420)-(426), организованных в таком порядке,что один из них назначается первичным провайдером по умолчанию. Если этот первичный провайдер становится недоступен, его место занимает вторичный провайдер. Если становятся недоступными и первичный, и вторичный провайдеры, то их место занимает провайдер по умолчанию третьего уровня, и аналогично происходит для всех провайдеров ИТДС (420)(426). Таким образом, инфраструктура ИТДС вместе с симметричной маршрутизацией разрешает проблему необходимости общедоступных ТДС (432) для осуществления двусторонней связи между отправителями и получателями,если хотя бы один -отправитель или получатель- подключен к ИТДС (100). Поскольку технология ИТДС основана на городских сетях, она имеет большую по сравнению с архитектурой ТДС способность к расширению и обеспечивает локализацию трафика с высокой устойчивостью к ошибкам, что не характерно для существующей архитектуры ТДС. Изобретение Оборудование, необходимое для реализации Индивидуальной точки доступа к сети ИТДС (100) в соответствии с принципами настоящего изобретения, показано на фиг. 3. ИТДС (100) состоит из четырех стоек (101),(102), (103) и (104), на которых установлено коммуникационное оборудование. На стойках(103) и (104) находится переключающее и маршрутизирующее ПУП/МП-оборудование. ПУП/МП получателя идентифицирует протокол сетевого уровня, стандартно используемый в сети Интернет. На третьей стойке (103) находятся два центральных маршрутизатора (105) и(106), два FDDI-концентратора (107) и (108), два переключателя Catalyst (110) и (111), три граничных маршрутизатора (112), (113) и (114), а также запасной граничный маршрутизатор(105) обозначается центр-1, а нижний центральный маршрутизатор (106) - центр-2. В данной реализации центральные маршрутизаторы (105) и (106) представляют собой модели Cisco 75056E1P1H8T, выпускаемые фирмой Cisco Systems,Inc., расположенной по адресу 170 W. Tasman(110) обозначается Catalyst-1, а нижний запасной переключатель Catalyst (111) обозначаетсяCatalyst-2. FDDI-концентраторы (107) и (108) и переключатели Catalyst (110) и (111) также выпускаются фирмой Cisco Systems, Inc. Верхний граничный маршрутизатор (112) обозначается граница-6S, средний граничный маршрутизатор(113) - граница-3S, а нижний граничный маршрутизатор (114) - граница 2S. Средний и нижний граничные маршрутизаторы (113) и (114) представляют собой модели Cisco 4700-6E8T, а верхний граничный маршрутизатор (112) - модель Cisco 7505-6E1F2H. Запасной граничный маршрутизатор (115) представляет собой модель Cisco 4700-6E1F4T. На четвертой стойке расположены центральный маршрутизатор (116), граничный маршрутизатор (117), два Ethernet-концентратора (118) и (120) и четыре дополнительных граничных маршрутизатора (121)-(124). Центральный маршрутизатор (116) обозначается центр-3 и аналогичен другим центральным маршрутизаторам (105) и (106). Верхний граничный маршрутизатор (117) обозначается как граница-45 и представляет собой модель Cisco 7505-6E1F2H. Верхний Ethernet-концентраторEthernet-концентраторы (118) и (120) выпускаются фирмой Hewlett-Packard, расположенной в Пало-Альто, штат Калифорния (США). Из четырех граничных маршрутизаторов (121)-(124) самый верхний (121) обозначается граница-5 В,следующий (122) - граница-5 А, затем (123) граница-1B и, наконец, нижний (124) - граница 1A. Эти граничные маршрутизаторы (121)-(124) представляют собой модели Cisco-4700 12E1F. На второй стойке (102) находятся три полки с устройствами обслуживания канала и данных (Channel Service Unit / Data Service Unit,CSU/DSU) линий T1 (125), (126) и (127), две полки для оборудования DSX1 (128) и (130),одна полка для оборудования DSX3 (131) и пять или более CSU/DSU для линий T1 (132), (133),(134), (135) и (136). Как известно, система цифровых носителей для линий T1 Telco поддержи 13 вает мультиплексные цифровые каналы с пропускной способностью DS1 (1,544 Мбит/с), а система цифровых носителей для линий Т 3 - с пропускной способностью DS3 (44,736 Мбит/с). На каждой из трех полок с оборудованием для линий T1 (125), (126) и (127) находится по 12(127 а-1). Каждое устройство CSU/DSU для линий T1 поддерживает одну линию T1. Каждое устройство CSU/DSU для линий Т 3 (132), (133) и (134) поддерживает одну линию T1. Оборудование каждой из полок для DSX1 (128) и (130) поддерживает 28 линий T1. Оборудование полки для DSX3 (131) поддерживает 28 линий Т 3. Все полки с оборудованием DSX(128), (130) и(131) служет интерфейсами между сетевыми носителями и устройствами CSU/DSU (125 а-1),(126 а-1), (127 а-1), (132), (133) и (134). В дальнейшем предполагается, что между каждым устройством CSU/DSU и линиями T1 или Т 3 существует перекрестное соединение DSX. Если число линий становится больше предельно возможного для какого-либо устройства, показанного на фиг. 1, то по мере необходимости на стойки (101)-(104) может устанавливаться дополнительное оборудование. На первой стойке (101) расположены серверы. На ее верху находится сетевой сервер NS1(140), а внизу - сервер NS2 (141), которые используют DNS-протокол сети Интернет (DNS означает Domain Name System, или служба имен доменов). Данная служба является системой,охватывающей всю структуру сети Интернет и позволяющей ее пользователям распознавать имя удаленного компьютера по IP-адресу с помощью доменных серверов, содержащих базу данных имен доменов. На следующей полке находится оборудование Интернет-почты 1(142), а ниже ее - резервное оборудование Интернет-почты 2 (143). Далее, на следующей полке находится оборудование сетевого управления 1 (144), а ниже ее - резервное оборудование сетевого управления 2 (145). На следующей полке расположена резервная машина (146), служащая для сохранения данных. На следующей полке расположена запасная машина (147), служащая физической заменой для любого из серверов(140)-(146). На следующей полке находится ленточная вертушка (148). Дублирующая машина (146) посылает данные на вертушку (148),которая оперирует лентами с резервными данными. Далее на следующей полке находится сервер новостей (150) системы Internet UsenetNews. Сервер новостей (150) использует INNпротокол сети Интернет. В самом низу первой стойки (101) находятся серверы пользователей сети Интернет (151). Следует отметить, что при размещении на ИТДС дополнительного оборудования и серверов пользователей возникнет необходимость установки дополнительных стоек помимо вышеуказанных стоек (101)-(104). 14 Далее будет показано, что вспомогательное оборудование в данной системе не ограничивается тем, что показано на фиг. 3. Стойки(101)-(104) занимают помещение площадью 162 кв.м., называемое центром данных Интернет(ЦДИ). Вспомогательное оборудование включает в себя также две системы вентиляции и кондиционирования воздуха весом 20 т, одна из которых является запасной и включается автоматически при отказе первой. Эти системы работают попеременно с интервалом в одну неделю. В комплект оборудования входит также источник бесперебойного питания мощностью 50 кВА. И источник питания, и система вентиляции и кондиционирования воздуха подключены к генератору электроэнергии, который включается автоматически в случае перебоев в подаче электроэнергии в центральной сети. Четыре стойки (101)-(104) установлены на приподнятом полу, под которым находятся стойки для прокладки проводов. Обеспечивается также противопожарная охрана стоек (101)-(104), реализованная с помощью системы сухого тушения огня, использующей химикат Halon, и резервной системы тушения водой. Каналы коммуникаций прокладываются от ЦДИ до помещения, в котором осуществляются подключения ко всем сетевым носителям, расположенным в том же здании (meet-me room). Возможны как Т 1-, так и Т 3-соединения. Данное помещение для подключения абонентов позволяет системе, основанной на настоящем изобретении, использовать кабели, сведенные в одну центральную точку от всех сетевых носителей. Таким образом, все пользователи сети могут соединяться между собой через один узел, что позволяет избежать прокладки запутанной системы проводов по всему зданию и дает системе возможность осуществлять соединение со всеми Национальными провайдерами Интернет-услуг в одном месте здания без необходимости закупки линий удаленного соединения. На фиг. 4 представлена блок-диаграмма,показывающая соединение ИТДС (100) на физическом уровне с остальным Интернетпространством через Национальных провайдеров, называемых провайдерами ИТДС. Сеть ИТДС представляет собой FDDI-ЛВС коллективного доступа мощностью 100 Мбит/с и двеEthernet-ЛВС на 10 Мбит/с, служащие резервными по отношению к FDDI-ЛВС. Центральные маршрутизаторы подключены ко всем трем ЛВС.FDDI (Fiber Distributed Data Interface, или распределенный интерфейс передачи данных по волоконно-оптическим каналам) представляет собой технологию ЛВС, обеспечивающую пропускную способность 100 Мбит/с по оптоволоконным линиям, а также предоставляющую возможности для самостоятельного восстановления данных. FDDI - технология двойного маркерного кольца (token ring) с движением 15 маркера по кольцам в противоположных направлениях. Сеть состоит из двух циклов (колец), начинающихся на одном компьютере, проходящих через все остальные компьютеры сети и приходящих обратно в исходную точку. Маркер (или кадр управления) последовательно передается между компьютерами и осуществляет контроль за передачей данных, сигнализируя о том, что система, в которой маркер находится в данный момент, готова к передаче или приему данных. В пределах одного кольца все маркеры передаются по часовой стрелке, а в пределах другого - против часовой стрелки. В полностью исправной сети FDDI используется только одно кольцо, а второе используется только если система оказывается неспособна передать маркер следующей системе в пределах первичного кольца. В этом случае система, сигнализирующая о проблеме с передачей данных, переправляет маркер на второе кольцо с противоположным направлением прохождения маркера, пытаясь обойти стороной проблемное место в первом кольце. Маркер может вернуться по второму кольцу на машины, в которых он уже был, но поскольку это происходит уже во втором кольце, машины в результате смогут передать его на те компьютеры, где он еще не был. У FDDI есть два способа физического соединения. В соответствии с одним из них, известным под названием гирляндной цепи, или цепи последовательного опроса (daisy-chaining),компьютер А напрямую соединен с компьютером В, который напрямую соединен с компьютером С, который, в свою очередь, соединен с компьютером А, и таким образом организуется цикл, описанный выше. Для присоединения дополнительных компьютеров цикл необходимо разорвать и включить новый компьютер между машинами А и В, В и С или С и А. Второй способ известен под названием способа концентраторов (concentrated). Два FDDI-концентратора образуют первичное и вторичное кольца. Каждый компьютер системы подключается не к другому компьютеру, а к обоим концентраторам. В свою очередь, концентраторы соединены друг с другом двумя связями и оперируют маркером, проходящим по разным системам и разным кольцам. Даже несмотря на то, что каждый компьютер в данном способе соединен с двумя разными концентраторами, такая FDDI-сеть все равно рассматривается как единая ЛВС. Способ концентраторов не требует разрывания кольца для добавления новых компьютеров и обеспечивает более надежную изоляцию компьютеров друг от друга. На фиг. 4 FDDI-1 (107) и FDDI-2FDDIконцентратора и соединены друг с другом двойной связью, как показано кольцом (152).Ethernet представляет собой технологию ЛВС, обеспечивающую пропускную способность линии 10 Мбит/с по кабелю витой пары(10Base2/5 Ethernet). Ethernet не является технологией с автоматическим восстановлением данных, в отличие от FDDI. 10BaseT Ethernet использует физическое устройство, известное как концентратор сети, или хаб, для подключения компьютеров. На фиг. 4 Ethernet-1 (118) иEthernet-2 (120) представляют собой два отдельных Ethernet-концентратора, образующих двеEthernet-ЛВС. Использование технологии внутренней маршрутизации ПУП/МП позволяет использовать FDDI-ЛВС в качестве основной внутренней сети, по которой проходит весь трафик, а две Ethernet-ЛВС (суммарной пропускной способностью 20 Мбит/с) - в качестве резервных линий на случай проблем с FDDIЛВС. Например, в случае отказа FDDIинтерфейса маршрутизатора, маршрутизатор перейдет на использование для передачи трафика двух Ethernet-ЛВС. В случае отказа одного из двух FDDI-концентраторов (107) или (108), технология FDDI, имеющая известный запас прочности, переведет весь трафик на другой FDDIконцентратор. В случае же отказа обоих FDDIконцентраторов (107) и (108) протокол маршрутизации выберет в качестве резервных линий две Ethernet-ЛВС. Система может быть расширена за счет добавления по мере необходимости дополнительных Ethernet-линий в качестве резервных. Маршрутизаторы центр-1 (105), центр-2(120). Каждый центральный маршрутизатор центр-1 (105), центр-2 (106) и центр-3 (116) также подключен к провайдерам ИТДС (Национальным провайдерам, к которым ИТДС имеет подключения). В целях страховки архитектура ИТДС разрешает подключение только одногоDS3-устройства к одному центральному маршрутизатору, так что при отказе одного центрального маршрутизатора остаются два другихDS3-соединения, продолжающих работать. Аналогично организованы Т 1-подключения: они распределены между центральными маршрутизаторами, а не подключены все к одному. На фиг. 4 провайдеры Интернет-услуг обозначены символом глобальной сети, представляющим собой зигзагообразную стрелку. Символы глобальной сети помечены названиями провайдеров, а скорости передачи данных обозначены либо знаком DS3, либо знаком Т 1 с соответствующим множителем. Маршрутизатор центр-1CSU/DSU (127d), которое соединено с провайдером PSI. Маршрутизатор центр-3 (116) подключен к Т 3-устройству CSU/DSU (134), которое подключено к провайдеру MCI. Следует отметить, что если существующие Т 1 соединения требуют модернизации до DS3 или для подключения к Национальному провайдеру требуется DS3-ycтройство, в данный момент не имеющееся на ИТДС, то потребуются дополнительные центральные маршрутизаторы иCSU/DSU-устройства для каждого нового DS3coeдинeния. Эти дополнительные центральные маршрутизаторы будут подключены к основной сети ИТДС так же, как и остальные центральные маршрутизаторы, а DS3-coeдинeниe будет подключено к национальному провайдеру так же, как и остальные DS3-coeдинeния. Для создания дополнительных Т 1-соединений потребуются дополнительные Т 1-устройства CSU/DSU, но эти соединения будут распределены между всеми центральными маршрутизаторами,каждый из которых поддерживает до шести Т 1 соединений. Вышеприведенное описание блокдиаграммы, приведенной на фиг. 4, показывает подключение ИТДС к ее провайдерам на базовом уровне реального соединения. На фиг. 2 то же самое показано более схематично, на более высоком уровне. В предпочтительном способе использования настоящего изобретения существуют три способа подключения провайдера Интернетуслуг к ИТДС: (1) через серверы на выделенной ЛВС, (2) через серверы на ЛВС коллективного доступа и (3) через соединения удаленного доступа. Серверы в ЛВС, обозначаемые как серверы пользователей, в реальности находятся в помещении ИТДС и подключены к ЛВС. Серверы удаленного доступа подключаются к сети ИТДС, находясь на площадях пользователей. На фиг. 5, в продолжение описания в соответствии с фиг. 4, приведен в форме блокдиаграммы один из способов подключения серверов пользователей (151) к ИТДС, а именно,через выделенную ЛВС. FDDI-1 (107), FDDI-2(108), Ethernet-1 (118) и Ethernet-2 (120), расположенные в нижней части фиг. 4, показаны в верхней части фиг. 5. Ниже этих ЛВС показаны четыре граничных маршрутизатора: граница-1A(124), граница-1B (123), граница-5 А (122) и граница-5 В (121). Эти четыре граничных маршрутизатора работают в парах в целях возможности взаимного резервирования (1 А с 1 В и 5 А с 5 В; этот способ соединения называется А/Впарами). В действительности два маршрутизатора одной пары работают одновременно, т.е. две пары работают параллельно, но в случае отказа одного маршрутизатора из пары его функции принимает на себя второй маршрутизатор. Это происходит автоматически и согла 003155 18 суется с требованиями надежности в соответствии со стандартными протоколами. Маршрутизатор граница-1A (124) подключен к каждому из устройств ЛВС, а именноEthernet-2 (120). Аналогично, маршрутизаторы граница-1B (123), граница-5 А (122) и граница 5 В (121) подключены к каждому из устройств ЛВС. Первый Ethernet-концентратор (153) подключен к маршрутизаторам граница-1A (124) и граница-1B (123). Ethernet-концентратор (153) не показан на фиг. 3, но представляет собой устройство, производимое фирмой Asante, СанХосе (штат Калифорния, США) и предназначенное для работы с индивидуальными серверами. К Ethernet-концентратору (153) может подключаться произвольное количество серверов пользователей (151 а). Аналогично, второйEthernet-концентратор (154) подключен к маршрутизаторам Ethernet-1 (118) и Ethernet-2 (120) и к нему так же может быть подключено произвольное количество серверов пользователей(151b). На фиг. 6 показано осуществление десяти соединений с пользователями для каждой пары маршрутизаторов. Так, пара маршрутизаторов,обозначенная как граница-1 А (124) и граница 1 В (123) может поддерживать десять серверов пользователей через десять Ethernet-концентраторов, как показано на фиг. 6. Аналогичным образом, вторая пара маршрутизаторов, обозначенная как граница-5 А (122) и граница-5 В (121) может поддерживать десять серверов пользователей через десять Ethernet-концентраторов. При необходимости поддержки дополнительного количества пользователей дополнительные пары маршрутизаторов могут по мере необходимости подключаться к FDDI-1 (107), FDDI-2(108), Ethernet-1 (118) и Ethernet-2 (120). У Ethernet-концентраторов (153) и (154) не существует резервных устройств. ОтказEthernet-концентратора приводит к отказу всей системы, но Ethernet-концентратор является устройством с довольно простым соединением и легко заменяется. Однако при желании заказчика оплатить дополнительную надежность, такая возможность существует. Она реализуется путем добавления дополнительного соединения на сервере пользователя для подключения к еще одной из десяти выделенных ЛВС. При отказе одной из ЛВС связь с сервером пользователя будет обеспечена дополнительным соединением. Этот тип соединения (450) показан на фиг. 6. Такая опция определяется исключительно экономической политикой (и возможностями) пользователя. Тип связи, показанный на фиг. 5 и 6, называется выделенным соединением, поскольку кEthernet-концентратору модели Asante (153) подключены серверы только одного пользователя (151 а). На фиг. 7 приведен пример ЛВС коллективного доступа. На этой фигуре два сер 19 вера (151 с) и (151d) двух разных пользователей совместно используют одинEthernetконцентратор модели Asante (153), подключенный к одной паре граничных маршрутизаторов. При реализации этой схемы необходимо обеспечить изоляцию трафиков пользователей. Два сервера пользователей (151 с) и (151d) не могут быть просто подключены кEthernetконцентратору (153). Соответственно, Ethernetконцентратор (153) подключен к двум серверам пользователей (155) и (156), каждый из которых,в свою очередь, подключен к другим Ethernetконцентраторам модели Asante (157) и (158). Маршрутизаторы пользователей (155) и (156) в предпочтительном способе использования изобретения представляют собой два маршрутизатора модели Cisco 2514, которые обеспечивают так называемую изоляцию типа брандмауэр(firewall) для пользователей, имеющих коллективный доступ к Ethernet-концентратору (153). Таким образом, маршрутизатор с защитой типа брандмауэр является устройством физического разделения трафика. Пользователи этой сети не имеют возможности отслеживать трафик друг друга. Следует отметить, что ЛВС коллективного доступа представляет собой всего лишь одну из выделенных ЛВС, к которой просто подключено много разных пользователей. Соответственно, можно организовать произвольное количество ЛВС коллективного доступа, просто трансформируя выделенные линии. Выше были описаны соединения выделенного и коллективного доступа. Ниже со ссылкой на фиг. 8 и 9 будет описан удаленный доступ к серверам пользователей, расположенным в помещениях последних. На фиг. 8 показано удаленное подключение ИТДС в соответствии с настоящим изобретением к серверам пользователей через линии Т 1, а на фиг. 9 - подключение ИТДС к серверам пользователей через линии Т 3. Как показано на фиг. 8, переключательFDDI-2 (108) (Catalyst-2 (111) - неподключенное запасное устройство). Переключатель Catalyst выполняет роль мостика между Ethernet и FDDI(он переводит кадры Ethernet в кадры FDDI и обратно), поэтому граничные маршрутизаторы удаленного соединения по линии Т 1 не обязательно должны иметь FDDIинтерфейсы (что оставляет больше места для последовательных Т 1-интерфейсов). Переключатели Catalyst-1(110) и Catalyst-2 (111) представляют собой переключатели ЛВС модели Cisco Catalyst 12008E1F. Граничные маршрутизаторы, обозначенные граница-2S (114) и граница-4S (117) соединены через Ethernet-интерфейс с переключателем Catalyst-1 (110) и через Ethernet-интерфейсы с устройствами Ethernet-1 (118) и Ethernet-2(120). Платы Tl CSU/DSU, расположенные на полках Т 1 CSU/DSU (127), (126) и (125), подключены к маршрутизаторам граница-2S и гра 003155 20 ница-4S и через сети с серверами пользователей. Каждый из этих граничных маршрутизаторов поддерживает восемь Т 1-соединений удаленного доступа, из которых только одно соединение показано для каждого маршрутизатора на фиг. 8. При необходимости осуществления соединений помимо суммарного количества, поддерживаемого маршрутизаторами граница-2S и граница-4S, на ИТДС могут быть установлены дополнительные маршрутизаторы данного типа. На фиг. 9 приведена блок-диаграмма удаленного соединения ИТДС в соответствии с настоящим изобретением с серверами пользователей на площадях последних через DS3-сети. Граничные маршрутизаторы, обозначенные как граница-3S (113) и граница-6S (112), подключены к устройствам FDDI-1 (107), FDDI-2 (108),Ethernet-1 (118) и Ethernet-2 (120). Дополнительные Т 3-устройства CSU/DSU (135) и (136) подключены либо к маршрутизатору граница-3S(на фиг. Т 3-устройство CSU/DSU (135) подключено к маршрутизатору граница-3S (113), а Т 3 устройство CSU/DSU (136) подключено к маршрутизатору граница-6S (112. Далее Т 3 устройства CSU/DSU через сети соединены с серверами пользователей. Каждый из этих граничных маршрутизаторов поддерживает два удаленных соединения DS3, из которых на фиг. 9 показано только по одному для каждого маршрутизатора. При необходимости осуществления соединений помимо суммарного количества, поддерживаемого маршрутизаторами граница-3S и граница-6S, на ИТДС могут быть установлены дополнительные маршрутизаторы данного типа. Следует учитывать, что все эти граничные маршрутизаторы (112), (113), (114) и (117) работают не так, как маршрутизаторы в А/В-парах,описанные выше, а индивидуально. Если удаленно подключенный пользователь желает обеспечить большую надежность своего соединения в случаях как выделенного, так и коллективного доступа, необходимо организовать вторую сеть удаленного доступа к ИТДС, которая будет подключена к другому граничному маршрутизатору. Таким образом, резервирование будет осуществляться второй сетью, отличной от тех, через которые пользователь подключен к ИТДС. Литера S в обозначениях граница-2S,граница-3S, граница-4S и граница-6S обозначаетserial (англ. последовательный), поскольку в данном случае реализуется последовательное соединение. Далее будет показано, что сетевые серверы сетевого управления (144) и (145) на первой стойке (101), показанной на фиг. 3, соединены с одной из выделенных ЛВС (153), описанных выше со ссылкой на фиг. 5 и 6. Серверы пользователей не подключаются к данной выделенной ЛВС (153). На серверах сетевого управления(144) и (145) установлено программное обеспе 21 чение ИТДС, служащее для выполнения различных процедур в соответствии со способом настоящего изобретения. Данное программное обеспечение, известное под названием ASsimilator, выполняет в пошаговом режиме процесс контроля маршрутизации ПУП/МП, который обеспечивает, что трафик между любыми провайдерами, подключенными к ИТДС и другими провайдерами,подключенными, прямо или опосредованно, к провайдерам ИТДС, проходит только через соединения данной ИТДС с ее провайдерами. Как описано выше, эта схема известна как симметричная маршрутизация, потому что и прямой и обратный трафик проходят по одному и тому же маршруту через провайдеров. Если подключение ИТДС к одному из ее провайдеров в данный момент недоступно или провайдер получателя не подключен к провайдеру ИТДС, процесс контроля маршрутизации в соответствии со способом настоящего изобретения посылает трафик симметрично через одного из провайдеров ИТДС, в данный момент сконфигурированного как первичного провайдера по умолчанию. Возможности резервирования, заложенные в систему ИТДС, позволяют переводить статус текущего провайдера по умолчанию на другого провайдера в соответствии с их доступностью.ASsimilator совмещает три основных аспекта: (1) определение конфигурации политики маршрутизации, (2) программное обеспечение,создающее и автоматически поддерживающие базы данных маршрутов и (3) взаимодействие с провайдерами ИТДС для установки их атрибутов ЛОКАЛ ПРЕФ протокола ПМИ 4 с целью обеспечения их доступа к ИТДС через их локальные соединения с данной ИТДС, а не через других провайдеров ИТДС (общедоступные ТДС). Параметр ЛОКАЛ ПРЕФ является атрибутом протокола ПМИ 4, дающим локальной автономной системе (АС) возможность контролировать приоритетность маршрутизации пакетов. Этот атрибут ЛОКАЛ ПРЕФ применяется к маршрутам путем конфигурирования маршрутизаторов АС. По определению, более высокое значение параметра ЛОКАЛ ПРЕФ означает предпочтительность провайдера, имеющего такой параметр, по сравнению с тем, у которого этот параметр ниже. Назначение аспекта (1) программы ASsimilator состоит в определении порядка приоритета провайдеров ИТДС, которые должны использоваться в качестве провайдеров по умолчанию, как описано выше. Необходимо определить, какой из провайдеров ИТДС назначается первичным по умолчанию, какой вторичным, какой третьего порядка и так далее для всех провайдеров ИТДС. После того, как эти приоритеты расставлены, процедуры, выполняемые программой ASsimilator, могут быть использованы для создания основных конфигураций маршрутизатора, которые будут взаимо 003155 22 действовать с другими устройствами и процессами и обеспечивать, чтобы трафик между ИТДС и провайдером, не подключенным к провайдеру ИТДС или провайдером, подключенным к ИТДС, но в данный момент недоступным, маршрутизировался симметрично через текущего провайдера по умолчанию. Аспект (1) также предназначен для симметричной маршрутизации трафика на получателей, подключенных к более чем одной ИТДС. Назначение аспекта (2) программы ASsimilator - создание и управление базами данных номеров автономных систем (номера АС используются в протоколе ПМИ 4 для распознавания провайдеров маршрутов), которые присваиваются каждому провайдеру ИТДС, а также номеров АС тех провайдеров, которые предположительно имеют пиринговые соглашения на общедоступной ТДС. Обновление этих баз данных производится с помощью (1) собственной процедуры АСсимилятора и прикладного программного обеспечения и (2) программы верификации маршрута Routebot. Если эти базы данных, равно как и вся таблица маршрутизации сети Интернет, заявлены каждым из провайдеров ИТДС, то становится возможным определить, какой из заявленных этими провайдерами маршрутов реально подключен к ним, при сохранении возможности резервирования и всех свойств симметричной маршрутизации, описанных в связи с аспектом (1) выше. Следует понимать, что ИТДС получает от каждого из своих провайдеров не только те маршруты, которые непосредственно подключены к ним, но и маршруты всех других провайдеров (включая других провайдеров, подключенных к ИТДС). Автоматической возможности отличить собственные маршруты, заявленные провайдерами, от маршрутов других провайдеров, соединенных с ними, не существует. Данная возможность распознавания собственных маршрутов провайдеров ИТДС из всей таблицы маршрутов сети Интернет, предоставляемая аспектом (2), является основой для обеспечения рассылки от ИТДС на ее провайдера через его соединение только того трафика, который предназначен для получателей в сети этого провайдера. Определение того, какие провайдеры имеют пиринговые соглашения в общедоступных ТДС, осуществляется с использованием эвристических методик программы ASsimilator. С точки зрения маршрутизации ПМИ 4 нет никакой возможности определить, имеет ли провайдер пиринговое соглашение с другим провайдером на ТДС, или же попросту напрямую покупает его услуги. Поскольку ТДС являются архитектурой уровня канала передачи данных (уровня 2), они невидимы для процедуры маршрутизации ПУП/МП сетевого уровня (уровня 3). Таким образом, ТДС не появляется среди заявленных маршрутов протокола ПМИ 4, что делает пиринговые соединения на ТДС неотличимыми 23 от прямых соединений. В настоящее время программа ASsimilator предполагает, что если провайдер подключен более чем к трем Национальным провайдерам, то он имеет с ними пиринговые отношения через ТДС. Этот эвристический подход основан на предположении о том, что практически не существует провайдеров, кроме провайдеров ИТДС, которые были бы подключены более чем к трем Национальным провайдерам. Это, однако, создает проблемы при взаимодействии с провайдерами, которые имеют пиринговые соглашения на ТДС только с тремя или менее провайдерами. Программа ASsimilator предоставляет возможность ручного обновления баз данных для учета подобных случаев,если таковые обнаруживаются. Назначение аспекта (3) - давать указание каждому из провайдеров ИТДС устанавливать его атрибут ЛОКАЛ ПРЕФ протокола ПМИ 4 таким образом, чтобы любой маршрут ИТДС,становящийся доступным для этого провайдера через его подключение к ИТДС, был для него приоритетным по сравнению с маршрутами,полученными от других провайдеров в рамках его пирингового соглашения на ТДС. Это является основой для маршрутизации трафика, приходящего через сети, соединенные с провайдером ИТДС, обратно на ИТДС через подключения этого провайдера ИТДС. На фиг. 10 представлена упрощенная схема диаграммы маршрутизации ИТДС во взаимодействии с глобальным Интернетпространством, на которой указаны соединения различных маршрутов. На ней представлены ИТДС (100), ТДС общего пользования (160) и шесть административных провайдеров (161)(166). Четыре из них, а именно (161), (162),(164) и (165) являются Национальными провайдерами, непосредственно подключенными к ИТДС (100), и поэтому могут рассматриваться как провайдеры ИТДС. Провайдеры (163) и(166) могут быть Национальными, простыми провайдерами Интернет-услуг, либо компаниями с большими внутренними сетями, но и в этом случае они будут для простоты здесь называться провайдерами. Четыре провайдера (161),(162), (164) и (165) помечены в соответствии с порядком их приоритетности в качестве провайдеров по умолчанию, т.е. первичного, вторичного и т.д. На фиг. 10 показано, что связь между ИТДС (100) и провайдером (164) в данный момент отсутствует, что обозначено большой буквой X на месте обозначения связи. Три из четырех провайдеров (161), (165) и (164) также подключены к провайдеру (166). Четыре провайдера (161), (162), (164) и (165), равно как и провайдер (163), напрямую подключены к общедоступной ТДС (160). ИТДС (100) в соответствии с настоящим изобретением маршрутизирует пакеты данных между пользователями ИТДС и пользователями любого из провайдеров симметричным образом, 003155(160), где это возможно. В частности, в первом случае, ИТДС (100) создает файлы конфигурации, которые, будучи загруженными в центральные маршрутизаторы (105), (106) и (116),фиг. 3 и 4, используют атрибут ЛОКАЛ ПРЕФ протокола ПМИ 4 таким образом, чтобы ИТДС(100) направляла трафик провайдерам ИТДС только через их сети. Как показано на фиг. 10,если отправитель А (167), являющийся пользователем ИТДС (100), желает обменяться данными с получателем В 1 (168), являющимся пользователем провайдера ИТДС (161), то прямой пакет идет через первый маршрут (170) непосредственно на провайдера (161) и затем сразу на получателя В 1 (168). В ИТДС (100) при установлении соединения с провайдером (161) его локальный приоритет был задан таким образом,чтобы предпочтительной была прямая маршрутизация его трафика на ИТДС (100), а не на общедоступную ТДС типа (160). Таким образом,когда получатель В 1 (168) посылает пакет обратно на отправителя А (167), этот пакет проходит по первому маршруту 170' от получателя В 1(168), подключенного к провайдеру (161), непосредственно на ИТДС (100) и далее отправителю А (167). Во втором случае ИТДС создает файлы конфигурации, которые используют локальные приоритеты и переменные длины маршрутов АС, которые были заявлены каждому провайдеру ИТДС как требующие маршрутизации через сеть провайдера ИТДС по умолчанию на пользователей, которые не подключены ни к одному из провайдеров ИТДС. Как показано на фиг. 10,отправитель А (167), являющийся пользователем ИТДС (100), желает обменяться данными с получателем В 2 (171), являющимся пользователем провайдера (163), не подключенного непосредственно к ИТДС (100). Провайдер (162) предварительно указан ИТДС (100) как текущий провайдер по умолчанию, поскольку он имеет статус первичного и в настоящий момент доступен. Прямой пакет идет по маршруту (172) через провайдера (162), общедоступную ТДС(160) и провайдера (163) получателю В 2 (171). Поскольку обратные маршруты на ИТДС, которые заявлены провайдеру (163) провайдером(162), имеют наименьшие длины маршрутов АС(провайдер (162) в данный момент выбран по умолчанию и, следовательно, имеет наименьшие длины маршрутов из всех провайдеров ИТДС), обратный пакет проходит по симметричному второму маршруту 172' через провайдера (163), общедоступную ТДС (160) и провайдера (162) на ИТДС (100) и от нее на отправителя А (167). В третьем случае ИТДС (100) создает файлы конфигурации, которые используют локальные приоритеты и переменные длины маршрутов АС для маршрутизации трафика на пользователей, имеющих соединения с более чем од 25 ним провайдером и с ИТДС (100), через такого провайдера ИТДС данных пользователей, который в данный момент имеет наивысший приоритет из провайдеров ИТДС по умолчанию. Как показано на фиг. 10, отправитель А (167),являющийся пользователем ИТДС (100), желает обменяться данными с получателем В 3 (173),являющимся пользователем провайдера (166),подключенного к провайдерам ИТДС (161),(164) и (165). Поскольку провайдер (165) имеет наивысший приоритет провайдера по умолчанию (второй) из этих трех общих для пользователя и ИТДС (100) провайдеров (161), (164) и(165), он выбирается в качестве симметричного маршрута, по которому будут проходить пакеты. Прямой пакет идет по третьему маршруту(174) через провайдера (165) непосредственно на провайдера (166) и затем на получателя В 3(173). Поскольку обратные маршруты на ИТДС(100), которые заявлены провайдеру (166) провайдером (165), имеют наименьшие длины маршрутов АС из провайдеров (161), (164) и(165), к которым подключен провайдер (166)(провайдер (165) является вторичным по умолчанию и поэтому из всех провайдеров, общих для ИТДС и провайдера (166), у него вторая после наименьшей длина маршрута АС), то обратный пакет проходит по симметричному второму маршруту 174' через провайдера (166),провайдера (165) и ИТДС (100) обратно на отправителя А (167). В четвертом случае ИТДС (100) создает файлы конфигурации, которые используют локальные приоритеты и переменные длины маршрутов АС, которые инструктируют ИТДС(100) маршрутизировать трафик на пользователей провайдеров ИТДС через текущего провайдера ИТДС по умолчанию, если соединение ИТДС (100) с провайдером получателя в данный момент отсутствует. Отсутствие связи здесь означает, что маршрутное или сетевое взаимодействие между ИТДС (100) и данным провайдером ИТДС не может быть реализовано. На фиг. 10 отправитель А (167), являющийся пользователем ИТДС (100), желает обменяться данными с получателем В 4 (175), являющимся пользователем провайдера (164), соединение с которым у ИТДС (100) в данный момент отсутствует. В этом случае, поскольку нет прямого соединения между ИТДС (100) и провайдером ИТДС (164), случай трансформируется в случай 2, описанный выше. Провайдер (162) предварительно выбран ИТДС (100) как текущий провайдер по умолчанию, поскольку он имеет первичный приоритет и в данный момент доступен. Прямой пакет идет по маршруту (176) через провайдера (162), общедоступную ТДС (160) и провайдера (164) получателю В 4 (175). Поскольку маршруты на ИТДС, которые заявлены провайдеру (164) общедоступной ТДС (160) имеют наименьшие длины маршрутов АС (провайдер (162) в данный момент выбран по умол 003155 26 чанию и, следовательно, имеет наименьшие длины маршрутов из всех провайдеров ИТДС),обратный пакет проходит по симметричному четвертому маршруту 176' через провайдера(162) на ИТДС (100) и от нее на отправителя А(167). Второй и четвертый случаи, описанные выше, являются единственными случаями, в которых трафик проходит через общедоступную ТДС (160). Таким образом, чем больше провайдеров подключено в ИТДС, тем реже трафик будет проходить через ТДС общего доступа. Как следует из вышесказанного, в соответствии с принципами настоящего изобретения существует способ симметричной маршрутизации пакетов между ИТДС (100) и как минимум двумя провайдерами ИТДС, подключенными к ней. Для исходящих пакетов видно, что ИТДС(100) создает файлы конфигурации, которые,будучи загруженными в маршрутизаторы, используют локальные приоритеты для того, чтобы ИТДС (100) маршрутизировала трафик пользователей провайдеров ИТДС только через их сети. Кроме того, те же файлы конфигурации маршрутизаторов предписывают ИТДС (100) маршрутизировать трафик пользователей, не подключенных непосредственно к провайдеру ИТДС или подключенных к провайдеру ИТДС,связь с которым в настоящий момент отсутствует, через сеть предварительно назначенного провайдера по умолчанию. Для возвращающихся входящих пакетов пользователей провайдеров ИТДС, ИТДС при установлении связи задает локальные приоритеты, вследствие чего предпочтительным является непосредственная маршрутизация трафика на ИТДС (100). Для пакетов, возвращенных от других получателей,ИТДС использует различающиеся длины маршрутов АС до каждого из провайдеров ИТДС для того, чтобы обратный маршрут проходил через того провайдера ИТДС, который является текущим провайдером по умолчанию, как описано выше. Способ в соответствии с настоящим изобретением включает шаги загрузки файлов конфигурации в маршрутизатор, инструктирование маршрутизатора на получение маршрутов от каждого из провайдеров ИТДС и применение им этих файлов конфигурации к полученным маршрутам. На фиг. 11 приведена блок-схема, показывающая шаги, используемые в данном способе для обеспечения симметричной маршрутизации в сети Интернет, подобной показанной на фиг. 10. Предполагается, что у каждого провайдера существует своя сеть, состоящая из получателей трафика, в обычном случае, компьютеров. Маршрутизаторы осуществляют соединение друг с другом и соединяют провайдеров между собой. Административное группирование любого числа сетей в рамках одного провайдера описывается термином маршрутизации, известным 27 как автономная система, или АС. Автономная система может иметь размеры одной ЛВС или же масштаб множества сетей дальней связи. Каждая АС имеет свой номер, служащий для ее идентификации, и у каждого провайдера есть свой собственный набор номеров АС. Случай использования двумя разными провайдерами одного и того же номера АС исключен. Провайдеры на фиг. 10 были выше разделены на Национальных провайдеров, локальных провайдеров и компании с собственными большими сетями. Теперь они все будут называться коллекциями автономных систем (или АС). При маршрутизации по протоколу ПМИ 4 маршрутизаторы заявляют о маршрутах до получателей сети Интернет в виде, известном как маршрут АС(атрибут АС ПАСС протокола ПМИ 4), который сопоставляется с каждым маршрутом. Маршрут АС является маршрутом автономных систем,через которые маршрутная заявка проходит от точки ее посылки до точки ее получения. В большинстве случаев это эквивалентно тому маршруту, через который прошел бы пакет, посланный из точки получения маршрутной заявки в точку ее посылки. Общий вид фиг. 11 иллюстрирует процесс работы программы ASsimilator как части ИТДС. Этот процесс не следует путать с алгоритмомASsimilator (180), который является основным алгоритмом, используемым программой ASsimilator в работе. Процесс программы ASsimilator, показанный на фиг. 11, в действительности состоит из двух основных прикладных программ, а именно ASsimilator и Routebot. Routebot отвечает за программу верификации маршрута (184). ASsimilator управляет остальными автоматизированными шагами, показанными на фиг. 11. По меньшей мере, два раза в сутки программа ASsimilator считывает данные, которые были ей заложены в базу данных АС ее провайдера (181), проверяет их актуальность и запускает свой алгоритм для определения необходимости добавления дополнительных данных в базу данных АС провайдеров (181). База данных АС провайдеров (181) представляет собой карту провайдеров ИТДС и их номеров АС, заложенную в сервер сетевого управления (144) (фиг. 3). Эта база данных выглядит примерно следующим образом:Netcom: 2551 6996 Каждый раз при запуске программы ASsimilator она восстанавливает ту часть базы данных исключений (Exceptions) AC (182), которую она уже создала. База данных исключений АС(182) - это список номеров АС, которые приходят от более чем трех различных провайдеров ИТДС, и эта база данных также заложена в сервер сетевого управления (144), показанный на фиг. 3. Как было описано выше, этот эвристический механизм служит для определения того,подключен ли провайдер к общедоступной ТДС и имеет ли он пиринговые отношения с провайдерами ИТДС. Таким образом, база данных исключений АС (182) является приближением тех АС, которые связаны пиринговыми отношениями на общедоступных ТДС. Такая база данных(182) может выглядеть следующим образом:Exceptions: 2685 1 3914 568 6456 5761 4136 6113 286 6172 293 297 2041 4006 1740 3703 2828 База данных исключений АС может также содержать определенное количество позиций,введенных программой верификации маршрута(184), описанной ниже, или вручную операторами в случае, когда автоматическое определение всех исключений номеров АС не дает корректного результата. Хорошим примером этого является АС, не являющаяся в действительности ТДС, но эвристически рассматриваемая программой ASsimilator как покупающая прямой доступ от трех Национальных провайдеров. ASsimilator и программа верификации маршрута(184) не были бы в таком случае способны определить, что эта АС имелась на ТДС. Операторы, однако, могут принять во внимание дополнительные признаки и четко определить, что эта АС находится на ТДС. Программа верификации маршрута (184),известная как Routebot, обновляет и базу данных АС провайдеров (181) и базу данных исключений АС (182), если выясняется, что эвристический метод, используемый программойASsimilator, не способен обеспечить симметричной маршрутизации. Routebot запускается каждые пять минут. Программа верификации маршрута (184), входящая в состав Routebot,реализуется с помощью так называемого приложения Traceroute, или отслеживание маршрута. Отслеживание маршрута является средством протокола ПУП/МП для определения 29 маршрута (на момент работы программы отслеживания маршрута), по которому пакет проходит от исходной до конечной точки. Отслеживание маршрута не определяет обратный маршрут от получателя к отправителю. Для этого требуется вторичное использование отслеживания маршрута, при котором получатель рассматривался бы как отправитель пакета обратно на исходного отправителя. Отслеживаемый маршрут содержит все прыжки или маршрутизаторы ПУП/МП, через которые проходит пакет. Таким образом, программа верификации маршрута (184) может отслеживать маршрут от отправителя до получателя пакета и обратно и определять, является ли такая маршрутизация симметричной. Если это оказывается не так, то программа верификации маршрута (184) принимает решение о том, следует ли добавить или удалить номер АС из базы данных исключений номеров АС (182) для того, чтобы маршрутизация пакетов после загрузки новой базы данных в маршрутизатор стала симметричной. При наличии базы данных АС провайдеров(181) и базы данных исключений АС (182) становится возможным определить, какие заявки маршрутов от провайдеров ИТДС связаны с пользователями этих провайдеров. Это осуществляется путем объединения баз данных (181) и (182), удаления номеров АС поочередно каждого провайдера из этой общей базы данных и применения получающегося списка АС только к тем маршрутам, которые заявлялись этим провайдером. Последняя операция производится так, что маршруты, не соответствующие ни одной АС из получающегося списка, впоследствии рассматриваются как маршруты данного провайдера. Для простоты представим, что требуется определить все маршруты пользователей провайдера А. Рассмотрим воображаемую базу данных АС провайдеров: Провайдер А 12 Провайдер В 3 Провайдер С 45 Также рассмотрим следующую воображаемую базу данных исключений АС:Exceptions 67 Как сказано выше, эти две базы данных объединяются, в результате чего получается следующий список номеров АС: 1234567 После этого следует удалить из него номера АС того провайдера, маршруты которого требуется определить. В данном случае нам следует удалить номера АС провайдера А, после чего список приобретает следующий вид: 34567 30 Теперь эти маршруты и соответствующие им маршруты АС заявляются этим провайдером на ИТДС: Маршрут R1: 1 6 13 17 Маршрут R2: 1 2 19 21 Маршрут R3: 1 4 Следует отметить, что каждый маршрут от провайдера А заканчивается (при маршрутизации ПМИ концевой АС считается та, номер которой крайний слева, а начальной - та, номер которой крайний справа) одним из номеров АС провайдера А, найденных в базе данных АС провайдеров. По этой причине невозможно просто отсеять номера напрямую соединенных АС каждого провайдера для определения маршрутов этого провайдера: провайдер заявляет таблицу Интернет-маршрутов, и все маршруты заканчиваются номером АС этого провайдера. Теперь полученный список АС следует применить к каждому из маршрутов таким образом, чтобы маршрут не рассматривался частью провайдера А, если он содержит номер АС, находящийся в полученном списке номеров АС. Эта процедура известна как отрицание маршрутов. Все неотрицаемые маршруты считаются пользователями данного провайдера. Так, маршрут R1 отрицается, поскольку его очередность номеров АС содержит номер 6,который находится в полученном списке номеров АС. Маршрут R3 отрицается, поскольку его очередность номеров АС содержит номер 4,который также находится в полученном списке номеров АС. Маршрут R2, напротив, принимается, поскольку его очередность номеров АС не содержит номеров АС, которые находились бы в полученном списке номеров АС. Существует и другой алгоритм, который может применяться к маршрутам от каждого конкретного провайдера и использует другой набор баз данных. Вместо объединения баз данных номеров АС провайдеров и исключений,удаления номеров АС текущего провайдера и последующего отрицания маршрутов, в которых находятся те же номера АС, что и в полученном списке, альтернативный алгоритм создает список номеров АС каждого провайдера (текущую базу данных АС провайдеров (181 и всех номеров АС, имеющих пиринговые отношения с каждым провайдером, а затем разрешает (принимает) те маршруты от провайдера, которые соответствуют списку. Поскольку второй список (номера АС, имеющих пиринговые отношения с каждым провайдером) изменяется достаточно регулярно, второй алгоритм следует запускать более часто, чем первый, который, как было показано, эффективен. В настоящее время используется первый алгоритм. Снова рассмотрим фиг. 10. Возможность определить, какие маршруты от каждого провайдера являются маршрутами его пользователей, обеспечивает такую маршрутизацию, при которой пакеты проходят от отправителя А(167) до получателя В 1 (168) через провайдера пользователя В 1 (Национального провайдера(161. На фиг. 11 представлен также алгоритм длины АС ПАСС (185), который посылает данные в базу данных АС ПАСС (УВ) (англ.:ASPATH Prepend) провайдера (186), хранящуюся на сервере сетевого управления (144),показанном на фиг. 3. Длина маршрутов АС,заявленных ИТДС ее провайдерам, является одним из атрибутов протокола, который настраивается в соответствии с принципами настоящего изобретения для обеспечения симметричной маршрутизации ИТДС, как показано на фиг. 10. В соответствии с этой фигурой, модификация длин маршрутов АС обеспечивает, что маршрутизация от получателя В 2 (171) обратно на отправителя А (167) происходит по тому же маршруту, что и от отправителя А (167) до получателя В 2 (171). Модификация длины маршрута АС является способом увеличения и уменьшения расстояния получателя от ИТДС через всех провайдеров ИТДС. В этом случае расстояние определяется как количество АС в атрибуте АС ПАСС заявленного маршрута ПМИ 4. Например, получатель, определив, что ИТДС находится на расстоянии 10 от провайдера MCI, 7- от провайдера Sprint и 5 - от провайдера UUNet, выбирает маршрут с наименьшим количеством АС (в данном случае UUNet). Если получатель видит, что все обратные маршруты до отправителя имеют одинаковые длины, то способа контролировать, по какому маршруту пойдет трафик, не существует. Для обеспечения контроля за обратным трафиком на ИТДС и симметричной маршрутизации необходимо искусственно увеличить количество АС на маршрутах, заявленных ИТДС каждому из ее провайдеров таким образом, чтобы последовательность провайдеров по умолчанию, описанная выше, для трафика до получателя была такой же, что и для обратного трафика до ИТДС от того же получателя. Для каждого провайдера ИТДС это достигается умышленным увеличением расстояния (Prepending) до собственных номеров АС ИТДС в маршрутах, заявляемых каждому провайдеру, таким образом, чтобы при получении маршрутов получателями, не подключенными к провайдеру ИТДС, маршруты от текущего провайдера ИТДС по умолчанию были кратчайшими. Таким образом достигается симметричная маршрутизация в соответствии с принципами настоящего изобретения. Если порядок провайдеров ИТДС по умолчанию уже определен, то алгоритм длины маршрута АС ПАСС (185) определяет, какое количество номеров АС ИТДС следует включить в заявки о маршрутах, посылаемые каждому провайдеру. Каждый провайдер таким образом будет иметь свое собственное количество номеров АС ИТДС, которые должны присутствовать в маршрутах, посылаемых этому провайдеру. База 32 данных провайдера АС ПАСС (УВ) (186) может выглядеть примерно следующим образом:PSI 7 добавленных номеров АС На фиг. 11 прямоугольник (187) включает в себя ряд блоков, представляющих собой ряд шагов в блок-схеме, соответствующих операциям, необходимым для достижения симметричной маршрутизации в ИТДС в соответствии с настоящим изобретением. Первый шаг (188) включает в себя определение политики маршрутизации провайдера. Следует понимать, что ИТДС должна работать в соответствии с набором правил и стратегией маршрутизации, которые соответствуют принятой практике стека протоколов Интернет (Internet Protocol Suite). Существует план или документ политики маршрутизации, который определяет такие правила. Первый шаг (188) в блок-схеме программы определения политики маршрутизации провайдера включает в себя выработку таких правил. В рамках понятий ИТДС в соответствии с настоящим изобретением первое правило политик маршрутизации, которое должно быть выработано, это порядок провайдеров по умолчанию,от первичного до вторичного и так далее для всех провайдеров ИТДС. На основании этого списка каждому провайдеру присваиваются два разных значения ЛОКАЛ ПРЕФ (локальный приоритет). В рамках протокола ПМИ 4 атрибут ЛОКАЛ ПРЕФ представляет собой число, которое, не будучи заданным специально, по умолчанию принимается равным 100. Чем выше параметр LOCALPREF, присвоенный маршруту от определенной точки, тем более предпочтителен данный маршрут. Первый набор значений параметра ЛОКАЛ ПРЕФ содержит значения, присвоенные маршрутам, которые в соответствии с настоящим изобретением определяются как непосредственно подключенные к данному провайдеру. Второй набор значений параметра ЛОКАЛ ПРЕФ содержит значения, присваиваемые маршрутам,посланным данным провайдером, но определенным как не подключенные к нему непосредственно. Эти маршруты становятся маршрутами по умолчанию. Второй набор значений параметра ЛОКАЛ ПРЕФ должен начинаться со значения, которое ниже самых низких значений из первого набора. Значения параметра ЛОКАЛ 33 ПРЕФ из первого набора расположены в порядке убывания поскольку, как объяснено выше со ссылкой на фиг. 10, если получатель подключен к двум провайдерам ИТДС, то необходимо выбрать того провайдера ИТДС, который находится выше в этом списке. Значения параметра ЛОКАЛ ПРЕФ из второго набора расположены в порядке убывания, поскольку, как объяснено выше со ссылкой на фиг. 10, если получатель не подключен к провайдеру ИТДС, то необходимо выбрать провайдера ИТДС по умолчанию, который находится выше в этом списке. Упорядоченный список провайдеров и присвоенных им значений ЛОКАЛ ПРЕФ может выглядеть примерно следующим образом:PSI 80 5 Первый столбец значений ЛОКАЛ ПРЕФ содержит значения атрибута LOCALPREF,присвоенные маршрутам, которые определены как напрямую подключенные к каждому из провайдеров. Второй, самый правый столбец значений ЛОКАЛ ПРЕФ содержит значения атрибутаLOCALPREF, присвоенные всем остальным маршрутам от каждого из этих провайдеров. Такое упорядочение используется алгоритмом длины маршрута АС ПАСС (185) для определения соответствующего количества АС,которое необходимо послать вместе с маршрутами каждому провайдеру ИТДС, тем самым контролируя входящую маршрутизацию ИТДС. Дополнительными функциями политики маршрутизации, не относящимися непосредственно к настоящему изобретению, являются (1) использование протокола ПМИ версии 4; (2) запрет на посылку или получение маршрута Интернет по умолчанию (0.0.0.0) на или от какого-либо провайдера ИТДС и (3) запрет на посылку маршрутов провайдеров ИТДС, полученных от других провайдеров ИТДС. Второй шаг (189) блок-схемы на фиг. 11 необходим для создания обязательных базовых конфигураций маршрутизатора для каждого провайдера ИТДС. Эти базовые конфигурации (базовые конфигурации и дополнительные конфигурации, добавляемые процессами, реализуемыми в соответствии с настоящим изобретением) хранятся на сервере сетевого управления(144) на фиг. 3, а также загружены в соответствующие маршрутизаторы (105), (106) и (116). Базовая конфигурация для каждого конкретного провайдера ИТДС хранится только в том маршрутизаторе, к которому этот провайдер непо 003155 34 средственно подключен. Основная цель этого шага - трансформировать правила политики маршрутизации, выработанные на шаге (188), в соответствующие команды конфигурации маршрутизатора. Там, где это уместно, базовым конфигурациям маршрутизатора присваиваются флаги для включения этих базовых конфигураций в команды конфигурации, добавляемые на последующих шагах. Базовые конфигурации маршрутизатора,реализующие вышеописанные правила политики маршрутизации, могут выглядеть для каждого провайдера ИТДС следующим образом:match as-path заполняется на третьем шаге (190)set local-pref заполняется на первом шагеset local-pref заполняется на первом шагеset as-path prepend заполняется на четвертом шаге (191)match as-path заполняется на третьем шаге (190)set local-pref заполняется на первом шагеset local-pref заполняется на первом шагеset as-path prepend заполняется на четвертом шаге (191)match as-path заполняется на третьем шаге (190)set local-pref заполняется на первом шагеset local-pref заполняется на первом шагеset as-path prepend заполняется на четвертом шаге (191)match as-path заполняется на третьем шаге (190)set local-pref заполняется на первом шагеset local-pref заполняется на первом шагеset as-path prepend заполняется на четвертом шаге (191)match as-path заполняется на третьем шаге (190)set local-pref заполняется на первом шагеset local-pref заполняется на первом шагеset as-path prepend заполняется на четвертом шаге (191)match as-path заполняется на третьем шаге (190)set local-pref заполняется на первом шагеset local-pref заполняется на первом шагеset as-path prepend заполняется на четвертом шаге (191)match as-path заполняется на третьем шаге (190)set local-pref заполняется на первом шагеset local-pref заполняется на первом шаге(188) Видно, что для каждой базовой конфигурации провайдера ИТДС существуют следующие команды:neighborremote-as: Эта команда определяет удаленную автономную систему провайдера ИТДС, с которым ИТДС имеет пиринговые отношения.neighbor version: Эта команда требует от соседнего узла использовать ПМИ версии 4.neighbordistribute-list I out: Эта команда обеспечивает, что ИТДС не посылает маршрут Интернет по умолчанию (0.0.0.0) провайдерам ИТДС.neighbor distribute-list I in: Эта команда обеспечивает, что ИТДС не получает маршрут Интернет по умолчанию (0.0.0.0) от провайдеров ИТДС.neighborroute-map Провайдер-LОСАLРRЕF in: Эта команда обращается к набору команд, начинающихся со строки route-map Провайдер-LОСАL-РRЕF permit 10. Эти команды определяют значения LOCAL-PREF, которые должны быть присвоены маршрутам, полученным от данного провайдера ИТДС.route-map Провайдер-ASPATH-PREPEND out: Эта команда обращается к набору команд, начинающихся со строки route-map ПровайдерАSРАТН-PREPEND permit 10. Эти команды определяют номера АС, которые должны быть добавлены к маршрутам, посылаемым данному провайдеру ИТДС.permit 10: Этот фрагмент команды route-map(permit 10 в отличие от permit 20) присваивает соответствующее значение локального приоритета (из вышеприведенной таблицы) маршрутам, которые определены как непосредственно подключенные к данному провайдеру. Значениеset local-pref присваивается в момент создания базовой конфигурации маршрутизатора из колонки LOCALPREF(1) вышеприведенной таблицы. Атрибут match as-path присваивается на третьем шаге (190). Условие match сравнивает все отрицаемые номера АС для данного провайдера с номерами, включенными в маршрут, и присваивает это значение локального приоритета тем маршрутам, в которых нет ни одного такого номера АС. Как описано выше в рамках понятий настоящего изобретения, маршрут, в котором нет ни одного отрицаемого номера АС,является тем, который непосредственно подключен к данному провайдеру.permit 20: Этот фрагмент команды route-map присваивает соответствующее значение локального приоритета (из вышеприведенной таблицы) всем маршрутам, которые не проходят пер 003155 38 вый фрагмент команды route-map, т.е. все маршруты, подвергшиеся отрицанию на предыдущем шаге route-map или все маршруты, не подключенные к данному провайдеру непосредственно. Все маршруты, не прошедшие первый шаг route-map, подпадают под этот шаг. Значение set local-pref присваивается в момент создания базовой конфигурации маршрутизатора из колонки LOCALPREF(2) вышеприведенной таблицы.route-map добавляет соответствующее количество номеров АС ИТДС каждому маршруту,посылаемому каждому конкретному провайдеру. Значение set aspath-prepend присваивается на четвертом шаге (191). Команда match as-path 10 предписывает присвоение этого значения всем маршрутам, подходящим под параметр АС ПАСС, описываемый номером 10. Все остальные маршруты неявным образом отрицаются. В случае ИТДС as-path 10 представляет собой список всех номеров АС ИТДС и пользователей ИТДС. Таким образом, команда route-map реализует два требования: (1) разрешает заявлять провайдеру только маршруты ИТДС или пользователей ИТДС и (2) добавляет соответствующее количество дополнительных номеров АС к каждому из этих маршрутов. Третий шаг на блок-схеме на фиг. 11 необходим для создания списка отрицаемых номеров АС для каждого провайдера, трансформацию этого списка в соответствующие конфигурационные команды маршрутизатора, добавление этих команд в базовую конфигурацию маршрутизатора и занесение в базовые конфигурации значений указателя списка номеров АС (отмечено выше как заполняется на третьем шаге(190. При наличии списка отрицаемых номеров АС для каждого провайдера, созданного на основе объединения всех номеров АС провайдера и номеров АС исключений, как описано выше, с удаленным номерами АС текущего провайдера,окончательный список для провайдера UUNet может выглядеть так: 1239 1785 1790 1791 1792 1793 1794 1795 4000 4001 4002 4003 4004 4005 6174 6175 6176 6177 1800 1789 1784 6449 6637 3650 3651 3652 3972 3973 4950 4951 6153 6154 6242 3447 7882 4000 4999 6367 1801 5778 7308 3561 4286 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 145 3378 1673 1321 1326 1327 1328 1329 1330 1331 1332 1333 1334 1662 1671 1322 1323 1660 1335 1667 1670 1672 1674 1675 1683 1686 1687 1694 1324 1325 1665 1677 174 1280 2554 8013 4200 4993 2551 6996 2685 1 3914 568 6456 5761 4136 6113 286 6172 293 2041 4006 1740 3703 2828 39 В результате команды отрицания в конфигурации для провайдера UUNet могут выглядеть так: В результате к строке match as-path в команде route-map UUNET-LOCAL-PREF permit 10 прибавляется значение 20, поскольку именно оно присутствует в вышеприведенном списке отрицаний. Таким образом, строка будет выглядеть как match as-path 20. Четвертый шаг (191) в блок-схеме на фиг. 11 необходим для определения количества номеров АС, которые необходимо прибавить каждому провайдеру и заполняет поле значения вprepend принимает в качестве аргумента любое количество номеров АС текущей АС. Так, у провайдера UUNet нет команды route-map ASPATH-PREPEND, поскольку его количество добавленных АС равно нулю. В соответствии с вышеприведенным примером добавления номеров АС, у провайдера Sprint будет один добавленный номер АС, и его строка as-path prepend будет выглядеть так:as-path prepend 6993 где 6993 является номером АС текущей ИТДС. Аналогично вышеописанному способу добавления номеров АС, для остальных провайдеров команды as-path prepend будут выглядеть так:PSI: as-path prepend 6993 6993 6993 6993 6993 6993 6993 Пятый шаг (192) блок-схемы на фиг. 11 задает значения ЛОКАЛ ПРЕФ провайдера. Этот шаг (192) выполняется в момент установления соединения и представляет собой посылку провайдеру ИТДС по телефону или электронной почте информации о том, что необходимо предпринять шаги для установки его атрибута ЛОКАЛ ПРЕФ протокола ПМИ 4 для соединения с ИТДС более высоким, чем для маршрутов, полученных от ТДС. После установки атрибута ЛОКАЛ ПРЕФ он остается нетронутым на все время подключения провайдера к ИТДС. Шестой шаг (193) блок-схемы на фиг. 11 загружает все индивидуальные конфигурации маршрутизаторов провайдеров в маршрутизаторы, к которым подключены соответствующие провайдеры. В результате выполнения этого шага (193) файлы конфигурации маршрутизаторов, созданные на предшествующих шагах(188), (189), (190) и (191), оказываются загруженными в маршрутизаторы, подключенные к провайдерам. В предпочтительном способе использования изобретения, раскрываемом в настоящем описании, алгоритм Assimilator (180),загруженный в серверы сетевого управления(144) и (145) на фиг. 3, создает файлы конфигурации, выполняя последовательно шаги (188),(189), (190) и (191), показанные на фиг. 11, и созданные им файлы конфигурации загружаются в центральные маршрутизаторы (105), (106) и(116), показанные на фиг. 3 и 4, в соответствии с шагом (193), фиг. 11. Седьмой шаг (194) блок-схемы на фиг. 11 предписывает маршрутизатору получить полные пути от провайдера. Это осуществляется с помощью протокола ПМИ 4 в момент загрузки файлов конфигурации маршрутизаторов в центральные маршрутизаторы (105), (106) и (116), и 43 между ИТДС и провайдером ИТДС осуществляется обмен данными по данному протоколу ПМИ 4. Восьмой шаг (195) блок-схемы на фиг. 11 предписывает маршрутизатору применить файлы конфигурации провайдеров ИТДС к маршрутам. В предпочтительном способе использования настоящего изобретения с маршрутизаторами Cisco это производится с помощью команд конфигурации маршрутизатора, созданных на предшествующих шагах (188), (189), (190),(191) и (192). На фиг. 12 представлена блок-схема в соответствии с принципами настоящего изобретения, подробно показывающая шаги процесса верификации маршрута (184), фиг. 11. Верификация маршрута производится программным обеспечением, известным под названием Routebot. Программа Routebot является резидентной программой серверов сетевого управления (144) и (145). Routebot использует базы данных АС провайдеров (181) и исключений AC (182), показанных на фиг. 11. На фиг. 12 процесс верификации маршрута представлен в рамках шагов настоящего способа. Процесс начинается на блоке (200), помеченном как Начало. Блок (201) является первым шагом, помеченным Нахождение сервера отслеживания маршрута в каждой сети провайдера ИТДС. Как показано на фиг. 2, в предпочтительном способе использования настоящего изобретения ИТДС (100) подключена к семи провайдерам, а именно Sprint, MCI, UUNet, Netcom, PSI, AGIS и ANS. В сетях всех этих провайдеров необходимо найти сервер, поддерживающий программу отслеживания маршрута(traceroute), которая позволяет внешним провайдерам использовать ее для определения маршрутов до других получателей в сети Интернет. На сегодняшний день хорошая библиотека адресов общедоступных СЛЕМ-серверов находится по адресу http://www.broadwatch.com/isp.trace.htm. Программа СЛЕМ (англ.: traceroute) служит для отслеживания маршрута в пределах каждой сети провайдеров ИТДС. Как только в сетях какого-либо провайдера ИТДС обнаруживается приемлемый СЛЕМ-сервер, его адрес включается в программу Routebot. Остальные шаги, описанные на фиг. 12, представляют собой алгоритм, используемый программой Routebot для обновления базы данных исключений АС (182). Следующий шаг в ряду шагов, показанных на фиг. 12, - блок (202), помеченный Для каждого провайдера. Он означает, что процесс верификации маршрута будет осуществлен для всех провайдеров, приведенных на фиг. 2 в соответствии со списком, данным выше. В дальнейшем термин провайдер будет употребляться для обозначения текущего провайдера. Следующий шаг в этой последовательности блок (203), помеченный как Выполнить 44 СЛЕМ-Д для СЛЕМ-сервера провайдера. Таким образом, команда СЛЕМ-Д сервера сетевого управления (144), фиг. 3, применяется к СЛЕМ-серверу текущего провайдера. Команда СЛЕМ-Д (англ.: prtraceroute) - это дополненная версия программы СЛЕМ, которая присваивает номера АС каждому прыжку. В предпочтительном способе использования настоящего изобретения такая команда, будучи использованной для отслеживания текущего СЛЕМсервера, выдаст следующий результат: В первой колонке даны номера прыжков, во второй - номера АС текущего прыжка,в третьей - IP-адрес или имя домена (если имеется) текущего прыжка, в четвертой - IP-адрес текущего прыжка, а в пятой - управляющий флаг, не используемый для целей настоящего изобретения. Данный результат показывает маршрут, по которому проходит пакет от ИТДС до СЛЕМ-сервера, находящегося в сетях провайдера Sprrint. Набор АС для такого маршрута будет выглядеть как 6993 6993 1239 1239 1790 1239 1239 1239. Следующий шаг, показанный на фиг. 12,представляет собой блок (204), помеченный Определить наличие более чем одного провайдера ИТДС на маршруте АС. Блок (204) сравнивает маршрут АС, пришедший обратно от программы СЛЕМ, с базой данный АС провайдеров (181). Целью этого шага является определение наличие более чем одного провайдера ИТДС на этом маршруте. В вышеприведенном примере номер 6993 соответствует ИТДС, 1239- провайдеру Sprint и 1790 - ему же. Таким образом, при отслеживании маршрута от ИТДС до получателя пересекается только этот провайдер. После шага (204) следует блок ветвления (205). На нем проверяется условие Более одного провайдера ИТДС на маршруте АС. Если ответ отрицательный (как в примере выше), то следующим выполняется шаг (206). Шаг (206) определяется как Использовать СЛЕМ-сервер провайдера для отслеживания обратного маршрута на ИТДС и запустить программу СЛЕМ-Д. Возвращаясь к шагу (203),отметим, что на нем определяется исходящий маршрут от ИТДС до СЛЕМ-сервера провайдера. На шаге (206) определяется обратный маршрут и выдается в качестве результата. Поскольку СЛЕМ-серверы провайдеров в большинстве случаев не запускают программу СЛЕМ-Д, данные, выдаваемые ими, необходимо пропускать через программу СЛЕМ-Д. Результат, выдаваемый СЛЕМ-сервером провайдераSprint на ИТДС после пропускания через программу СЛЕМ-Д может быть следующим: Номера АС такого маршрута будут 1239 1239 1239 1790 1239 1239 6993 6993. Следующий шаг (207) помечен как Определить наличие более чем одного провайдера ИТДС на маршруте АС. Этот шаг аналогичен шагу(204), за исключением того, что он оперирует обратным маршрутом от провайдера до ИТДС. После шага (207) следует блок ветвления (208). Как и в предыдущем шаге ветвления (205), на нем проверяется условие Более одного провайдера на маршруте АС. Если ответ положительный, то следующим выполняется очередной шаг проверки условия (210). На нем проверяется условие Существует ли подключение провайдера к ИТДС в настоящее время. Если ответ положительный, то выполняется шаг (211). Если же соединение ИТДС с провайдером во время работы программы СЛЕМ по какой-либо причине отсутствует, результат будет некорректным, поскольку придется маршрутизировать трафик через резервных провайдеров ИТДС до восстановления данного соединения. В этом случае проблем не возникает. Однако, если соединение провайдера с ИТДС существует во время нахождения программы на этом шаге, то возникает проблема, которая не может быть решена программой Routebox автоматически. Блок (211) помечен как Послать почту в Центр управления сетью. Так, если маршрут от ИТДС до провайдера правилен, но обратный маршрут от провайдера неправилен и соединение с провайдером в настоящее время существует, то посылается сообщение по электронной почте, и оператор может проверить и решить данную проблему. Возвратимся на первый блок ветвления(205). Если ответ на вопрос проверки его условия положительный, то выполняется блок ветвления (212). Так, при отслеживании маршрута от ИТДС до провайдера и обнаружении более одного провайдера ИТДС на маршруте программа приходит к блоку ветвления (212). Результат, выдаваемый программой СЛЕМ-Д при наличии более чем одного провайдера на маршруте, будет выглядеть так: 46 Номера АС на этом маршруте будут следующие: 6993 3993 701 701 701 1239 1239 3914. Поскольку номер 701 значится в базе данных номеров АС провайдеров (181) как принадлежащий провайдеру UUNet, a 1239 - провайдеруSprint, этот маршрут проходит через более чем двух провайдеров ИТДС. Блок ветвления (212) проверяет условие Существует ли подключение провайдера к ИТДС в настоящее время Если ответ отрицательный, то такой маршрут приемлем. Если сеть провайдера в данное время недоступна, то ИТДС должна маршрутизировать трафик на получателя на текущем провайдере по умолчанию, и результатом будет вышеприведенный маршрут. Тогда программа переходит на шаг(213). На нем проверяется условие Есть ли еще провайдеры Если ответ отрицательный (все провайдеры ИТДС на этом уже проверены), то программа останавливается на блоке (214)(Конец). Если ответ на вопрос блока (213) положительный, то программа возвращается на шаг (202), и алгоритм переходит на следующего провайдера из списка. Если на вопрос блока(208) получен отрицательный ответ, то программа переходит на блок (213) и проверяет условие Есть ли еще провайдеры Если, как и выше, ответ отрицательный, то программа останавливается на блоке (214) (Конец). Если ответ на вопрос блока (210) отрицательный, то программа переходит на блок ветвления (213). Если ответ на вопрос блока (212) положительный, то программа переходит на блок (217),помеченный как Начать поиск маршрутов АС от АС получателя назад на АС ИТДС (справа налево). Этот шаг является началом внутреннего цикла, который выполняется для каждого номера АС на маршруте справа налево. Вышеприведенный список состоит из строк от 1 до 8 сверху вниз. Однако, номера АС маршрута следует представлять в виде слева направо. Таким образом, беря за основу этот маршрут АС (6993 3993 701 701 701 1239 1239 3914), цикл следует начать с крайнего правого номера АС (3914) и проходить по нему до крайнего левого номера(6993). Для каждого номера АС, начиная с этого шага, программа выходит на блок (218), помеченный как Определить, принадлежит ли данная АС провайдеру ИТДС. Это означает поиск текущего номера АС в базе данных номеров АС провайдеров (181) на предмет совпадения его с номером АС провайдера ИТДС. С этого шага программа переходит на блок ветвления (220),помеченный как Принадлежит ли АС провайдеру ИТДС Если ответ отрицательный, то программа переходит на блок ветвления (224),помеченный Есть ли еще номера АС в маршруте Если ответ положительный, то программа возвращается на блок (217) и выполняет вышеприведенные шаги для следующего номера АС. Если же ответ отрицательный, то программа переходит на другой блок ветвления(225), проверяющий условие Есть ли еще провайдеры Если ответ отрицательный, то программа останавливается на блоке (226) (Конец). Если же ответ положительный, то программа возвращается обратно на блок (202) и выполняет алгоритм для следующего провайдера. Если ответ на вопрос блока (220) положительный, то программа переходит на следующий блок (221), помеченный Вернуться на только что проверенный номер АС, не принадлежащий провайдеру. В приведенном примере положительный ответ на вопрос блока (220) дается в том случае, если программа проходит номер АС 3914 и переходит на номер 1239. Наличие этого номера в базе данных номеров АС провайдеров говорит о том, что он принадлежит провайдеру Sprint. Таким образом, шаг (221) предписывает программе вернуться на предыдущий номер АС (3914). С шага (221) программа переходит на шаг (222), помеченный как Проверить, есть ли номер АС в базе данных исключений. Таким образом, для проверки наличия номера АС 3914 в базе данных исключений проводится его поиск в этой базе данных. После этого программа переходит на блок ветвления (223), помеченный как Есть ли номер АС в базе данных исключений. Если ответ положительный, то, следовательно, номер АС 3914 был неоправданно включен в базу данных исключений (182) алгоритмом Assimilator (180),поскольку если номер АС существует в базе данных исключений (182), то предполагается,что АС с этим номером в данное время не подключена напрямую ни к какому провайдеру ИТДС. Если маршрутизация осуществляется как в вышеописанном случае, то очевидно, что трафик должен посылаться напрямую на провайдера Sprint, но вместо этого был направлен на провайдера по умолчанию UUNet. Таким образом, если номер AS3914 был удален из базы данных исключений (182), поскольку его маршруты имеют тэг 1239 (как имеющие соединение с провайдером Sprint), то маршрутизатор увидит номер АС AS3914 как напрямую подключенный к провайдеру Sprint и будет направлять трафик через этого провайдера. Если ответ на вопрос шага (223) положительный, то программа переходит на шаг (216), на котором некорректный номер АС удаляется из базы данных исключений (182). После этого программа переходит на блок ветвления (213), описанный выше. Если ответ на вопрос шага (223) отрицательный, то программа переходит на шаг (215),помеченный как Послать почту в Центр управления сетью. Обнаружена проблема в маршрутизации. Это означает, что обнаружена проблема, требующая вмешательства оператора. После шага (215) алгоритм переходит на шаг 48 На фиг. 13 и 14 приведена блок-схема,подробно показывающая шаги алгоритма ASsimilator (180), фиг. 11. На фиг. 13 последовательность шагов начинается с блока (230), помеченного как Начало. На первом шаге (231),помеченном как Загрузить данные АС провайдеров, алгоритм инициируется. На этом шаге все карты провайдеров и АС из базы данных АС провайдеров (181) загружаются в память. На следующем шаге (232), помеченном как Для каждого номера АС в списке, соответствующего каждому провайдеру, начинается двойной цикл, первая часть которого проходит по всем провайдерам в базе данных АС провайдеров(181), а вторая - по всем номерам АС, в данный момент приписанным к каждому провайдеру. Следующий шаг (233) помечен как Использовать программу ИНФУДАС (англ.: whois ) для поиска информации по удаленной АС. Служебная программа ИНФУДАС поиска в Интернет-директориях используется для получения информации по текущему номеру АС текущего провайдера. Как указано в запросе на комментарий (Request For Comment, RFC) (954), программа ИНФУДАС позволяет пользователю на отдельной машине получить информацию об удаленной системе. При выполнении программы ИНФУДАС для поиска информации по АС имя удаленной системы становится rs. internic.net, представляющей собой сервер InterNIC(233) программа переходит на блок ветвления(234), помеченный как Относится ли информация по АС к провайдеру Информация, выдаваемая программой ИНФУДАС, имеет примерно следующий вид:Database list updated on 7-Aug-97 04:30:06 EDT. Запись, подобная данной, для каждого номера АС просматривается при поиске имени текущего провайдера. Если имя текущего провайдера в записи не найдено, то ответ на вопрос шага (234) отрицательный и программа переходит на шаг (235), помеченный как Удалить АС из списка АС провайдера. Это означает, что по 49 какой-то причине данный номер АС был ранее зарегистрирован на данного провайдера, но более не принадлежит ему, и поэтому этот номер АС должен быть удален из базы данных АС провайдеров (181). После этого программа переходит на другой блок ветвления (236), помеченный как Еще номера АС для обработки. Если ответ на вопрос шага (234) положительный, то программа также переходит на блок ветвления (236). С него, если для текущего провайдера имеются дополнительные номера АС и в списке имеются дополнительные провайдеры для проверки, программа переходит обратно на шаг (232). Если ответ на вопрос шага (236) отрицательный, то это означает, что программа уже закончила проверку актуальности всех текущих карт провайдеров и АС. Алгоритм выполняется таким образом, что в случае его первого запуска база данных АС провайдеров (181) должна быть просто первоначально заполнена номерами непосредственно подключенных АС каждого провайдера. Каждый последующий раз,когда запускается этот алгоритм, данные сначала проверяются, неверные данные удаляются, и на их место записываются новые данные. Если ответ на вопрос шага (236) отрицательный, то программа переходит на шаг (237),помеченный Получить и обработать дамп таблиц маршрутов от каждого провайдера. Этот шаг обращается ко всем центральным маршрутизаторам (105), (106) и (116), фиг. 3, и загружает все атрибуты АС ПАСС, присвоенные каждому маршруту каждого маршрутизатора. После этого список маршрутов АС сортируется по провайдерам ИТДС и повторяющиеся атрибуты удаляются. Получаемый список выглядит примерно следующим образом: 1239 1 3749 1239 1 3790 1239 1 3801 1239 1 3909 3909 1239 1 4151 1239 1 4355 1239 1 4454 1239 1 4550 1239 1 4766 3559 1239 1 4766 3559 4060 1239 1 4766 4660 1239 1 49 1239 1 4926 1239 1 4926 4270 5692 1239 1 5000 5000 5660 5660 5660 5660 5660 5660 5660 1239 1 5388 1239 1 5494 1239 1 5623 1239 1 5623 6905 1239 1 5684 1239 1 5691 1239 1 5691 35 1239 1 5723 1239 1 5727 2713 2915 50 1239 1 5727 4631 1239 1 5727 4742 4742 1239 1 6 1239 1 6059 1239 1 6203 и т.д. В настоящее время существует 9209 таких маршрутов, которые обрабатываются каждый раз при запуске этого алгоритма, и их число может меняться ежечасно. После шага (237) программа переходит на шаг (238), помеченный как Для каждого атрибута АС ПАСС из дампа. Шаг (237) представляет собой начало цикла, который выполняется для каждого маршрута АС из дампа таблицы маршрутов, описанного выше. С шага (238) программа переходит на шаг (240), помеченный как Для каждого номера АС в АС ПАСС (L-R,Forward-Path). Этот блок показывает, что внутри каждого маршрута АС по каждому номеру АС будет выполняться цикл с движением слева направо по маршруту. Так, если маршрут имеет АС 1239 1 6203, то первый номер АС, который будет обработан, будет 1239, а последний 6203. Следует отметить, что это прямо противоположно процедуре верификации маршрута(184), фиг. 11, которая работает справа налево по маршруту АС. С шага (240) программа переходит на блок ветвления (241), помеченный Первый номер АС в АС ПАССЕсли текущий номер AC - первый в обрабатываемом маршруте АС, то ответ на этот вопрос положительный, и программа переходит на блок (245),помеченный Искать АС в базе данных АС провайдера для определения провайдера, заявившего этот АС ПАСС. Первый номер АС в любом маршруте АС будет напрямую подключенным номером АС какого-либо провайдера ИТДС. Таким образом, выполняя поиск первого номера АС в маршруте из базы данных АС провайдеров(181), можно определить провайдера, который заявил маршрут с таким порядком номеров АС. После этого программа переходит на блок ветвления (247), помеченный Еще номера АС в АС ПАССТаким образом, при движении слева направо по номерам АС в данном маршруте,если обнаруживаются дополнительные номера АС, подлежащие обработке, то ответ на этот вопрос будет положительным и программа вернется на шаг (240). Если больше нет никаких номеров АС в текущем маршруте АС, то ответ на вопрос будет отрицательным и программа переходит на блок ветвления (248), помеченный Еще АС ПАССЕсли есть еще маршруты АС в дампе таблицы маршрутизации, то ответ на вопрос шага (248) положительный и программа возвращается на шаг (238). Если ответ на вопрос шага (241) отрицательный, то программа переходит на шаг (242),помеченный Использовать программу ИНФУДАС для поиска информации по АС. Так же,как уже существующая база данных АС провай 51 деров (181) проверялась ранее, каждый номер АС после первого номера в каждом маршруте АС ищется с помощью программы ИНФУДАС,и имя текущего провайдера (найденного при поиске первого номера АС в базе данных АС провайдеров (181 ищется в записи, получаемой в результате. С этого шага программа переходит на блок ветвления (243), помеченный как Соответствует ли информация по АС провайдеру АС ПАССЕсли имя провайдера совпадает с полученной от программы ИНФУДАС записью, то ответ на этот вопрос положительный и программа переходит на шаг (244), помеченный как Добавить номер АС в базу данных АС провайдера, если не существует. Таким образом, если текущий провайдер найден в записи, полученной от программы ИНФУДАС по текущему номеру АС в текущем маршруте, то текущий номер АС добавляется в базу данных АС провайдеров (181) в набор АС текущего провайдера. После этого программа переходит на шаг (247), описанный выше. Если при проверке на шаге (243) выясняется, что текущий номер АС не соответствует провайдеру и ответ на вопрос этого шага (243) отрицательный, то программа переходит на шаг (246), помеченный как Увеличить счетчик текущего номера АС. После этого программа переходит на блок ветвления (248), описанный выше. Таким образом,если текущий номер АС не найден в списке АС текущего провайдера, то обработка по текущему маршруту АС может быть прекращена. Способ в соответствии с данным изобретением обрабатывает только номера АС, принадлежащие провайдерам ИТДС. Для каждой пары номер AC / провайдер ведется счетчик, служащий для реализации эвристического механизма в рамках программы ASsimilator, при котором любая АС,являющаяся соседней для более чем трех провайдеров АС, считается имеющей пиринговые отношения с провайдерами на ТДС и, следовательно, включается в базу данных исключений АС (182). Возвращаемся к шагу (248). Если программа обработала все маршруты АС из дампа таблицы маршрутов, то следующим шагом является блок (250) на фиг. 14, помеченный Для каждого номера АС со счетчиком, на котором определяется, какие встреченные номера АС, не являющиеся провайдерами, следует добавить в базу данных исключений АС (182). С шага (250) программа переходит на блок ветвления (251),помеченный Счетчик 3. Таким образом,если для текущего встреченного номера АС обнаруживается подключение к более чем трем провайдерам, то ответ на вопрос положительный и программа переходит на блок (252), помеченный Добавить АС в базу данных исключений АС. После этого программа останавливается на блоке (254), помеченном Конец. Если ответ на вопрос блока (251) отрицательный, то программа переходит на другой блок 52 ветвления (253), помеченный Еще номера АС со счетчиком Если встречаются дополнительные номера АС, отвечающие этому условию, и,следовательно, ответ на вопрос положительный,то программа возвращается на шаг (250). Если дополнительных номеров АС со счетчиком больше 3 непосредственно после номера АС провайдера не обнаружено и ответ на вопрос отрицательный, то программа останавливается на блоке (254) Конец. На фиг. 15 представлена блок-схема, показывающая шаги процедуры определения количества номеров АС ИТДС, которые необходимо добавить к маршрутам, заявленным каждому провайдеру. Эта блок-схема является детализацией алгоритма длины маршрута АС ПАСС(185), показанного на фиг. 11. Процесс начинается с блока (260), помеченного Начало. Первый шаг (261) помечен Для каждого провайдера. Это означает начало цикла, который будет выполняться для каждого провайдера ИТДС,обозначаемого здесь как провайдер. После этого программа переходит на блок (262), помеченный как Перейти на любую общедоступную ТДС и получить образец маршрута ИТДС от провайдера. На ТДС установлены общедоступные серверы, позволяющие осуществлять поиск любых маршрутов Интернет с сервера,имеющего пиринговые отношения с несколькими провайдерами на ТДС. Таким образом,принцип заключается в том, чтобы просматривать маршрут, заявленный ТДС провайдеру и затем заявленный провайдером общедоступной ТДС. В ИТДС в соответствии с настоящим изобретением существует маршрут ПУП/МП 206.253.192.0/19, который заявляется всем провайдерам ИТДС и затем заявляется ими на ТДС. От ТДС этот маршрут и его соответствующие маршруты АС (один для каждого провайдера) выглядят следующим образом: ПМИ routing table entry for 206.253.192. 0/19, version 1013580 701 6 993 4200 6993 6993 6993 6993 6993 6993 6993 1239 6993 6993 2551 6993 6993 6993 6993 6993 6993 6993 6993 3561 6993 6993 6993 6993 1673 1331 6993 6993 6993 6993 6993 174 6993 6993 6993 6993 6993 6993 6993 6993 6993 Так выглядит маршрут после выполнения данного алгоритма и обнаружения соответствующего числа добавлений маршрутов АС. Позиции таблицы маршрутов, подобные этой, могут быть найдены на общедоступном сервере маршрутов Интернет, например http://nitrous.digex.net. После определения того, в каком месте сети сервера маршрутов делается запрос на маршрут (обычно на одной из общедоступных ТДС), следует просто набрать маршрут, который необходимо проверить, и ожидать ответа. 53 Предположим, что перед добавлением дополнительных маршрутов АС имеется следующий список маршрутов АС для маршрута 206.253.192.0/19: 701 6993 1239 1661 6993 3561 6993 1673 1331 1211 1213 1214 1215 1216 1217 1218 6993 4200 6993 2551 6993 174 6993 В вышеприведенном примере маршрут,соответствующий 701 - это UUNet, 1239 -Sprint,3561 - MCI, 1673 - ANS, 4200 - AGIS, 2551 Netcom и 174 - PSI. Шаг (262) выбирает один из вышеприведенных маршрутов АС в зависимости от того, какой из провайдеров анализируется в данный момент. После этого программа переходит на блок(263), помеченный Запросить длину АС ПАСС для данного образца маршрута, обозначаемую как ДЛИНА (англ.: PAPL). Для каждого провайдера существует значение ДЛИНА, являющееся длиной маршрута АС этого провайдера в образце маршрута. После этого программа переходит на блок ветвления (264), помеченный Еще провайдеры. Если есть дополнительные провайдеры, подлежащие обработке, то программа возвращается на шаг (261). Если дополнительных провайдеров нет, то, в соответствии с данным примером, значения ДЛИНА для каждого провайдера выгладят следующим образом: ДЛИНА[UUNеt]: 2 ДЛИНА[Sprint]: 3 ДЛИНА[МСI]: 2 ДЛИHA[ANS]: 10 ДЛИНА[АGIS]: 2 ДЛИНА[Nеtcom]: 2 ДЛИНА[РSI]: 2 Если ответ на вопрос шага (264) отрицательный, и значения ДЛИНА для каждого провайдера соответствуют вышеприведенным, то программа переходит на блок (265), помеченный Для каждого провайдера в порядке убывания приоритета (см. политику маршрутизации) получить значения ДЛИНА (ДЛИНАО). На этом шаге программа начинает первый из двух циклов, который проходит по всем провайдерам ИТДС в порядке убывания приоритета в соответствии с политикой маршрутизации, определенной на первом шаге (188) на фиг. 11. Этот список провайдеров для ИТДС в соответствии с настоящим изобретением выглядит так: 1. UUNet 2. Sprint 3. MCI 4. ANS 5. AGIS 6. Netcom 7. PSI 54 Первый провайдер, который будет обработан на шаге (265), это UUNet, вторым будетSprint и так далее до PSI. Значение ДЛИНА текущего провайдера присваивается временной переменной, называемой ДЛИНАО. После этого программа переходит на шаг (266), помеченный Для всех остальных провайдеров, за исключением обработанных в основном цикле, получить значение ДЛИНА (ДЛИНАI). Таким образом,данный внутренний цикл просматривает всех провайдеров, за исключением текущего, и пропускает тех, которые были обработаны в первом цикле. Следовательно при первом выполнении внешнего цикла UUNet является провайдером внешнего цикла, a Sprint, MCI, ANS, AGIS, Netcom и PSI - провайдерами внутреннего цикла. При втором выполнении внешнего цикла Sprint является провайдером внешнего цикла, a MCI,ANS, AGIS, Netcom и PSI - провайдерами внутреннего цикла. Следует обратить внимание на то, что при втором выполнении внешнего цикла провайдер UUNet уже не является провайдером внутреннего цикла, поскольку он уже был обработан на внешнем цикле и поэтому в этом внутреннем цикле не используется. Так продолжается до тех пор, пока внутренний цикл не будет выполнен для всех провайдеров ИТДС. На шаге(266) при каждом прохождении внутреннего цикла значение ДЛИНА текущего провайдера внутреннего цикла присваивается временной переменной ДЛИНАI. После этого программа переходит на блок ветвления (267), помеченный как ДЛИНАОДЛИНАI Это означает проверку того, превышает ли значение ДЛИНА текущего провайдера внешнего цикла значение ДЛИНА текущего провайдера внутреннего цикла. Если ответ отрицательный, то программа возвращается на шаг (266) для обработки следующего провайдера внутреннего цикла. Если значение ДЛИНА текущего провайдера внешнего цикла меньше,чем значение ДЛИНА текущего провайдера внутреннего цикла, то никаких действий выполнять не требуется, поскольку внешний цикл управляет первичным порядком провайдеров(следует помнить о том, что чем короче маршрут АС, тем предпочтительнее провайдер). Таким образом, если значение ДЛИНА текущего провайдера внешнего цикла равно 2 и он более предпочтителен, чем провайдер внутреннего цикла со значением ДЛИНА, равным 4, то никаких действий не требуется, поскольку у провайдера внешнего цикла значение ДЛИНА и так предполагается меньшим. Если же ответ на вопрос шага (267) положительный, то программа переходит на шаг(268). На нем провайдер внешнего цикла изначально предполагается более предпочтительным, но у текущего провайдера внутреннего цикла значение ДЛИНА меньше, и поэтому более предпочтительным должен был бы стать именно он. Это несоответствие необходимо ис 55 править таким образом, чтобы длина маршрута менее предпочтительного провайдера стала больше. Это осуществляется на шаге (268) по формуле, отмеченной на соответствующем ему блоке: ДЛИНАО = ДЛИНАI + 1. Таким образом, если провайдер внешнего цикла имеет значение ДЛИНА, равное 4, а провайдер внутреннего цикла имеет значение ДЛИНА, равное 2, то новое значение ДЛИНА провайдера внутреннего цикла становится 4+1=5. Значение ДЛИНА = 5 больше, чем ДЛИНА = 4 для провайдера внешнего цикла, поэтому предпочтительным будет провайдер внешнего цикла. Данное значение ДЛИНАI сохраняется как значение ДЛИНА текущего провайдера, так что в следующий раз при сравнении того же самого провайдера внутреннего цикла с другим провайдером внешнего цикла его значение 5 будет больше,чем текущее значение 2. Каждый раз при генерации нового значения ДЛИНАI на шаге (268) программа переходит на блок ветвления (270),помеченный как Еще провайдеры во внутреннем цикле Если во внутреннем цикле текущего внешнего цикла находятся дополнительные провайдеры, то ответ на вопрос шага (270) положительный и программа возвращается на шаг(266), чтобы продолжить работу со следующим провайдером внутреннего цикла. Если ответ отрицательный, то программа переходит на другой блок ветвления (271), помеченный как Еще провайдеры во внешнем цикле Если во внешнем цикле есть дополнительные провайдеры, то ответ на вопрос шага (271) положительный и программа возвращается на шаг (265). Если ответ на вопрос шага (271) отрицательный, то программа переходит на шаг (272). Если представить этот процесс визуально с использованием в качестве примеров вышеприведенных значений ДЛИНА, то каждый раз при прохождении внешнего цикла значения ДЛИНА каждого провайдера будут выглядеть так: При переходе на шаг (272), помеченный Запомнить разность между исходным и новым значением ДЛИНА каждого провайдера, исходное значение ДЛИНА в начале процесса вычитается из текущего значения ДЛИНА после прохождения двух циклов. Получаемое значение сохраняется в базе данных АС ПАСС (УВ) провайдера (186). Таким образом, используя вышеприведенный пример, значения, которые необходимо загрузить в базу данных АС ПАСС(УВ) провайдера (186), можно представить следующим образом:PSI 13-2= 11 После этого программа останавливается на блоке (273), помеченном как Конец. На фиг. 16 представлена блок-схема в соответствии с принципами настоящего изобретения, подробно показывающая шаги процесса определения политики маршрутизации на первом шаге (188),фиг. 11. Процесс начинается на блоке (274), помеченном как Начало. Блок (275) - первый шаг, помеченный Определить базовую политику маршрутизации. Это - шаг, на котором программа определяет, какой базовый набор принятых правил маршрутизации в сети Интернет по протоколу ПМИ 4 следует использовать. Как обсуждалось выше, рассматриваются следующие вопросы: (1) Какую версию протокола ПМИ использовать (версия 4 в настоящий момент является единственной принятой версией);(2) разрешать ли посылку и получение маршрута Интернет по умолчанию (0.0.0.0) и (3) применять ли фильтрование для обеспечения того,чтобы маршруты одного провайдера не заявлялись другому. После этого программа переходит на шаг (276), помеченный Определить порядок провайдеров по умолчанию. На этом шаге определяется последовательность провайдеров по умолчанию от первого и так далее в порядке убывания приоритета. После этого программа переходит на блок (277),помеченный Определить исходное значениеLOCALPREF. Этим значением может быть любое действительное значение ЛОКАЛ ПРЕФ протокола ПМИ 4. По умолчанию используется значение параметра, равное 100. Это значение будет присвоено наиболее предпочтительному из всех провайдеров. После этого программа переходит на блок (278), помеченный Для каждого провайдера в порядке убывания приоритета. На этом шаге начинается цикл, который будет выполняться для всех провайдеров в порядке, определенном на шаге (276). После этого программа переходит на шаг (279), помеченный как Определить значение ЛОКАЛ ПРЕФ для провайдера, которое меньше, чем значение ЛОКАЛ ПРЕФ предыдущего провайдера или меньше исходного значения ЛОКАЛ ПРЕФ при первом запуске данного цикла. Таким образом,при первом выполнении этого цикла значение ЛОКАЛ ПРЕФ должно быть выбрано меньшим, 57 чем значение LOCALPREF, определенное на шаге (277). Если это выполнение цикла не первое, то значение ЛОКАЛ ПРЕФ должно быть выбрано меньшим, чем значение ЛОКАЛ ПРЕФ предыдущего провайдера. После этого программа переходит на блок (280), помеченный как Записать значение ЛОКАЛ ПРЕФ провайдера в категории LOCALPREF(1). Как обсуждалось выше, существует два набора значений-это те значения, которые присвоены маршрутам, определенным как непосредственно подключенные к каждому провайдеру. В этом цикле все присвоенные значения ЛОКАЛ ПРЕФ записываются в этой категории для текущего провайдера. После этого программа переходит на блок ветвления (281), помеченный как Еще провайдеры по умолчанию Если такие провайдеры существуют и подлежат обработке в данном цикле, то ответ на вопрос положительный и программа возвращается на шаг (278). Если ответ на вопрос шага (281) отрицательный, то программа переходит на шаг (320),помеченный как Определить исходное значение LOCALPREF, меньшее, чем последнее значение LOCALPREF. На этом шаге начинается присвоение второго набора значений LOCALPREF, которые должны начинаться со значения, меньшего, чем наименьшее из первого набора, поскольку эти значения присваиваются маршрутам, не подключенным непосредственно к провайдерам и, следовательно, используемым только в случаях недоступности первых. Исходное значение ЛОКАЛ ПРЕФ из этого набора должно быть меньше последнего значения LOCALPREF, присвоенного в предыдущем цикле. После этого программа переходит на шаг (321), помеченный Для всех провайдеров в порядке убывания приоритета. Как и ранее, на этом шаге начинается второй цикл, в котором обработка каждого провайдера ИТДС происходит в порядке убывания приоритета. После этого программа переходит на шаг (322),помеченный Определить значение ЛОКАЛ ПРЕФ для провайдера, которое меньше, чем значение ЛОКАЛ ПРЕФ предыдущего провайдера или меньше исходного значения ЛОКАЛ ПРЕФ при первом запуске данного цикла. Эта операция выполняется в точности так же, как и шаг (279), описанный выше, с единственным отличием в том, что исходная ее точка при первом запуске цикла - шаг (320). После этого программа переходит на шаг (323), помеченный как Записать значение ЛОКАЛ ПРЕФ для провайдера в категории LOCALPREF(2). Это - второй набор значений ЛОКАЛ ПРЕФ (LOCALPREF(2, присваиваемых всем маршрутам провайдеров, не подключенным к ним непосредственно. В этом цикле все присвоенные значения ЛОКАЛ ПРЕФ записываются в этой категории для текущего провайдера. После этого программа переходит на блок ветвления(324), помеченный как Еще провайдеры по умолчанию Если такие провайдеры существуют и подлежат обработке в данном цикле, то ответ на вопрос положительный и программа возвращается на шаг (321). Если же ответ отрицательный, то программа останавливается на блоке (325). Результатом этой процедуры является таблица, уже обсужденная выше:PSI 80 5 В третьей колонке приведены значения атрибута LOCALPREF, присвоенные маршрутам,которые определены как непосредственно подключенные к провайдерам. В четвертой колонке приведены значения атрибута LOCALPREF, присвоенные всем остальным маршрутам провайдеров. На фиг. 17 представлена блок-схема, показывающая шаги процесса создания и указания ссылок на команды отрицания в индивидуальных базовых конфигурациях для каждого провайдера. Эта блок-схема начинается на третьем шаге (190) на фиг. 11, помеченном Добавить конфигурации ЛОКАЛ ПРЕФ ИТДС. Процедура, иллюстрируемая на фиг. 17, начинается на блоке (282), помеченном как Начало. Первый шаг (283) помечен как Для каждого провайдера. Это означает начало внешнего цикла, который будет вносить дополнения в файлы конфигурации каждого провайдера ИТДС. После этого программа переходит на шаг (284), помеченный как Получить индивидуальный номер списка. Каждый список номеров АС в конфигурации маршрутизатора должен иметь индивидуальный номер соответствующего типа. Для маршрутизаторов Cisco списки номеров АС должны иметь номера от 1 до 99. Поскольку данный шаг является первым шагом цикла для каждого провайдера, он требует, чтобы у каждого списка АС провайдеров был свой номер. После этого программа переходит на шаг (285),помеченный как Для всех остальных провайдеров. Здесь начинается внутренний цикл, который просматривает всех провайдеров за исключением текущего. Таким образом, если внешний цикл в данный момент находится на провайдере UUNet, то внутренний цикл должен будет просмотреть провайдеров Sprint, MCI,ANS, Netcom, AGIS и PSI. Порядок просмотра провайдеров во внешнем или внутреннем циклах не имеет значения, хотя, поскольку провайдеры уже упорядочены в соответствии с поли 59 тикой маршрутизации, их просмотр в существующем порядке будет равнозначен любому иному. После этого программа переходит на шаг (286), помеченный как Искать в базе данных АС провайдеров все значения АС, соответствующие другому провайдеру. Это означает,что для текущего провайдера внутреннего цикла программа ищет все номера АС, которые соответствуют этому провайдеру в базе данных АС провайдеров (181). После этого программа переходит на шаг (287), помеченный как Создать команду отрицания АС ПАСС для каждого значения АС с использованием индивидуального номера списка. Для каждого из номеров АС,выданных программой в результате выполнения поиска на шаге (286), создается команда отрицания АС ПАСС с использованием индивидуального номера списка, созданного на шаге(284). При использовании ИТДС в соответствии с настоящим изобретением, если текущий провайдер внутреннего цикла Netcom, то выданные номера АС будут 2551 и 6993. Предположим также, что текущий индивидуальный номер списка - 20. В результате индивидуальные команды отрицания АС ПАСС для маршрутизатора Cisco и текущего провайдера внутреннего цикла Netcom будут следующими:ip as-path access-list deny 6993 После этого программа переходит на шаг(288), помеченный как Добавить все команды отрицания АС ПАСС в индивидуальный файл конфигурации провайдера. На этом шаге все уже обсужденные команды отрицания добавляются в индивидуальный файл конфигурации провайдера. После этого программа переходит на блок ветвления (289), помеченный Еще провайдеры Если есть дополнительные провайдеры, подлежащие обработке в данном цикле, то ответ на этот вопрос положительный и программа возвращается на шаг (285). Если ответ отрицательный, то программа переходит на блок (290), помеченный как Искать в базе данных исключений АС все значения исключений АС. Перед шагом (290) внутренний цикл, начинающийся на шаге (285) и кончающийся на блоке ветвления (289), производит ранее обсужденное действие объединения базы данных АС провайдеров (181) и удаления номеров АС текущего провайдера. При переходе на шаг (290) на предмет всех этих данных запрашивается база данных исключений АС. После этого программа переходит на шаг (291), помеченный как Создать команду отрицания АС ПАСС для каждого значения АС с использованием индивидуального номера списка. На этом шаге создаются команды отрицания аналогично шагу(287) с использованием того же самого номера списка (поскольку программа в данный момент работает с тем же провайдеров внешнего цикла). После этого программа переходит на блок(292), помеченный Добавить все команды от 003155 60 рицания АС ПАСС в индивидуальный файл конфигурации провайдера. Этот шаг аналогичен шагу (288). После этого программа переходит на шаг (293), помеченный как Загрузить индивидуальный номер списка в подкомандуmatch as-path соответствующей команды routemap. Как обсуждалось выше, конфигурация для каждого провайдера имеет команду конфигурации Cisco, называемую route-map, помеченную как Провайдер-LОСАL-PREF. В этой команде route map находится подкоманда matchas-path заполняется на шаге. Шаг (293) вносит индивидуальный номер списка, созданный на шаге (284), в эту команду match as-path. Например, команда ЛОКАЛ ПРЕФ route-map для провайдера MCI выглядела бы так:set local-preference 25 где список номер 20 - список команд отрицания для MCI, созданный в процессе, описанном на фиг. 17. Как описывалось ранее, первая часть команды route-map присваивает одно значение локального приоритета всем маршрутам, которые, как предполагается, напрямую подключены к провайдеру, а вторая часть присваивает значение локального приоритета по умолчанию всем маршрутам, которые не отвечают требованию первой части команды. После этого программа переходит на блок ветвления (294), помеченный как Еще провайдеры Если есть еще провайдеры, которых следует пройти в данном внешнем цикле, то ответ на вопрос шага(294) положительный и программа возвращается на шаг (283). Если ответ отрицательный, то программа останавливается на шаге (295). На фиг. 18 представлена блок-схема, показывающая шаги процесса добавления соответствующего количества АС к маршрутам, заявленным каждому из провайдеров. Эта блоксхема подробно описывает шаг 4 (191) на фиг. 11 конфигурирования длины АС ПАСС. Процесс начинается на блоке (300), помеченном как Начало. Первый шаг (301) помечен как Для каждого провайдера. Это - начало цикла, который выполняется один раз для каждого провайдера. Требования какого-либо особого порядка обработки провайдеров не существует. После этого программа переходит на шаг (302), помеченный как Определить количество добавлений АС для данного провайдера. Это означает,что производится поиск для текущего провайдера в базе данных АС ПАСС (УВ) провайдеров(186) для определения количества номеров АС,которые необходимо добавить для этого провайдера. Как описывалось выше, база данных
МПК / Метки
МПК: H04L 12/56
Метки: маршрутизатор, интернет-маршрутов, точки, соединения, доступа, провайдеров, сети, индивидуальной
Код ссылки
<a href="https://eas.patents.su/30-3155-marshrutizator-individualnojj-tochki-dostupa-k-seti-dlya-soedineniya-provajjderov-internet-marshrutov.html" rel="bookmark" title="База патентов Евразийского Союза">Маршрутизатор индивидуальной точки доступа к сети для соединения провайдеров интернет-маршрутов</a>
Система для обеспечения глобального портативного доступа к сети интернет с использованием низкоорбитального спутника земли и спутниковой системы прямого радиовещания
Номер патента: 1943
Опубликовано: 22.10.2001
Автор: Ротблатт Мартин А.
МПК: H04L 12/00
Метки: системы, спутника, глобального, земли, спутниковой, портативного, доступа, интернет, система, низкоорбитального, прямого, радиовещания, использованием, сети, обеспечения
Формула / Реферат:
1. Система для обеспечения портативного доступа к компьютерной сети, содержащая спутниковую систему прямого радиовещания, содержащую первый спутник и вещательную станцию для передачи вещательных программ к первому спутнику, пользовательский терминал, содержащий приемник сигналов прямого радиовещания для приема вещательных программ, передаваемых от первого спутника, шлюз для обеспечения обслуживания компьютерной сети, и канал связи между...
Система для избирательной загрузки информации из сети интернет в пользовательские терминалы с использованием спутниковой системы радиовещания
Номер патента: 2330
Опубликовано: 25.04.2002
Автор: Кампанелла С.Джозеф
МПК: H04N 7/10
Метки: информации, пользовательские, избирательной, использованием, система, системы, терминалы, радиовещания, загрузки, интернет, сети, спутниковой
Формула / Реферат:
1. Система для обеспечения пользовательских терминалов информацией, по меньшей мере, от одной удаленной коммуникационной сети, содержащая приемник, спутник, выполненный с возможностью приема канала широковещательной передачи, содержащего пакеты, включающие упомянутую информацию, относящуюся, по меньшей мере, к одной из множества тем, при этом канал широковещательной передачи содержит данные, указывающие, какой из пакетов соответствует какой из...
Способ и система обеспечения доступа к информации в сети
Номер патента: 2932
Опубликовано: 31.10.2002
Авторы: Осаку Тейзо, Есинага Есихиро
МПК: G06F 17/30, H04L 29/06
Метки: сети, доступа, система, обеспечения, способ, информации
Формула / Реферат:
1. Система, предназначенная для осуществления доступа к сетевой информации с использованием упрощенной сетевой адресации, содержащая a) платформу, имеющую сетевой доступ, которая воспринимает вводимую информацию, предназначенную для осуществления доступа к сетевой информации; b) средство, предназначенное для приема упрощенного сетевого адреса, соответствующего сетевому адресу информации; c) базу данных, определяющую соответствия между...
Способ и система многопротокольной оптимизации телекоммуникационных маршрутов
Номер патента: 1507
Опубликовано: 23.04.2001
Авторы: Маккарти Уильям Ф., Каплан Аллен Д.
МПК: H04M 7/00
Метки: маршрутов, система, многопротокольной, оптимизации, телекоммуникационных, способ
Формула / Реферат:
1. Способ оптимизации выбора телекоммуникационного маршрута для передачи файла данных удаленному адресату с помощью телекоммуникационной системы коммутации, включающей множество интерфейсов, каждый из которых взаимосвязан с ассоциированным телекоммуникационным маршрутом, имеющим заданные параметры, хранящиеся в запоминающем устройстве в системе коммутации, и переменные параметры, включающий операции: а) измерения переменных параметров для...
Способ и устройство для определения рабочей точки нелинейного усилителя канала связи
Номер патента: 2214
Опубликовано: 28.02.2002
Авторы: Бетшайдер Герхард, Арле Ги
МПК: H04B 17/00
Метки: рабочей, связи, определения, усилителя, способ, нелинейного, устройство, канала, точки
Формула / Реферат:
1. Способ для определения рабочей точки нелинейного усилителя канала связи, через который передается сигнал полезной нагрузки с предварительно определенным уровнем, содержащим следующие этапы: генерацию первого псевдошумового сигнала PN(t), модуляцию сигнала чистой несущей f(t) упомянутым первым псевдошумовым сигналом PN(t), для генерирования сигнала модулированной ПШ чистой несущей s(t), передачу упомянутого сигнала модулированной ПШ чистой...
Предыдущий патент: Клапан для выдачи
Следующий патент: Система и способ обновления удаленной базы данных в сети
Случайный патент: Способ лечения заболевания дыхательных путей, пищевая композиция и способ получения пищевой и лечебной композиций