Утверждена приказом ао «казахтелеком»

Вид материала

Подобный материал:

1 ... 7 8 9 10 11 12 13 14 15

Техническая поддержка
1. Поставщик должен иметь возможность предоставить АО «Казахтелеком» следующие услуги по технической поддержке после завершения гарантийного срока:
  1. Для устранения возникающих в оборудовании проблем поставщик обязан 24 часа в сутки 7 дней в неделю предоставлять соответствующие услуги. Услуги по технической поддержке заключаются в полном устранении неисправности и приведении оборудования в состояние, имевшее место до аварии;
  2. Техническая поддержка должна включать в себя поставку и ремонт оборудования, сопровождение программного обеспечения (устранение ошибок, загрузка новых версий ПО и др.), устранение аварий;
2. Услуги по технической поддержке классифицированы по степеням в зависимости от уровня серьёзности проблемы:
  1. полная или частичная потеря трафика (ПРОБЛЕМА ПЕРВОЙ СТЕПЕНИ);
  2. опасность потери трафика (ПРОБЛЕМА ВТОРОЙ СТЕПЕНИ);
  3. проблемы, не влияющие на трафик (ПРОБЛЕМА ТРЕТЬЕЙ СТЕПЕНИ);
  4. Нормативное время на устранение проблем:
  5. проблема первой степени – 4 часа;
  6. проблема второй степени – 48 часов;
  7. проблема третьей степени – 10 дней.
3. Услуги по технической поддержке должны оказываться на весь период эксплуатации оборудования.
4. Услуги по технической поддержке оказываются на основе отдельно заключаемого договора.

Монтаж, запуск, наладка оборудования и тестирование Сети

Работы по Монтажу, запуску, Наладке и Тестированию Сети выполняются Поставщиком на объектах Покупателя. При этом для выполнения работ по подключению к каналам связи, электропитанию и заземлению привлекаются соответствующие специалисты Покупателя. Процесс выполнения работ на объектах Покупателя включает:
1. распаковка, подготовка и монтаж оборудования;
2. выполнение всех внутришкафных соединений оборудования с подключением его к системам распределения;
3. подключение к каналам связи (с привлечением ответственного персонала Покупателя);
4. необходимое конфигурирование оборудования;
5. тестирование работоспособности оборудования в соответствии с технологическими инструкциями Поставщика.

Требования к документации
1. Общие требования
  1. Вся документация должна быть на русском языке.
  2. Вся документация должна соответствовать принятым стандартам. По возможности должны быть использованы стандартизированные символы и термины, рекомендованные МСЭ и МЭК.
2. Документация должна быть представлена в бумажном и электронном видах.

Приемо-сдаточные испытания
1. После завершения монтажа Оборудования и установки Программного обеспечения на всех Местах установки, проводятся приёмо-сдаточные испытания сети в комплексе, которые должны подтвердить, что сеть работоспособна и функционирует в полном соответствии с Техническими требованиями.
2. В случае если для проведения приёмо-сдаточных испытаний необходимо дополнительное тестовое Оборудование или Программное Обеспечение, оно предоставляется Поставщиком.
3. Приёмо-сдаточные испытания проводятся Поставщиком согласно разработанной Поставщиком Программе и методике тестирования работоспособности и функциональности сети с участием представителей Покупателя.

8. Технические требования

к оборудованию BRAS услугам по монтажу и пусконаладке «под ключ»

для АО «Казахтелеком». Лот 8.

Общие требования к расширению оборудования BRAS
1. Цель расширения

Расширение оборудования BRAS в сети должно осуществляться с целью увеличения максимального количества поддерживаемых абонентов в Системе Предоставления Услуг широкополосного доступа (далее - услуга ШПД).

Перечень городов
1. Расширение BRAS должно производиться в следующих городах (ОДТ):

Алматы (ОПТС4);
Караганда (Карагандинская ОДТ);
Костанай (Костанайская ОДТ);
Актобе (Актюбинская ОДТ);
Шымкент (Шымкентская ОДТ).

Расширение шасси BRAS
1. В городах:

Алматы;
Актобе;
Шымкент.

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

Требования к составу необходимого оборудования и количеству лицензий указаны в Табл. 2.

Табл. 2 Требования к составу новых BRAS

№п.п	Оборудование/Лицензии	Алматы	Актобе	Шымкент
1	Шасси не менее 12 слотов	2	-	-
2	Шасси не менее 6 слотов	-	1	1
3	Интерфейсный адаптер для модуля управления	2	1	1
4	Модуль управления 320GB	4	-	-
5	Модуль фабрики коммутации 320GB	6	-	-
6	Модуль управления 120GB	-	2	2
7	Модуль фабрики коммутации 120GB	-	3	3
8	Линейный модуль 4GB	8	2	2
9	Интерфейсный адаптер 4х1GB	8	2	2
10	Оптический трансивер 1GB	32	8	8
11	Линейный модуль 10GB Uplink	3	1	-
12	Интерфейсный адаптер 2х10GB	3	1	-
13	Оптический трансивер 10GB	4	2	-
14	Лицензия на количество абон. сессий	32000	16000	16000
15	Оптический трансивер DWDM 10GB	7
	ЗИП
16	Оптический трансивер 1GB	4
17	Оптический трансивер 10GB	3
18	Линейный модуль 10GB Uplink	1
19	Интерфейсный адаптер 2х10GB	2
20	Оптический трансивер DWDM 10GB	5

Доукомплектация существующих BRAS
1. В городах:

