CITKIT.ru
3 терабайта свободного софта!
Logo    
IT-рынок Новости мира IT Океан(!) софта на CITKIT.ru Форумы Поступления в библиотеку Учебный центр Курилка
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

16.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 11.05 - Intel создает свою группу по Open Source
  • 11.05 - Банк контролирует использование USB устройств при помощи DeviceLock
  • 11.05 - Microsoft устранила опасную дыру в Windows
  • 11.05 - "Корпорация ОСС" создает антимонопольный альянс операторов IP-телефонии
  • 11.05 - В Mac OS X найдены множественные уязвимости
  • 11.05 - "Билайн" запускает услугу "Мобильная почта"
  • 11.05 - Две критические уязвимости в браузере Firefox 1.0.3
  • 11.05 - IBM покупает начинающую Open Source-компанию Gluecode
  • 11.05 - Microsoft готова к битве с Open Source за школы
  • 11.05 - Sun завершит "открытие" Solaris в ближайшие 45 дней
  • 11.05 - Создатели браузера Firefox выпускают юбилейные монеты в честь 50 миллионов скачанных копий
  • 11.05 - Вышла пятая версия мобильной ОС от Microsoft
  • 11.05 - Поисковые движки умнеют быстрее, чем люди
  • 11.05 - Фишеры постоянно совершенствуются
  • 11.05 - Специалисты прогнозируют появление аналога Google Adsense от "Яндекс"
  • 06.05 - ICANN озаботилась проблемой торговых марок
  • 06.05 - Google патентует сортировку новостей
  • 06.05 - Intel готовит двуядерные процессоры второго поколения
  • 06.05 - Schoolforge-UK и OSC продвигают Open Source в школы
  • 06.05 - Новая версия рекламной программы подстрекает пользователей купить ПО для своего лечения
  • 06.05 - Microsoft продает ряд своих закрытых разработок
  • 06.05 - Google Labs анонсировал ускоритель интернета
  • 06.05 - Microsoft подвешивает пиратам "морковку"
  • 06.05 - В США входят в обиход "интеллектуальные" тележки для супермаркетов
  • 06.05 - Microsoft работает над аналогом PDF
  • 05.05 - Yahoo video search теперь доступен массам
  • 05.05 - Алмазы помогут бороться с хакерами
  • 05.05 - Интернет-охоту хотят запретить
  • 05.05 - Microsoft привлекает блоггеров для теста Longhorn
  • 05.05 - Основатель Red Hat предложил Стиву Джобсу помощь в решении проблемы с торговой маркой
  • 05.05 - Компьютерная система оргкомитета Кубка мира по футболу 2006 года пострадала от червя Sober
  • 04.05 - Cisco Systems представила многофункциональный продукт Adaptive Security Appliance 5500
  • 04.05 - Администрация Евросоюза поддержала идею всеевропейской интернет-библиотеки
  • 04.05 - Компьютерный вирус дарит билеты на чемпионат мира по футболу
  • 04.05 - Лаборатория Касперского: Обзор вирусной активности - апрель 2005
  • 04.05 - Microsoft хочет отсудить у россиянина два домена
  • 04.05 - Сделка между Lenovo и IBM завершена
  • 04.05 - Эпидемия червя Sober.p зафиксирована в Западной Европе
  • 04.05 - Panda Software публикует отчет о вирусной активности за апрель
  • 03.05 - Институт SANS обновил список наиболее опасных уязвимостей

    Архив новостей >>>


  • 2005 г.

    4.4.26 Обобщенная мультипротокольная коммутация по меткам (GMPLS)

    Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

    1. Введение

    Архитектура протокола MPLS [RFC3031] была определена для переадресации пакетов на основе меток. В этой архитектуре предполагается, что маршрутизаторы LSR способны (a) распознавать границы пакетов или ячеек, и (b) могут обрабатывать заголовки пакетов (для LSR, способных распознавать границы пакетов) или заголовки ячеек (для LSR, способных распознавать границы ячеек).

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

    Подобные LSR, или точнее интерфейсы LSR, могут быть отнесены к следующим классам:

    1. Интерфейсы, которые распознают границы пакетов/ячеек и могут переадресовать данные с учетом содержимого заголовка пакета/ячейки. Примерами могут служить интерфейсы маршрутизаторов, которые переадресуют данные на основе содержимого промежуточных заголовков, интерфейсы ATM-LSR, которые переадресуют данные на основе VPI/VCI ATM. Такие интерфейсы считаются способными коммутировать пакеты (PSC - Packet-Switch Capable).

    2. Интерфейсы, которыеи переадресуют данные на основе циклических временных доменов. Примером такого интерфейса является соединение SONET/SDH. Такие интерфейсы считаются мультиплексирующими по времени (TDM).

    3. Интерфейсы, которые переадресуют данные на основе длины волны, на которой данные получены. Примером такого интерфейса является оптические коммутаторы, которые работают на уровне отдельных длин волн. Такие интерфейсы считаются l -переключателями LSC (Lambda Switch Capable).

    4. Интерфейсы, которые переадресуют данные на основе положения данных в реальном физическом пространстве. Примером такого интерфейса является оптическое подключение, которое работает на уровне одного (или нескольких) волокон. Такие интерфейсы считаются оптическими переключателями FSC (Fiber-Switch Capable).

    Использование концепции вложенных путей с коммутацией по меткам (LSP) позволяет системе масштабировать построение иерархии переадресаций. На верху этой иерархии интерфейсы FSC, далее следуют интерфейсы LSC, затем TDM, и, наконец, PSC. Таким образом, LSP, который имеет на входе и выходе интерфейс PSC, может образовывать цепи вложения с другими LSP, формируя LSP, который начинается и завершается интерфейсом TDM. Этот LSP, в свою очередь, может вкладываться (вместе с другими LSP) в LSP, который начинается и завершается интерфейсом LSC, который в свою очередь вкладывается совместно с другими LSP в LSP, который начинается и завершается интерфейсом FSC. Подробности смотри в [MPLS-HIER RCHY]. Установление LSP, который покрывает только первый класс интерфейсов, определено в [RFC3036, RFC3212, RFC3209]. В данном документе предлагается функциональное описание расширений, которые необходимы для обобщения MPLS в направлении поддержки каждого из четырех классов интерфейсов. Форматы, специфические для протокола определены в [RFC3473] и [RFC3472].


    2. Обзор

    Обобщенный MPLS отличается от традиционного MPLS тем, что он поддерживает много типов коммутации, т.е., TDM, l -, волоконную коммутацию. Поддержка дополнительных видов коммутации вынуждают обобщенный протокол MPLS расширить некоторые базовые функции MPLS и, в некоторых случаях добавить определенные функции. Эти изменения и добавления оказывают влияние на то, как осуществляются запросы и транспортировка меток, как пересылаются сообщения об ошибках и как выполняется синхронизация на входе и на выходе.

    В традиционном управлении трафиком MPLS (TE), каналы, через которые проходит LSP, могут содержать сегменты с разной кодировкой меток. Например, LSP может содержать каналы, соединяющие маршрутизаторы, каналы между маршрутизаторами и ATM-LSR, и каналы между ATM-LSR. Обобщенный MPLS осуществляет расширение функциональности путем включения каналов, где метка кодируется как временной домен, длина волны, или позиция в физическом пространстве. Также как и в традиционном MPLS TE, где не все LSR могут распознавать границы IP-пакетов (напр., ATM-LSR) при переадресации, обобщенный MPLS включает в себя поддержку LSR, которые не распознают границ IP-пакетов. В традиционном MPLS TE LSP, который транспортирует IP, должен начинаться и завершаться в маршрутизаторе. Обобщенный MPLS требует, чтобы LSP начинался и завершался в LSR того же типа. Кроме того, в обобщенном MPLS тип данных, который транспортируется через LSP, может включать в себя SONET/SDH, GE или 10Гбитный Ethernet. Эти изменения традиционного MPLS отражаются в механизме запроса и переноса меток, смотри разделы 3.1 и 3.2. Специальный случай l -переключения, называемого волновой коммутацией, описан в разделе 3.3.

    Другим базовым отличием традиционного и не-PSC типа обобщенного LSP MPLS, является то, что полоса пропускания, выделяется для LSP дискретными порциями, смотри раздел 3.1.3. Заметим, что использование FA (Forwarding Adjacencies), смотри [MPLS-HIERARCHY], предоставляет механизм, который может улучшить использование полосы пропускания, когда выделение полосы осуществляется дискретным образом, а также механизм агрегатирования состояния переадресации, что может сократить требуемое число меток.

    Обобщенный MPLS допускает возможность предложения метки вышестоящим узлом, смотри раздел 3.4. Это предложение может быть отвергнуто нижестоящим узлом, за счет увеличения времени установления LSP. Предлагаемая метка представляет ценность, когда LSP устанавливается через определенное оптическое оборудование, где конфигурирование системы коммутации может быть долгим. Например, микрозеркала могут быть подняты или удалены, и это физическое перемещение и последующее установление потребует времени. Если метки и, следовательно, оптическая система коммутации сконфигурированы в обратном порядке (норма), может потребоваться задержать сообщение MAPPING/Resv на десятки миллисекунд на один шаг, для того чтобы установить маршрут переадресации. Предлагаемая метка может быть полезной также при восстановлении в случае отказа узла.

    Обобщенный MPLS расширяет понятие ограничения диапазона меток, которые могут быть выбраны нижестоящим узлом, смотри раздел 3.5. В обобщенном MPLS, входной или другой вышестоящий узел может ввести ограничения на метки, которые могут быть использованы в LSP. Эта особенность пришла из оптической области, где бывают случаи, когда длины волн, используемые в пределах маршрута, должны быть ограничены узким диапазоном или даже одной длиной волны. Это требование возникает, из-за того, что некоторое оборудование может работать с ограниченным набором длин волн или некоторые промежуточные устройства не могут вообще выполнять коммутацию по длинам волн.

    В то время как традиционный трафик, формируемый MPLS является однонаправленным, обобщенный MPLS поддерживает установление двунаправленных LSP, смотри раздел 4. Необходимость двунаправленных LSP вызвана не-PSC приложениями. Существует много причин, зачем нужны такие LSP, в частности конкуренция за ресурсы при формировании LSP с привлечением разных сигнальных сессий, и упрощение процедур восстановления при ошибках в случае не-PSC. Двунаправленные LSP имеют также преимущества малой задержки установления канала и малого числа сообщений при реализации этого процесса.

    Обобщенный MPLS поддерживает специфические метки для специальных интерфейсов, смотри раздел 6. [RFC-3473] поддерживает также специальные механизмы RSVP для быстрого уведомления об ошибках.

    Обобщенный MPLS формализует возможное разделение каналов управления и данных, смотри раздел 9. Такая поддержка особенно важна для поддержки технологий, где управление трафиком не может осуществляться в рамках информационного потока.

    Обобщенный MPLS также позволяет использование параметров, специфических для сигнальной технологии. Предполагается, что для всех технологических параметров, при работе с RSVP, в SENDER_TSPEC и других сопряженных объектах, при использовании CR-LDP, применяется формат TLV.


    3. Форматы, относящиеся к меткам

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

    Заметим, что, так как узлы, посылающие и принимающие новые формы меток, знают, какой тип канала они используют, обобщенная метка не содержит поля тип, вместо этого предполагается, что узлы знают из контекста, какие метки следует ожидать.


    3.1. Обобщенные запросы меток

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

    Запрос обобщенной метки содержит параметр кодирования LSP, называемый тип кодирования LSP. Этот параметр указывает тип кодирования, например, SONET/SDH/GigE и т.д., который будет использоваться для данных, ассоциированных с LSP. Тип кодирования LSP характеризует природу LSP, а не природу каналов, через которые он проходит. Канал может поддерживать несколько форматов кодирования, где под поддержкой подразумевается то, что канал может транспортировать и коммутировать сигналы одного или более форматов кодирования в зависимости от доступных ресурсов и емкости канала. Например, рассмотрим LSP с управлением с помощью l -кодирования. Ожидается, что такой LSP не поддерживает электронных преобразований и ничего не известно о модуляции и быстродействии промежуточных узлов. Другие форматы обычно требуют знания структуры кадров и параметров полей.

    Запрос обобщенной метки указывает также на тип коммутации, который запрашивается для канала. Это поле в норме согласуется со всеми сегментами LSP.


    3.1.1. Необходимая информация

    Информация, транспортируемая в обобщенном запросе метки, имеет формат:

    1

    Тип кодирования LSP :8 бит

    Указывает на запрашиваемый тип кодирования LSP. Ниже представлена таблица возможных значений этого поля:

    Значение

    Тип

    1

    Пакет

    2

    Ethernet

    3

    ANSI/ETSI PDH

    4

    Зарезервировано

    5

    SDH ITU-T G.707 / SONET ANSI T1.105

    6

    Зарезервировано

    7

    Цифровой конверт

    8

    Lambda (оптическое)

    9

    Волокно

    10

    Зарезервировано

    11

    FiberChannel

    ANSI PDH и ETSI PDH типы обозначают соответствующие сетевые технологии. DS1 и DS3 являются примерами ANSI PDH LSP. E1 LSP будет ETSI PDH. Тип кодирования Lambda относится к LSP, которые охватывают все длины волн. Тип кодирования волокно (Fiber) относится к LSP, работающим с оптоволоконным портом.

    Тип коммутации : 8 бит

    Указывает на тип коммутации, которая должна осуществляться в заданном канале. Это поле необходимо для каналов, которые анонсируют более одного типа коммутации. Это поле следует связать с одним из значений, анонсированных для соответствующих каналов в описателе возможностей маршрутной коммутации (Switching Capability Descriptor), смотри [GMPLS-RTG]. В настоящее время определены следующие значения:

    Значение

    Тип

    1

    Packet-Switch Capable-1 (PSC-1)

    2

    Packet-Switch Capable-2 (PSC-2)

    3

    Packet-Switch Capable-3 (PSC-3)

    4

    Packet-Switch Capable-4 (PSC-4)

    51

    Layer-2 Switch Capable (L2SC)

    100

    Time-Division-Multiplex Capable (TDM)

    150

    Lambda-Switch Capable (LSC)

    200

    Fiber-Switch Capable (FSC)

    Обобщенный PID (G-PID): 16 бит

    Идентификатор поля данных, транспортируемых через a LSP, т.е., идентификатор уровня клиента данного LSP. Он используется узлами в конечных точках LSP, и иногда предпоследним узлом. Стандартные значения Ethertype используются для пакета и Ethernet LSP; прочие значения перечислены в таблице:

    Значение

    Тип

    Технология

    0

    Не определено

    Все

    1

    Зарезервировано

    2

    Зарезервировано

    3

    Зарезервировано

    4

    Зарезервировано

    5

    Asynchronous mapping of E4

    SDH

    6

    Asynchronous mapping of DS3/T3

    SDH

    7

    Asynchronous mapping of E3

    SDH

    8

    Bit synchronous mapping of E3

    SDH

    9

    Byte synchronous mapping of E3

    SDH

    10

    Asynchronous mapping of DS2/T2

    SDH

    11

    Bit synchronous mapping of DS2/T2

    SDH

    12

    Зарезервировано

    13

    Asynchronous mapping of E1

    SDH

    14

    Byte synchronous mapping of E1

    SDH

    15

    Byte synchronous mapping of 31 * DS0

    SDH

    16

    Asynchronous mapping of DS1/T1

    SDH

    17

    Bit synchronous mapping of DS1/T1

    SDH

    18

    Byte synchronous mapping of DS1/T1

    SDH

    19

    VC-11 в VC-12

    SDH

    20

    Зарезервировано

    21

    Зарезервировано

    22

    DS1 SF Asynchronous

    SONET

    23

    DS1 ESF Asynchronous

    SONET

    24

    DS3 M23 Asynchronous

    SONET

    25

    DS3 C-Bit Parity Asynchronous

    SONET

    26

    VT/LOVC

    SDH

    27

    STS SPE/HOVC

    SDH

    28

    POS - No Scrambling, 16 bit CRC

    SDH

    29

    POS - No Scrambling, 32 bit CRC

    SDH

    30

    POS - Scrambling, 16 bit CRC

    SDH

    31

    POS - Scrambling, 32 bit CRC

    SDH

    32

    ATM mapping

    SDH

    33

    Ethernet

    SDH, l , волокно

    34

    SONET/SDH

    l , волокно

    35

    Зарезервировано (SONET против)

    l , волокно

    36

    Цифровой конверт

    l , волокно

    37

    Lambda

    Fiber

    38

    ANSI/ETSI PDH

    SDH

    39

    Зарезервировано

    SDH

    40

    Протокол доступа к каналу SDH LAPS - X.85 и X.86)

    SDH

    41

    FDDI

    SDH, l , волокно

    42

    DQDB (ETSI ETS 300 216)

    FiberChannel

    43

    FiberChannel-3 (услуги)

    FiberChannel+

    44

    HDLC

    SDH

    45

    Ethernet V2/DIX (only)

    SDH, l , волокно

    46

    Ethernet 802.3 (only)

    SDH, l , волокно


    3.1.2. Кодирование полосы пропускания

    Кодирование полосы пропускания осуществляется 32 битовым числом в формате IEEE для чисел с плавающей запятой (измеряется в байтах в сек). Для беспакетных LSP, полезно определить дискретные величины, чтобы идентифицировать полосу LSP. Некоторые типичные значения для запрошенной полосы перечислены ниже. Дополнительные значения будут определяться по мере необходимости. Значения кодов полосы ассоциируются с протоколами, смотри [RFC3473] и [RFC3472].

    Тип сигнала

    Скорость обмена

    Значение (байт/сек)
    (IEEE плавающий формат)

    DS0

    0.064 Mbps (Мбит/с)

    0x45FA0000

    DS1

    1.544 Mbps

    0x483C7A00

    E1

    2.048 Mbps

    0x487A0000

    DS2

    6.312 Mbps

    0x4940A080

    E2

    8.448 Mbps

    0x4980E800

    Ethernet

    10.00 Mbps

    0x49989680

    E3

    34.368 Mbps

    0x4A831A80

    DS3

    44.736 Mbps

    0x4AAAA780

    STS-1

    51.84 Mbps

    0x4AC5C100

    Fast Ethernet

    100.00 Mbps

    0x4B3EBC20

    E4

    139.264 Mbps

    0x4B84D000

    FC-0 133M

    0x4B7DAD68

    OC-3 FC-0/STM-1

    155.52 Mbps

    0x4B9450C0

    FC-0 266M

    0x4BFDAD68

    FC-0 531M

    0x4C7D3356

    OC-12/STM-4

    622.08 Mbps

    0x4C9450C0

    GigE

    1000.00 Mbps

    0x4CEE6B28

    FC-0 1062M

    0x4CFD3356

    OC-48/STM-16

    2488.32 Mbps

    0x4D9450C0

    OC-192/STM-64

    9953.28 Mbps

    0x4E9450C0

    10GigE-LAN

    10000.00 Mbps

    0x4E9502F9

    OC-768/STM-256

    39813.12 Mbps

    0x4F9450C0


    3.2. Обобщенная метка

    Обобщенная метка расширяет функциональность традиционной метки, допуская представление не только меток, которые транспортируются соответствующими информационными пакетами, но также меток, которые идентифицируют временные домены, длины волн, или пространственное мультиплексирование по положению. Например, обобщенная метка может содержать данные, которые представляют (a) одно волокно из пучка, (b) один волновой диапазон в волокне, (c) одну длину волны из диапазона (или волокна), или (d) набор временных доменов для заданной длины волны (или волокна). Метка может также нести данные о базовой метке MPLS, метке Frame Relay, или метке ATM (VCI/VPI).

    Обобщенная метка не идентифицирует класс, к которому принадлежит метка. Это определяется возможностями мультиплексирования канала, где используется метка.

    Обобщенная метка несет в себе лишь метку одного уровня, т.е., она не является неиерархическим объектом. Когда требуется несколько уровней меток (LSP внутри LSP), каждый LSP должен быть сформирован отдельно, смотри [MPLS-HIERARCHY]. Каждый TLV-объект обобщенной метки несет в себе параметр метки переменной длины.

    3.2.1. Необходимая информация

    Метка : переменная длина

    Несет в себе данные метки. Интерпретация этого поля зависит от типа канала, где используется метка.

    3.2.1.1. Метки длины волны и порта

    Некоторые конфигурации переключения волокон FSC и l -переключение LSC используют несколько каналов/соединений, контролируемых одним управляющим каналом. В таких случаях метка ассоциируется с информационным каналом, используемым в LSP. Заметим, что этот случай не тождественен варианту применения [MPLS-BUNDLE]. Метка в случае работы с коммутацией портов и длин волн имеет длину 32 бита.

    Метка :32 бит

    Указывает на порт/волокно или длину волны, которая должна использоваться, с позиции отправителя объекта TLV. Значения, используемые в этом поле, имеют значение только для соседей, и получатель может оказаться вынужден преобразовать полученное значение. Значения могут конфигурироваться или динамически определяться с помощью протокола [LMP].

    3.2.1.2. Прочие метки

    Базовые метки MPLS и Frame Relay кодируются с выравниванием по правому полю в 32 бита (4 октета). Метки ATM кодируются посредством VPI, выровненными по правому полю в битах 0-15, а VCI выравниваются по правому полю в битах 16-31.

    3.3. Коммутация по длине волны

    Специальным случаем l -коммутации является переключение по диапазонам длин волн. Волновой диапазон представляет собой набор смежных длин волн, которые могут быть все вместе переключены на новый волновой диапазон. По причине оптимизации для оптического коммутатора может быть желательно переключать несколько длин волн одним блоком. Это может уменьшить искажение для индивидуальных длин волн и позволить более плотное их размещение индивидуальных. Метка волнового диапазона определена для поддержки этого специального случая.

    Переключение волновых диапазонов вводит естественно другой уровень иерархии меток и волновой диапазон, как таковой рассматривается также как и все другие метки высокого уровня.

    Поскольку это касается протоколов MPLS, нет большой разницы между меткой диапазона длин волн и меткой длины волны за исключением того, что семантически диапазон длин волн может быть поделен между несколькими метками, ответственными за мультиплексирование, например, по времени.

    3.3.1. Необходимая информация

    Коммутация по диапазонам длин волн использует тот же формат, что и обобщенная метка, смотри раздел 3.2.1. В контексте коммутации по диапазонам длин волн обобщенная метка имеет следующий формат:

    2

    Id диапазона длин волн : 32 бит.

    Идентификатор диапазона длин волн. Значение выбирается отправителем и повторно используется во всех последующих сопряженных сообщениях.

    Начальная метка : 32 бит

    Указывает на идентификатор канала наинизшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

    Конечная метка : 32 бит

    Указывает на идентификатор канала наибольшей длины волны, образующей диапазон, берется из TLV-объекта отправителя.

    Идентификаторы канала устанавливаются либо при конфигурации, либо протокольными средствами, такими как LMP [LMP]. Они обычно используются как параметр обобщенной метки PSC и LSC.

    3.4. Предложенная метка

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

    Использование предложенной метки служит целям оптимизации. Если нижележащий узел передает различные метки вверх по течению, вышестоящий LSR реконфигурируется так, чтобы его использование метки определялось нижестоящим узлом. Заметим что, передача метки не подразумевает, что предлагаемая метка доступна для использования. В частности, принимающий узел не должен передавать данные с привлечением предлагаемой метки до тех пор, пока нижерасположенный узел не передаст метку вверх по течению.

    Информация, содержащаяся в предлагаемой метке, идентична содержащейся в обобщенной метке.

    3.5. Набор меток

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

    Мы описываем четыре варианта, когда набор меток полезен для оптической области применений. Первый вариант реализуется, когда оконечное оборудование способно передавать ограниченный набор длин волн/диапазонов. Второй вариант имеет место, когда последовательность интерфейсов не поддерживает преобразование длин волн и требует использования одной длины волны на всем пути. Третий вариант возникает, когда желательно ограничить число преобразований длин волн, чтобы уменьшить искажения оптических сигналов. Последний случай представляет собой вариант, когда разные концы канала поддерживают различные наборы длин волн.

    Набор меток используется, чтобы ограничить диапазон меток, который может быть использован для конкретного LSP между двумя партнерами. Получатель набора меток должен ограничить свой выбор одной меткой из оговоренного набора. Аналогично метке, набор меток может относиться к нескольким шагам маршрута. В этом случае каждый узел генерирует свой собственный исходящий набор меток, возможно, базирующийся на входном наборе меток и возможностях узлового оборудования. Этот вариант является обычным для узлов с интерфейсами, неспособными преобразовывать длины волн.

    Использование набора меток является опционным, если его нет, можно использовать все метки из допустимого диапазона. Концептуально отсутствие набора меток предполагает применение набора меток {U}, к которому относятся все допустимые метки.

    3.5.1. Необходимая информация

    Набор меток состоит из одной или более объектов Label_Set/TLV. Каждый объект/TLV содержит один или более элементов набора меток. Каждый элемент воспринимается как идентификатор субканала и имеет тот же формат, что и обобщенная метка. Информация в наборе меток имеет формат:

    3

    Действие :8 бит

    0 - включающий список

    Указывает, что объект/TLV содержит один или более субканальных элементов, которые включены в набор меток.


    1 - исключающий список

    Указывает, что объект/TLV содержит один или более субканальных элементов, которые исключены из набора меток.

    2 - включающий диапазон

    Указывает, что объект/TLV содержит диапазон меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона. Второй элемент указывает на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

    3 - исключающий диапазон

    Указывает, что объект/TLV содержит диапазон меток, которые исключены из набора меток. Объект/TLV содержит два субканальных элемента. Первый элемент указывает на начало диапазона. Второй - на конец диапазона. Значение нуль говорит о том, что соответствующая часть диапазона не имеет ограничения.

    Зарезервировано :10 бит

    Это поле зарезервировано. Оно должно быть установлено равным нулю при передаче и игнорироваться при приеме.

    Тип метки : 14 бит

    Указывает тип и формат меток, содержащийся в объекте/TLV. Значения зависят от сигнального протокола.

    Субканал:

    Субканал представляет метку (длина волны, волокно...), которая может быть присвоена. Это поле имеет тот же формат, что описан для меток в разделе 3.2.

    4. Двунаправленные LSP

    В этом разделе определены двунаправленные LSP. Поддержка определена для LSP, которые имеют те же требования управления трафиком, включая долю совмещения, защиту и восстановление, LSR, и ресурсные требования (напр., задержка и разброс) для каждого из направлений. В дальнейшем под "инициатором" подразумевается узел, который начинает формирование LSP, а под "терминатором" подразумевается узел, который является конечным пунктом LSP. Заметим, что для полнодуплексных LSP, имеется только один инициатор и один терминатор.

    В норме для установления двунаправленного LSP при использовании [RFC3209] или [RFC3212] должны быть независимо сформированы два однонаправленных маршрута. Этот подход имеет следующие недостатки:

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

    • Избыточность управления в два раза больше чем в случае однонаправленных LSP. Это связано с тем, что нужно генерировать отдельные управляющие сообщения (напр., Path и Resv) для обоих сегментов двунаправленного LSP.

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

    • Труднее предоставить хороший интерфейс для оборудования SONET/SDH, которое может базироваться на двунаправленных пошаговых маршрутах.

    • Двунаправленные оптические LSP (или световоды) рассматриваются в качестве требования большинством сетевых сервис-провайдеров.

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

    4.1. Необходимая информация

    Для двунаправленных LSP, надо выделить две метки. Установление двунаправленного LSP отмечается наличием объекта/TLV метки для маршрута вверх по течению в соответствующем сигнальном сообщении. Вышестоящая метка имеет тот же формат, что и обобщенная метка, смотри раздел 3.2.

    4.2. Разрешение конфликтов

    Конфликты для меток могут происходить между двумя запросами установления двунаправленных LSP, которые направлены в противоположных направлениях. Этот конфликт происходит, когда обе стороны выделяют одни и те же ресурсы (метки) в одно и то же время. Если нет ограничений на использование меток в двунаправленных LSP и если ресурсы являются альтернативными, тогда оба узла передадут разные метки вверх по течению и конфликта не будет. Однако если имеется ограничение на метки, которые могут быть использованы для двунаправленных LSP (например, если они должны быть физически связаны с одной и той же интерфейсной I/O картой), или если нет более доступных ресурсов, тогда конфликт должен разрешаться другими средствами. Чтобы разрешить конфликт, узел с более высоким значением ID выиграет соревнование и он должен послать сообщение PathErr/NOTIFICATION с указанием "Routing problem/Label allocation failure" (проблема с маршрутизацией/отказ присвоения метки). После получения такого сигнала ошибки, узел должен попытаться выделить другую метку для сегмента выше по течению (и другую предлагаемую метку, если таковая используется) в двунаправленном маршруте. Однако если других ресурсов нет, узел должен начать стандартную процедуру обработки ошибки.

    Чтобы уменьшить вероятность конфликта, можно ввести правило, когда узел с более низким ID никогда не предлагает меток для сегмента ниже по течению и всегда воспринимает предлагаемую метку от вышестоящего узла с более высоким значением ID. Кроме того, так как метки пересылаться посредством LMP, может использоваться альтернативное правило, узел с более высоким номером может присваивать метки, начиная с верхнего края диапазона меток, в то время как узел с меньшим номером использует метки нижнего конца диапазона меток. Этот механизм усилит любой алгоритм кластеризации, который может быть использован для оптимизации полосы частот (или длин волн). Особым случаем, на который следует обратить внимание при использовании RSVP и поддержке этого подхода, является то, что ID соседнего узла может быть неизвестно при посылке исходного сообщения Path. Когда такое происходит, узлу следует предложить метку, выбранную из доступного пространства меток случайным образом.

    Пример конфликта между двумя узлами (PXC 1 и PXC 2) показан на рис. 1. В этом примере PXC 1 присваивает метку для сегмента выше по течению для канала, соответствующего локальному BCId=2 (локальный BCId=7 для PXC 2), и посылает предлагаемую метку для канала, соответствующего локальному BCId=1 (локальный BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению для канала, соответствующего его локальному BCId=6 (локальный BCId=1 для PXC 1) и посылает предлагаемую метку для канала, соответствующего его локальному BCId=7 (локальный BCId=2 для PXC 1). Если нет ограничения на метки, которые можно использовать для двунаправленных LSP и если имеются альтернативные ресурсы, тогда PXC 1 и PXC 2 передадут разные метки вверх по течению и конфликт разрешится естественным образом (смотри рис. 2). Однако, если имеются ограничения для меток, используемых в двунаправленных LSP (например, если они должны быть физически подключены к одной I/O карте), тогда конфликт должен быть разрешен с привлечением ID узла (смотри рис. 3).

    4

    Рис. 1 . Конфликт меток

    В этом примере PXC 1 присваивает метку для сегмента выше по течению, используя BCId=2 (BCId=7 для PXC 2) и рекомендуемую метку, используя BCId=1 (BCId=6 для PXC 2). Одновременно PXC 2 присваивает метку для сегмента выше по течению, используя BCId=6 (BCId=1 для PXC 1) и рекомендуемую метку, используя BCId=7 (BCId=2 для PXC 1).

    5

    Рис. 2 . Разрешение конфликта меток без ограничений ресурсов

    В этом примере, нет ограничения на метки, которые можно использовать двусторонним соединением и здесь нет конфликта.

    6

    Рис. 3 . Разрешение конфликта меток посредством ограничений ресурсов

    В этом примере, метки 1,2 и 3,4 для PXC 1 (метки 6,7 и 8,9 для PXC 2, соответственно) должны использоваться одним и тем же двусторонним соединением. Так как PXC 2 имеет больший ID узла, он выигрывает соревнование и PXC 1 должен использовать другой набор меток.

    5. Уведомление об ошибках в метках

    Существуют случаи в традиционном MPLS и в GMPLS, которые вызывают сообщения об ошибке, содержащие уведомление "Unacceptable label value" (неприемлемое значение метки), смотри [RFC3209], [RFC3472] и [< раздел смотри меток, набору обычному идентичен меток приемлемых набора Формат [RFC3473]. и [RFC3472] ошибке, об сообщении протокольном специальном соответствующем в транспортируется набор Приемлемый меток). (приемлемый Set" Label "Acceptable помощью с информации такой передачи возможность вводит GMPLS случая, этого покрытия Для приемлемы. быть могут метки какие указать, полезно быть, может ошибки, сообщение генерирующего узла, для происходит, такое Когда>

    6. Прямое управление по меткам

    В традиционном MPLS, интерфейсы, используемые LSP могут управляться через определенный маршрут, т.е., ERO или ER-Hop. Это допускает включение определенных узлов/интерфейсов, и завершение LSP в конкретном выходном интерфейсе выходного LSR. Где могут нумероваться интерфейсы, смотри в [MPLS-UNNUM].

    Существуют случаи, когда существующая явная семантика маршрута не предоставляет достаточно информации для управления LSP на желательном уровне. Это происходит в случае, когда LSP-инициатор хочет выбрать метку, используемую каналом. Точнее проблема заключается в том, что ERO и ER-Hop не поддерживают явных субобъектов меток. Примером, где желателен такой механизм, является случай, где имеется два LSP, которые должны быть связаны друг с другом, т.е., где конец первого LSP нужно связать с началом второго LSP. Этот последний случай, вероятно, следует использовать в не-PSC классах каналов. Чтобы покрыть этот случай, введен Label ERO subobject/ER Hop.

    6.1. Необходимая информация

    Явная метка (Label Explicit) и запись маршрутов содержит:

    L:1 бит Этот бит должен быть равен 0.

    U:1 бит Этот бит указывает направление метки. Оно равно 0 для метки сегмента вниз по течению. Оно равно 1 для метки противоположного направления и используется только для двунаправленных LSP.


    Метка : переменная

    Это поле идентифицирует используемую метку. Формат этого поля идентичен тому, который используется полем метка в обобщенной метке, смотри раздел 3.2.1. Размещение и порядок этих параметров зависит от сигнального протокола.

    7. Защитная информация

    Защитная информация транспортируется в новом объекте/TLV. Она используется для описания атрибутов защиты канала запрошенного LSP. Использование информации защиты для конкретного LSP является опционным. Защитная информация указывает на желательный тип защиты канала LSP. Если запрошен конкретный тип защиты, т.е., 1+1, или 1:N, тогда запрос соединения обрабатывается, только если запрашиваемый тип защиты может быть реализованa. Заметим, что возможности защиты канала могут анонсироваться в ходе маршрутизации, смотри [GMPLS-RTG]. Алгоритмы расчета маршрута могут учитывать эту информацию при формировании LSP.

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

    7.1. Необходимая информация

    Следующие данные содержатся в полях защитной информации:

    7

    Вторичный (S):1 бит

    Когда равен 1, указывает, что запрошенный LSP является вторичным.

    Зарезервировано :25 бит

    Это поле зарезервировано. Оно должно быть равно нулю при передаче и игнорироваться при приеме. Эти биты должны передаваться транзитными узлами без модификации.

    Флаги канала :6 бит

    Отмечает желательный тип защиты канала. Как ранее упоминалось, возможности защиты канала могут анонсироваться при маршрутизации. Значение 0 подразумевает, что может использоваться любая защита канала, включая ее отсутствие. Можно использовать более одного бита для указания нескольких приемлемых типов защиты. Когда установлено несколько бит и доступны несколько типов защиты, выбор типа защиты определяется локально.

    Определены следующие флаги:

    0x20 Улучшенная

    Указывает на то, что следует использовать, ту схему защиты, которая более надежна, чем 1+1, напр., 4 волокна BLSR/MS-SPRING.

    0x10 Выделенная 1+1

    Указывает, что для LSP следует использовать выделенную схему защиты канального уровня, т.е., защиту 1+1.


    0x08 Выделенная 1:1

    Указывает, что для LSP следует использовать выделенную схему защиты канального уровня, т.е., 1:1.


    0x04 Совместная

    Указывает, что для LSP следует использовать совместную схему защиты канального уровня, такую как 1:N.


    0x02 Незащищено

    Указывает, что LSP не должен использовать средства защиты.


    0x01 Дополнительный трафик

    Указывает, что LSP должен использовать каналы, которые защищают другой первичный трафик. Такие LSP могут быть разорваны, когда отказывают каналы с защищенным трафиком.

    8. Информация административного состояния

    Административная статусная информация транспортируется в новом объекте/TLV. Эта информация используется в настоящее время двумя способами. В первом информация характеризует административное состояние, сопряженное с определенным LSP. В таком применении, административная статусная информация отображает состояние LSP. Индикация состояния включает в себя "up" или "down", если система находится в режиме тестирования, и если маршрут ликвидируется. Действия, предпринимаемые узлом, базируются на локальных статусных характеристиках. Примером действия, которое может быть предпринято, является запрет уведомления о сигнале тревоги, когда LSP находится в состоянии "down" или в тестовом режиме, или сообщение уведомления о тревоге, связанное с соединением, имеющем приоритет равный или меньше чем "Non service affecting" (не влияет на обслуживание).

    Во втором способе использование административной статусной информации, может означать запрос установления состояния LSP. Эта информация всегда относится к входному узлу, который обрабатывает запрос. Подробности смотри в [RFC3473] и [RFC3472]. Использование административной статусной информации для конкретного LSP является опционным.

    8.1. Необходимая информация

    Следующие данные содержатся в полях административной информации статуса:


    8

    Отражение (R):1 бит

    Когда бит равен 1, это указывает, что крайний узел должен вернуть объект/TLV назад в соответствующем сообщении. Этот бит не должен устанавливаться в случае запроса изменения состояния, т.е., в сообщениях уведомления.

    Зарезервировано :28 бит

    Это поле зарезервировано. Оно должно быть равно нулю при передаче и игнорироваться при приеме. Эти биты должны передаваться транзитными узлами без модификации.


    Тестирование (T):1 бит

    Когда бит равен 1, это указывает, что локальные действия относятся к режиму тестирования.


    Административно выключено (A): 1 бит

    Когда бит равен 1, это указывает, что локальные действия относятся к состоянию "выключено административно".


    Аннулирование в процессе (D): 1 бит

    Когда бит равен 1, это указывает, что локальные действия относящиеся к LSP следует аннулировать. Крайние узлы могут использовать этот флаг для управления аннулированием соединения.

    9. Разделение каналов управления

    Концепция канала управления отличается от концепции канала данных, введенной MPLS в связи с объединением каналов, смотри [MPLS-BUNDLE]. В GMPLS разделение каналов данных и управления может быть связано с несколькими факторами. Сюда относится объединение каналов и другие случаи, такие как информационные каналы, которые не могут транспортировать управляющие данные.

    9.1. Идентификация интерфейса

    В традиционном MPLS имеется неявная ассоциация каналов управления и данных. Когда имеет место такая ассоциация, не требуется никакой дополнительной или специальной информации, чтобы связать формирование определенного LSP с заданным каналом данных.

    В случаях, где нет явной ассоциации каналов данных и управления, необходимо передавать дополнительную информацию, чтобы идентифицировать определенный канал данных, который требует управления. GMPLS поддерживает явную идентификацию канала данных, предоставляя ID интерфейса. GMPLS допускает использование нескольких схем идентификации интерфейсов, включая адреса IPv4 или IPv6, индексы интерфейсов (смотри [MPLS-UNNUM]) и составные интерфейсы (установленные посредством конфигурирования или протокола, такого как [LMP]). Во всех случаях выбор информационного интерфейса индицируется вышестоящим узлом с помощью адресов и идентификаторов.

    9.1.1. Необходимая информация

    В Interface_ID содержится TLV, которые имеют следующий формат:

    9

    Длина : 16 бит

    Указывает полную длину TLV, т.е., 4 + длина поля значения в октетах. Поле значение , чья длина не кратна четырем, должно дополняться нулями так, чтобы длина TLV стало кратным четырем октетам.

    Тип :16 бит

    Указывает тип идентифицируемого интерфейса. Определены следующие значения:

    Тип

    Длина

    Формат

    Описание

    1

    8

    IPv4 Addr.

    IPv4

    2

    20

    IPv6 Addr.

    IPv6

    3

    12

    см. ниже

    IF_INDEX (индекс интерфейса)

    4

    12

    см. ниже

    COMPONENT_IF_DOWNSTREAM (Составной интерфейс)

    5

    12

    см. ниже

    COMPONENT_IF_UPSTREAM (Составной интерфейс)

    Для типов 3, 4 и 5 поле значение имеет формат:

    0

    IP-адрес : 32 бита

    Поле IP-адрес может включать IP-адрес канала или IP-адрес соответствующего маршрутизатора, содержащийся в TLV адреса маршрутизатора.

    ID интерфейса :32 бита. Для 3-го типа применения, ID интерфейса несет в себе идентификатор интерфейса.

    Для типов 4 и 5, ID интерфейса указывает на составной канал. Специальное значение 0xFFFFFFFF может быть использовано для обозначения того, что одна и та же метка служит для всех компонентов канала.

    9.2. Обработка отказов

    Имеется два новых отказа, которые должны обрабатываться, когда канал управления независим от канала данных. В первом, существует канальный или другой тип отказа, который ограничивает возможность соседних узлов передавать сообщения управления. В такой ситуации, соседние узлы в течение некоторого времени не могут обмениваться управляющими сообщениями. Как только связь восстановится, нижележащий управляющий протокол должен сигнализировать, что узлы сохранили свое состояние во время отказа. Управляющий протокол должен также гарантировать, что любое изменение состояния, произошедшее за время отказа, произошло синхронно для всех вовлеченных узлов.

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

    Заметим, что эти случаи применимы, когда имеются механизмы детектирования отказов канала данных независимо от отказов канала управления.

    11. Соображения безопасности

    В данном документе не вводится никаких дополнительных мер безопасности за исключением рассмотренных в [RFC3212] или [RFC3209]. Соображения безопасности, упомянутые в [RFC3212] или [RFC3209], относятся к специфическим протокольным формам GMPLS, смотри [RFC3473] и [RFC3472].

    12. Соображения IANA

    IANA ответственна за присвоения новых значений для пространства имен, определенных в этом документе. В этом разделе используется терминология [BCP26].


    В данном документе определены следующие наборы имен:

    • Тип кодирования LSP: 8 бит

    • Тип коммутации:8 бит

    • Обобщенный PID (G-PID): 16 бит

    • Действие: 8 бит

    • Тип Interface_ID :16 бит

    Тип кодирования LSP - допустимый диапазон 1-255. В данном документе определены значения 1-11.

    Тип коммутации - допустимый диапазон 1-255. В данном документе определены значения 1-4, 100, 150 и 200.

    Обобщенный PID (G-PID) - допустимый диапазон 0-1500. В данном документе определены значения 0-46.

    Действие - допустимый диапазон 0-255. В данном документе определены значения 0-3.

    Тип Interface_ID - допустимый диапазон 1-65535. В данном документе определены значения 1-5.

    14. Ссылки

    14.1. Нормативные ссылки

    [RFC2119]

    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.

    [RFC3036]

    Andersson, L., Doolan, P., Feldman, N., Fredette, A. и B. Thomas, "LDP Specification", RFC 3036, January 2001.

    [RFC3209]

    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. и G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

    [RFC3212]

    Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. и A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.

    [RFC3472]

    Ashwood-Smith, P. и L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.

    [RFC3473]

    Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

    14.2. Информационные ссылки

    [GMPLS-RTG]

    Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.

    [GMPLS-SONET]

    Ashwood-Smith, P., et al., "GMPLS - SONET/SDH Specifics", Work in Progress.

    [LMP]

    Lang, et al., "Link Management Protocol", Work in Progress.

    [MPLS-BUNDLE]

    Kompella, K., Rekhter, Y. и L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.

    [MPLS-HIERARCHY]

    Kompella, K. и Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.

    [RFC2026]

    Bradner, S., "The Internet Standards Process --Revision 3," BCP 9, RFC 2026, October 1996.

    [RFC2434]

    Narten, T. и H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998./td>

    [RFC3031]

    Rosen, E., Viswanathan, A. и R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.


     


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


    NetPromoter - единственный российский профессиональный комплекс программ и сервисов для раскрутки сайта и интернет-статистики


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    5-55: the ITIL company. Практический опыт и теоретические знания на лучших семинарах по ITIL и процессам ITSM.


    Подписка на новости IT-портала CITForum.ru
    (библиотека, ftp-архив CITKIT.ru)

    Новые поступления в on-line библиотеку:

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

  • Детальный аудит для практических целей
  • Шифруем свои ресурсы данных

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы - pr@citforum.ru, тел. +7 095 4119920 Пресс-релизы - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...