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

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

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

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

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

10. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

к оборудованию и услугам монтажа и пусконаладки «под ключ» для расширения и модернизации сети агрегации сервисов ПД АО «Казахтелеком». Лот №10.

Общие требования к модернизированной сети
1. Целью модернизации сети агрегации является расширение функциональных возможностей Магистральной Сети передачи Данных (МСПД) АО «Казахтелеком» для увеличения пропускной способности, расширения портовой ёмкости и обеспечения внедрения новых сервисов доступа FTTH на базе технологии GPON.
2. Модернизируемая сеть должна обеспечивать высокоскоростной доступ к внутренним ресурсам АО «Казахтелеком», а также к глобальной сети Интернет.
3. Абоненты услуг широкополосного доступа, подключаемые по технологии GPON должны получать услугу с использованием сервисной модели DHCP.
4. Модернизация сети агрегации должна включать в себя комплекс взаимосвязанных мероприятий: расширение погранично-транзитного сегмента, модернизация и расширение сервисной границы, внедрение системы сервисных политик DHCP модели, настройка и изменение конфигурации сети для предоставления услуг ШПД абонентам GPON.

Требования к модернизации пограничных маршрутизаторов сети передачи данных (ASBR)
1. Должна быть произведена модернизация существующих трех узлов погранично-транзитного сегмента:

Погранично-транзитный узел в г. Алматы;
Погранично-транзитный узел в г. Астана;
Погранично-транзитный узел в г. Актобе;

Маршрутизатор T1600 в каждом из узлов должен обеспечивать следующие основные функции:

Погранично-транзитные функции, а именно: обеспечение пограничных функций с пиринг- и апстрим- провайдерами, транзит трафика для внутреннего сегмента МСПД;
Погранично-транзитные функции для клиентских сетей и транзит клиентского трафика к пиринг- и апстрим- провайдерам и для внутреннего сегмента МСПД;

В каждом из узлов маршрутизатор T1600 должен быть дооснащен линейными картами FPC: T1600-FPC4-ES.

Маршрутизатор T1600 в г. Алматы тремя FPC T1600-FPC4-ES.
Маршрутизатор T1600 в г. Астана тремя FPC T1600-FPC4-ES.
Маршрутизатор T1600 в г. Актобе двумя FPC T1600-FPC4-ES.

Дополнительно каждый маршрутизатор T1600 в каждом из узлов должен быть дооснащен 10-ти портовыми 10GE модулями PIC PD-5-10XGE-SFPP со сменными оптическими трансиверами SFPP-10GE-LR, 5 из 10 портов которых способны работать в режиме line-rate.

Маршрутизатор T1600 в г. Алматы шестью PIC PD-5-10XGE-SFPP и 16-ю SFPP-10GE-LR.
Маршрутизатор T1600 в г. Астана шестью PIC PD-5-10XGE-SFPP и 15-ю SFPP-10GE-LR.
Маршрутизатор T1600 в г. Актобе четырьмя PIC PD-5-10XGE-SFPP и 17-ю SFPP-10GE-LR.

Общие требования по увеличению портовой емкости маршрутизаторов T1600 приведены в таблице:

Узел

Модули

FPC T1600-FPC4-ES

PICPD-5-10XGE-SFPP

SFPP-10GE-LR

Алматы

3

6

16

Астана

3

6

15

Актобе

2

4

17
Необходимо обеспечить настройку физических интерфейсов устанавливаемых модулей в режим полной скорости портов 10GE;
Необходимо согласовать и реализовать подсистему транспорта трафика протокола IPv4;
Необходимо обеспечить настройку IPv4 адресации на интерфейсах устанавливаемых модулей;
Необходимо обеспечить настройку протокола внутри доменной маршрутизации между ASBR и модернизируемыми маршрутизаторами сервисной границы;
Необходимо обеспечить настройку обеспечение прохождения трафика сервиса High Speed Internet (HSI) между граничными маршрутизаторами и модернизируемыми маршрутизаторами сервисной границы по выделенной IP топологии, минуя существующее ядро сети (L1 и L2 P-маршрутизаторы);

Требования к функциональности пограничных маршрутизаторов
1. Устройства должны обеспечивать поддержку протоколов и стандартов:

IPv4;
IPv6;
MPLS коммутацию

В том числе поддерживаемые стандарты для MPLS:

RFC 2547, BGP/MPLS VPNs
RFC 2702, Requirements for Traffic Engineering Over MPLS
RFC 2858, Multiprotocol Extensions for BGP-4
RFC 3031, Multiprotocol Label Switching Architecture
RFC 3032, MPLS Label Stack Encoding
RFC 3063, MPLS Loop Prevention Mechanism
RFC 3140, Per Hop Behavior Identification Codes
RFC 3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services (E-LSPs only)
RFC 3443, Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
RFC 3469, Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
RFC 3564, Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering
RFC 4124, Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering

В том числе для LDP:

RFC 3036, LDP Specification
RFC 3212, Constraint-Based LSP Setup using LDP

В том числе для GMPLS:

RFC 3471
RFC 3473, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation [sic] Protocol-Traffic Engineering (RSVP-TE) Extensions (Only Section 9, “Fault Handling,” is supported.)
RFC 4206, Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)

В том числе для RSVP:

RFC 2205, Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification
RFC 2209, Resource ReSerVation Protocol (RSVP)—Version 1 Message Processing Rules
RFC 2210, The Use of RSVP with IETF Integrated Services

Устройства должны поддерживать следующие протоколы IP маршрутизации:

OSPF;
IS-IS;
BGPv4;

В том числе для OSPF:

RFC 1587, The OSPF NSSA Option
RFC 2328, OSPF Version 2
RFC 2370, The OSPF Opaque LSA Option (support provided by the RSVP update-threshold configuration option)
RFC 2740, OSPF for IPv6

В том числе для ISIS:

International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 10589, Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing [sic] information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)
RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
RFC 2104, HMAC: Keyed-Hashing for Message Authentication
RFC 2763, Dynamic Hostname Exchange Mechanism for IS-IS
RFC 2966, Domain-wide Prefix Distribution with Two-Level IS-IS
RFC 2973, IS-IS Mesh Groups
RFC 3277, Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance

В том числе для BGP:

RFC 1745, BGP4/IDRP for IP—OSPF Interaction
RFC 1772, Application of the Border Gateway Protocol in the Internet
RFC 1965, Autonomous System Confederations for BGP
RFC 1966, BGP Route Reflection—An alternative to full mesh IBGP
RFC 1997, BGP Communities Attribute
RFC 2270, Using a Dedicated AS for Sites Homed to a Single Provider
RFC 2283, Multiprotocol Extensions for BGP-4
RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option
RFC 2439, BGP Route Flap Damping
RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
RFC 2796, BGP Route Reflection – An Alternative to Full Mesh IBGP
RFC 2858, Multiprotocol Extensions for BGP-4
RFC 2918, Route Refresh Capability for BGP-4
RFC 3065, Autonomous System Confederations for BGP
RFC 3107, Carrying Label Information in BGP-4
RFC 3392, Capabilities Advertisement with BGP-4
RFC 4271, A Border Gateway Protocol 4 (BGP-4)
RFC 4360, BGP Extended Communities Attribute
RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 4456, BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)

Протоколы, обеспечивающие работоспособность IPv4 Multicast:

RFC 1112, Host Extensions for IP Multicasting (defines IGMP Version 1)
RFC 2236, Internet Group Management Protocol, Version 2
RFC 2327, SDP: Session Description Protocol
RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
RFC 2365, Administratively Scoped IP Multicast
RFC 2547, BGP/MPLS VPNs
RFC 2710, Multicast Listener Discovery (MLD) for IPv6
RFC 2974, Session Announcement Protocol
RFC 2858, Multiprotocol Extensions for BGP-4
RFC 3031, Multiprotocol Label Switching Architecture
RFC 3208, PGM Reliable Transport Protocol Specification
RFC 3376, Internet Group Management Protocol, Version 3 (SSM include mode only)
RFC 3446, AnycastRendevous [sic] Point (RP) Mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
RFC 3569, An Overview of Source-Specific Multicast (SSM)
RFC 3590, Source Address Selection for the Multicast Listener Discovery (MLD) Protocol (SSM include mode only)
RFC 3618, Multicast Source Discovery Protocol (MSDP)
RFC 3973, Protocol Independent Multicast – Dense Mode (PIM-DM): Protocol Specification (Revised)
RFC 4601, Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised)

Устройство должно поддерживать функции QoS:

Классификация трафика по признакам:
IP Precedence;
Differential Services Code point;
MPLS Exp;

А так же соответствовать стандартам:

RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 2475, An Architecture for Differentiated Services
RFC 2597, Assured Forwarding PHB Group
RFC 2598, An Expedited Forwarding PHB
RFC 2697, A Single Rate Three Color Marker
RFC 2698, A Two Rate Three Color Marker

Требования к модернизации маршрутизаторов сервисной границы (PE)
1. Модернизируемые объекты сети располагаются в семнадцати городах Республики Казахстан и подразделяются на региональные и центральные узлы сервисной границы МСПД.
2. Центральные узлы сервисной границы МСПД расположены в следующих городах:

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

Региональные узлы сервисной границы МСПД расположены в следующих городах:

Актау;
Атырау;
Караганда;
Кокшетау;
Костонай;
Кызылорда;
Павлодар;
Петропавловск;
Семей
Талдыкорган;
Тараз;
Уральск;
Усть-каменогорск;
Шымкент;

Во всех семнадцати узлах сервисной границы МСПД обеспечить готовность к использованию 64-битной сетевой ОС JunOS c целью увеличения доступного количества DHCP-подписчиков до 128 тысяч на каждое шасси, при условии использования не менее трех сервисов и одного логического интерфейса на каждого подписчика в модели S-VLAN.
В настоящее время:

В центральных узлах сервисной границы установлены шасси маршрутизаторов - MX960.
В региональных узлах сервисной границы - MX480;

Во всех семнадцати узлах сервисной границы требуется оснастить существующие шасси дополнительными линейными картами, интерфейсными модулями, конверторами для обеспечения подключений оборудования доступа на базе GPON, а также обеспечения подключений к вышестоящим пограничным маршрутизаторам МСПД.
Во всех семнадцати узлах сервисной границы потребуется согласовать и обеспечить IP-адресацию на вновь организуемых линках между собой, а также вышестоящими пограничными маршрутизаторами ASBR. Также требуется обеспечить интеграцию новых устройств в существующий IGP домен и организовать взаимодействие с существующими Router Reflector маршрутизаторами МСПД по протоколу MP-BGP.
Во всех семнадцати узлах сервисной границы требуется обеспечить функционал широкополосного сетевого шлюза (Broadband Network Gateway–далее BNG) для сервисной модели DHCP.
Аутентификация пользователей для BNG должна осуществляться на основе идентификатора Option82. Сам процесс аутентификации должен производиться во взаимодействии с существующими в АО «Казахтелеком» системами ACP.
В двух центральных узлах сервисной границы (г. Алматы и г. Астана) должны быть установлены в резервируемой схеме дополнительно системы аутентификации/авторизации/сбора статистики (система AAA). Необходимо обеспечить взаимодействие по протоколу RADIUS между данными серверами и модернизируемыми устройствами сервисной границы, а также согласовать спецификацию SQL-запросов/ответов в базу данных АСР.
В двух центральных узлах сервисной границы (г. Алматы и г. Астана) должны быть также установлены в резервируемой схеме серверы системы сервисных политик для организации пользовательских подписок.
Авторизация сервисов, т.е. обеспечение полосы пропускания в сеть АО «Казахтелеком» при наличии достаточных средств на счету абонента должно производиться с централизованных серверов системы сервисных политик c обращением через систему AAA к АСР.
Необходимо обеспечить, во взаимодействии с существующей АСР, контроль за состоянием счета абонента и запрещать доступ к сервису доступа в сеть АО «Казахтелеком» в случае блокировки по каким-то причинам его лицевого счета либо отсутствием средств на нем. Контроль должен осуществляться без использования механизма реавторизации (stop/start) сервисов.

Требования к аппаратному обеспечению модернизируемых маршрутизаторов сервисной границы МСПД
1. Маршрутизаторы должны быть устройствами операторского класса;
2. Маршрутизаторы должны быть модульными;
3. Маршрутизаторы должны иметь пропускную способность 60 Гбит/с (в режим full duplex) на каждый слот;
4. Маршрутизаторы должны иметь общую пропускную способность 1320 Гбит/с в центральных узлах сервисной границы МСПД и 720Гбит/с в региональных узлах;
5. Маршрутизаторы должны иметь возможность установки резервного процессорного модуля и резервной матрицы коммутации;
6. Маршрутизаторы должны иметь возможность установки 12 или 6 линейных модулей в центральных и региональных узлах сервисной границы МСПД соответственно;
7. При необходимости в региональном узле г. Алматы требуется предусмотреть установку дополнительных шасси маршрутизаторов для обеспечения требуемой потребности расширения портовой емкости, а также соответствующего функционала.
8. Маршрутизаторы должны быть дооснащены линейными картами с возможностью установки не менее двух интерфейсных модулей; При этом линейные карты для организации DOWNLINK-интерфейсов дополнительно должны поддерживать возможность создания иерархических политик качества обслуживания сервисов.
9. Маршрутизаторы должны быть дооснащены интерфейсными модулями с возможностью организации не менее четырех портов 10 GE;
10. Маршрутизаторы должны быть дооснащены интерфейсными конверторами типа XPF для оптоволоконных (Single Mode) каналов связи до 10 км, а в определенных случаях - до 40 км.;
11. Общие требования по дооснащению аппаратной части маршрутизаторов:

Узел	Линейные карты для организации DOWNLINK-портов	Линейные карты для организации UPLINK-портов	Интерфейсные модули с четырьмя портами 10GE	XFP, Single Mode, до 10 км	XFP, Single Mode, до 40 км
Астана	4	4	14	51	3
Алматы	7	10	29	79	21
Актобе	2	2	6	18	-
Актау	2	-	4	16	-
Атырау	2	-	4	10	-
Караганда	2	2	6	20	-
Кокшетау	2	2	6	22	-
Костонай	2	-	4	12	-
Кызылорда	2	-	4	18	-
Павлодар	2	-	4	14	-
Петропавловск	2	-	4	10	-
Семей	2	2	6	12	-
Талдыкорган	2	2	6	12	-
Тараз	2	-	4	10	-
Уральск	2	-	4	20	-
Усть-Каменогорск	2	-	4	14	-
Шымкент	2	-	4	10	-

Маршрутизаторы в г. Алмате должны быть дополнительно дооснащены интерфейсными конверторами DWDM XFP с возможностью перестройки рабочей длины волны в соответствии с ITU-T Grid Channels (конкретные длины волн будут отдельно определены Заказчиком) в количестве 7 шт., а также основным и резервным устройством (программатором) для задания необходимой длины волны;
Маршрутизаторы должны иметь возможность установки резервного блока охлаждения;
Маршрутизаторы должны иметь возможность установки резервного блока питания на постоянный ток;
Модули должны характеризоваться максимальным требованием к электропитанию постоянного тока не более 5100 Вт в центральных узлах сервисной границы МСПД и в 2900 Вт - в региональных узлах;
Модули должны поддерживать рабочий температурный режим от 0 до 40 градусов Цельсия;
Маршрутизаторы должны поддерживать режим работы при относительной влажности от 5% до 90%;
Маршрутизаторы не должны иметь полную физическую массу более 152/82 килограмм при максимальной аппаратной конфигурации для центральных/региональных узлов сервисной границы МСПД соответственно;
Маршрутизаторы не должны занимать в высоту более 16/8RU при монтаже в телекоммуникационную стойку для центральных/региональных узлов сервисной границы МСПД соответственно;

Требования к функциональным возможностям модернизируемых маршрутизаторов сервисной границы МСПД
1. Маршрутизаторы должны поддерживать следующие протоколы передачи данных:
  1. IPv4 (RFC 791);
  2. IPv6 (RFC 2460);
  3. MPLS коммутацию (RFC 3031).
  4. Маршрутизаторы должны поддерживать следующие протоколы маршрутизации:
  5. IS-IS (RFC 1195);
  6. OSPFv2 (RFC 2328);
  7. OSPFv3 (RFC 2740);
  8. BGPv4 с мультипротокольных расширениями (RFC 4271, RFC 2858).
2. Маршрутизаторы должны поддерживать следующие протоколы и технологии коммутации по меткам (MPLS):
  1. Функции LSP (MPLS Р-маршрутизатора) (RFC 3031);
  2. Функции LER (MPLSPE-маршрутизатора) (RFC 3031);
  3. Протокол LDP для распространения меток (RFC 3036);
  4. MPLS-VPN (RFC2547 bis) с 1500 VPN/VRF на устройство;
  5. L2 VPNVPLS с поддержкой сигнализация LDP (draft-Martini) и сигнализация BGP (draft-Kompella) с не менее чем 2000 инстанций на устройство;
  6. Carrier support Carrier VPN;
  7. MPLS Traffic Engineering (MPLS-TE);
  8. Протокол RSVP с расширениями для MPLS-TE (RFC 3209);
  9. Diffserv aware MPLS-TE (RFC 4124, RFC 4125, RFC 4126, RFC 4127, RFC 4128);
  10. MPLS-TE расширения для протоколов OSPF и IS-IS. В том числе стандартных расширений для Diffserv-awareMPLS-TE (RFC 3630, RFC 3784);
  11. Возможность работы протоколов IGP маршрутизации поверх MPLS-TE тоннелей. MPLS TE Forwarding Adjacency;
  12. TE Unequal Load Balancing;
  13. InterAS support for L2VPN;
