32. Мосты Довольно часто в организации возникает несколько ЛВС, которые надо объединить между собой. Этой цели служат специальные устройства, называемые мостами, которые функционируют на уровне канала данных. Это означает, что это устройство не анализирует заголовков пакетов уровня сетевого и выше и, таким образом, может просто копировать IP, IPX, OSI пакеты, в то время как маршрутизаторы могут работать только с определенными пакетами. Мосты из 802 в 802 На первый взгляд может показаться, что построить мост из 802 в 802 не столь сложно. Но это не так. У каждой из девяти комбинаций, пар есть свои трудности. Но прежде чем начать рассматривать эти индивидуальные проблемы, начнем с общих. Первая - каждый стандарт имеет свой собственный формат кадра. НЕ было никаких технических причин в этих различиях. Просто корпорации, поддерживавшие их разработки Xerox, GM, IBM , не захотели пойти на встречу друг другу и что-то изменить у себя. В результате при переходе из сети в сеть требуется реформатирование кадра, на что тратиться время процессора, пере вычисляется контрольная сумма. Ничего этого не потребовалось бы если бы три комитета смогли договориться о едином формате. Следующая проблема - разные сети могут работать с разной скоростью. Если передача идет из скоростной сети в медленную, то мост должен обладать достаточным буфером. Эта проблема может усугубляться не постоянством скорости передачи, как например, в 802.3 из-за коллизий. Эта ситуация может усугубляться тем, что несколько сетей могут посылать трафик одной и той же сети, что опять приведет к перекосу скоростей. Другой тонкой, но важной проблемой является проблема моста как источника временной задержки в сравнении со значениями таймеров на верхних уровнях. Предположим что сетевой уровень над 802.4 старается послать длинное сообщение, как последовательность кадров. После отправки последнего кадра устанавливается таймер на ожидание уведомления о получении. Если сообщение проходит через мост с медленной 802.5, то есть опасность что наступит time-out прежде, чем последний кадр будет передан в медленную сеть. Сетевой уровень решит, что все сообщение утеряно и начнет все сначала. После нескольких попыток сетевой уровень сообщит транспортному, что получатель отсутствует. Третьей, и наиболее серьезной проблемой является то, что все три стандарта имеют разную максимальную длину кадра. Для 802.3 на 10 Мврs это 1500 байт, для 802.4 - 8191 байт, для 802.5 - максимальная длина ограничена временем удержания маркера. Последняя величина по умолчанию имеет значение 10 msec, что соответствует 5000 байтам. Очевидная проблема, когда длинный кадр надо пропихнуть в сеть с короткими кадрами. Разбиение кадра на части не является задачей данного уровня. Это не значит что таких протоколов не было создано. Просто стандарты 802 не предусматривают надлежащих средств. В принципе, там решения нет. Слишком длинные кадры просто сбрасываются. 802.3 - 802.3 Здесь есть только одна опасность, что сеть, в которую передают сильно перегружена и мост не успевает пропихивать свои кадры. Есть опасность переполнения буфера у моста и тогда мост начнет сбрасывать кадры. По отношению к двум другим стандартам все проще так, как мост обязательно получит маркер, и получит свой временной слот на передачу кадров. 802.4 - 802.3 Здесь две проблемы. Первая - кадры из 802.4 содержат биты приоритета, а в кадрах 802.3 таких нет. В результате если две 802.4 взаимодействуют через 802.3, то информация о приоритетах будет уничтожена. Вторая проблема вызвана исключительно тем, что в кадре 802.4 есть бит временной передачи маркера получателю для уведомления. Что делать мосту если ему поступит такой кадр? Послать подтверждение самому нельзя - получатель может быть не работоспособен. С другой стороны, если не дать подтверждения, то отправитель решит что получатель не работоспособен, что может быть не так, и предпринять соответствующие меры. Похоже, что у этой проблемы нет решения. 802.5 - 802.3 Здесь мы имеет проблемы аналогичные тем, что мы обсуждали выше. Например, там есть биты А и С, которые используются для анализа информации о доставке и получении кадра. Как поступать мосту с такими кадрами? Если мост сам начнет имитировать за получателя значения этих разрядов, то очевидно, здесь могут возникать трудно исправимые ошибки. Ситуация выглядит так, что появление моста может менять семантику отдельных разрядов кадра и как решить эту проблему представить трудно. 802.3 - 802.4 Здесь основную трудность представляют биты приоритета. Что там писать? Возможно здесь стоит все кадры пускать с наивысшим приоритетом, так как они уже настрадались от задержек при передачи 802.4 - 802.4 Единственная проблема, которая здесь существует - это как поступать с временной передачей маркера? Мост может посылать такой кадр как можно быстрее в надежде что ответ придет раньше, чем time-out. Можно посылать его с наивысшим приоритетом. При этом мост, так сказать покривит душой, но это увеличит вероятность получения ответа до time-out. 802.5 - 802.4 Здесь проблему представляют биты А и С. Кроме этого семантика приоритетов в этих сетях немного разная. Но выбора нет. Остается просто копировать биты приоритетов в надежде на хороший исход. 802.3 - 802.5 В этом случае надо генерировать биты приоритета. Других проблем здесь нет. 802.4 - 802.5 Здесь может возникнуть проблема слишком длинного кадра. Опять-таки здесь присутствует передача маркера. 802.5 - 802.5 Здесь надо только решить что делать с битами А и С. Транспортный протокол - это центральный протокол во всей иерархии протоколов. Именно он обеспечивает надежную передачу данных от одного абонента в сети другому. Здесь мы рассмотрим достаточно подробно организацию, сервис, протоколы и производительность.