Актобе;
Караганда;
Костанай.

Модернизация BRAS должна осуществляться путём доукомплектации находящихся в эксплуатации шасси дополнительными линейными модулями и интерфейсными адаптерами. Также в городах Актобе, Караганда и Костанай на существующем BRAS необходимо расширить лицензию на максимальное количество абонентских сессий. Требования к составу необходимого оборудования и количеству лицензий указаны в Табл. 3.

Табл. 3 Требования к комплектации существующих BRAS

№ п.п	Оборудование/Лицензии	Актобе	Караганда	Костанай	Талдыкорган	Атырау	Тараз
1	Линейный модуль 4GB			1
2	Интерфейсный адаптер 4х1GB			1
3	Оптический трансивер 1GB			4
4	Линейный модуль 10GB Uplink	1		2	2	2	2
5	Интерфейсный адаптер 2х10GB	1		2	2	2	2
6	Оптический трансивер 10GB	2		4	4	4	4
7	Апгрейд лицензий на количество абонентских сессий c 16000 до 32000	1	3	2

Технические требования к поставляемому оборудованию BRAS
1. Технические требования к шасси
2. Общие требования к шасси
  1. Поставляемые шасси должны:
    1. Быть модульной конструкции;
    2. Быть полностью пассивными устройствами;
    3. Быть построены на базе общей архитектуры и поддерживать возможность оснащения взаимозаменяемыми управляющими модулями, модулями фабрики коммутации, а также линейными модулями и интерфейсными адаптерами;
    4. Поддерживать установку интерфейсного адаптера для модуля управления;
    5. Обладать слотами на фронтальной стороне для установки управляющих и линейных модулей, а также модулей фабрики коммутации;
    6. Обладать слотами на тыльной стороне для установки интерфейсных адаптеров;
    7. Быть предназначены для установки в 19-ти дюймовую телекоммуникационную стойку;
    8. Быть оснащены двумя независимыми вводами для подачи электропитания постоянного тока;
    9. Поддерживать диапазон входных напряжений от -40 до -72 вольт;
    10. Поддерживать режим «горячей» замены (hot-swap) модулей и прочих элементов системы без отключения подачи электропитания;
    11. Быть работоспособны при колебаниях температуры окружающей среды от 5°C до 40°C.
3. Требования к шасси в г.Алматы
  1. В г.Алматы, поставляемое шасси должно:
    1. Поддерживать установку 2-х резервированных модулей управления с пропускной способностью 320Гбит/с;
    2. Поддерживать установку 3-х модулей фабрики коммутации с пропускной способностью 320Гбит/с;
    3. Иметь не менее 12-и слотов для установки линейных модулей и интерфейсных адаптеров;
    4. Быть снабжено модулями системы охлаждения.
4. Требования к шасси в гг. Актобе и Шымкент
  1. В гг. Актобе и Шымкент поставляемые шасси должны:
    1. Поддерживать установку 2-х резервированных модулей управления с пропускной способностью 120Гбит/с;
    2. Поддерживать установку 3-х модулей фабрики коммутации с пропускной способностью 120Гбит/с;
    3. Иметь не менее 6-и слотов для установки линейных модулей и интерфейсных адаптеров;
    4. Быть снабжены модулями системы охлаждения.
Технические требования к управляющим модулям
1. Общие требования к управляющим модулям
  1. Поставляемые управляющие модули должны:
    1. Осуществлять функции хранения и обработки маршрутной информации, сбора и обработки статистики, вычисления таблиц коммутации, хранения конфигурации, а также прочие функции управления системой;
    2. Иметь минимум 4GB оперативной памяти;
    3. Иметь в комплекте 2 flash-карты для хранения программного обеспечения и конфигурационных файлов;
    4. Поддерживать режим обеспечения отказоустойчивости 1:1;
    5. Совместно с фабрикой коммутации обеспечивать пропускную способность 10Гбит/с для каждого слота линейного модуля;
    6. Иметь максимальное энергопотребление не более 140 Ватт.
2. Требования к управляющим модулям 320GB
  1. Управляющие модули 320GB должны:
    1. Совместно с фабрикой коммутации обеспечивать общую пропускную способность системы 320Гбит/с;
    2. Применяться в одном шасси только с фабрикой коммутации 320GB;
    3. Применяться в одном шасси только с аналогичным модулем управления 320GB;
    4. Быть совместимы с любым из поставляемых шасси (с 12-ю или 6-ю слотами под линейные модули).
3. Требования к управляющим модулям 120GB
  1. Управляющие модули 120GB должны:
    1. Совместно с фабрикой коммутации обеспечивать общую пропускную способность системы 120Гбит/с;
    2. Применяться только с фабрикой коммутации 120GB;
    3. Применяться только с аналогичным модулем управления 120GB в одном шасси;
    4. Быть совместимы с поставляемыми шасси (с 6-ю слотами под линейные модули).
Технические требования к модулям фабрики коммутации
1. Общие требования к модулям фабрики коммутации
  1. Поставляемые модули фабрики коммутации должны:
    1. Совместно с управляющими модулями обеспечивать пропускную способность 10Гбит/с для каждого слота линейного модуля;
    2. Поддерживать режим обеспечения отказоустойчивости N+1;
    3. Иметь максимальное энергопотребление не более 95 Ватт.
