Быстрое установление соединения для доступа к сети

Быстрое установление соединения для доступа к сети

Иллюстрации

Показать все

Реферат

Настоящая Заявка на патент заявляет приоритет Предварительной заявки США № 60/592 470, озаглавленной "Method and Apparatus for Fast Packet Data Session Establishment", зарегистрированной 30 июля 2004 года и назначенной правопреемнику этой заявки, и таким образом явно содержится в данном документе посредством ссылки.

I. Область техники, к которой относится изобретение

Настоящее изобретение, в общем, относится к передачам пакетов данных, а более конкретно к первоначальным сеансам связи перед установлением соединения передачи пакетных данных для доступа к сети.

II. Предшествующий уровень техники

Глобальное взаимодействие сетей позволяет информации быть быстро доступной независимо от географических расстояний. Фиг. 1 показывает упрощенный схематический чертеж глобального соединения сетей, обычно именуемого как Интернет, обозначенный ссылкой с номером 20. Интернет 20 является, в сущности, многими сетями с разными уровнями иерархии, связанными вместе. Интернет 20 работает по IP (протоколу Интернета), опубликованному IETF (инженерной проблемной группой Интернет). Детали IP могут быть найдены в RFC (Запросы на комментарии) 791, опубликованные IETF.

Подсоединенными к Интернету 20 являются разные отдельные сети, иногда называемые LAN (локальные вычислительные сети) или WAN (глобальные вычислительные сети) в зависимости от размеров сети. Показанные на фиг. 1 являются некоторыми из таких сетей 22, 24 и 26.

В каждой из сетей 22, 24 и 26 могут быть разные части оборудования, соединенные с и во взаимодействии друг с другом. Примерами являются компьютеры, принтеры и серверы, если назвать только немногие, которые обычно называются узлами. Когда узел осуществляет связь за пределами своей собственной сети через Интернет 20, узлу должен быть назначен IP-адрес. Назначение IP-адреса может быть ручным или автоматическим. Ручное назначение IP-адреса может быть выполнено сетевым администратором, например. Более часто, IP-адрес назначается автоматически, например, выделенным сервером в LAN.

Возьмем пример для иллюстрации. Предположим, что узел 30 в сети 22 пытается отправить пакет данных другому узлу 34 в сети 24. Под управлением IP каждый пакет данных должен иметь адрес источника и адрес получателя. В этом случае адрес источника - это адрес узла 30 в сети 22. Адрес получателя - это адрес узла 34 в сети 24.

Очень часто требуются соединения узел-узел перед доступом к сети, такой как Интернет 20. Например, предположим, что узел 30 в сети 22 является портативным компьютером. Узел 30 портативного компьютера не имеет прямого доступа к сети 22. Тем не менее узел 30 портативного компьютера может связаться с NAS (сервером доступа к сети) 32 в сети 22 через некоторые другие средства, например, посредством коммутируемого вызова проводного модема через телефонную линию. В этом случае, узел 30 типично устанавливает сеанс PPP (протокол точка-точка) с NAS (сервером доступа к сети) 32 в сети 22. Передачи пакетов данных после того, как установлены между узлом 30 и сетью 22 или любыми другими сетями через Интернет 20, будут проходить через проводной модем и телефонную линию. Если модем передает и принимает сигналы последовательно и асинхронно через телефонную линию, пакеты данных, передаваемые по телефонной линии, также должны быть соответственно разбиты на кадры, чтобы удовлетворять требованиям последовательной и асинхронной модемной линии связи.

Приход беспроводных технологий позволяет узлам перемещаться из своей первоначально зарегистрированной сети в другую сеть. Например, обращаясь опять к фиг. 1, узел 30 вместо постоянно связанного проводом с сетью 22 может быть беспроводным устройством, таким как PDA (персональный цифровой помощник), сотовым телефоном или мобильным компьютером. Беспроводной узел 30 может передвигаться за границы своей домашней сети 22. Таким образом, узел 30 может передвигаться далеко от своей домашней сети 22 в чужую сеть 26. Чтобы получить доступ к сети 26 или быть соединенным с другими сетями через Интернет 20, узел 30 также типично устанавливает PPP-сеанс с NAS (сервером доступа к сети) 33 в сети 26. Связь между узлом 30 и NAS 33 в этом случае существует через радиоканал. С другой стороны, пакеты данных, передаваемые между узлом 30 и беспроводной сетью, также должны быть разбиты на кадры, чтобы умещаться в формат, который установлен во время PPP-сеанса между узлом 30 и NAS 33 через радиоканал.

