Сети и телекоммуникации

591

байта), даже если реальное значение маркера размещается в VPI/VCI-поле. Это делается для того, чтобы гарантировать постоянное присутствие универсальной MPLS-вставки в IP-пакете. В противном случае, не было бы возможности определить, содержит IP-пакет вставку или нет, т.е. невозможно определить наличие дополнительных записей в наборе маркеров.)

Существуют только два способа для удаления этого дополнительного по-

ля с универсальной MPLS-вставкой, а именно:

априорное знание того, IP-пакеты содержат только одиночный маркер

(например, возможно сеть поддерживает только один уровень маркеров);

использование двух VC-соединений для одного FEC-класса, т.е. одного

— для тех IP-пакетов, которые содержат только одиночный маркер, а

другого — для тех IP-пакетов, которые содержат более одного маркера.

Второй способ может потребовать, чтобы имело место некоторое сред-

ство сигнализации на основе LDP-протокола, которое бы оповещало, что VC-

соединение предназначено только для доставки IP-пакетов с одиночным марке-

ром, и не предназначено для доставки универсальной MPLS-вставки. Когда реализуется функция объединения VC-соединений, тогда можно было бы не объединять VC-соединение, по которому не доставляются IP-пакеты с универ-

сальной MPLS-вставкой, с VC-соединением, по которому такие IP-пакеты дос-

тавляются, или наоборот.

Несмотря на то, что оба способа разрешены, весьма сомнительно, что они имеют какое-либо практическое применение. Следует заметить, что если уни-

версальная MPLS-вставка отсутствует, то исходящее TTL-значение транслиру-

ется в TTL-поле заголовка сетевого уровня.

Обработка TTL-значения

Рассматриваемые далее процедуры касаются только граничных LSR-мар-

шрутизаторов, входящих сетевой ATM/LSR-сегмент. Сами по себе ATM/LSR-

коммутаторы не могут каким-либо образом корректировать TTL-значение.

592

Процедура настройки значения в TTL-поле следующая. Если IP-пакет,

принятый граничным LSR-маршрутизатором, является не помеченным, то

«входящее TTL-значение» извлекается из поступившего IP-заголовка. Если же

IP-пакет, принятый граничным LSR-маршрутизатором, является помеченным,

то используется MPLS-вставка, и «входящее TTL-значение» извлекается из верхней записи в наборе маркеров.

Если значение счѐтчика РУ было связано с привязкой маркера, которая использовалась при доставке IP-пакета, то «исходящее TTL-значение» будет:

a)либо больше нуля:

b)либо составлять разницу между входящим TTL-значением и значением счѐтчика РУ.

Если значение счѐтчика РУ не было связано с привязкой маркера, которая использовалась при доставке IP-пакета, то «исходящее TTL-значение» будет:

a)либо больше нуля:

b)либо на единицу меньше входящего TTL-значения.

Если в результате рассмотренных манипуляций с входным TTL-значени-

ем выходное TTL-значение становится нулевым, то IP-пакет не должен переда-

ваться как помеченный IP-пакет, использующий специализированный маркер.

Врезультате анализа IP-пакета могут быть предприняты следующие действия:

он может рассматриваться как IP-пакет с просроченным «временем жиз-

ни». И в этой связи можно отправить ICMP-сообщение;

IP-пакет может быть доставлен как непомеченный, в котором TTL-значе-

ние на единицу меньше входящего TTL-значения. В данном случае, такая доставка могла бы понадобиться при установлении виртуального соеди-

нения без использования MPLS-коммутации.

Конечно, если входное TTL-значение равно единице, то реализуется только первая из рассмотренных выше функций.

Если IP-пакет доставляется как помеченный, то исходящее TTL-значение транслируется, как это описано ранее.

593

Когда граничный LSR-маршрутизатор получает помеченный IP-пакет че-

рез LC/ATM-интерфейс, он извлекает входящее TTL-значение из верхней за-

писи набора маркеров, являющегося универсальной MPLS-вставкой, или, если такая вставка отсутствует — из IP-заголовка.