2. Требования к модулям фабрики коммутации 320GB
  1. Модули фабрики коммутации 320GB должны:
    1. Совместно с управляющими модулями обеспечивать общую пропускную способность системы 320Гбит/с;
    2. Применяться в одном шасси только с модулями управления 320GB;
    3. Применяться в одном шасси только с аналогичными модулями фабрики коммутации 320GB;
    4. Быть совместимы с любым из поставляемых шасси (с 12-ю или 6-ю слотами под линейные модули).
3. Требования к модулям фабрики коммутации 120GB
  1. Модули фабрики коммутации 120GB должны:
    1. Совместно с управляющими модулями обеспечивать общую пропускную способность системы 120Гбит/с;
    2. Применяться в одном шасси только с модулями управления 120GB;
    3. Применяться в одном шасси только с аналогичными модулями фабрики коммутации 120GB;
    4. Быть совместимы с поставляемыми шасси (с 6-ю слотами под линейные модули).
Технические требования к интерфейсным адаптерам модуля управления
1. Требования к интерфейсным адаптерам модуля управления
  1. Поставляемые интерфейсные адаптеры модуля управления должны:
    1. Быть совместимы с модулями управления 120GB или 320GB;
    2. Быть совместимы с любым из поставляемых шасси (с 12-ю или 6-ю слотами под линейные модули);
    3. Должны быть минимально снабжены следующими типами и количеством интерфейсов управления:

Одним 10/100Base-T Ethernet интерфейсом с разъёмом RJ-45;
Двумя интерфейсами RS-232 с разъёмами DB-9;

Иметь энергопотребление не более 15 Ватт.

Технические требования к линейным модулям
1. Общие требования к линейным модулям
  1. Поставляемые линейные модули 4GB должны:
    1. Выполнять функции обработки трафика;
    2. Взаимодействовать с интерфейсными адаптерами с целью обработки и коммутации трафика от различных сетевых соединений;
    3. Быть совместимы с любым из поставляемых шасси (с 12-ю или 6-ю слотами под линейные модули);
    4. Быть совместимы с модулями управления и фабриками коммутации 320GB и 120GB.
2. Требования к линейным модулям 4GB
  1. Линейные модули 4GB должны:
    1. Обеспечивать пропускную способность до 3,9Гбит/с при подключении к фабрике коммутации 320GB;
  2. Иметь возможность выполнять функции резервирования для аналогичного линейного модуля 4GB;
    1. Иметь энергопотребление не более 176 Ватт.
3. Требования к линейным модулям 10GB Uplink
  1. Линейные модули 10GB Uplink должны:
    1. Обеспечивать пропускную способность до 10Гбит/с при подключении к фабрике коммутации 320GB или 120GB;
    2. Иметь возможность выполнять функции резервирования для аналогичного линейного модуля 10GB Uplink;
    3. Иметь энергопотребление не более 150 Ватт.
Технические требования к интерфейсным адаптерам
1. Общие требования к интерфейсным адаптерам
  1. Поставляемые интерфейсные адаптеры должны:
    1. Быть совместимы с любым из поставляемых шасси (с 12-ю или 6-ю слотами под линейные модули);
    2. Быть совместимы с модулями управления и фабриками коммутации 320GB и 120GB;
2. Требования к интерфейсным адаптерам 4х1GB
  1. Интерфейсные адаптеры 4х1GB должны:
    1. Быть совместимы с линейным модулем 4GB;
    2. Занимать половину высоты линейного модуля;
    3. Иметь 4 порта 1GigabitEthernet;
    4. Поддерживать трансиверы формата SFP;
    5. Поддерживать следующие типы SFP:

1000Base-SX;
1000Base-LX;
1000Base-ZX;
1000Base-T;

Иметь энергопотребление не более 21 Ватт.

Требования к интерфейсным адаптерам 2х10GB
1. Интерфейсные адаптеры 2х10GB должны:
  1. Быть совместимы с линейным модулем 10GB Uplink;
  2. Занимать полную высоту линейного модуля;
  3. Иметь 2 порта 10GigabitEthernet;
  4. Обеспечивать работу портов в режиме 1:1;
  5. Поддерживать оптические трансиверы формата XFP;
  6. Поддерживать следующие типы XFP:

10Gb Base-SR;
10Gb Base-LR;
10Gb Base-ER;
10Gb Base-ZR;

Иметь энергопотребление не более 48 Ватт.

Технические требования к оптическим трансиверам
1. Требования к оптическим трансиверам 1GE
  1. Поставляемые оптические трансиверы 1GigabitEthernet должны:
    1. Быть формата SFP;
    2. Работать по одномодовому волокну (SM) на длине волны 1310нм на расстояние до 10км;
    3. Иметь тип оптического разъема LC;
    4. Излучаемая мощность передатчика трансивера должна находится в пределах от -9.5 до -3 дБм;
    5. Чувствительность приемника трансивера должна находиться в пределах от -20 до -3 дБм.
2. Требования к оптическим трансиверам 10GE
  1. Поставляемые оптические трансиверы 10GigabitEthernet должны:
    1. Быть формата XFP;
    2. Работать по одномодовому волокну (SM) на длине волны 1310нм на расстояние до 10км;
    3. Иметь тип оптического разъема LC;
    4. Излучаемая мощность передатчика трансивера должна находится в пределах от -8.2 до 0.5 дБм;
    5. Чувствительность приемника трансивера должна находиться в пределах от -14.4 до -0.5 дБм.

Требования к функциональности оборудования BRAS

Все поставляемые устройства BRAS должны быть снабжены актуальной версией операционной системы.