Основная часть PPP описывается в RFC 1661 и 1662, опубликованных IETF. PPP является протоколом взаимодействия равноправных систем, в котором оба узла являются равноправными. То есть, никто не принимает на себя роль ни клиента, ни сервера. Каждая сторона может запросить действия или выполнить действия по отношению к другой. По существу, PPP является исследовательским и договаривающимся сеансом между узлами, во время которого узлы узнают о ресурсах друг друга в терминах возможностей и доступности и окончательно приближаются к тому, чтобы установить взаимно приемлемые варианты параметров, прежде какого-либо потока сетевого трафика.

Фиг. 2 показывает блок-схему последовательности примерного PPP-сеанса 34 связи, в котором узел 30 в сети 26 стремится установить канал связи (прим: соединение, канал связи - любой вид коммуникационного пути между двумя компьютерами (получателем и отправителем данных)) с NAS 32 для получения доступа к Интернету 20.

PPP имеет ряд компонентов протокола. В примерном PPP-сеансе, показанном на фиг. 2, PPP имеет LCP (протокол управления соединением) 36, CHAP (протокол аутентификации по методу "вызов-приветствие") 38 и IPCP (протокол конфигурации протокола Интернета) 40 в качестве компонентов.

Сначала, после завершения установления физического канала связи, то есть узел 30 и NAS 33 способны связаться друг с другом на аппаратном уровне, например, есть необходимость пройти через LCP 36. LCP 36 служит цели установления основного канала связи между узлом 30 и NAS 33. Во время LCP 36 узел 30 и NAS 33 обмениваются и обсуждают необходимые варианты параметров связи друг с другом. Варианты могут включать в себя максимальный размер пакета данных в канале связи, параметры, относящиеся к управлению качеством, используемую схему сжатия поля HDLC (высокоуровневый протокол управления каналом передачи данных) заголовка и готов ли равноправный участник сети быть аутентифицированным.

Процессы для LCP 36 более или менее работают по этикету "рукопожатия" (квитирования запросов). Сначала запрашивающая сторона предлагает один или более параметров, отправляя сообщение запроса конфигурации. Если какой-либо параметр не распознается принимающей стороной, принимающая сторона отвечает обратно с помощью сообщения отклонения конфигурации. Если отвергнутый параметр является критическим для искомого канала связи, запрашивающая сторона тогда должна прекратить PPP-сеанс.

С другой стороны, если параметр распознается, но вариант, относящийся к параметру, неприемлем, отвечающая сторона отправляет обратно сообщение об отсутствии подтверждения приема конфигурации. Запрашивающая сторона снова может либо завершить PPP-сеанс, либо отправить другое сообщение запроса конфигурации с другим вариантом для того же параметра.

Как упомянуто ранее, PPP является протоколом взаимодействия равноправных систем. Либо узел 30, либо NAS 33 может быть запрашивающей стороной. То же самое считается истинным для роли отвечающей стороны. Все параметры с ассоциативно связанными вариантами должны быть обсуждены и отрегулированы таким образом, как описано выше. Может потребоваться несколько циклов согласования, как показано на фиг. 2. Общая схема согласования в своей основе является односторонним процессом. Если запрашивающая сторона определяет, что все необходимые параметры являются приемлемыми для отвечающей стороны, запрашивающая сторона отправляет финальное сообщение о подтверждении приема конфигурации отвечающей стороне. После того как обе стороны отправили сообщения подтверждения приема конфигурации, они затем переходят к фазе аутентификации.

Чтобы гарантировать, что стороны авторизованы, должна быть выполнена аутентификация. Одним способом выполнить аутентификацию является использовать другой PPP-компонент CHAP 38. Это типично NAS 33, который инициирует CHAP 38, чтобы проверить идентичность узла 30. Во время CHAP 38 NAS 33 отправляет сообщение, называемое сообщением вызова, узлу 30. Под управлением CHAP существует совместно используемый секрет, который используется вместе с сообщением вызова, который используется, чтобы вычислить ответное сообщение с использованием предварительно согласованного алгоритма. Узел 30 затем отправляет ответное сообщение, сгенерированное секретным алгоритмом, к NAS 33. NAS 33 после этого сравнивает принятое ответное сообщение с сообщением, вычисленным самим NAS 33. Если сравнение указывает совпадение, узлу 30 говорится перейти к CHAP 38, в котором NAS 33 отправляет сообщение об успехе CHAP узлу 30. Иначе сервером NAS 33 отправляется сообщение о неудаче CHAP.

