Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача
| Вид материала | Задача |
- Поурочне планування курсу "Основи Інтернет – технологій", 88.8kb.
- Работа nat введение, 150.17kb.
- 1. Сервіси Internet, 731.38kb.
- 1. Сервіси Internet, 347.99kb.
- Internet Information Services (iis). Понимание организации сетей, tcp/ip и Domain Name, 17.07kb.
- Что такое Internet? Ресурсы Internet*, 347.7kb.
- Лабораторна робота №19 ”Internet”, 103.46kb.
- Е. Е. Израилевич Практическая грамматика английского языка с упражнениями и ключами, 14711.83kb.
- Математическая логика сквозь школьные предметы, 133.29kb.
- Мифы и реальности Internet известные и скрытые возможности сети Что такое Internet, 306.75kb.
Что касается конкретного канала данных, можно использовать следующие термины:
- Поле данных кадра:
Содержимое поля данных кадра, исключая любые заголовки и поля завершения кадра (например, MAC-заголовки, LLC-заголовки, 802.1Q-заголовки, PPP-заголовки, контрольные суммы, и т.д.).
Когда кадр несет в себе непомеченную IP-дейтограмму, поле данных кадра представляет собой саму IP-дейтограмму. Когда кадр несет в себе помеченную IP-дейтограмму, поле данных кадра состоит из записей стека меток и IP-дейтограммы.
- Обычный максимальный размер поля данных кадра:
Максимальный размер поля данных кадра определяется стандартами канала данных. Например, обычный максимальный размер поля данных кадра для Ethernet равен 1500 байтов.
- Истинный максимальный размер поля данных кадра:
Максимальный размер поля данных кадра, который можно послать и получить через интерфейс канала данных.
Для сетей Ethernet и 802.3, считается, что истинный максимальный размер поля данных кадра на 4-8 байта больше обычного максимального размера поля данных (поскольку ни переключатель, ни бридж не могут увеличить размер заголовка в процессе транспортировки пакета до следующего узла сети). Например, считается, что большинство оборудования Ethernet может принимать и посылать пакеты, содержащие, по крайней мере, 1504 или даже 1508 байт, поскольку заголовок Ethernet не имеет полей 802.1Q или 802.1p. В каналах PPP, истинный максимальный размер поля данных кадра может быть неограниченным.
- Эффективный максимальный размер поля данных для помеченных кадров:
Это либо обычный максимальный размер поля данных кадра или истинный максимальный размер поля данных кадра, в зависимости от возможностей оборудования канала и размера заголовка канального уровня.
- Первично помеченная IP-дейтограмма:
Предположим, что непомеченная IP-дейтограмма получена конкретным LSR, и что LSR вводит метку в стек перед тем, как переадресовать эту дейтограмму. Такая дейтограмма будет называться первично помеченной в этом LSR IP-дейтограммой.
- Ранее помеченная IP-дейтограмма:
IP-дейтограмма, которая уже была помечена до того, как была получена конкретным LSR.
3.2. Максимальный исходный размер помеченной IP-дейтограммы
Каждый LSR, который способен
a) получать непомеченные IP-дейтограммы,
b) добавлять метки в стек дейтограммы, и
c) переадресовывать полученный в результате помеченный пакет,
должен поддерживать конфигурационный параметр, называемый "максимальный размер первично помеченной IP-дейтограммы", который может быть установлен неотрицательным. Если этот конфигурационный параметр установлен равным нулю, он ни на что не влияет. Если он имеет положительное значение, то он используется следующим образом. Если:
a) получена непомеченная IP-дейтограмма, и
b) эта дейтограмма имеет в заголовке бит DF=0, и
c) дейтограмма перед переадресацией должна быть помечена, и
d) размер дейтограммы (до пометки) превышает значение данного параметра, тогда
a) Дейтограмма должна быть разделена на фрагменты с размером не больше, чем указано в данном параметре, и
b) Каждый фрагмент должен быть помечен и после этого переадресован.
Например, если этот конфигурационный параметр установлен равным 1488, тогда любая непомеченная IP дейтограмма, содержащая более 1488 байт, будет фрагментирована до выполнения пометки. Каждый фрагмент будет способен передавать через канал 1500 байт, без последующей фрагментации, даже если в стек будет занесено до трех меток.
Другими словами, установка этого параметра не равным нулю, позволяет исключить фрагментацию уже помеченных IP пакетов, но это может вызвать иногда фрагментацию первично помеченных IP-дейтограмм, когда это совсем не нужно.
Заметим, что установка этого параметра не влияет на обработку IP-дейтограмм, которые содержат бит DF=1, следовательно, установка этого параметра не влияет на результат определения MTU пути.
3.3. Когда помеченная IP-дейтограмма слишком велика?
Помеченная IP-дейтограмма, чей размер превышает обычный максимальный размер поля данных канала, может рассматриваться как "слишком большая".
Помеченная IP-дейтограмма, чей размер превышает истинный максимальный размер поля данных кадра канала, через который она должна переадресоваться, считается "слишком большой".
Помеченная IP-дейтограмма, которая не является "слишком большой" должна передаваться без фрагментации.
3.4. Обработка помеченных дейтограмм Ipv4, которые слишком длинны
Если помеченная IPv4 дейтограмма "слишком велика", и бит DF в IP заголовке =1, тогда LSR может отбросить дейтограмму.
Заметим, что отбрасывание таких дейтограмм является разумным, только если "Максимальный размер первично помеченной IP-дейтограммы" установлен равным ненулевому значению во всех LSR сети, способных добавлять метки в стек непомеченных IP-дейтограмм.
Если LSR решает не отбрасывать помеченные IPv4-дейтограммы, которые слишком велики, или если в дейтограмме флаг DF=1, тогда должен быть выполнена следующая последовательность операций:
1. Удалить записи в стеке, чтобы получить IP-дейтограмму.
2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).
3. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =0:
a. Разбить ее на фрагменты, каждый из которых должен иметь размер, по крайней мере, на N байт меньше, чем эффективный максимальный размер поля данных кадра.
b. Преобразовать каждый фрагмент, снабдив его заголовком, который имела исходная дейтограмма.
c. Переадресовать фрагменты.
4. Если IP-дейтограмма содержит в IP заголовке бит "Don't Fragment" =1:
a. Дейтограмма не должна переадресовываться.
b. Сформировать ICMP-сообщение “Адресат недостижим”:
i. Установить значение поля [3] равным "Fragmentation Required and DF Set",
ii. Установить значение поля Next-Hop MTU [4] равным разности между эффективным максимальным размером поля данных кадра и величиной N
c. Если возможно, послать ICMP-сообщение “Адресат недостижим” отправителю отброшенной дейтограммы.
3.5. Обработка помеченных дейтограмм IPv6, которые слишком длинны
Чтобы обработать помеченную IPv6-дейтограмму, которая слишком велика, LSR должен реализовать следующий алгоритм:
1. Удалить записи в стеке, чтобы получить IP-дейтограмму.
2. Пусть N равно числу байт в стеке (т.e, число записей в стеке меток, умноженное на 4).
3. Если IP-дейтограмма содержит более 1280 байтов (не считая записи стека меток), или, если она не содержит заголовка фрагмента, тогда:
a. Сформировать ICMP-сообщение “Too Big Message”, и установить значение поля Next-Hop MTU равным разности между эффективным максимальным размером поля данных кадра и величиной N.
b. Если возможно, послать отправителю дейтограммы ICMP-сообщение “Too Big Message”.
c. Отбросить помеченную IPv6-дейтограмму.
4. Если IP-дейтограмма не длиннее 1280 октетов, и содержит заголовок фрагмента, тогда
a. Преобразовать ее в фрагменты, каждый из которых должен быть по крайней на N байт меньше, чем эффективный максимальный размер поля данных кадра.
b. Снабдить каждый фрагмент тем же помеченным заголовком, который имела исходная дейтограмма.
c. Переадресовать фрагменты.
Восстановление сообщения из фрагментов осуществляется конечным получателем.
3.6. Реализация с учетом определения MTU пути
Описанные выше процедуры обработки дейтограмм, которые имеют в заголовке бит DF=1, но являются "слишком большими", связаны с процедурами определения MTU пути RFC 1191 [4]. ЭВМ, которые используют эти процедуры, определят MTU, который достаточно мал, чтобы позволить занесение в дейтограмму n маркеров, без необходимости фрагментации. Здесь n равно числу меток, заносимых на используемом пути через домен.
Другими словами, дейтограммы от ЭВМ, которые используют определение MTU пути, никогда не потребуют фрагментации из-за занесения меток в заголовок. Заметим, что дейтограммы от ЭВМ, использующих определение MTU пути, имеют бит DF=1, и таким образом не могут быть фрагментированы в любом случае.
Отметим также, что определение MTU пути будет работать корректно, только если в точке, где может потребоваться фрагментация помеченной IP-дейтограммы, возможна посылка отправителю ICMP сообщения “Destination Unreachable”. Смотри раздел 2.3. Если невозможна посылка отправителю слишком большой дейтограммы ICMP-сообщения из MPLS "туннеля", но конфигурация сети предоставляет возможность LSR конца туннеля получать слишком большие пакеты, которые должны проходить через туннель, тогда:
- LSR на передающем конце туннеля должен уметь определять MTU туннеля в целом. Он может это сделать путем посылки пакетов через туннель в направлении его приемной части, и выполняя процедуру определения MTU пути для этих пакетов.
- Всякий раз, когда передающий конец туннеля должен посылать пакет в туннель, и этот пакет имеет DF=1, а его длина превышает значение MTU туннеля, передающий конец должен послать ICMP-сообщение “Destination Unreachable” узлу, приславшему пакет с кодом "Fragmentation Required and DF Set ", и полем Next-Hop MTU установленным так, как показано выше.
4. Передача помеченных пакетов через PPP
Протокол PPP (Point-to-Point Protocol) [6] предоставляет стандартный метод транспортировки многопротокольных дейтограмм через каналы точка-точка. PPP определяет расширяемый протокол управления каналом и предлагает семейство протоколов управления сетью для установления и конфигурации различных протоколов сетевого уровня.
В этом разделе определен протокол управления сетью для установления и конфигурации коммутации меток в канале PPP.
4.1. Введение
PPP содержит три основные компонента:
1. Метод инкапсуляции мультипротокольных дейтограмм.
2. Протокол управления каналом LCP (Link Control Protocol ) установления, конфигурации и тестирования канала.
3. Семейство протоколов управления сетью для установления и конфигурирования различных протоколов сетевого уровня.
Для того чтобы установить связь через канал точка-точка, каждый конец PPP канала должен сначала послать LCP-пакеты, чтобы сконфигурировать и протестировать канал. После того как канал установлен и согласованы опционные возможности, как это требует LCP, PPP должен послать пакеты "MPLS Control Protocol", чтобы разрешить посылку помеченных пакетов. Как только "MPLS Control Protocol" оказался открыт, можно посылать помеченные пакеты через канал. Канал будет оставаться сконфигурирован для коммуникаций, пока управляющие протокольные пакеты LCP или MPLS его не закроют, или пока не произойдет какое-то внешнее событие (сработает таймер пассивности или не вмешается сетевой администратор).
4.2. Протокол управления PPP для MPLS
Протокол управления MPLS (MPLSCP) отвечает за разрешение/запрещение использования коммутации меток в канале PPP. Он использует тот же механизм обмена, что и протокол управления каналом LCP (Link Control Protocol). Пакеты MPLSCP не могут пересылаться до тех пор, пока PPP не достигнет фазы протокола сетевого уровня. Пакеты MPLSCP, полученные до достижения этой фазы, должны просто отбрасываться.
Протокол управления MPLS тождественен протоколу управления каналом [6] за следующими исключениями:
1. Модификации кадра
Пакет может использовать любые модификации базового формата кадра, которые были согласованы на фазе установления канала.
2. Поле протокола канального уровня
В информационное поле пакета PPP вкладывается только один пакет MPLSCP, где поле протокола PPP содержит шестнадцатеричный код 8281 (MPLS).
3. Поле кода
Используются только коды от 1 до 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack и Code-Reject). Прочие коды должны рассматриваться как нераспознанные и приводить к Code-Rejects.
4. Таймауты
Пакеты MPLSCP не могут пересылаться, пока PPP не достигнет фазы протокола сетевого уровня. Реализация должна быть готова ждать окончания аутентификации и определения качества канала, прежде чем наступит таймаут в ожидании Configure-Ack или других откликов.
4.3. Посылка помеченных пакетов
Прежде чем какие-либо пакеты будут посланы, PPP должен достичь фазы протокола сетевого уровня, и управляющий протокол MPLS должен стать активным (состояние Opened).
В информационное поле пакета PPP вкладывается только один помеченный пакет, где поле протокола PPP содержит шестнадцатеричные значения кода тип 0281 (MPLS Unicast) или 0283 (MPLS Multicast). Максимальная длина помеченного пакета, переданного через канал PPP, та же что и максимальная длина информационного поля инкапсулированного пакета PPP.
Заметим, что определены два кода для помеченных пакетов, один для мультикастных и один для уникастных. Как только MPLSCP переходит в рабочее состояние (Opened), по каналу PPP могут посылаться как мультикаст, так и уникаст-пакеты.
5. Пересылка помеченных пакетов в среде LAN
В каждом кадре транспортируется только один помеченный пакет. Записи стека меток размещаются непосредственно после заголовка сетевого уровня, а сразу за ними следует заголовок канального уровня, включая, например, любые заголовки 802.1Q, которые только могут существовать.
Шестнадцатеричный код Ethertype 8847 используется для индикации того, что кадр содержит уникастный MPLS-пакет. Шестнадцатеричный код Ethertype 8848 служит для указания того, что кадр содержит MPLS-пакет.
Эти значения Ethertype могут быть использованы либо при Ethernet-инкапсуляции, либо при инкапсуляции 802.3 LLC/SNAP для транспортировки помеченных пакетов. Процедура выбора одной из этих инкапсуляций находится вне пределов рассмотрения данного документа.
6. Соображения IANA
Значения меток 0-15 включительно имеют специальное назначение, как это определено в данном документе, или как позднее будет задано IANA. В этом документе, значения меток 0-3 специфицированы в разделе 2.1. Значения меток 4-15 могут быть определены IANA, на основе согласия с IETF.
7. Соображения безопасности
Инкапсуляция MPLS, которая специфицирована здесь, не предполагает какой-либо дополнительной безопасности, помимо той, что заложена в архитектуре MPLS [1] или в структуре протокола сетевого уровня.
Существует два соображения безопасности, следующие из архитектуры MPLS и рассматриваемые здесь:
- Некоторые маршрутизаторы могут реализовать процедуры безопасности, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Эти процедуры не будут работать, когда используется MPLS-инкапсуляция, так как эта инкапсуляция имеет варьируемый размер.
- Метка MPLS имеет силу в результате соглашения между LSR, который заносит метку в стек ("автор метки"), и LSR, который интерпретирует эту метку ("читатель метки"). Однако стек меток не предлагает никаких средств определения того, кто является автором конкретной метки. Если помеченные пакеты восприняты от ненадежных источников, результатом может стать то, что пакеты будут маршрутизированы незаконным образом.
8. Библиография
[1] Rosen, E., Viswanathan, A., и R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[4] Mogul, J. и S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[5] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[7] Conta, A. и S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, December 1995.
[8] McCann, J., Deering, S. и J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[9] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E. и G. Swallow, "MPLS Using LDP и ATM VC Switching", RFC 3035, January 2001.