Процедура обмена данными в LANE
Когда клиент-отправитель пользовательских данных точно знает, по какому АТМ-адресу (т.е. какому клиенту LEC) он должен послать эту информацию, то он устанавливает в его сторону соединение АТМ (если оно ранее уже не было установлено). Процедура установления соединения АТМ для целей LANЕ несколько отличается от обычной процедуры, которая описана в следующей главе, поэтому остановимся на ней. По установленному виртуальному каналу, называемому каналом данных - Data Direct VCC, никогда не будут передаваться управляющие запросы и ответы. Все управление будет идти через серверы.
Процесс установления соединения показан на рис.21. В нем серверы LES и BUS не участвуют. Как видим, вызываемая станция после того, как выдала подтверждение готовности связи, получает дополнительное подтверждение от своего узла коммутации в виде сообщения Connect_Ack. До этого момента никаких расхождений с обычным процессом установления соединения в сети АТМ нет.
Как видим, вызываемый клиент может получить сообщение Connect_Ack до того, как вызывающий получит сообщение Connect, поскольку Connect_Ack посылается местным узлом своей оконечной станции, а не от удаленного абонента. В результате может оказаться, что если вызывающий клиент начнет сразу передавать данные, то начало этих данных не сможет быть принято, поскольку вызывающий клиент не успел принять сигнальное сообщение Connect или не успел его обработать. Забегая несколько вперед скажем, что сообщения сигнализации, к которым относится и Connect, проходят через сеть по отдельному виртуальному каналу, и, следовательно, данные могут это сообщение обогнать. Поэтому вызываемая станция еще не входит в режим передачи данных после получения сообщения Connect Ack, а ждет прихода еще одного подтверждения Ready Ind, которое посылается вызывающей стороной. Она посылает это сообщение только после того, как ею будет принято сообщение Connect, и она будет готова к передаче данных. Иными словами, вызываемый абонент сможет передавать данные только после того, как убедится, что противоположная сторона сможет их принимать.
Рис. 21. Установление соединения: запрос/индикация вызова
Конечно, сообщение Ready Ind может потеряться, и для защиты от этого на вызываемой стороне после получения сообщения Connect Ack запускается таймер, значение которого дает достаточный запас времени для того, чтобы противоположная сторона успела принять Connect. Если Ready Ind не поступит за время действия этого таймера, то вызываемая сторона будет считать, что это сообщение потерялось в сети, а сам абонент уже готов к работе. Вызываемый тем не менее пошлет контрольное сообщение, содержащее запрос о готовности Ready Query, в ответ на которое вызывающий должен сразу ответить сообщение Ready Ind.
Может показаться странным, что такая многоуровневая зашита предусмотрена на потерю сообщения Ready Ind и ничего нет для защиты сообщения Connect, которое тоже может потеряться. Дело в том, что если оно потеряется, вызывающий абонент будет считать, что соединение не было установлено и по истечении таймаута возобновит его с самого начала, т.е. снова пошлет сообщение SETUP.
Итак, мы поняли, что передача пользовательских данных в рамках ELAN может проходить двумя способами. Первый - это прямой обмен между LEC по отдельному виртуальному каналу, и он используется, когда все адреса уже точно известны. Второй способ - это обмен через сервер широковещания BUS, и он используется для поддержки протокола ARP, а также в тех случаях, когда идет широковещательная передача.
Эти два способа реализуются через совершенно разные виртуальные каналы, и, поэтому, если какой-то клиент LEC сначала передавал данные по первому способу, а затем - по второму (или наоборот), то весьма вероятно, что пользовательские данные будут переданы между клиентами в перепутанном порядке, т.е. кадры, поступившие, скажем, на широковещательный канал, могут обогнать данные, шедшие по индивидуальному каналу, хотя и были отправлены позже. Значит и рабочие станции получат данные в перепутанном порядке, что для ЛВС нетипично, и у рабочих станций может не быть механизма исправления последовательности.
Можно гарантировать только, что кадры, шедшие в рамках одного и того же канала придут с соблюдением исходной последовательности.
Поэтому в системе LANE предусмотрен специальный механизм защиты от возможных искажений такого рода, который называется FLUSH. Его суть состоит в том, что когда у клиента LEC возникает потребность сменить канал передачи, то перед этим по используемому в настоящий момент каналу посылается специальное сообщение FLUSH, и это сообщение будет последним в этом канале перед переходом на другой. Это сообщение после приема в удаленном LEC должно быть немедленно отправлено назад, и, когда это возвращенное сообщение будет принято в клиенте, который его сгенерировал, то тем самым этот последний будет уверен, что все предыдущие кадры, шедшие по этому каналу, уже доставлены - ведь в рамках одного канала имеется гарантия соблюдения последовательности. Конечно, пока это сообщение FLUSH "гуляет" по сети, вся последующая должна ждать, и это вносит некоторую задержку передачи, но для передачи данных это несущественно. Только после приема своего же сообщения FLUSH клиент имеет право переключиться на другой канал.
Таким образом, рабочие станции, подключаемые к ELAN, будут видеть друг друга точно так же, как если бы они находились в рамках одной и той же физической сети, хотя могут располагаться в разных городах и на разных континентах. Конечно, при передаче кадров Ethernet через сеть АТМ никаких коллизий, характерных для этого протокола, быть не может, так же как не бывает коллизий между различными сегментами Ethernet.
Надо заметить, что создание ELAN вовсе не может решить проблемы совместимости различных типов ЛВС, так, ELAN не поможет осуществить взаимодействие между Ethernet и Token Ring. Действительно, как мы уже заметили, сеть ELAN не производит никаких действий над пользовательскими кадрами, если не считать считывания поля адреса из их заголовков. Раз так, то для сопряжения между различными сетями необходим соответствующий мост, как и в случае соединения физических ЛВС.По этой же самой причине все приложения, характерные для ЛВС, могут передаваться через АТМ, которая для пользователей совершенно невидима.