Требования к функциональности BRAS
1. Функциональность BRAS
  1. Устройства должны быть способными работать как BRAS в сетях построенных на базе архитектур C-VLAN (VLAN на абонента), и S-VLAN (VLAN на сервис);
  2. Должен поддерживаться стандарт 802.1Q для передачи нескольких VLAN в одном физическом интерфейсе. Должна так же поддерживаться возможность стекирования 802.1Q тэгов;
  3. Должен поддерживаться механизм автоматического конфигурирования VLAN на интерфейсах, предназначенных для подключения пользователей;
  4. Должен поддерживать протокол RADIUS для авторизации абонентов и сбора статистики трафика по пользовательским сессиям;
  5. Терминации на BRAS должна осуществляться на третьем уровне стандартной модели OSI;
  6. Устройства должны поддерживать терминацию подписчиков по протоколам PPPoE, IPoE и L2TP (L2TP LNS);
  7. Устройства должны иметь возможность классифицировать трафик абонентов для функций QoS, фильтрации, переадресации и учета по следующим признакам:

IP адреса отправителя и получателя;
IP DSCP;
IP Precedence;
MPLS Exp;
Номер IP-протокола;
TCP/UDP порты источника и назначения.

Оборудования должно поддерживать списки доступа, позволяющие фильтровать пользовательский трафик;
Устройства должны поддерживать механизмы механизм многоуровневого QoS (Shaping, Queuing) в направлениях к подписчику с количеством уровней не менее 3-х;
Устройства должны иметь возможность переадресовать трафик пользователя так, чтобы он был прозрачно перенаправлен на Web-портал оператора;
Политика доступа пользователя к сети (QoS, фильтрация, сервисы, по которым учитывается трафик, переадресация трафика пользователя на web-портал) должна определяться для каждого подписчика отдельно. При этом должна быть предусмотрена возможность ее централизованного конфигурирования при помощи RADIUS сервера или системы управления;
Оборудование должно поддерживать возможность изменения политики доступа пользователя без разрыва PPPoE соединения. В частности должно обеспечиваться:
Снижение скорости доступа абонента в Интернет по исчерпанию отпущенной квоты без снижения скорости остальных сервисов;
Повышение скорости доступа в Интернет после пополнения квоты.
Оборудование должно поддерживать экспорт статистики потребленного абонентом трафика, как для всей сессии, так и для отдельных классов трафика (сервисов);
Должна быть предусмотрена возможность передачи статистической информации в систему управления во время сессии (interim accounting) и по ее окончанию;
Минимально поддерживаемый интервал для interim accounting должен быть равен 10 минутам;
Для PPPoE абонентов должна поддерживаться возможность совместной работы с DSLAM, передающим идентификатор абонентской линии в соответствии с рекомендацией DSL Forum TR-101. Идентифицирующий тэг должен передаваться в одном из атрибутов сообщения Access-Request протокола RADIUS;
Для PPPoE абонентов должна поддерживаться возможность совместной работы с DSLAM или коммутатором, передающим идентификатор абонентской линии в соответствии в DHCP опции 82. Идентифицирующий тэг должен передаваться в одном из атрибутов сообщения Access-Request протокола RADIUS;
BRAS должен поддерживать функцию DHCP-Relay;

Требования к поддерживаемым протоколам