3. Маршрутизаторы должны поддерживать следующие функции для протоколов маршрутизации:
  1. Не менее 1000 процессов OSPF и RIP;
  2. Не менее 500 сессий BGP;
  3. BGP Route Flap Damping (RFC 2439);
  4. BGP Route Reflection – An Alternative to Full Mesh IBGP (RFC 2796);
4. Маршрутизаторы должны поддерживать протоколы, обеспечивающие работоспособность IPv4 Multicast:
  1. IGMP v1/2/3;
  2. PIM Sparce Mode;
  3. PIM Dense Mode;
  4. Multicast source discovery protocol;
  5. Multicast Listener Discovery;
  6. Anycast RP;
  7. Source Specific Multicast;
5. Маршрутизаторы должны поддерживать следующие функции для обеспечения качества обслуживания сервисов:
  1. Ограничение доступной полосы пропускания для каждого отдельного виртуального интерфейса VLAN/VPN;
  2. Поддержку приоритезации трафика на основе: IP Precedence, MPLS Exp, DSCP, 802.1p;
  3. Возможность перемаркировки 802.1p, MPLS EXP и IP Precedence на любых интерфейсах (включая MPLS, MPLS CsC);
  4. Поддержку иерархического механизма качества обслуживания (ограничение полосы пропускания; управления очередями) на входящих и исходящих интерфейсах;
6. Следующие функции QoS: MPLS CoS, WRED, Policing и LowLatencyQueuing должны поддерживаться на всех физических и логических интерфейсах;
  1. Наличие буферной памяти для входящего/исходящего интерфейса на уровне 100 мс на скорости порта, включая интерфейсы 10GE;
  2. Возможность QoSmapping между 802.1p, MPLS EXP и IP Precedence в любых комбинациях
7. Маршрутизаторы должны поддерживать следующие функции для обеспечения сетевой безопасности:
  1. Возможность установки до 10000 ACL на устройство без влияния на производительность с временем установки не выше 100 сек на 10000 записей;
  2. Поддержку расширенной фильтрации по заголовкам 3-го (IP) и 4-го уровней на всех физических и логических интерфейсах;
8. Маршрутизаторы должны поддерживать дополнительно следующие функции:
  1. Поддержка overlapping идентификаторов VLAN для разных абонентов и обработка Ethernet фреймов в разные инстанции VPLS;
  2. Поддержка ограничения трафика (policing) на интерфейсах VPLS;
  3. Поддержка протокола сбора аккаутингаNetflow версии 9,10;
  4. Поддерживать балансировку трафика как равную, так и в пропорциях на основе «стоимости» каналов MPLS;
  5. Поддерживать функцию GracefullRestrart для протоколов BGP, BGP с MPLS, OSPF, OSPFv3, IS-IS, LDP, RSVP, VPN третьего уровня;
  6. Поддерживать замену программного обеспечения части или всего в целом без остановки коммутации/маршрутизации данных.
9. Маршрутизаторы должны обеспечивать возможность активацию функции BroadbandNetworkGateway – BNG, при этом:
  1. BNG должен обеспечивать работу в модели централизованного BroadbandServerRouter (BNG) с единой точкой доступа к сервисам и должна быть рассчитана на предоставление IP-сервисов конечным подписчикам.
  2. В качестве основных модели доставки сервисов должны поддерживаться как C-VLAN, так и S-VLAN;
  3. BNG должны поддерживать функции согласно основным рекомендациям Broadband-форума: TR-059, 069 и WT-101.
  4. BNG должен поддерживать до 128-х тыс. DHCP подписчиков или до 64-х тыс. PPPoEподписчиков.
10. Маршрутизаторы должны допускать установку сервисных модулей для активации дополнительных сетевых сервисов: трансляция сетевых адресов (NAT) для пакетов IPv4, IPv6, брандмаура (FW), IDP/DPI, контроль качества предоставления сервиса передачи голосовых и видео данных на уровне контента.

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