Альтернативно, вместо CHAP 38 аутентификация может быть выполнена посредством прохождения через PAP (протокол аутентификации по паролю). В PAP узел просто отправляет NAS 33 имя пользователя и пароль для проверки. Если подтверждено, узлу 30 говорится перейти к PAP.

Если узлу 30 нужен IP-доступ, информация, относящаяся к IP, опять должна быть передана и согласована. Например, среди прочего узлу 30 может быть необходимо иметь назначение IP-адреса для того, чтобы получить доступ к Интернет 20 (фиг. 1) в соответствии с IP. Чтобы достичь этой цели, начинается согласование и обмен вариантов параметров по IPCP 40. В примерном PPP-сеансе 34 узел 30 первоначально запрашивает IP-адрес 0.0.0.0 у NAS 33. В ответ NAS 33 отправляет сообщение об отсутствии подтверждения приема конфигурации, предлагая узлу 30 использовать IP-адрес a.b.c.d. Если принято, узел 30 подтверждает использование IP-адреса a.b.c.d, отправляя NAS 33 другое сообщение для подтверждения приема.

В конечном счете, когда узел 30 согласовывает все параметры, обсужденные во время IPCP 40, узел 30 отправляет сообщение о подтверждении приема к NAS 33. Впоследствии передаются пользовательские данные сеанса доступа к сети. IP-пакеты данных сетевого трафика инкапсулируются в PPP-кадры с параметрами и согласовываются во время LCP 36 ранее.

В конце доступа к сети либо узел 30, либо NAS 33 может отправить сообщение запроса завершения другому, который после этого отвечает обратно сообщением подтверждения завершения и заканчивает сеанс связи.

Как может быть видно на фиг. 2 и описано выше, в самом деле существует ряд сообщений, передаваемых между узлом 30 и NAS 33 во время PPP-сеанса 34. По существу, затрачивается значительная продолжительность времени. Это особенно верно, если PPP-сеанс 34 согласовывается по медленному каналу связи с высокой латентностью данных.

Соответственно, существует необходимость предоставить более быстрый и более эффективный способ установления первоначальных каналов связи перед любыми следующими уровнями трафика данных.

Сущность изобретения

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

Кроме того, могут быть осуществлены возможности обработки отказа, при которых, если сеанс связи в соответствии с примерным вариантом осуществления изобретения не может быть установлен, может быть принят традиционный PPP (протокол точка-точка), чтобы продолжить сеанс связи.

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

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

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

Краткое описание чертежей

Фиг. 1 - схематический чертеж глобального соединения сетей.

Фиг. 2 - схема последовательности соединения сеанса связи традиционного протокола.

Фиг. 3 - схематический чертеж узлов, затронутых в примерном варианте осуществления изобретения.

Фиг. 4 - схематический чертеж, показывающий стек протоколов в иерархическом порядке.

Фиг. 5 - схема последовательности соединения сеанса связи в соответствии с примерным вариантом осуществления изобретения.

Фиг. 6 - блок-схема, показывающая этапы, подразумеваемые в соответствии с примерным вариантом осуществления изобретения.

Фиг. 7 - схема последовательности соединения, показывающая примерный вариант осуществления, выполненный с возможностями обработки отказа по отношению к традиционному протоколу.

Фиг. 8 - соответствующая блок-схема для схемы последовательности соединения на фиг. 7.

Фиг. 9 - схема другой последовательности связи, показывающая примерный вариант осуществления, выполненный с другой возможностью обработки отказа по отношению к традиционному протоколу.

Фиг. 10 - соответствующая блок-схема для схемы последовательности соединения на фиг. 9.

Фиг. 11 - схематический чертеж части схемы узла, стремящегося получить доступ к сети в соответствии с примерным вариантом осуществления.

Фиг. 12 - схема последовательности соединения сеанса связи на фиг. 1, осуществленного с дополнительными типами сообщений.

Фиг. 13 - схематический чертеж части схемы узла, стремящегося получить доступ к сети в соответствии с примерным вариантом осуществления.