Протокол IP
1. RFC 768—User Datagram Protocol;
2. RFC 791—Internet Protocol DARPA Internet Program Protocol Specification;
3. RFC 792—Internet Control Message Protocol;
4. RFC 793—Transmission Control Protocol;
5. RFC 854—Telnet Protocol Specification;
6. RFC 919—Broadcasting Internet Datagrams;
7. RFC 922—Broadcasting Internet Datagrams in the Presence of Subnets;
8. RFC 950—Internet Standard Subnetting Procedure;
9. RFC 1112—Host Extensions for IP Multicasting;
10. RFC 1122—Requirements for Internet Hosts—Communication Layers;
11. RFC 1812—Requirements for IP Version 4 Routers;
12. RFC 3419—Textual Conventions for Transport Addresses.
Протокол IPv6
1. RFC 2373—IP Version 6 Addressing Architecture;
2. RFC 2460—Internet Protocol, Version 6 (IPv6);
3. RFC 2461—Neighbor Discovery for IPv6;
4. RFC 2462—IPv6 Stateless Address Autoconfiguration;
5. RFC 2463—Internet Control Message Protocol for IPv6 Specification;
6. RFC 2464—Transmission of IPv6 Packets over Ethernet Networks;
7. RFC 2465—Management Information Base for IPv6: Textual Conventions and General Group;
8. RFC 2466—Management Information Base for IPv6: ICMPv6 Group.
Протокол маршрутизации OSPF
1. RFC 2328 — OSPF Version 2;
2. RFC 2370 — The OSPF Opaque LSA Option;
3. RFC 2740 — OSPF for IPv6;
4. RFC 3623 — Graceful OSPF Restart;
5. RFC 3630 — Traffic Engineering (TE) Extensions to OSPF Version 2.
6. RFC 5187 – OSPFv3 Graceful Restart.
Протокол маршрутизации IS-IS
1. RFC 1195 — Use of OSI IS-IS for Routing in TCP/IP and Dual Environments;
2. RFC 2763 — Dynamic Hostname Exchange Mechanism for IS-IS;
3. RFC 2966 — Domain-wide Prefix Distribution with Two-Level IS-IS;
4. RFC 2973 — IS-IS Mesh Groups;
5. RFC 3277 — IS-IS Transient Blackhole Avoidance;
6. RFC 3373 — Three-Way Handshake for IS-IS Point-to-Point Adjacencies;
7. RFC 3784 — IS-IS Extensions for Traffic Engineering (TE);
8. RFC 3847 — Restart Signaling for IS-IS;
9. RFC 4444 – Management Information Base for IS-IS;
10. RFC 5309 - Point-to-point operation over LAN in link-state routing protocols;
11. Extended Ethernet Frame Size Support — draft-ietf-isis-ext-eth-01.txt.
Протокол маршрутизации BGP
1. RFC 1657 — Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2;
2. RFC 1745 — BGP4/IDRP for IP — OSPF Interaction;
3. RFC 1772 — Application of the Border Gateway Protocol in the Internet;
4. RFC 1773 — Experience with the BGP-4 protocol;
5. RFC 1774 — BGP-4 Protocol Analysis;
6. RFC 1863 — A BGP/IDRP Route Server alternative to a full mesh routing;
7. RFC 1930 — Guidelines for creation, selection, and registration of an Autonomous System;
8. RFC 3065 — Autonomous System Confederations for BGP;
9. RFC 1966 — BGP Route Reflection An alternative to full mesh IBGP;
10. RFC 1997 — BGP Communities Attribute;
11. RFC 1998 — An Application of the BGP Community Attribute in Multi-home Routing;
12. RFC 2270 — Using a Dedicated AS for Sites Homed to a Single Provider;
13. RFC 2385 — Protection of BGP Sessions via the TCP MD5 Signature Option;
14. RFC 2439 — BGP Route Flap Damping;
15. RFC 2519 — A Framework for Inter-Domain Route Aggregation;
16. RFC 2545 – Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing;
17. RFC 2796 – BGP Route Reflection—An Alternative to Full Mesh IBGP;
18. RFC 2858 — Multiprotocol Extensions for BGP-4;
19. RFC 2918 — Route Refresh Capability for BGP-4;
20. RFC 3065 — Autonomous System Confederations for BGP;
21. RFC 3392 — Capabilities Advertisement with BGP-4;
22. RFC 4271 — A Border Gateway Protocol (BGP-4);
23. RFC 4360 – BGP Extended Communities Attribute;
24. RFC 4724 – Graceful Restart Mechanism for BGP;
25. RFC 4893 — BGP Support for Four-octet AS Number Space;
26. RFC 5291 – Outbound Route Filtering Capability for BGP-4;
27. Address Prefix Based Outbound Route Filter for BGP-4 – draft-chen-bgp-prefix-orf-07.txt;
28. Dynamic Capability for BGP-4 – draft-ietf-idr-dynamic-cap-10.txt.
Протокол MPLS и приложения
1. RFC 2104 – HMAC: Keyed-Hashing for Message Authentication;
2. RFC 2205 – RSVP v1, Functional Specification;
3. RFC 2209 – RSVP v1, Message Processing Rules;
4. RFC 2210 – The Use of RSVP with IETF Integrated Services;
5. RFC 2211 – Specification of the Controlled-Load Network Element Service;
6. RFC 2474 – Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers;
7. RFC 2475 – An Architecture for Differentiated Services;
8. RFC 2597 – Assured Forwarding PHB Group;
9. RFC 2685 – Virtual Private Networks Identifier;
10. RFC 2702 – Requirements for Traffic Engineering over MPLS;
11. RFC 2747 – RSVP Cryptographic Authentication;
12. RFC 2836 – Per Hop Behavior Identification Codes;
13. RFC 2961 – RSVP Refresh Overhead Reduction Extensions;
14. RFC 3031 – Multiprotocol Label Switching Architecture;
15. RFC 3032 – MPLS Label Stack Encoding;
16. RFC 3035 – MPLS using LDP and ATM VC Switching;
17. RFC 3036 – LDP Specification;
18. RFC 3037 – LDP Applicability;
19. RFC 3097 – RSVP Cryptographic Authentication Updated Message Type Value;
20. RFC 3107 – Carrying Label Information in BGP-4;
21. RFC 3140 – Per Hop Behavior Identification Codes;
22. RFC 3209 – RSVP-TE: Extensions to RSVP for LSP Tunnels;
23. RFC 3210 – Applicability Statement for Extensions to RSVP for LSP-Tunnels;
24. RFC 3246 – An Expedited Forwarding PHB (Per-Hop Behavior);
25. RFC 3270 – MPLS Support of Differentiated Services;
26. RFC 3443 – Time To Live (TTL) Processing in MPLS Networks;
27. RFC 3471 – GMPLS Signaling Functional Description;
28. RFC 3473 – GMPLS Signaling RSVP-TE Extensions;
29. RFC 3478 – Graceful Restart Mechanism for LDP;
30. RFC 3479 – Fault Tolerance for the LDP;
31. RFC 3564 – Requirements for support of DiffServ-aware MPLS TE;
32. RFC 3916 – Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3);
33. RFC 3985 – Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture;
34. RFC 4023 – Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE);
35. RFC 4090 – Fast Reroute Extensions to RSVP-TE for LSP Tunnels;
36. RFC 4364 – BGP/MPLS IP Virtual Private Networks (VPNs);
37. RFC 4379 – Detecting MPLS Data Plane Failures;
38. RFC 4447 – Pseudowire Setup and Maintenance Using the LDP;
39. RFC 4448 – Encapsulation Methods for Transport of Ethernet Over IP/MPLS Networks;
40. RFC 4618 – Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks;
41. RFC 4659 – BGP-MPLS IP VPN Extension for IPv6 VPN;
42. RFC 4661 – Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS LSPs;
43. RFC 4684 – Constrained Route Distribution for BGP/MPLS VPNs;
44. RFC 4717 – Encapsulation Methods for Transport of ATM Over MPLS Networks;
45. RFC 4761 – VPLS Using BGP for Auto-Discovery and Signaling;
46. RFC 4762 – VPLS Using LDP Signaling;
47. RFC 4875 – Extensions to RSVP-TE for Point-to-Multipoint TE LSPs;
48. RFC 4905 – Encapsulation Methods for Transport of Layer 2 Frames Over MPLS Networks;
49. RFC 4906 – Transport of Layer 2 Frames Over MPLS;
50. LDP IGP Synchronization – draft-jork-ldp-igp-sync-03.txt;
51. Connecting IPv6 Islands across IPv4 Clouds with BGP – draft-ietf-ngtrans-bgp-tunnel-04.txt;
52. Layer 2 VPNs over Tunnels – draft-kompella-l2vpn-l2vpn-01.txt;
Протоколы Multicast
1. RFC 2236—Internet Group Management Protocol, Version 2;
2. RFC 2362—Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification;
3. RFC 2932—IPv4 Multicast Routing MIB;
4. RFC 2933—Internet Group Management Protocol MIB;
5. RFC 2934 – Protocol Independent Multicast MIB for IPv4;
6. RFC 3292—General Switch Management Protocol (GSMP) V3;
7. RFC 3376—Internet Group Management Protocol, Version 3;
8. RFC 3569—An Overview of Source-Specific Multicast (SSM);
9. RFC 3710—Multicast Listener Discovery (MLD) for IPv6;
10. RFC 4605 – IGMP/MLD Proxying;
11. RFC 4607 – Source-Specific Multicast for IP;
12. RFC 4608 – Source-Specific Protocol Independent Multicast in 232/8;
13. RFC 5519 – Multicast Group Membership Discovery MIB;
14. A “ traceroute” Facility for IP Multicast—draft-ietf-idmr-traceroute-ipm-07.txt;
15. GSMP extensions for layer2 control (L2C) Topology Discovery and Line Configuration – draft-wadhwa-gsmp-l2control-configuration-02.txt;
16. Multicast in MPLS/BGP IP VPNs—draft-rosen-vpn-mcast-13.txt;
17. Distance Vector Multicast Routing Protocol – draft-ietf-idmr-dvmrp-v3-11.txt.
Функции QoS
1. RFC 2474—Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers;
2. RFC 2475—An Architecture for Differentiated Services;
3. RFC 2597—Assured Forwarding PHB Group;
4. RFC 2598—An Expedited Forwarding PHB;
5. RFC 2698—A Two Rate Three Color Marker;
6. RFC 2990—Next Steps for the IP QoS Architecture;
7. RFC 2998—A Framework for Integrated Services Operation over Diffserv Networks;
8. RFC 3246—An Expedited Forwarding PHB (Per-Hop Behavior);
9. RFC 3260—New Terminology and Clarifications for Diffserv;
10. DSL Forum Technical Report (TR)-059—DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services.

