Кратко
- Идентификатор вызываемой стороны мог выбрать PPP среди служб одного ISDN-доступа, но не разрешал работу PPP и не удостоверял звонящего.
- Если LCP не получил административное событие
Open, вызов следовало отклонить; принять его, чтобы затем закрыть канал или игнорировать пакеты, запрещалось. - После приёма отдельно подтверждались кодирование, кадрирование,
Up, LCPOpened, аутентификация, NCP и прикладной результат.
Точный номер, закрытая служба
RFC 1618 вышла в мае 1994 года и описала PPP на коммутируемых линиях ISDN. Авторы не ожидали единой монолитной мировой ISDN. Коммутаторы, абонентские правила и терминалы отличались; стандарт выбирал несколько общих исходных режимов ради совместимости, а не объявлял всю среду одинаковой.
B-канал был двухточечным носителем, а PRI могла предоставлять много таких каналов одновременно. D-канал тоже допускал PPP при подходящем кадрировании, но имел меньшую полосу и часто ограничивался местным коммутатором. Доступность носителя ничего не говорила о том, хочет ли конечная система принимать на нём службу.
Несколько телефонных номеров могли вести на одно физическое подключение. Администратор связывал каждый номер со службой, а местный коммутатор сообщал идентификатор вызываемой стороны. Значение выбирало дверь. Оно не удостоверяло вошедшего и не открывало дверь.
Богатая подсказка терялась по дороге
LLC Information Element выглядел подходящим способом заранее сообщить кодирование или кадрирование. Но RFC зафиксировала обратный опыт: совместимых коммутаторов было мало, политики подписки различались, поэтому элемент ненадёжно проходил из конца в конец.
Значение LLC-IE для PPP ещё не назначили. Другие значения не описывали PPP-линию и могли игнорироваться. Документ прямо запрещал полагаться на них при выборе кадра и кодирования.
Общая семантика требует, чтобы каждый посредник сохранил поле и его область действия. Если операторская политика решает, передавать ли его дальше, исходное утверждение не становится фактом у получателя. RFC 1618 оставила более узкую локальную подсказку и отдельное локальное решение.
Кто создавал Open
При использовании вызываемого номера — или будущего PPP-значения LLC — отсутствие административного Open в LCP требовало отклонить вызов. Нельзя было принять соединение, а потом закрыть его или молча отбрасывать пакеты.
RFC 1548 и RFC 1661 определяют Open как разрешение администратора сети, человека или программы. Up приходит снизу и означает готовность физического носителя. Opened возникает позже, когда автомат LCP прошёл обмен конфигурацией.
Коммутатор предоставляет канал, местная политика допускает службу, два узла согласуют её. Одинаково звучащие метки не дают одному участнику полномочий другого. Ранний отказ сохранял эту границу и не занимал коммутируемый ресурс.
Если принять вызов, а затем замолчать, внешнему наблюдателю трудно отличить запрет от несовместимого кадра, отсутствующего узла или потери. Отказ до приёма оставляет причину у того, кто её создал.
Автоопределение было серией опытов
Даже разрешённая служба могла не знать представление битов. С точки зрения PPP канал ISDN был полнодуплексным синхронным соединением, а кодирование и скремблирование относились к DTE/DCE. RFC 1618 рекомендовала NRZ по умолчанию в точке T, NRZI как настраиваемую альтернативу и объявляла устаревшим инвертированный NRZ.
Для нескольких простых режимов надёжным считалось только переключение. В каждом режиме дважды посылался LCP Configure-Request, затем давалось время на ответ. Общая серия должна была завершиться не позже 59 секунд, предпочтительно за обычные 30.
Это не распознавание готовой истины, а ограниченные испытания. Молчание не устанавливает причину; оно разрешает следующий шаг. Временной бюджет не даёт неопределённости бесконечно занимать платный или дефицитный канал.
Без предварительной настройки B-канал начинал с бит-синхронного HDLC. Октет-синхронный HDLC требовал доступных границ октетов и настройки. Несколько видов кадрирования не следовало запускать одновременно. RFC 1549 также связывала NRZI с ослаблением некоторых свойств 16-битного FCS и рекомендовала согласовать 32-битный FCS.
Для этого применения документ объявлял V.120 устаревшим, поскольку его кадрирование могло быть трудно отличить от Frame Relay, и вместо него рекомендовал переносить PPP внутри Frame Relay. Это был ограниченный выбор ради совместимости, а не доказательство способа, применённого в конкретном вызове.
Очередь становилась причиной следующего вызова
MTU сетевого уровня рекомендовалось ограничить значением 1500, кроме случая явного согласования с узлом MRU не менее 2048. Таймер повторов должен был экспоненциально расти от 250 миллисекунд до трёх секунд. Постоянный дозвон требовал ограничения. После неудачи можно было удалить очередь передачи и временно убрать пакет, который снова запускал соединение.
Ожидающий пакет вызывает набор; неудача оставляет пакет; тот вызывает набор снова. Без предела одна прикладная просьба множит затраты. Без журнала перед очисткой исчезает доказательство начальной причины.
RFC 1618 предпочитала PPP Multilink механизму BONDING с собственной инициализацией. RFC 1990 позже описала объединение нескольких каналов ISDN, но физические каналы становились логическим bundle лишь после переговоров LCP.
За приёмом следовала длинная лестница
Нужно было подобрать кодирование и кадр, получить Up, довести LCP до Opened, завершить выбранную аутентификацию и открыть NCP нужного сетевого протокола. Только затем передавались датаграммы; их передача ещё не доказывала результат приложения.
Карточка RFC Editor подтверждает публикацию, автора и нынешний статус Proposed Standard, но не внедрение или современную практику. RFC 1618 не рассматривает безопасность, поэтому вызываемый номер не удостоверяет звонящего.
Принцип Heng Lu о первичности работающего кода отделяет поле от фактического действия. Его минимальная начальная спецификация объясняет, почему общие правила могли быть узкими, а допуск оставался местным.
Коммутатор назвал службу, но не получил право открыть её за конечную систему. RFC 1618 поместила отказ до принятия канала, сохранив решение видимым и приписанным его владельцу.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