Фиг. 14 - схематический чертеж части схемы узла доступа к сети в соответствии с примерным вариантом осуществления.

Подробное описание вариантов изобретения

Последующее описание предоставлено для того, чтобы позволить любому специалисту в данной области техники реализовать и использовать изобретение. Детали изложены в последующем описании в целях объяснения. Должно быть оценено, что обычный специалист в данной области техники поймет, что изобретение может быть применено на практике без использования этих конкретных деталей. В других случаях хорошо известные структуры и процессы не разрабатываются в деталях для того, чтобы не загромождать описание изобретения излишними деталями. Таким образом, настоящее изобретение не предназначено, чтобы быть ограниченным показанными вариантами осуществления, а должно согласовываться с самой широкой областью применения, согласованной с принципами и признаками, раскрытыми в данном документе.

Фиг. 3 показывает упрощенный схематический чертеж узлов, затронутых в примерном варианте осуществления изобретения. Общая система связи обозначается ссылкой с номером 42. В этом варианте осуществления система 42 связи включает в себя сеть 48, соединенную с базовой сетью 50, которая может быть интранетом или Интернетом. В сети 48 располагается NAS (сервер доступа к сети), который служит в качестве шлюза между сетью 48 и любым узлом, который стремится получить доступ к сети. В системе 42 предполагается, что существует такой узел 44, который ищет доступ либо к сети 48, либо к другим сетям (не показаны) через базовую сеть 50. Узел 44 связывается с NAS 46 через канал 45 связи.

Канал 44 связи может иметь разные формы. Назовем только несколько, например канал 44 связи может быть проводным каналом связи, таким как традиционное телефонное проводное соединение, каналом связи по коаксиальному кабелю или каналом связи по оптическому кабелю. Кроме того, канал 45 связи может также быть беспроводным каналом связи. В этом случае канал 45 связи является радиоинтерфейсом.

В этом варианте осуществления предполагается, что канал 45 связи является радиоинтерфейсом. Узел 44 является мобильным устройством, которое связывается с NAS 46 беспроводным образом. Сеть 48 поддерживает беспроводные технологии, такие как стандарты cdma2000, как изложено TIA/EIA (Ассоциацией изготовителей средств связи/ассоциацией электронной промышленности). NAS 46 в этом случае является PDSN (узлом обслуживания передачи пакетных данных), соединенным с RAN (сеть радиодоступа), которая осуществляет связь с узлом 44 через RF (радиочастотные) сигналы по радиоканалу 45. PDSN и RAN известны в данной области техники и не показаны на фиг. 3 по соображениям ясности и краткости.

Перед описанием операционных деталей системы 42 связи он поможет объяснить сначала различные типы протоколов с разными уровнями иерархии и их взаимными отношениями.

В области сетевых коммуникаций протоколы располагаются в иерархии в соответствии с OSI-моделью (взаимодействие открытых систем), как изложено ISO (Международной организацией по стандартизации) и ITU-T (Сектором по стандартизации Международного союза электросвязи). Целью является облегчить взаимодействие оборудования от разных поставщиков. То есть, каждый уровень иерархии протоколов имеет свои собственные спецификации. По существу, пока спецификации отдельного уровня иерархии удовлетворяются, гарантируется, что разработки продуктов на этом уровне должны быть совместимы с другими продуктами на других уровнях.

Предполагается, что система 42 на фиг. 3 поддерживает IP (протокол Интернета). Фиг. 4 схематически показывает стек протоколов в иерархическом порядке, обычно именуемый как "стек протоколов", и в общем обозначаемый ссылкой с номером 52. Стек 52 IP-протоколов структурирован в соответствии с IETF (инженерная проблемная группа Интернет) моделью, которая похожа, но не точно такая же, что и модель OSI. В соответствии с IETF-моделью стек 52 протоколов IP имеет пять уровней, начиная с уровня 1 до уровня 5. Таким образом, пакет данных, отправленный узлом, таким как узел 44 или 46, показанный на фиг. 3, должен быть обработан стеком 52 протоколов. Стек протоколов 52 создается в узле в форме программного или аппаратного обеспечения или их комбинации. Также пакет данных, принятый тем же узлом, должен быть обработан стеком 52 протоколов, но в обратном порядке.