Требования к отказоустойчивости
1. Предлагаемые BRAS должны быть оснащены резервными модулями управления;
2. Выход из строя одного из модулей управления не должен приводить к снижению производительности матрицы коммутации;
3. Должен поддерживаться режим «горячей» замены и автоматического переключения между основным и резервным модулем управления без потери пользовательских PPPoE сессий.

Требования к масштабируемости
1. Для дальнейшего расширения BRAS должен поддерживать следующие виды интерфейсов:
  1. 10 Gigabit Ethernet;
  2. STM-4 POS;
  3. STM-16 POS;
  4. STM-1 ATM;
  5. STM-4 ATM.
2. Все слоты устройства должны допускать установку модулей с 10 Gigabit Ethernet интерфейсами. При этом должна обеспечиваться неблокируемая коммутация на скорости физического интерфейса;
3. Устройство должно поддерживать до 500000 записей в таблице IPv4 маршрутизации;
4. Линейная карта устройства должна поддерживать как минимум 256000 счетчиков для сбора статистики в каждом из направлений.

Требования к характеристикам взаимосвязей BRAS со смежными системами управления

Общие требования к взаимодействию
1. Оборудование должно обеспечивать интеграцию с существующей в АО "Казахтелеком" Системой Управления Сетями Телекоммуникаций посредством передачи потоков аварийных и информационных сообщений с использованием одного из интерфейсов: SNMP, RS-232 / Telnet;
Общие требования ко всем интерфейсам
1. Все принимаемые сообщения должны содержать:
  1. Физический и/или логический адрес оборудования, на котором произошла неисправность;
  2. Идентификатор или внутренний номер репортажа;
  3. Тип репортажа (проблема/разрешение/информация);
  4. Категория срочности устранения неисправности (critical/minor/major, и т.п.);
  5. Дата и время возникновения неисправности;
  6. Другая дополнительная информация, которую технический персонал может использовать для локализации и устранения неисправности оборудования.
Эксплуатационная документация на поставляемое оборудование должна содержать перечни аварийных и информационных сообщений, включающие в себя описание формата сообщений, идентификаторы (уникальные ключевые слова) сообщений, и их описание на английском и русском языках.
Требования к интерфейсу SNMP
1. Сообщения должны передаваться в следующих форматах:
  1. SNMP V1 traps, V2c traps, and V3 traps;
  2. SNMP V2c and V3 informs.