Если на следующем РУ IP-пакета расположен ATM/LSR-коммутатор, то исходящее TTL-значение формируется с использованием рассмотренных ранее процедур. В противном случае, исходящее TTL-значение формируется с ис-

пользованием процедур, рассмотренных в стандарте RFC-3032.

Процедуры, рассмотренные в данном разделе, предназначены только для

IP-пакетов с однонаправленными (unicast) адресами.

Функция обнаружения петлевых маршрутов: распределение маршрутных векторов

Каждый ATM/LSR-коммутатор должен обладать, в качестве дополните-

льной, функцией обнаружения петлевых маршрутов доставки. Сама же функ-

циональная процедура именуется как «обнаружение петлевого маршрута с по-

мощью маршрутных векторов» (Loop Detection via Path Vectors, LDPV). Эта процедура не предотвращает формирование петлевых маршрутов доставки, но гарантирует, что любые подобные маршруты будут обнаружены. Если эта до-

полнительная функция не реализована, то петлевые маршруты выявляются с помощью способа, основанного на подсчѐте числа РУ, рассмотренного ранее.

Если же эта функция реализована, то петлевые маршруты выявляются намного быстрее, но с более существенными затратами.

Когда передаѐтся нисходящий трафик с маршрутными векторами

Предположим, что LSR-маршрутизатор R передаѐт противоположной стороне своего следующего РУ запрос на данные о привязке маркера к опреде-

лѐнному LSP-маршруту. Тогда, если R не реализует функцию объединения VC-

соединений, но R способен осуществлять LDPV-процедуру:

595

Могут возникнуть ситуации, при которых LSR-маршрутизатор R должен информировать свои соседние LSRВП об изменении значения счѐтчика РУ соот-

ветствующих определѐнному LSP-маршруту (с использованием ответного со-

общения с данными о привязке маркера). Если выполнены все следующие ус-

ловия:

o R настроен на выполнение LDPV-процедуры;

o R реализует функцию объединения VC-соединений; o R не является выходом данного LSP-маршрута;

oR не информирует своих соседей об уменьшении значения счѐтчика РУ,

то R обязан включить данные о маршрутном векторе в ответное сообще-

ние.

Если изменение значения счѐтчика РУ явилось следствием информирова-

ния R LSR-маршрутизатором S, расположенном на противоположной стороне следующего РУ, об изменении значения счѐтчика РУ, а сообщение отправлен-

ное S LSR-маршрутизатору R содержит данные о маршрутном векторе, то, если все указанные выше условия выполнены, R обязан добавить себя в эти данные и отправить результирующее сообщение LSRВП. В противном случае, если все указанные выше условия выполнены, R обязан сформировать новые данные только со своим собственным IP-адресом.

Если R настроен на выполнение LDPV-процедуры, и R реализует функ-

цию объединения VC-соединений, то он может включить данные о маршрут-

ном векторе в любое ответное сообщение, содержащее данные о привязке мар-

кера, которое он передаѐт LSRВП. Соответственно, в любой момент времени,

когда R принял от противоположной стороны следующего РУ ответное сооб-

щение с данными о привязке маркера, и если это ответное сообщение включает маршрутный вектор, то R может (если он настроен на выполнение LDPV-про-

цедуры) отправить своим соседним LSRВП ответ, содержащий данные о мар-

шрутном векторе, сформированные путѐм добавления своего собственного IP-

адреса в полученный маршрутный вектор.

596

Если R не реализует функцию объединения VC-соединений, то ему не це-

лесообразно передавать LSRВП данные о маршрутном векторе.

Если R принял от противоположной стороны следующего РУ сообщение,

в котором данные о маршрутном векторе включают его собственный IP-адрес,

то LSR-маршрутизатор обязан действовать так, как если бы он принял сообще-

ние со значением счѐтчика РУ, равным MAXHOP.

LSR-маршрутизаторы, которые настроены на выполнение LDPV-проце-

дуры, не должны хранить маршрутный вектор, после того как соответствующие данные о маршрутном векторе были переданы.