Возьмем пример для иллюстрации. Предполагается, что пакет данных обрабатывается для того, чтобы быть отправленным из узла, такого как узел 44 или 46 (фиг. 3), пакет данных сначала создается в соответствии с одним из протоколов на уровне приложений, т. е. уровне 5. Уровень 5 включает в себя HTTP (протокол передачи гипертекста), SMTP (простой протокол пересылки электронной почты), FTP (протокол передачи файлов) и RTP (транспортный протокол реального времени). Дополнительно предполагается, что пакет данных является продуктом VoIP (передача голоса по протоколу Интернет) сеанса. Пакет данных таким образом должен быть отформатирован в соответствии с RTP на уровне 5.

Чувствительные ко времени пакеты данных, такие как пакеты данных, полученные в результате из протокола RTP на уровне 5, должны быть обработаны в реальном времени. Конкретно, поврежденные пакеты обычно не пересылаются, а вместо этого просто пропускаются, так чтобы не затруднять передачи других исходящих пакетов данных. RTP пакеты данных поэтому обычно передаются через UDP (протокол пользовательских дейтаграмм) на уровне 4, транспортном уровне. Соответственно, пакет данных из RTP на уровне 5 далее должен быть сформулирован в соответствии с UDP на уровне 4.

С другой стороны, если пакет данных создается из других протоколов на уровне 5, таких как FTP, пакет данных обычно отправляется через TCP (протокол управления передачей) на уровне 4. Под управлением TCP важное значение имеет точная доставка пакета данных. По существу, поврежденные пакеты всегда пересылаются, хотя, возможно, замедляют общий процесс передачи данных.

Пакеты данных после прохождения через этот транспортный уровень, уровень 4, дополняются информацией, такой как номера портов источника и получателя.

Пакет данных после прохождения через транспортный уровень, уровень 4, затем отправляется сетевому уровню, уровню 3, для обработки. В этом частном случае, результирующий пакет данных из уровня 4 должен быть опять отформатирован в соответствии с IP, например, с добавленными адресами источника и получателя пакета данных.

Должно быть отмечено, что по соображениям краткости на уровне 3 показан только IP на фиг. 4. Существуют другие протоколы, которые выполняют дополнительные к IP функции, также существующие на уровне 3. Примером является ICMP (протокол управляющих сообщений сети Интернет), который служит в целях отправки сообщений об ошибках для недоставленных пакетов данных.

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

Самый нижний уровень стека 52 протокола на фиг. 4 - это физический уровень, уровень 1, который имеет дело с физическим осуществлением передачи пакета данных. Например, если канал 45 связи (фиг. 3) является традиционным проводным каналом связи, физический уровень, уровень 1, имеет отношение к аппаратной схеме в обоих узлах 44 и 46 (фиг. 3), возбуждающей сигналы через провода, которые составляют канал 45 связи. Если канал 45 связи представлен радиоинтерфейсом, физический уровень, уровень 1, относится к воздушному пространству и аппаратной схеме в обоих узлах 44 и 46 (фиг. 3), принимающей и передающей сигналы по воздушному пространству.

Что касается пакета данных, принятого узлом, таким как узел 44 и 46 (фиг. 3), пакет данных должен быть обработан таким же стеком 52 протоколов, но в обратном порядке, то есть от уровня 1 к уровню 5.

Теперь ссылка возвращается к фиг. 3. В этом примере предполагается, что узел 44 стремится получить доступ к сети через NAS 46. Перед каким-либо обменом сообщениями физический канал 45 связи должен быть готов передавать сигналы. Выражаясь иначе, физический уровень, уровень 1 узлов 44 и 45, должен физически присутствовать и быть установленным.

В этом варианте осуществления, как упоминалось ранее, канал 45 связи является радиоинтерфейсом, а беспроводной технологией, поддерживаемой сетью 48, является cdma2000. Физический уровень имеет дело с беспроводной схемой в узле 44 и RAN в NAS 46. RAN может включать в себя, по меньшей мере, один BSC (контроллер базовой станции) и множество BS (базовых станций). RAN, BSC и BS не показаны на фиг. 3.

В соответствии с этим вариантом осуществления после того, как физический уровень, уровень 1, установлен, то есть оба узла 44 и 46 обнаружили взаимное физическое присутствие друг друга, NAS 46 немедленно отправляет первое сообщение узлу 44.

Фиг. 5 является блок-схемой, показывающей последовательность передачи сообщений между узлом 44 и NAS 46. Общий поток процесса обозначается ссылкой с номером 54.