2. Эксплуатационная документация на поставляемое оборудование должна содержать:
  1. Версию используемого протокола;
  2. Набор всех необходимых MIB файлов, соответствующий оборудованию, включая все вышестоящие MIB;
  3. Описание Trap’ов и Inform’ов;
  4. Описание и формат значений передаваемых OID’ов.
Требования к интерфейсу RS-232/Telnet
1. Сообщения должны передаваться в формате ASCII или CP1251;
2. Выводить сообщения без запроса (без выполнения команд);
3. Сообщение должно заканчиваться фиксированным символом или их набором информируя о логическом завершении сообщения.
Прочие требования
1. Для осуществления контроля качества (QOS) на вновь вводимых сегментах Сети Передачи Данных все активное сетевое оборудование, которое будет участвовать в определений границ доверия на сети (маршрутизаторы, коммутаторы Метро сетей и оборудования Магистральных сетей IP/MPLS), должно быть дополнительно укомплектовано маршрутизатором, содержащим компонент Service Assurance Agent (SAAsr с типом интерфейса Fast Ethernet), для проведения измерений. Сетевое оборудование должно иметь дополнительный интерфейс Fast Ethernet для подключения SAAsr, либо конвертирующее устройство, через которое можно будет подключить SAAsr к соответствующему интерфейсу устройства.
2. При проектировании сетевой архитектуры необходимо учитывать организацию каналов мониторинга SLA параметров.

Требования к пассивному оборудованию

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

Общие требования
1. Пассивное оборудование должно включать в себя:
  1. Телекоммуникационные 19-ти дюймовые стойки необходимого типоразмера для установки новых шасси BRAS в следующих городах:

Алматы;
Актобе;
Шымкент.

Соединительные патчкорды (оптические и медные) необходимой длины и в необходимом количестве для подключения оборудования BRAS к оборудованию сетей агрегации;
(При необходимости) Оптические и медные патч-панели для коммутации соединительных патч-кордов;
Прочие материалы и расходные элементы, необходимые для монтажа и подключения оборудования BRAS.

Требования к содержанию и составу работ
1. Оказываемые услуги и проводимые работы должны включать в себя:
  1. Разработку Требований к Местам установки Оборудования;
  2. Предпроектные изыскания на Объектах;
  3. Разработку Технического Проекта;
  4. Разработку Рабочей документации;
  5. Разработку Программы и методики тестирования работоспособности и функциональности сети;
  6. Приемку Мест установки под монтаж Оборудования;
  7. Сборку стенда, наладку и конфигурирование комплектов Оборудования на производственных площадях АО «Казахтелеком»;
  8. Проведение стендовых испытаний;
  9. Установку и пуско-наладку предконфигурированных комплектов и тестирование оборудования на местах установки;
  10. Проведение приемо-сдаточных испытаний.

Требования к документации
1. Общие требования
  1. Вся документация должна быть на русском языке.
  2. Вся документация должна соответствовать принятым стандартам. По возможности должны быть использованы стандартизированные символы и термины, рекомендованные МСЭ и МЭК.
  3. Документация должна быть представлена в бумажном и электронном видах.

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

Общее описание проводимой модернизации оборудования BRAS;
Общие требования, предъявляемые к оборудованию BRAS;
Схемы и описания подключений оборудования BRAS к сетям MetroEthernet;
Описание комплектации BRAS с указанием функциональных возможностей компонентов;
Общее описание функционирования BRAS;
Описание IP адресации;
Описание организации маршрутизации для оборудования BRAS;
Описание настроек типовых сервисов на устройствах BRAS;
Описание мероприятий по вводу в эксплуатацию вновь устанавливаемых BRAS;

Спецификация оборудования, абонентских лицензий и программного обеспечения.

Состав рабочей документации
1. Рабочая документация на каждый объект должна содержать:

Лист общих данных;
Структурная схема узла сети;
Схема расположения модулей на оборудовании BRAS (фасады аппаратуры);
Схема расположения оборудования в монтажных шкафах (фасады шкафов);
План расположения оборудования и кабельных проводок.
Схема соединений оборудования на узле.
Схема подключения проектируемого оборудования BRAS к существующим сетям MetroEthernet;
Схема подключения проектируемого оборудования BRAS к существующим сетям электропитания и заземления;
Таблица потребления мощности проектируемым оборудованием BRAS;
Спецификация оборудования.

Состав документации программы и методики испытаний работоспособности оборудования BRAS
1. Перечень объектов, подлежащих испытаниям;
2. Критерии успешного проведения испытний;
3. Условия и порядок проведения испытаний;
4. Материально-техническое обеспечение испытаний;
5. Перечень тестов (проверок), по которым проводятся испытания;
6. Методики проведения испытаний и обработки их результатов;
7. Перечень оформляемой в ходе испытаний документации.

9. Технические требования к оборудованию для расширения

транспортных сетей передачи данных для увеличения скорости услуг

широкополосного доступа. Лот № 9.

Общие требования к модернизированной сети
1. Целью модернизации транспортных сетей передачи данных является:

Повыщение пропускной способности стыков МСПД-Metro Ethernet, посредством перевода с интерфейсов1GE на интерфейсы 10GE.
Расширение маршрутизаторов Магистральной сети передачи данных интерфейсами 10GE
Расширение маршрутизаторов Metro Ethernet интерфейсами 10GE.
Обеспечение потребности в ЗИП.

Требования к составу оборудования