(Примечание. Если сетевой ATM/LSR-сегмент включает только лишь ATM/LSR-коммутаторы, не реализующие функцию объединения VC-соединений, то нет необходимости всегда передавать LSRВП маршрутные векторы, так как любые петлевые маршруты будут выявляться с посредством маршрутных векторов, доставляемых в составе нисходящих потоков.)

Если не транслировать маршрутные векторы до тех пор, пока счѐтчик РУ возрастает, то во многих ситуациях, когда нет петлевого маршрута, LSR-мар-

шрутизатор старается их не передавать. Издержки появляются в тех ситуациях,

в которых существует петлевой маршрут, а время выявления петлевого мар-

шрута может увеличиться.

ЛИ Т Е Р А Т У Р А

1.Коржик В.И., Финк Л.М. Помехоустойчивое кодирование в каналах со случайной структурой. — М.: Связь. 1975.

2.Финк Л.М. Сигналы, помехи, ошибки ... Заметки о некоторых неожиданностях, парадоксах и заблуждениях в теории связи. М.: Радио и связь, 1984.

3.Финк Л.М. и др. Теория передачи сигналов. М.: Радио и связь, 1986.

4.Макаров С.Б., Цикин И.А. Передача дискретных сообщений по радиоканалам с ограниченной полосой пропускания. — М.: Радио и связь. 1988.

5.Григорьев В.А. Передача сигналов в зарубежных информационно-технических системах. — СПб.: ВАС, 1995.

6.Кунегин С.В. Системы передачи информации. Курс лекций. М.: в/ч 33965, 1997.

7.Цифровые и аналоговые системы передачи: Учебник для вузов / В.И. Иванов, В.Н. Гордиенко, Г.Н. Попов и др.; Под ред. В.И. Иванова. - М.: Радио и связь, 1995.

8.Витерби А.Д., Омура Дж.К. Принципы цифровой связи и кодирования. М.: Радио и связь, 1982.

9.Ungerboeck G. Channel coding with multilevel/phase signals // IEEE Trans. on Inform. Theory. 1982. Vol. IT—28. № 1. P. 55-67.

10.Wei L.F. Trellis-coded Modulation with Multidimensional Constellations // IEEE Trans.— 1987.— Vol.IT-33,

№ 4.

11.G.A. Zimmerman. Test environments for HDSL2. PairGain contribution T1E1.4/97-182, May 15, 1997.

12.Mike Tu. A 512-State PAM TCM for HDSL2. PairGain contribution T1E1.4/97-300 September 1997.

13.G.A. Zimmerman. HDSL2 Tutorial: Spectral Compatibility and Real-World Performance Advances. PairGain Technologies, Inc. June 1998.

14.G.A. Zimmerman. HDSL2, Spectral Compatibility, and Future xDSLs. PairGain Technologies, Inc. April 2000.

15.Зяблов В.В. и др. Высокоскоростная передача сообщений в реальных каналах. — М.: Радио и связь.

1991.

16.Ларионов А.М. и др. Вычислительные комплексы, системы и сети. Л.: Энергоатомиздат, 1987.

17.Шварцман В.О. и др. Синхронные сети передачи данных. М.: Радио и связь, 1988.

18.Дэвис Д., Барбер Д. Сети связи для вычислительных машин. М.: Мир, 1976.

19.Дэвис Д. и др. Вычислительные сети и сетевые протоколы. М.: Мир, 1982.

20.Блэк Ю. Сети ЭВМ: Протоколы, стандарты, интерфейсы. М.: Мир, 1990.

21.Шварц М. Сети связи: протоколы, моделирование и анализ. М.: Наука, 1992. Ч. 1, 2.

22.Самойленко С.И. Сети ЭВМ. М.: Наука, 1986.

23.Морозов В.К., Долганов А.В. Основы теории информационных сетей. М.: Высш. шк., 1987.

24.Толковый словарь по вычислительным системам. М.: Машиностроение, 1990.

25.Якубайтис Э.А. Информационно-вычислительные сети. М.: Финансы и статистика, 1984.

26.Беллами Дж. Цифровая телефония. М.: Радио и связь, 1986.