Первое сообщение называется сообщением синхронизации и обозначается ссылкой с номером 56. Сообщение 56 синхронизации включает в себя все возможные варианты аутентификации для узла 44, чтобы выбрать из них. Варианты могут включать в себя сообщение вызова по CHAP (протоколу аутентификации по методу "вызов-приветствие") и запрос пароля и имени пользователя, требуемых протоколом PAP (протоколом аутентификации по паролю). В сообщение 56 синхронизации также должны быть включены отличные от CHAP и PAP другие протоколы аутентификации, которые определены и поддерживаются в PPP.

После приема сообщения 56 синхронизации узел 44 отвечает сообщением 58 запроса, как показано на фиг. 5.

В сообщение 58 запроса узел 44 включает необходимую информацию аутентификации в ответ на запросы, как изложено в сообщении 56 синхронизации. Кроме того, узел 44 также включает в сообщение 58 запроса все варианты параметров, необходимые для установления канала связи узла 44 для последующего доступа к сети через NAS 46. Не делается различие, относятся ли параметры с ассоциативно связанными вариантами к конфигурации канала связи, аутентификации или контролю доступа к сети. То есть, вместо классификации параметров согласно функциям компонентов протокола, таких как LCP (протокол управления каналом связи), CHAP (протокол аутентификации по методу "вызов-приветствие") и IPCP (протокол управления протоколом Интернета), как описано ранее по отношению к PPP, в сообщении 58 запроса этого варианта осуществления все параметры с вариантами включаются независимо от функций. Более конкретно, параметры с вариантами в сообщении 58 запроса могут включать в себя ответ на сообщение вызова, или имя пользователя и пароль, если применимо, параметры конфигурации канала 45 связи, такие как размер дейтаграммы и схему сжатия поля HDLC-заголовка (высокоуровневый протокол управления каналом передачи данных), так же как и все параметры для доступа к сети, такие как IP-адрес, конфигурацию DNS (доменная система имен) и протокол сжатия IP-заголовка, если применимо, и так далее.

Должно быть отмечено, что сообщение 58 запроса предпочтительно формируется с намеренной избыточностью в терминах выбора, так чтобы позволить NAS 46 выбрать варианты, которые поддерживаются обоими узлами 30 и 46, таким образом позволяя обоим узлам 44 и 46 быстро закончить общий процесс первоначального установления канала связи. Из разнообразия альтернатив NAS 46 может выборочно выделить параметры с ассоциативно связанными вариантами, которые очевидно поддерживаются, в целях увеличения вероятности успешного канала связи, таким образом сокращая время установки. Выражаясь иначе, сообщение 58 запроса, по существу, действует как сообщение объявления со всеми доступными вариантами параметров, поддерживаемых узлом 44, в котором выбор поднабора вариантов посредством NAS 46 должен позволить осуществление процесса соединения.

Соответственно, как показано на фиг. 5, NAS 46 отвечает сообщением 60 ответа после приема сообщения 58 запроса. В сообщении 60 ответа NAS 46 выбирает варианты из различных альтернатив. Сообщение 60 ответа включает в себя выбранные варианты параметров с их ассоциативно связанными значениями конфигурации. Очень часто сообщение 60 ответа является последним сообщением, необходимым перед началом сетевого трафика от узла 44.

В отличие от способов других протоколов, таких как PPP-протокол точка-точка, описанный ранее, в соответствии с этим вариантом осуществления нет необходимости в каких-либо сообщениях подтверждения, чтобы подтверждать прием или не подтверждать прием. По существу, в ответ на любое сообщение, будь это сообщение 56 синхронизации, сообщение 58 запроса или сообщение 60 ответа, ни Ack-, ни Nak-сообщения не нужны. Отвечающий узел просто переходит к следующему этапу. Отсутствие ответа на любой отдельный запрошенный элемент подразумевает, что такой элемент недоступен или не поддерживается.

Возвращаясь назад к фиг. 5, после приема сообщения 60 ответа, если варианты, выбранные посредством NAS 46, удовлетворяют определенному пороговому значению, например, все выбранные варианты позволяют узлу 44 установить канал связи для доступа к сети, узел 44 переходит прямо к передаче пользовательских данных 62 к NAS 46. Опять же сообщение подтверждения приема не отправляется узлом 44.