Табл. 1. Оборудование для расширения маршрутизаторов Магистральной сети передачи данных.

Тип	Наименование	Кол-во
SPA-1X10GE-L-V2	Универсальные порт-адаптеры (SPA) с портами 10GE для маршрутизаторов магистрального уровня CRS-1	36
XFP-10GLR-OC192SR	Оптические модули 10GE для маршрутизаторов магистрального уровня CRS-1	36
ЗИП
SPA-1X10GE-L-V2	Универсальные порт-адаптеры (SPA) с портами 10GE для маршрутизаторов магистрального уровня CRS-1	2
XFP-10GLR-OC192SR	Оптические модули 10GE для маршрутизаторов магистрального уровня CRS-1	2
CRS-FLASH-DISK-2G=	Твердотельный накопитель для маршрутизаторов CRS-1	4

Табл. 2. Оборудование для расширения маршрутизаторов Metro Ethernet сетей.

Тип	Наименование	Кол-во
76-ES+T-4TG=	Линейная плата сервисов Carrier Ethernet для маршрутизаторов серии 7600	11
XFP-10GLR-OC192SR	Оптические модули 10GE для маршрутизаторов серии 7600	44
76-ES+ADVIP-LIC	Расширенная лицензия на MVPN, 6vPE, L3 IP/MPLS VPN	11
A9K-8T-L	8-портовые линейные карты для маршрутизаторов ASR9k	1
A9K-2T20GE-L=	Универсальная линейная карта 2-порта 10GE, 20-портов GE	2
76-ES+4TG3CXL	Линейная плата сервисов Carrier Ethernet для маршрутизаторов серии 7600	3
76-ES+ADVIP-LIC	Расширенная лицензия на MVPN, 6vPE, L3 IP/MPLS VPN	2
	ЗИП
15454-M-D2ROADM-SK	Перестраиваемый оптический мультиплексор ввода- вывода для ONS 15454	1
15454-M6-DC=	Блок питания для шасси ONS 15454	1
DWDM-XFP-xx.xx	Настраиваемый или фиксированный под длину волны DWDM-XFP	2
XFP-10GLR-OC192SR	Интерфейсный модуль 10GBASE-LR и OC192 SR-1	2

Требования к характеристикам взаимосвязей системы со смежными системами управления

Оборудование должно обеспечивать интеграцию с существующей в АО "Казахтелеком" Системой Управления Сетями Телекоммуникаций посредством передачи потоков аварийных и информационных сообщений с использованием одного из интерфейсов: SNMP, RS-232 / Telnet;

Общие требования ко всем интерфейсам:
Все принимаемые сообщения должны содержать:

Физический и/или логический адрес оборудования, на котором произошла неисправность;
Идентификатор или внутренний номер репортажа;
Тип репортажа (проблема/разрешение/информация);
Категория срочности устранения неисправности (critical/minor/major, и т.п.);
Дата и время возникновения неисправности;
Другая дополнительная информация, которую технический персонал может использовать для локализации и устранения неисправности оборудования.

Эксплуатационная документация на поставляемое оборудование должна содержать перечни аварийных и информационных сообщений, включающие в себя описание формата сообщений, идентификаторы (уникальные ключевые слова) сообщений, и их описание на английском и русском языках.
Требования к интерфейсу SNMP:
1. Сообщения должны передаваться в следующих форматах:
  1. SNMP V1 traps, V2c traps, and V3 traps;
  2. SNMP V2c and V3 informs.
Эксплуатационная документация на поставляемое оборудование должна содержать:
1. Версию используемого протокола;
2. Набор всех необходимых MIB файлов, соответствующий оборудованию, включая все вышестоящие MIB;
3. Описание Trap’ов и Inform’ов;
4. Описание и формат значений передаваемых OID’ов.
Требования к интерфейсу RS-232 / Telnet:
1. Сообщения должны передаваться в формате ASCII или CP1251;
2. Выводить сообщения без запроса (без выполнения команд);
3. Сообщение должно заканчиваться фиксированным символом или их набором информируя о логическом завершении сообщения.
Для осуществления контроля качества (QOS) на вновь вводимых сегментах Сети Передачи Данных все активное сетевое оборудование, которое будет участвовать в определений границ доверия на сети (маршрутизаторы, коммутаторы Метро сетей и оборудования Магистральных сетей IP/MPLS ДКП), должно быть дополнительно укомплектовано маршрутизатором, содержащим компонент Service Assurance Agent (SAAsr с типом интерфейса Fast Ethernet), для проведения измерений.
Сетевое оборудование должно иметь дополнительный интерфейс Fast Ethernet для подключения SAAsr, либо конвертирующее устройство, через которое можно будет подключить SAAsr к соответствующему интерфейсу устройства.
При проектировании сетевой архитектуры необходимо учитывать организацию каналов мониторинга SLA параметров.

Гарантийное обслуживание

4.1 Гарантийный срок на поставляемое оборудование и оказанные услуги -12 месяцев с даты подписания Акта предварительной приемки и сдачи оборудования;

Гарантийное обслуживание должно включать в себя ремонт оборудования, сопровождение программного обеспечения (устранение ошибок, загрузка новых версий ПО и др.), устранение аварий, консультирование с целью разрешения технических проблем по телефону, факсу или электронной почте (по вопросам функционирования, эксплуатации и конфигурации Оборудования);
Неисправное оборудование должно быть восстановлено и возвращено поставщиком в течение 45 дней со дня отправки на ремонт.

Blog

Утверждена приказом ао «казахтелеком»