RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых

3.4 Интерфейс между IP и транспортным уровнем

Интерфейс между IP и транспортным уровнем должен обеспечивать полный доступ ко всем механизмам уровня IP, включая опции, тип обслуживания TOS и время жизни (TTL). Транспортный уровень должен иметь механизм установки интерфейсных параметров или/и обеспечивать передачу таких параметров от приложений.

  • Обсуждение:
  • Для приложений очень важна возможность использования таких параметров, даже если соответствующие механизмы еще недостаточно эффективны в Internet (например, TOS). Реализация поддержки этих механизмов обеспечивает возможность работы с ними без серьезного изменения программных настроек хоста по мере реализации механизмов в Internet.

Опишем концептуальный интерфейс между транспортным уровнем и IP, как набор процедурных вызовов. Приведенное здесь описание является расширением [RFC791] (параграф 3.3).

  • Передача дейтаграмм

    SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)

    параметры процедуры описаны в RFC 791. Передача параметра Id необязательна (см. 3.2.1.5).

  • Прием дейтаграмм

    RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt)

    Все параметры определены в RFC 791, за исключением SpecDest = указанный адрес получателя дейтаграммы (см. 3.2.1.3).

    Полученный в результате параметр dst содержит адрес получателя дейтаграммы. Поскольку этот адрес может быть широковещательным, должен передаваться параметр SpecDest, не определенный в RFC 791. Параметр opt содержит все опции IP для дейтаграммы и также должен передаваться на транспортный уровень.

  • Выбор адреса отправителя

    GET_SRCADDR(remote, TOS) -> local remote = remote IP address
    • TOS = тип обслуживания (Type-of-Service)
    • local = локальный адрес IP

    См. параграф 3.3.4.3.

  • Определение максимального размера дейтаграмм

    GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
    • MMS_R = максимальный размер принимаемого сообщения транспортного уровня.
    • MMS_S = максимальный размер передаваемого сообщения транспортного уровня.
    • (local, remote, TOS определены выше)

    См. параграфы 3.3.2 и 3.3.3.

  • Сообщение об успешной доставке

    ADVISE_DELIVPROB(sense, local, remote, TOS)

    Параметр sense представляет собой 1-битовый флаг, показывающий тип анонса (позитивный или негативный), описанного в параграфе 3.3.1.4. Остальные параметры были определены выше.

  • Передача сообщения ICMP

    SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result

    (Параметры определены в RFC 791).

    Передача параметра Id не является обязательной (см. параграф 3.2.1.5). Транспортный уровень должен быть способен передавать некоторые сообщения ICMP Port Unreachable или любой из запросов. Эта функция может рассматриваться как частный случай вызова SEND() и отдельное рассмотрение ее диктуется лишь задачами упрощения.

  • Прием сообщения ICMP

    RECV_ICMP(BufPTR ) -> result, src, dst, len, opt

    (Параметры определены в RFC 791).

    Уровень IP должен передавать некоторые сообщения ICMP соответствующим программам транспортного уровня. Эта функция может рассматриваться как частный случай вызова RECV() и указана отдельно лишь для упрощения.

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

На верхний уровень передаются, в частности, следующие сообщения:

  • Destination Unreachable
  • Source Quench
  • Echo Reply (пользовательскому интерфейсу ICMP, если Echo Request передан не с уровня IP)
  • Timestamp Reply (пользовательскому интерфейсу ICMP)
  • Time Exceeded
  • Обсуждение:
  • В будущем интерфейс обмена данными между транспортным уровнем и IP может быть расширен (см. параграф 3.3.1.3) для передачи информации о пути.

Страница 50 из 86

2007 - 2022 © Русские переводы RFC, IETF, ISOC.