По окончании доступа к сети либо узел 44, либо NAS 46 может отправить сообщение 64 запроса завершения другому, который после этого отвечает обратно сообщением 66 подтверждения завершения и заканчивает сеанс связи.

В менее часто встречающихся обстоятельствах может быть недостаточно вариантов конфигурации в сообщении 58 запроса для NAS 46 для того, чтобы установить канал связи для доступа к сети, которого добивается узел 44. То есть, варианты, выбранные посредством NAS 46, в сообщении 60 ответа могут быть недостаточными, чтобы удовлетворить пороговому значению для узла 44, чтобы установить канал связи для доступа к сети. NAS 46, однако, отправляет сообщение 58 ответа только с принятыми вариантами, а непринятые варианты пропускаются. Снова, нет необходимости в Nak-сообщении. Как упомянуто ранее, предложенные варианты, включенные в состав сообщения 58 запроса, но пропущенные в сообщении 60 ответа, косвенным образом указывают отсутствие поддержки пропущенных вариантов. В этом случае NAS 46 не может установить сетевой трафик и ожидает, пока узел 44 не отправит новое сообщение запроса.

Что касается узла 44, если он выбирает соединение, несмотря на пропущенные варианты параметров из-за отсутствия поддержки в сообщении 60 ответа, например, пропущенные варианты являются некритическими, узел 44 может начать передачу сетевого трафика. С другой стороны, если пропущенные параметры абсолютно необходимы, чтобы установить соединение для доступа к сети, например, IP-адрес, запрашиваемый узлом 44, пропущен в сообщении 60 ответа, сетевой трафик не может быть установлен, и говорится, что соединение не удалось.

Общий процесс 54 также показан в блок-схеме на фиг. 6.

Процесс установления соединения согласно изобретению также конфигурируется, чтобы иметь возможности обработки отказа для других протоколов связи. В этом варианте осуществления, если процесс 54 соединения, показанный на фиг. 5 и 6, не поддерживается либо в узле 44, либо в NAS 46 (фиг. 3), традиционный PPP задействуется в качестве протокола перехода на аварийный режим, чтобы продолжить процесс соединения, приводящий к возможному доступу к сети, которого добивается узел 44.

По существу, могут быть две возможности, соответственно описанные ниже в данном документе.

Первый сценарий возникает, когда узел 44 поддерживает процесс 54 соединения, а NAS 46 - нет. Ссылка теперь направлена на фиг. 7 в соединении с фиг. 3. Фиг. 7 является блок-схемой, которая показывает последовательность передачи сообщений между узлом 44 и NAS 46 в этом сценарии. Общий поток сообщений обозначен ссылкой с номером 68. Так как предполагается, что узел 44 поддерживает процесс 54 соединения, при установлении физического уровня, уровня 1, между узлами 44 и 46 узел 44 ожидает сообщение 56 синхронизации. Однако NAS 46 не имеет сообщения 56 синхронизации, чтобы отправить, потому что также предполагается, что NAS 46 не поддерживает процесс 54 соединения. Вместо этого NAS 46 отправляет сообщение 70 запроса конфигурации LCP по протоколу PPP узлу 44.

После приема сообщения 70 запроса конфигурации LCP узел 44 немедленно узнает, что NAS 46 не поддерживает процесс 54 соединения, и быстро принимает действия, чтобы связаться с NAS 46 через традиционный PPP. Конкретно, в ответ на сообщение 70 запроса конфигурации LCP узел 44 отправляет сообщение 72 подтверждения приема конфигурации LCP, как показано на фиг. 7. Альтернативно, узел может отправить сообщение о отсутствии подтверждения приема конфигурации, если предложенные варианты LCP в сообщении 70 запроса конфигурации являются нежелательными, таким же образом, подобным традиционному PPP.

Должно быть отмечено, что в этом варианте осуществления либо узел 44, либо узел 46 распознает, является ли принятое сообщение PPP-сообщением или неPPP-сообщением. Как будет описано позже, формат кадра данных, используемый в этом варианте осуществления, является таким же, что и используемый для PPP, таким образом позволяя быстрое распознавание и различение сообщений.

Перерыв в процессе, по существу, похож на процесс 34, показанный на фиг. 2. То есть, после успешного соединения трафик 74 данных устанавливается между узлом 44 и NAS 46. По окончании доступа к сети либо узел 44, либо NAS 46 может отправить сообщение 76 запроса завершения другому, который после этого отвечает обратно сообщением 78 подтверждения завершения и завершает сеанс 68 связи.