Система сервисных политик должна предлагаться как отдельный программно-аппаратный комплекс.
Система сервисных политик предназначена для оптимизации процесса подключения абонента к сети, активации/деактивации его сервисов, автоматизации процесса создания и настройки интерфейса доступа на всем множестве BRAS-ов для всего множества подписчиков и сервисов сети широкополосного доступа АО «Казахтелеком».
Система сервисных политик должна поддерживать возможность централизованного создания и ведения базы данных пользователей и сервисов:
1. Сервисы для широкополосных абонентов должны быть описаны в терминах IP-адресов Source/Destination), TCP/UDP портов, типов трафика (IP-precedence/DSCP).
2. Для каждого сервиса для входящего и исходящего трафика в отдельности должен быть описан набор правил обслуживания: правил фильтрации, ограничения полосы пропускания для каждого абонента и сервиса, ip-redirect, перемаркировки значения IP-perecedence/DSCP.
3. Система должна поддерживать возможность автоматизации создания сервисов для бизнес-абонентов L3 VPN с различными профилями доступа к сетевым ресурсам оператора связи.
Система сервисных политик должна поддерживать протокол RADIUS для взаимодействия с вновь устанавливаемымиAAA-серверамидля взаимодействия с системой АСР.
Система сервисных политик должна обеспечивать аутентификацию и авторизацию абонентов и сервисных сессий с использованием дополнительной опцией (Option82) вставляемой в пользовательские запросы для получения IP-адреса по протоколу DHCP.
В зависимости от типа, которым воспользовался абонент для входа в систему (DHCP/PPPoE/web-авторизация), система должна автоматически классифицировать тип создаваемого интерфейса и применить соответствующий набор правил доступа для абонента.
Система сервисных политик должна быть проинтегрирована с существующей АСР системой и обеспечить согласование новой схемы активации сервисов для сети АО «Казахтелеком».
Система сервисных политик должна обеспечивать аутентификацию и авторизацию сервисных сессий для абонентов сети на основе ID подписчика, ID сервиса и параметров переданных AAA-сервером от системы АСР (Service-Bundle, Session-Volume-Quote, Session-Time-Out):
Система должна иметь возможность посылать RADIUS-запросы на авторизацию каждой сервисной сессии в отдельности.
1. Система должна позволять активировать множество одновременных сервисных сессий для одного пользователя (более 8 сессий на пользователя),
2. После аутентификации пользователя и авторизации DHCP сессии абонента система должна автоматически активировать сервисы из состава сервисного пакета, на которые подписан абонент (например, iDNetMotor).
3. Система сервисных политик должна предусматривать возможность гостевого входа в систему и организацию сервиса HTTP-redirect.
4. Система должна автоматически терминировать сервисные сессии при обнулении параметра SessionTimeOut.
5. Система должна иметь возможность автоматически терминировать сервисную сессию или переключить сервис на более низкую скорость доступа при обнулении параметра квоты на объем (общего или в отдельности исходящего/входящего) трафика, обрыв абонентской сессии (PPPoE/IPoE) при этом не допускается.
6. Система должна иметь возможность активировать сервисную сессию при обновлении сервисной квоты (на объем, время или квоты выданной в условных единицах на один сервис или на набор из нескольких сервисов) без переустановления абонентской (PPPoE/IPoE) сессии. Допускается временная задержка равная 10 минутам между моментом обновления квоты и моментом активации сервиса.
7. Система сервисных политик должна иметь развитые средства построения сервисов типа Pre-paied (предоплаченные сервисы), где в качестве меры утилизации сервиса используется временной интервал, объем данных либо условные единицы. Учет утилизации должен вестись, как по отдельному сервису, так и группе сервисов.
Система сервисных политик должна обеспечивать сбор и передачу статистики (accounting) по протоколу RADIUS в виде Start, Stop, Interim обновлений для каждого сервиса в отдельности.
Система сервисных политик должна иметь возможность ведения учета активных сервисных сессий и сетевых ресурсов, и осуществлять контроль их доступности для включения очередного сервиса для подписчика сети – Call/Session Admission Control.
Система сервисных политик должна иметь возможность развертывания системы само-подписки для пользователей сети (Self-serviceportal).
Для организации сервисов с добавленной стоимостью система должна поддерживать возможность интеграции с платформами приложений третьих производителей по протоколам (Radius, Diametr, Corba, SOAP XML).
Система сервисных политик должна иметь:
1. развитые графические средства GUI для администрирования системой;
2. развитые средства администрирования и мониторинга системы (текущих параметров подключений абонентов и сервисов и т.д.) с WEB-интерфейсом;
3. развитые средства CLI.
Система сервисных политик должна предусматривать добавление новой функциональности за счет установки новых plug-in модулей в том числе, разработанных сторонними производителями
Система сервисных политик должна обеспечивать гибкое разграничение административных прав доступа для администраторов разного уровня.
Система должна предусматривать такую схему работы, при которой разные подразделения (дирекции) службы эксплуатации АО «Казахтелеком», имеют возможность самостоятельно, с использованием независимых схем предоставления сервисов, аутентификации и авторизации, определять перечень сервисов для своих подписчиков – при этом физически сессии всех подписчиков терминируются на одних и тех же устройствах.
Система сервисных политик должна при необходимости позволять развертывать дополнительные сервисы обеспечения сетевой безопасности – Threat Mitigation Service.
Система сервисных политик должна предусматривать возможность одновременной работы до 500 тысяч абонентов и до 1,5 миллионов одновременных сервисных сессий (до 3 сессии на абонента).
Система сервисных политик должна поставлять в отказоустойчивой конфигурации предусматривающей наличие активной и резервной систем.
С целью повышения безопасности и отказоустойчивости cистема сервисных политик должна предусматривать возможность разнесения отдельных функциональных модулей на разных аппаратных платформах.

