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.
4.2.3. Соображения совместимости
Легко видеть, что некоторые пятерки не образуют жизнеспособных схем MPLS. Например:
-
В этих схемах MPLS, нижестоящий LSR Rd пересылает ассоциации меток вышестоящему LSR Ru только по запросу от Ru, но Ru никогда не делает таких запросов. Очевидно, эти схемы нежизнеспособны, так как они не способны осуществлять корректную рассылку ассоциаций меток.
- <*, RequestNever, *, *, ReleaseOnChange>
В этих схемах MPLS, Rd аннулирует ассоциации, если он их не использует, но он никогда не запрашивает их снова, даже если они ему позднее понадобятся. Эти схемы, таким образом, не гарантируют того, что ассоциации меток будут разосланы корректно.
В этом разделе специфицируются правила предотвращения того, чтобы партнеры по рассылке меток выбирали процедуры, которые ведут к недопустимым схемам MPLS. Эти правила требуют либо обмена информацией между партнерами по рассылке меток во время инициализации системы, либо априорного знания (полученного каким-то методом, который находится за пределами рассмотрения данного документа).
1. Каждый субъект должен объявить, поддерживает ли он объединение меток.
2. Если Rd не поддерживает объединение меток, Rd должен выбрать либо процедуру PulledUnconditional, либо PulledConditional. Если Rd выбирает PulledConditional, Ru вынужден использовать процедуру RequestRetry.
То есть, если нижестоящий LSR не поддерживает объединения меток, его предпочтения имеют приоритет, при выборе схем MPLS.
3. Если Ru не поддерживает объединение меток, а Rd поддерживает, Ru должен выбрать процедуру RequestRetry или RequestNoRetry. Это вынуждает Rd использовать соответственно процедуру PulledConditional или PulledUnConditional.
То есть, если только один из LSR не поддерживает объединение меток, его предпочтения имеют приоритет, при выборе схем MPLS.
4. Если как Ru, так и Rd поддерживают объединение меток, тогда выбор между свободным и консервативным режимами удержания меток остается за Ru. То есть, Ru предоставляется выбрать либо использование RequestWhenNeeded/ReleaseOnChange (консервативный), или использовать RequestNever/NoReleaseOnChange (свободный). Однако, выбор push либо pull и "условный" либо "безусловный" принадлежит Rd. Если Ru выбирает свободный режим удержания меток, Rd может выбрать либо PushUnconditional, либо PushConditional. Если Ru выбирает консервативный режим удержания меток, Rd может выбрать PushConditional, PulledConditional или PulledUnconditional. Такой выбор определяет использование схемы MPLS .
5. Соображения безопасности
Некоторые маршрутизаторы могут реализовать безопасные процедуры, которые зависят от заголовка сетевого уровня, положение которого фиксировано по отношению к заголовку канального уровня. Базовая инкапсуляция MPLS подразумевает введение прослойки между заголовком канального и сетевого уровня. Это может вызвать отказ в работе некоторых процедур безопасности. Метка MPLS имеет свое значение благодаря соглашению между LSR, который записывает метку в стек (источник метки), и LSR, который интерпретирует метку (получатель метки). Если помеченный пакет получен от непроверенного отправителя, или если некоторая метка получена от LSR, которому она не посылалась, тогда пакеты могут маршрутизоваться некорректным образом.
6. Ссылки
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress.
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress.
[MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress.
[MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
4.4.19. Кодирование меток в MPLS
Семёнов Ю.А. (ГНЦ ИТЭФ), ссылка скрыта
E. Rosen, RFC-3032, MPLS Label Stack Encoding
Аннотация
"Многопротокольная коммутация меток (MPLS)" [1] требует наличия набора процедур для пакетов со стеком меток (помеченных пакетов). Маршрутизаторы, которые поддерживают MPLS, называются LSR (Label Switching Routers). Для того чтобы переслать помеченный пакет по конкретному каналу, LSR должен поддерживать систему представления стека меток и обработки пакетов сетевого уровня. В данном документе специфицирована система представления стека меток, используемая LSR, для того чтобы передавать помеченные пакеты по каналам PPP (Point-to-Point Protocol), по каналам данных LAN, и возможно по другим каналам. В других каналах кодирование может быть иным, но представление стека меток должно быть стандартным. Здесь также специфицируются правила и процедуры для обработки различных полей записей в стеке меток.
1. Введение
"Многопротокольная коммутация меток (MPLS)" [1] требует набора процедур для дополнения пакетов сетевого уровня "стеком меток", таким образом превращая их в помеченные пакеты. Маршрутизаторы, которые поддерживают протокол MPLS, называются LSR (Label Switching Routers). Для того чтобы передать помеченный пакет по определенному каналу, LSR должен поддерживать методику кодирования, и анализа помеченных пакетов. Данный документ специфицирует кодирование, используемое LSR, для того чтобы передать помеченный пакет по каналу данных PPP и LAN. Специфицированная кодировка может быть применена и в других каналах данных.
Этот документ специфицирует также правила и процедуры обработки различных полей стека меток. Так как MPLS не зависит от сетевого протокола, большинство таких процедур являются протокольно независимыми. Некоторые, однако, являются разными для различных протоколов. В этом документе, мы специфицируем протокольно независимые процедуры, а также протокольно зависимые процедуры для IPv4 и IPv6.
LSR, которые реализованы на определенном коммутационном оборудовании (таком как ATM-коммутаторы) могут использовать различные системы кодирования верхних записей в стеке.
2. Стек меток
2.1. Кодирование стека меток
Стек меток представляет собой последовательность записей. Каждая запись в стек имеет длину 4 октета. Формат такой записи показан на рис. 1.
Рис. 1. Формат записи стека меток
Запись стека меток размещается после заголовка канального уровня, и перед заголовком сетевого уровня (например, между Ethernet- и IP-заголовком). Верх стека записывается первым, а дно - последним. Сетевой заголовок следует сразу вслед за записью стека меток с битом S=1. Каждая запись стека меток содержит в себе следующие поля:
1. Дно стека (S)
Этот бит устанавливается равным 1 для последней записи в стеке меток (т.e., для дна стека), и нулю для всех прочих записей.
Замечание переводчика. Следует заметить, что данный формат меток не является единственно возможным (я здесь не имею в виду ATM или FR). В IP-телефонии, например, предлагается использовать метку, которая содержит (слева-направо) код 0х8100, за которым идет 3-битовое поле приоритета (0-7) и идентификатор VPN (0-4095). Смотри журнал LANline N10, 2002, стр 140).
2. Время жизни (TTL)
Это 8-битовое поле служит для представления значения времени жизни пакета. Обработка этого поля описана в разделе 2.4.
3. Экспериментальное поле
Это 3-битовое поле зарезервировано для экспериментальных целей (QoS).
4. Значение метки
Это 20-битовое поле несет в себе код метки.
Когда получен помеченный пакет, анализируется значение метки на верху стека. В результате этого анализа определяется:
a) следующий шаг, куда должен быть переадресован пакет;
b) операция, которая должна быть выполнена со стеком меток до переадресации; эта операция может быть заменой метки на вершине стека, или удаление записи из стека, или замещение верхней позиции в стеке и занесение туда затем одной или более новых записей.
В дополнение к определению следующего шага и операции со стеком меток, можно также получить данные об инкапсуляции выходной информации, и возможно другие данные, которые необходимы, для того чтобы корректно переадресовывать пакеты. Существует несколько зарезервированных значений меток:
i. Значение 0 представляет "IPv4 Explicit NULL Label". Это значение метки является единственно допустимым для дна стека меток. Оно указывает, что стек должен быть очищен, и переадресация пакета должна основываться на IPv4-заголовке.
ii. Значение 1 представляет "Router Alert Label". Это значение метки является легальным в любом месте стека меток за исключением дна. Когда полученный пакет содержит такую метку на вершине стека, он доставлен локальному модулю для обработки. Действительная переадресация пакета определяется меткой, в его стеке. Однако, если пакет переадресуется дальше, еще до переадресации в стек должна быть занесена метка Router Alert. Использование этой метки сходно с применением опции "Router Alert" в IP-пакетах [5]. Так как эта метка не может лежать на дне стека, она не ассоциируется с определенным протоколом сетевого уровня.
iii. Значение 2 представляет "IPv6 Explicit NULL Label". Это значение метки является единственно допустимым для записи на дне стека. Оно указывает, что стек должен быть очищен, а переадресация пакетов должна после этого основываться на заголовке IPv6.
iv. Значение 3 представляет "Implicit NULL Label". Это метка, которую LSR может присваивать и рассылать, но которая в действительности никогда не используется при инкапсуляции. Когда LSR замещает метку на верху стека на новую, и эта новая метка является "Implicit NULL", LSR очистит стек вместо того, чтобы осуществить замену. Хотя это значение не может появиться при инкапсуляции, оно должно быть специфицировано в протоколе рассылки меток, так что значение может считаться зарезервированным.
v. Значения 4-15 зарезервированы.
2.2. Определение протокола сетевого уровня
Когда последняя метка удалена из стека (стек становится пустым), дальнейшая обработка пакета осуществляется на основе его заголовка сетевого уровня. LSR, который извлекает последнюю метку из стека, должен быть способен работать с протоколом сетевого уровня. Однако, стек меток не содержит поля, идентифицирующего протокол сетевого уровня. Это означает, что идентичность сетевого протокола должна определяться по значению кода метки, извлеченной со дна стека, возможно, вместе с самим содержимым заголовка сетевого уровня.
Следовательно, когда в сетевой пакет заносится первая метка, она должна быть уникальной для конкретного сетевого уровня или для набора сетевых протоколов. Кроме того, когда бы в процессе передачи метка ни была заменена другой, новая метка также должна отвечать тем же критериям. Если эти условия не выполнены, LSR, который удаляет последнюю метку из пакета, не сможет идентифицировать сетевой протокол.
Строгое соблюдение этих условий не обязательно приведет немедленно к тому, что узлы будут распознавать сетевой протокол. В обычных условиях, это необязательно, но в ситуациях ошибок это оказывается крайне желательным. Например, если промежуточный LSR определяет, что помеченный пакет не может быть доставлен, может быть желательно для данного LSR сформировать сообщение об ошибке, которое является специфическим для пакетов сетевого уровня. Единственные средства, которыми располагает промежуточный LSR для идентификации сетевого уровня, является анализ верха стека и заголовка сетевого уровня. Таким образом, если промежуточные узлы способны посылать протокольно зависимые сообщения об ошибках для помеченных пакетов, все метки в стеке должны отвечать критериям, приведенным выше для меток, которые занесены на дно стека.
Если пакет не может быть переадресован по какой-то причине (например, его размер превосходит MTU канала), и либо его протокол сетевого уровня не может быть идентифицирован, либо не существует протокольно зависимых правил для обработки случаев ошибок, тогда пакет должен быть без комментариев отброшен.
2.3. Генерация ICMP-сообщений для помеченных пакетов
В разделах 2.4 и 3 обсуждаются ситуации, в которых желательно формировать ICMP-сообщения для помеченных IP-пакетов. Для того чтобы конкретный LSR мог формировать и посылать ICMP пакеты отправителям IP-пакетов, должны выполняться два условия:
1. Данный LSR должен быть способен определить, что конкретный помеченный пакет является IP-пакетом.
2. Данный LSR должен быть способен проложить путь до места назначения IP-пакета.
Условие 1 обсуждается в разделе 2.2. В следующих двух подразделах обсуждается условие 2. Однако встречаются ситуации, когда условие 2 совсем не выполняется, и в этих случаях невозможно сформировать сообщение ICMP.
2.3.1. Туннелирование через транзитную область маршрутизации
Предположим, что MPLS используется для организации туннеля через транзитную область маршрутизации, где данные о внешних маршрутах не попадает к внутренним маршрутизаторам. Например, внутренние маршрутизаторы работают с протоколом OSPF, и могут только знать, как достичь объектов в пределах зоны OSPF. Домен может содержать несколько пограничных маршрутизаторов автономной системы ASBR (Autonomous System Border Routers), которые взаимодействуют друг с другом с помощью BGP. Однако в этом примере маршруты от BGP не рассылаются OSPF, и LSR, которые не являются ASBR, поддерживают BGP.
В этом примере, только ASBR будет знать, как проложить маршрут до отправителя некоторого произвольного пакета. Если внутренний маршрутизатор должен послать сообщение ICMP отправителю IP-пакета, он не будет знать как маршрутизовать это ICMP-сообщение.
Одним из решений является занесение ASBR маршрута по умолчанию в IGP. Это бы гарантировало то, что любой непомеченный пакет, который должен выйти из домена (такой как ICMP-пакет), попадет в маршрутизатор, который имеет полную маршрутную информацию. Маршрутизаторы с полной маршрутной информацией будет помечать пакеты, прежде чем их послать через транзитную область, так что использование маршрутов по умолчанию в пределах транзитного домена не приводило к образованию циклических путей.
Это решение работает только для пакетов, которые имеют глобально уникальные адреса, и для сетей, в которых все ASBR имеют полную маршрутную информацию. В следующем подразделе описывается решение, которое работает, когда эти условия не выполняются.
2.3.2. Туннелирование частных адресов через общедоступную опорную сеть
В некоторых случаях, когда MPLS используется для туннелирования через домен маршрутизации, может быть вообще невозможно проложить путь до адреса отправителя фрагментированных пакетов. Такая ситуация возникла бы, например, если IP-адреса в пакетах были частными адресами (т.e., не были глобально уникальными), и MPLS использовался для туннелирования таких пакетов через общедоступную опорную сеть. Маршруты по умолчанию в ASBR не будет работать в таких условиях.
В этих условиях, для того чтобы послать ICMP-сообщение отправителю пакета, можно копировать стек меток исходного пакета в ICMP-сообщение, и затем осуществить коммутацию по меткам для ICMP-пакета. Это заставит сообщение двигаться в направлении места назначения исходного пакета, а не его отправителя. Если только сообщение не является коммутируемым по меткам на всем пути до ЭВМ назначения, оно завершит путь непомеченным в маршрутизаторе, который знает путь до отправителя исходного пакета, отсюда сообщение будет послано в правильном направлении.
Эта технология может быть весьма полезной, если ICMP-сообщением является "Time Exceeded" (время истекло) или "Destination Unreachable because fragmentation needed and DF set" (место назначение недостижимо из-за необходимости фрагментации и DF=1).
При копировании стека меток из исходного пакета в сообщение ICMP, значения меток должны копироваться точно, но значения TTL должны устанавливаться равными величине, размещенной в IP-заголовке ICMP-сообщения. Это значение TTL должно быть достаточным, чтобы позволить кружной маршрут, которому должен следовать ICMP-сообщение.
Заметим, что если истечение TTL сопряжено с наличием петли маршрута, тогда в случае использования этой техники, ICMP-сообщение может циклить. Так как сообщение ICMP никогда не посылается в ответ на ICMP-пакет, и так как многие реализации ограничивают частоту посылки ICMP-сообщений, проблем это создать не должно.
2.4. Обработка поля времени жизни
2.4.1. Определения
"Входное TTL" помеченного пакета по определению должно равняться значению поля TTL в записи наверху стека меток на момент получения пакета. "Выходное TTL" помеченного пакета по определению должно равняться большему из:
a) входное значение TTL минус один,
b) нуль.
2.4.2. Протокольно независимые правила
Если выходное TTL помеченного пакета =0, тогда помеченный пакет не должен более переадресовываться и пакет следует далее непомеченным. Время жизни пакета в сети считается истекшим. В зависимости от значения метки в стеке, пакет может быть просто отброшен, или он может быть передан сетевому слою для обработки ошибки (например, для генерации ICMP сообщения об ошибке, смотри раздел 2.3).
Когда помеченный пакет переадресуется, поле TTL записи наверху стека меток должно быть установлено равным выходному значению TTL.
Заметим, что выходное значение TTL является функцией входного значения TTL, и зависит оттого, были ли перед этим в стек занесены или извлечены какие то метки до переадресации пакета. Значения поля TTL в записях, за исключением верхней, никакого влияния не оказывают.
2.4.3. Правила, зависящие от IP
Мы определяем поле "IP TTL" равным величине поля IPv4 TTL, или значению поля IPv6 Hop Limit, в зависимости оттого, что используется.
Когда IP-пакет помечен впервые, поле TTL в стеке должно быть установлено равным значению поля IP TTL.
Когда все метки извлекаются из стека, и он оказывается пустым, значение поля IP TTL должно быть замещено величиной выходного TTL, как это определено выше. В случае IPv4 это потребует также корректировки контрольной суммы IP заголовка.
Признается, что могут существовать ситуации, когда сетевая администрация предпочитает декрементировать IPv4 TTL на 1 при прохождении через домен MPLS, вместо того чтобы декрементировать IPv4 TTL на число LSR в домене.
2.4.4. Преобразование различных инкапсуляций
Иногда LSR может получить помеченный пакет через, например, интерфейс ATM (LC-ATM) [9], и должен будет послать его через PPP или LAN. Тогда входной пакет будет получен без инкапсуляции, описанной в данном документе, а будет послан уже с применением такой инкапсуляции.
В этом случае значение "входное TTL" определяется процедурами обработки помеченных пакетов, например, в интерфейсе LC-ATM. Обработка TTL будет тогда происходить так, как это описано выше. Иногда LSR может получить помеченный пакет через канал PPP или LAN, и должен его послать на выход через интерфейс LC-ATM. Тогда входной пакет будет принят с использованием инкапсуляции, описанной в данном документе, а выходной пакет послан с привлечением иной инкапсуляции. В этом случае процедура формирования значения "выходного TTL" определяется процедурами, применяемыми к помеченным пакетам, например, в интерфейсах LC-ATM.
3. Фрагментация и определение MTU пути
Поскольку возможно получение непомеченной IP-дейтограммы, которая слишком велика, чтобы быть передана в выходной канал, имеется возможность получения помеченного пакета, который также невозможно передать по этой причине на выход.
Возможно также, что полученный пакет (помеченный или нет), который первоначально был достаточно мал для передачи через канал, становится слишком большим, получив одну или более меток. При коммутации меток, пакет может расти в размере, если в его стек заносятся дополнительные метки. Таким образом, если получен помеченный пакет с 1500-байтовым полем данных, и в него записана дополнительная метка, переадресовать нужно будет пакет с размером 1504-байта.
В этом разделе специфицируются правила обработки помеченных пакетов, которые являются "слишком большими". В частности, речь идет о правилах, которые гарантируют, что ЭВМ, использующие определение MTU пути [4], и ЭВМ, работающие с IPv6 [7,8], будут способны формировать IP-дейтограммы, которые не нуждаются в фрагментации, даже если эти дейтограммы получили дополнительные метки при прохождении через сеть.
Вообще, ЭВМ IPv4, которые не используют определение MTU пути [4], посылают IP-дейтограммы, содержащие не более 576 байт. Так как большинство используемых MTU равняются 1500 байт или больше, вероятность того, что такие дейтограммы будут нуждаться в фрагментации, даже если они помечены, весьма мала.
Некоторые ЭВМ, которые не используют определение MTU пути [4], формируют IP-дейтограммы, содержащие 1500 байт. Поскольку IP-адреса отправителя и получателя в одной и той же субсети, эти дейтограммы не проходят через маршрутизаторы, и, следовательно, не будут фрагментироваться
Если же IP-адрес отправителя и получателя находятся в разных автономных системах, это единственный случай, когда имеется риск фрагментации при пометке пакета.
В этом документе специфицированы процедуры, которые позволяют конфигурировать сеть так, что большие дейтограммы от ЭВМ, не использующих определение MTU пути, фрагментируются только раз, когда они впервые помечены. Эти процедуры делают возможным избежать фрагментации пакетов, которые уже помечены.