Соответствующая блок-схема процесса 68 показана на фиг. 8. Этапы традиционного PPP не показаны на фиг. 8 ради краткости.

Второй сценарий происходит, когда NAS 46 поддерживает процесс 54 соединения, а узел 44 - нет. Ссылка теперь направлена на фиг. 9 в соединении с фиг. 3. Фиг. 9 является блок-схемой, показывающей последовательность передачи сообщений между узлом 44 и NAS 46 в этом сценарии. Полный поток сообщений обозначается ссылкой с номером 70. Так как предполагается, что NAS 46 поддерживает процесс 54 соединения, после установки физического уровня, уровня 1, между узлами 44 и 46 NAS 46 немедленно отправляет сообщение 56 синхронизации узлу 44. Так как также предполагается, что узел 44 не поддерживает процесс 54 соединения, после приема сообщения 56 синхронизации узел 44 не распознает сообщение 56 синхронизации. Как упомянуто ранее и будет дополнительно объяснено ниже, узел 44 может отличить PPP-сообщение от неPPP-сообщения. Таким образом, с нераспознанным сообщением 56 синхронизации узел 44 отбрасывает нераспознанное сообщение 56 синхронизации, используя стандартные PPP-процедуры. Вместо этого узел 44 отправляет сообщение 72 запроса конфигурации LCP по физическому каналу связи, установленному между узлом 44 и NAS 46.

Если NAS 46 принимает сообщение 72 запроса конфигурации LCP или PPP-отклонение сообщения 56 синхронизации, NAS 46 немедленно отменяет все функции, относящиеся к процессу 54 соединения (фиг. 5 и 6), и идет через традиционный PPP-процесс 34, как показано на фиг. 2 и описано ранее.

После успешного соединения может произойти обмен трафиком 74 данных между узлом 44 и NAS 46. По окончании доступа к сети либо узел 44, либо NAS 46 может отправить сообщение 76 запроса завершения другому, который после этого отвечает обратно сообщением 78 подтверждения завершения и завершает сеанс 70 связи.

Фиг. 10 показывает соответствующую блок-схему процесса 70. Этапы традиционного PPP не показаны на фиг. 10 по соображениям краткости и ясности.

Фиг. 11 показывает формат кадра данных, используемого в потоке процесса 54 (фиг. 5). Шаблон кадра для пакета данных процесса 54 обозначается ссылкой с номером 80. По существу, шаблон 80 похож на соответствующий шаблон пакета данных, используемый PPP, как изложено в RFC 1662. В частности, кадр 80 данных включает в себя поле 82 флага, поле 84 адреса, управляющее поле 86, поле 88 номера протокола, поле 90 данных и поле 92 FCS (контрольная последовательность кадра).

Поле 82 флага имеет однобайтную длину и указывает начало кадра пакета данных. Поле 82 флага всегда принимает шестнадцатиричное значение 7E и является таким же значением, используемым для процесса 54 соединения и PPP, как требуется по RFC 1662.

Поле 84 адреса также имеет однобайтную длину и всегда устанавливается в шестнадцатиричное значение, равное FF, как также изложено в RFC 1662.

Управляющее поле 86 имеет однобайтную длину и фиксировано с шестнадцатиричным значением, равным 03, как также описано в RFC 1662.

В поле 88 номера протокола значение в этом поле указывает, что пакет 80 данных присутствует. Поле 88 номера протокола является двухбайтным по длине. Например, как определено в RFC 1661 и 1662, каждое из LCP-сообщений, таких как сообщение 70 запроса конфигурации, имеет шестнадцатиричное значение, равное C021. В этом варианте осуществления каждое из сообщений, таких как сообщение 56 синхронизации, сообщение 58 запроса или сообщение 60 ответа, используемых в процессе 54 соединения (фиг. 5), имеет уникальное значение протокола, отличное от любого из значений протокола, используемых в PPP. По существу, легко может быть распознано, является ли пакет 80 данных PPP-пакетом или неPPP-пакетом.

Поле 90 данных имеет длину, которая изменяется от нуля до более байт, полезной нагрузки, которая содержит либо данные, либо управляющую информацию. Например, если значение в поле 88 номера протокола со значением, которое указывает, что пакет 80 данных - это сообщение 58 запроса, поле данных включает в себя всю информацию, относящуюся к вариантам парам