Требования к системе аутентификации, авторизации и сбора статистики
1. Система аутентификации, авторизации и сбора статистики должна предлагаться на отдельном аппаратной платформе со следующими характеристиками:
  1. Архитектура SPARC;
  2. Наличием менее 4-мью процессорами с тактовой частотой 2,75 ГГц;
  3. Оперативной памятью не менее 8 Гб;
  4. Резервированными жесткими дисками с объемом не менее 30 Гб.
2. Быть предназначенной для работы в сетях операторах связи.
3. Обеспечивать процесс аналогичный текущему взаимодействию между устройствами BRAS и системой АСР, функционирующей в настоящее время в АО «Казахтелеком».
4. Система должна поддерживать не менее 1,5 миллиона одновременных сессий аутентификации/авторизации.
5. Система должна предоставлять поддержку взаимодействия с базами данных LDAP, SQL (JDBC and Native Oracle Support).
6. Система должна предоставлять возможность задания бизнес-логики с помощью внутренних программных скриптов.
7. Система должна поддерживать протоколы аутентификации такие как PAP, CHAP, MS-CHAP v2, EAP, SIM, AKA, TTLS, TLS.
8. Система должна обеспечивать поддержку протоколов IPv4, IPv6.
9. Система должна поддерживать туннелирование протокола RADIUS.
10. Cистема должна поддерживать протоколы сетевого управления SNMP.

Общие требования к управлению сетевыми устройствами
1. Требования к интерфейсу управления устройством:
  1. Устройство должно поддерживать следующие способы управления:

Управление при помощи RS232 интерфейса;
Управление через сеть передачи данных (inband);
Управление посредством СУ Cisco ANA.

Должны поддерживаться следующие протоколы управления:

Telnet;
SNMP.

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

Локальной базы данных;
RADIUS;
TACACS+.

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

Требования к безопасности:
1. Устройство должно поддерживать фильтрацию трафика управления с помощью списков доступа;
2. Для протоколов маршрутизации должны поддерживаться расширения, обеспечивающие аутентификацию их сообщений;

Требования к ЗИП
1. Должен быть предоставлен следующий перечень запасных частей:

№	Позиция	Количество
1	Линейная карта для организации DOWNLINK-портов для маршрутизатора сервисной границы МСПД	1
2	Интерфейсный модуль с четырьмя портами 10GE для маршрутизатора сервисной границы МСПД	1
3	Интерфейсный адаптер для организации портов 10GE для маршрутизатора сервисной границы МСПД (Single Mode, до 10 км.)	1
4	Интерфейсный адаптер для организации портов 10GE для пограничного маршрутизатора МСПД (Single Mode, до 10 км.)	1

Требования к характеристикам взаимосвязей системы со смежными системами управления
1. Оборудование должно обеспечивать интеграцию с существующей в АО "Казахтелеком" Системой Управления Сетями Телекоммуникаций посредством передачи потоков аварийных и информационных сообщений.Сбор аварийных сообщений от оборудования и отправка в СУСТ верхнего уровня должен быть обеспечен через имеющуюся систему управления.
2. Общие требования ко всем интерфейсам:
  1. Все принимаемые сообщения должны содержать:

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

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

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