27.Лазарев В.Г., Лазарев Ю.В. Динамическое управление потоками информации в сетях связи. М.: Радио и связь, 1983.

28.Протоколы и методы управления в сетях передачи данных / Под ред. Куо Ф.Ф. М.: Радио и связь, 1985.

29.Special Issue: Dynamic Routing in Telecommunications Networks. IEEE Commun. Mag., vol. 33 no. 7, 1995.

30.Галлагер Р. Теория информации и надежная связь. М.: Советское радио, 1974.

31.Бертсекас Д., Галлагер Р. Сети передачи данных. М.: Мир, 1989.

32.Лазарев В.Г. Сетевые протоколы и управление в распределенных вычислительных системах. М.: Наука, 1986.

33.Суздалев А.В., Чугреев О.С. Передача данных в локальных сетях связи. М.: Радио и связь, 1987.

34.Щербо В.К. и др. Стандарты по локальным вычислительным сетям. - М.: Радио и связь, 1990.

35.Douglas E. Comer. Internetworking with TCP/IP. New Jersey, 1991.

36.Stevens W.R. TCP/IP illustrated. New York, 1994.

37.Smith Ph. Frame Relay: Principles and Applications. Addison-Wesley, 1993.

38.Баушев С.В., Тормышев С.А., Яковлев А.А. Режимы доставки для широкополосных цифровых сетей интегрального обслуживания. - Зарубежная радиоэлектроника. 1992, № 2.

39.Prycker M. de. Asynchronous Transfer Mode: Solution for Broadband ISDN. Ellis Horwood, 1993.

40.Postel, J., «User Datagram Protocol», RFC-768, August 1980.

41.Postel, J., «Internet Protocol», RFC-791, September 1981.

42.Postel, J., «Internet Control Message Protocol», RFC-792, September 1981.

43.Postel, J., ed., «Transmission Control Protocol», RFC-793, September 1981.

44.Postel,J. and J. Reynolds, «File Transfer Protocol (FTP)», RFC-959, October1985.

45.Simpson, W., ed., «The Point-to-Point Protocol (PPP)», RFC-1661, July 1994.

598

46.Carpenter, B.,ed., «Architectural Principles of the Internet», RFC-1958, June 1996.

47.Malkin, G., ed., «Internet Users' Glossary», RFC-1983, August 1996.

48.Moy, J., «OSPF Version 2», RFC 2328, April 1998.

49.Deering S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC-2460, December 1998.

50.Hinden,R. and S.Deering, «IP Version 6 Addressing Architecture», RFC-4291, February 2006.

51.Awduche D., «Requirements for Traffic Engineering Over MPLS», RFC 2702, September 1999.

52.Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

53.Rosen E., «MPLS Label Stack Encoding», RFC 3032, January 2001.

54.Conta A., «Use of Label Switching on Frame Relay Networks Specification», RFC 3034, January 2001.

55.Davie B., «MPLS using LDP and ATM VC Switching», RFC 3035, January 2001.

56.Andersson L., «LDP Specification», RFC 5036, January 2001.

57.Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January

2006.

58.Мельников Д. Frame Relay для профессионалов и не только... Часть 1. - Сети. М.: Открытые системы. - № 10, 1997.

59.Костиков Д., Мельников Д., Савельев М., Шерстнев В. Frame Relay для профессионалов и не только...

Часть 2. - Сети. М.: Открытые системы. - № 3, 1998.

60.Захаркин С., Мельников Д., Савельев М. Frame Relay для профессионалов и не только... Часть 3. - Сети. М.: Открытые системы. - № 5, 1998.

61.Мельников Д.А. Организация информационного обмена в информационно-вычислительных сетях. Учебное пособие. — М.: ФАПСИ, 1998.

62.Мельников Д.А. Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы, модели... — М.: КУДИЦ-ОБРАЗ, 1999, ISBN 5-93378-0002-2.

63.Мельников Д.А. Организация и обеспечение безопасности информационно-технологических сетей и систем: Учебник. — М.: IDO Press. Университетская книга, 2012, ISBN 978-5-91304-246-0.