a) SNMP V1 traps, V2c traps, and V3 traps;
b) SNMP V2c and V3 informs.

Эксплуатационная документация на поставляемое оборудование должна содержать:

Версию используемого протокола;
Набор всех необходимых MIB файлов, соответствующий оборудованию, включая все вышестоящие MIB;
Описание Trap’ов и Inform’ов;
Описание и формат значений передаваемых OID’ов.

Требования к интерфейсу RS-232 / Telnet:

Сообщения должны передаваться в формате ASCII или CP1251;

Выводить сообщения без запроса (без выполнения команд);
Сообщение должно заканчиваться фиксированным символом или их набором информируя о логическом завершении сообщения.

Для осуществления контроля качества (QOS) на вновь вводимых сегментах Сети Передачи Данных , все активное сетевое оборудование, которое будет участвовать в определений границ доверия на сети (маршрутизаторы, коммутаторы Метро сетей и оборудования Магистральных сетей IP/MPLS), должно быть дополнительно укомплектовано маршрутизатором, содержащим компонент Service Assurance Agent (SAAsr с типом интерфейса Fast Ethernet), для проведения измерений.
Сетевое оборудование должно иметь дополнительный интерфейс Fast Ethernet для подключения SAAsr, либо конвертирующее устройство, через которое можно будет подключить SAAsr к соответствующему интерфейсу устройства.
При проектировании сетевой архитектуры необходимо учитывать организацию каналов мониторинга SLA параметров.

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

Техническая поддержка
1. Поставщик должен иметь возможность предоставить АО «Казахтелеком» следующие услуги по технической поддержке после завершения гарантийного срока:
2. Для устранения возникающих в оборудовании проблем поставщик обязан 24 часа в сутки 7 дней в неделю предоставлять соответствующие услуги. Услуги по технической поддержке заключаются в полном устранении неисправности и приведении оборудования в состояние, имевшее место до аварии;
3. Техническая поддержка должна включать в себя поставку и ремонт оборудования, сопровождение программного обеспечения (устранение ошибок, загрузка новых версий ПО и др.), устранение аварий;
4. Услуги по технической поддержке классифицированы по степеням в зависимости от уровня серьёзности проблемы:

полная или частичная потеря трафика (ПРОБЛЕМА ПЕРВОЙ СТЕПЕНИ);
опасность потери трафика (ПРОБЛЕМА ВТОРОЙ СТЕПЕНИ);
проблемы, не влияющие на трафик (ПРОБЛЕМА ТРЕТЬЕЙ СТЕПЕНИ);
Нормативное время на устранение проблем:
проблема первой степени – 4 часа;
проблема второй степени – 48 часов;
проблема третьей степени – 10 дней.

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

Требования к услугам по проектированию, монтажу и пуско-наладке
1. Оказываемые услуги и проводимые работы должны включать в себя:

Разработку Требований к местам установки оборудования;
Предпроектные изыскания на объектах Заказчика;
Разработку Технического проекта;
Разработку Рабочей документации;
Разработку Программы и методики тестирования работоспособности и функциональности сети;
Приемку Мест установки под монтаж оборудования;
Установку и пуско-наладку предварительно сконфигурированных комплектов и тестирование оборудования на местах установки;
Проведение приемочных испытаний.
Требования к документации

Общие требования

Вся документация должна быть на русском языке.
Вся документация должна соответствовать принятым стандартам. По возможности должны быть использованы стандартизированные символы и термины, рекомендованные МСЭ и МЭК.

Документация должна быть представлена в бумажном и электронном видах.

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

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

Общая топологическая схема сети и другие схемы (по необходимости).
Описание комплекса технических средств.
Спецификация оборудования и программного обеспечения.

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

Перечень объектов, подлежащих испытаниям;
критерии приема системы и ее частей;
условия и порядок проведения испытаний;
материально-техническое обеспечение испытаний;
перечень тестов (проверок), по которым проводятся испытания;
методики проведения испытаний и обработки их результатов;
перечень оформляемой в ходе испытаний документации.

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

Приемо-сдаточные испытания

Узел	Модули
Узел	FPC T1600-FPC4-ES	PICPD-5-10XGE-SFPP	SFPP-10GE-LR
Алматы	3	6	16
Астана	3	6	15
Актобе	2	4	17

Blog

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