ANEXO I Especificaciones Técnicas Red Troncal MPLS IP

Anexo I
Especificaciones Tcnicas
Red Troncal Multiservicio MPLS/IP
Proyecto red IP/MPLS ARSAT SA
Pgina 1 de 80
NDICE
1.
OBJETIVO ....................................................................................................................................... 6
2.
INTRODUCCIN .............................................................................................................................. 6
3.
ALCANCE ........................................................................................................................................ 6
4.
METODOLOGA DE RESPUESTA. ..................................................................................................... 7
5.
DESCRIPCION DE LA SOLUCION TECNOLOGICA A COTIZAR ............................................................. 7
5.1.
ARQUITECTURA DE REFERENCIA ................................................................................................. 9
5.2.
SITIOS A CONECTAR .................................................................................................................. 13
5.3.
DESCRIPCIN DE LA TOPOLOGA DE LA RED ............................................................................. 13
5.3.1.
ARQUITECTURA DE LA RED .................................................................................................. 13
5.3.1.1.
NIVEL CORE ....................................................................................................................... 14
5.3.1.2.
NIVEL DE AGREGACIN/DISTRIBUCIN ............................................................................ 15
5.3.1.3.
NIVEL DE ACCESO .............................................................................................................. 15
6.
CARACTERISTICAS TECNICAS Y PRESTACIONES REQUERIDAS ....................................................... 15
6.1.
CARACTERSTICAS TCNICAS .................................................................................................... 15
6.1.1.
CARACTERSTICAS GENERALES DEL EQUIPAMIENTO ............................................................. 15
6.1.2.
CAPACIDAD DE CONMUTACIN ........................................................................................... 16
6.1.3.
DISPONIBILIDAD Y REDUNDANCIA........................................................................................ 17
6.2.
REQUERIMIENTOS DE ROL PE, P,IGW Y RR .................................................................. 18
6.2.1.
INTERFACES .......................................................................................................................... 18
6.2.1.1.
ETHERNET ......................................................................................................................... 19
6.2.1.1.1.
CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 19
6.2.1.1.2.
PROTOCOLO DE NIVEL 2.................................................................................................... 20
6.2.1.2.
ATM .................................................................................................................................. 20
6.2.1.2.1.
6.2.1.2.2.
6.2.1.3.
POS ................................................................................................................................... 21
6.2.1.3.1.
6.2.1.3.2.
6.2.1.4.
SDH CANALIZADAS ............................................................................................................ 21
6.2.1.4.1.
6.2.1.4.2.
6.2.1.5.
OTRAS ............................................................................................................................... 22
6.2.1.6.
ETHERNET ......................................................................................................................... 22
Pgina 2 de 80
6.2.1.6.1.
6.2.1.6.2.
6.2.1.7.
IPODWDM ........................................................................................................................ 23
6.2.1.7.1.
6.2.1.7.2.
6.2.1.8.
ETHERNET ......................................................................................................................... 24
6.2.1.8.1.
6.2.1.8.2.
6.2.2.
ROUTING .............................................................................................................................. 25
6.2.2.1.
PROTOCOLOS DE RUTEO REQUERIDOS ............................................................................. 26
6.2.2.2.
POLICY ROUTING .............................................................................................................. 30
6.2.2.2.1.
FUNCIONALIDADES POLICY ROUTING ............................................................................ 31
6.2.2.3.
PERFORMANCE EN IPV4 .................................................................................................... 31
6.2.2.4.
PROTOCOLO IPV6 ............................................................................................................. 31
6.2.2.5.
PERFORMANCE EN IPV6 .................................................................................................... 32
6.2.2.6.
OTRAS FUNCIONALIDADES DE ROUTING........................................................................... 32
6.2.3.
MPLS (MULTI PROTOCOL LABEL SWITCHING) ....................................................................... 33
6.2.4.
FUNCIONALIDADES ............................................................................................................... 36
6.2.4.1.
ACCESS LIST ...................................................................................................................... 36
6.2.4.2.
VPN-MPLS ......................................................................................................................... 37
6.2.4.2.1.
GESTIN DE VPN MPLS ..................................................................................................... 38
6.2.4.2.2.
CLASE DE SERVICIO Y CALIDAD DE SERVICIO ..................................................................... 38
6.2.4.3.
DIFFSERV .......................................................................................................................... 40
6.2.4.4.
DIFFSERV MPLS .............................................................................................................. 40
6.2.4.4.1.
DIFFSERV-AWARE MPLS TRAFFIC ENGINEERING .............................................................. 41
6.2.4.4.2.
MTODOS DE CLASIFICACIN ........................................................................................... 42
6.2.4.5.
ALTA DISPONIBILIDAD ...................................................................................................... 42
6.2.4.6.
TRAFFIC ENGINEERING ...................................................................................................... 43
6.2.4.6.1.
TRAFFIC ENGINEERING FAST RE ROUTE (TE-FRR) .............................................................. 44
6.2.4.6.2.
PWE3 (PSEUDO-WIRE EMULATION EDGE-TO-EDGE) ......................................................... 44
6.2.4.6.3.
VPLS .................................................................................................................................. 46
6.2.4.6.4.
PATH MTU DISCOVERY ..................................................................................................... 47
6.2.4.6.5.
VIRTUAL ROUTER REDUNDANCY PROTOCOL (VRRP) ......................................................... 48
6.2.4.6.6.
ROUTER VIRTUAL .............................................................................................................. 48
6.2.4.6.7.
TUNNELING ....................................................................................................................... 48
Pgina 3 de 80
6.2.4.6.8.
TUNNELING Y ENCRIPCIN DE DATOS MEDIANTE IPSEC ................................................... 49
6.2.4.7.
NETWORK-BASED FIREWALL ............................................................................................. 50
6.2.4.8.
NETWORK-BASED NAT ...................................................................................................... 50
6.2.4.9.
CONTROL DE APLICACIONES ............................................................................................. 51
6.2.4.10.
AGENTE DE MEDICION DE PERFORMANCE ........................................................................ 51
6.2.4.11.
SINCRONISMO .................................................................................................................. 51
6.2.4.11.1.
FUENTES DE SINCRONISMO .......................................................................................... 52
6.2.4.12.
OPERACIN, ADMINISTRACIN Y MANTENIMIENTO ........................................................ 52
6.2.4.13.
MEF ELMI (ETHERNET LOCAL MANAGEMENT INTERFACE) ................................................ 52
6.2.4.14.
IEEE 802.3AH OAM............................................................................................................ 52
6.2.4.14.1.
IEEE 802.1AG (ETHERNET CONNECTIVITY FAULT MANAGEMENT) ................................. 53
6.2.4.14.2.
ITU Y.1731 (PERFORMANCE FAULT MANAGMENT) ....................................................... 53
6.2.4.14.3.
INTEROPERABILIDAD DE OAM. ..................................................................................... 54
6.2.4.14.4.
OTRAS ........................................................................................................................... 54
6.3.
CAPACIDADES DE GESTIN PROVISTAS POR EL ELEMENTO DE RED .......................................... 54
6.3.1.
INTERFACES GESTION ........................................................................................................... 54
6.3.2.
FUNCIONALIDADES ............................................................................................................... 55
6.3.2.1.
ASOCIACIN ENTRE FUNCIONALIDADES E INTERFACE ...................................................... 55
6.3.2.2.
FALLAS .............................................................................................................................. 55
6.3.2.3.
CONFIGURACIN .............................................................................................................. 56
6.3.2.4.
PERFORMANCE ................................................................................................................. 56
6.3.2.5.
CONTABILIZACIN (ACCOUNTING) ................................................................................... 57
6.3.2.6.
SEGURIDAD ....................................................................................................................... 57
6.3.2.7.
INVENTARIO DE ELEMENTOS ............................................................................................ 57
6.3.3.
ADMINISTRACIN DE SOFTWARE ......................................................................................... 58
6.3.4.
REGISTROS (LOGS) ................................................................................................................ 58
6.3.5.
COPIA DE RESPALDO (BACKUP) / RESTAURACIN (RESTORE) ............................................... 58
6.3.6.
ROADMAP GESTION ............................................................................................................. 59
6.3.7.
ROADMAP EQUIPAMIENTO .................................................................................................. 59
6.4.
VALORES MINIMOS DE FUNCIONALIDADES BSICAS POR TIPO DE NODO (PE, P, RR E IGW) [O]
59
6.4.1.
VALORES MINIMOS DE FUNCIONALIDADES BSICAS PARA NODO PE ............................... 59
6.4.2.
VALORES MINIMOS DE FUNCIONALIDADES BSICAS PARA NODO IGW ............................ 59
6.4.3.
VALORES MINIMOS DE FUNCIONALIDADES BSICAS PARA NODO P ................................. 60
6.4.4.
VALORES MINIMOS DE FUNCIONALIDADES BSICAS PARA NODO RR ............................... 60
Pgina 4 de 80
7.
ESCENARIOS REQUERIDOS ........................................................................................................... 60
7.1.
OBJETO REQUERIDO: ROL P [O] ................................................................................................ 60
7.1.1.
CANTIDAD DE INTERFACES I-P-P [O] ..................................................................................... 61
7.1.2.
CANTIDAD DE INTERFACES I-P-PE [O] ................................................................................... 63
7.1.3.
CANTIDAD DE INTERFACES I-P-IGW [O] ................................................................................ 64
7.1.4.
CANTIDAD DE INTERFACES I-P-PE (DATA CENTER) [O] .......................................................... 65
7.1.5.
CANTIDAD DE INTERFACES I-P-RR [O] ................................................................................... 66
7.2.
OBJETO REQUERIDO: ROL PE [O] .............................................................................................. 67
7.2.1.
CANTIDAD DE INTERFACES I-PE-P [O] ................................................................................... 68
7.2.2.
CANTIDAD DE INTERFACES I-PE-AN SEC [O] .......................................................................... 69
7.2.3.
CANTIDAD DE INTERFACES I-PE-AN SUB [O] ......................................................................... 70
7.2.4.
CANTIDAD DE INTERFACES I-PE-AN [O] ................................................................................ 71
7.3.
OBJETO REQUERIDO: ROL IGW [O] ........................................................................................... 72
7.3.1.
7.4.
CANTIDAD DE INTERFACES I-IGW-P E I-IGW-CI [O] ............................................................... 73

OBJETO REQUERIDO: ROL RR.................................................................................................... 74
7.4.1.
7.5.
CANTIDAD DE INTERFACES I-RR-P [O] ................................................................................... 74

OBJETO REQUERIDO: MAQUETA [O] ........................................................................................ 75
8.
VISTA DE RACK ............................................................................................................................. 76
9.
ALCANCE DEL SUMINISTRO Y SERVICIOS [O] ................................................................................ 76
9.1.
ALCANCE DE SUMINISTRO ........................................................................................................ 76
10.
DOCUMENTACION EJECUTIVA [O] ............................................................................................ 76
11.
CRONOGRAMA DE EJECUCION DE TRABAJOS [O] ..................................................................... 77
12.
PROYECTO TCNICO DE LA PRESENTACIN [O] ........................................................................ 77
13.
CURSOS DE CAPACITACIN [O]................................................................................................. 78
14.
PRUEBAS DE CALIFICACION [O]................................................................................................ 78
15.
PRUEBAS DE HOMOLOGACION Y STRESS [O] ............................................................................ 78
15.1.
PRUEBAS FUNCIONALES Y DE INTEROPERABILIDAD ............................................................. 79
15.2.
PRUEBAS DE STRESS ............................................................................................................. 79
16.
GARANTIA DE DISEO [O] ........................................................................................................ 80
Pgina 5 de 80
1. OBJETIVO
El objetivo del presente documento es establecer las especificaciones tcnicas para
la provisin de equipos de networking, software, mano de obra y accesorios para la
puesta en marcha, operacin, ingeniera para la instalacin y optimizacin de la
red y asistencia tcnica, permitiendo el desarrollo e implementacin del Red Troncal
(Backbone) de la Red Federal de transporte de datos de alta capacidad basados en
tecnologa IP/MPLS
2. INTRODUCCIN
Esta especificacin forma parte del proyecto que rene la planificacin,
estructuracin y desarrollo de la obra Red Federal de Fibra ptica
de
Telecomunicaciones, para integrar sistemas multiservicios de voz, datos y video en
una misma red.
Esta Red Troncal Multiservicio debe integrar, a travs de enlaces de fibra ptica, a
la totalidad de los nodos principales de la traza. Esta permitir, adems, la
interconexin de otros nodos, secundarios y subtendidos, y localidades va vnculos
alternativos compatibles con la red. De esta forma, se logra, extender sus servicios
a Prestadores locales de Servicios de Telecomunicaciones y a Empresas de los
estados provinciales y otros organismos pblicos.
La presente especificacin da las pautas y caractersticas de los componentes a
ofrecer para lograr la correcta prestacin de los servicios solicitados.
El oferente deber presentar un esquema y una plataforma que debe responder los
requerimientos del presente pliego respetando la arquitectura solicitada.
La Contratista deber hacerse cargo de la confeccin de la documentacin segn lo
determinado en este Documento.
3. ALCANCE
El alcance de la obra incluye la realizacin del diseo, la ingeniera de detalle, la
instalacin y puesta en condiciones de funcionamiento de la troncal (backbone) de
la red multiservicio IP/MPLS, asistencia tcnica, provisin de los equipos activos,
pasivos y sus repuestos, y otras acciones complementarias como la capacitacin
integral del personal tcnico de ARSAT. Adems, incluye la provisin de una
herramienta de gestin y monitoreo a instalarse en el nodo principal de la red y las
tareas de prueba de toda la infraestructura montada, de acuerdo a las
especificaciones indicadas en el presente documento.
El oferente, deber contemplar la topologa inicial que se presenta, teniendo en
cuenta que el equipamiento, software y servicios ofertados deber ser escalable,
flexible, para soportar futuros crecimientos de trfico y nuevos servicios. El sistema
deber ser capaz de soportar mltiples servicios con flexibilidad de crecimiento
segn la demanda por sitio o regin y con el mnimo impacto posible a nivel de
ingeniera para las necesidades actuales y futuras.
La troncal de la red multiservicio deber ser apta para transportar voz, datos y
video sobre una plataforma de MPLS del tipo Carrier Class, para incorporar seales
Pgina 6 de 80
de TV y telefona celular, servicios punto a punto, punto a multipunto, multipunto a

multipunto, tanto layer 2 como layer 3 (IPv4 e IPv6), triple play, desde el inicio.
Los principales servicios, a utilizar de MPLS son :
VPN Layer 2 y Layer 3.(VPWS, VPLS, VRF, PW)

Ingeniera de trafico.
Garantizar QoS a nivel aplicativo (respetar los SLAs)
Transmisin y sincronismo de Clock IEEE1588
Multicast sobre MPLS
Este sistema ser concebido para integrar redes de larga distancia para prestacin
de servicios de Internet, redes privadas virtuales (VPNs), emulacin de circuitos
punto a punto, punto multipunto, anillos o redes malladas basada en una red de
alta capacidad, con facilidades de extraccin e insercin de trfico en los nodos
primarios, secundarios y subtendido definidos en la red, y respectivas plataformas
de soporte, tales como servicios de traslacin de nombres y direcciones (DNS),
autenticacin (Radius/TACACS), registros de auditoria (Syslog), sincronismo de
tiempo (NTP), medidores de desempeo y correccin de fallas (Sflow), red de
gerenciamiento (DCN), as como los sistemas de gestin de equipos, formacin,
garanta, puesta en servicio, apoyo y asistencia tcnica.
El sistema propuesto deber ser flexible y reconfigurable para adaptarse a las
necesidades actuales y futuras, y que simplifique las operaciones de red tanto en
el despliegue, activacin del servicio, adicin de servicios, agregacin,
reconfiguracin y mantenimiento.
4. METODOLOGA DE RESPUESTA.
Se deber responder a cada punto mediante la indicacin cumple no cumple.
Dichas respuestas deben ser justificadas fehacientemente y con documentacin
adicional que aporte a la respuesta.
Se deber responder en cada punto para cada versin de equipamiento ofertada
(aclarando explcitamente a cual se refiere).
En los casos de funcionalidades (features) disponibles a futuro, se deber aclarar
explcitamente la versin y la fecha en que dicha funcionalidad estar disponible.
Al responder el punto a punto, se deber evitar el uso de expresiones tales como
toma conocimiento o toma nota u otras que den lugar a interpretaciones errneas, y
por lo tanto, estas sern interpretadas como No Cumple. Los puntos indicados con
[O], son de cumplimiento obligatorio.
5. DESCRIPCION
COTIZAR
DE
LA
SOLUCION
TECNOLOGICA
A continuacin se detallan las principales caractersticas y datos relevantes de la

solucin tecnolgica a cotizar, bajo las condiciones y especificaciones tcnicas que
se describen en el presente documento.
Pgina 7 de 80
La Red Multiservicio, de la cual forma parte la troncal (backbone) objeto del

presente concurso,
constituye la Red Federal de Fibra ptica de
telecomunicaciones.
La tecnologa a presentar para la troncal de la red, debe permitir brindar una

arquitectura MPLS homognea. Es decir que, desde cualquier nodo de acceso (AN)
a cualquier otro, atravesando el backbone de la red, se debe tener tecnologa MPLS.
Para toda la red se definen tres tipos de nodos en donde se deber proveer distinto
tipo de equipamiento dependiendo su funcionalidad en la red:
Nodo Primario: es el que alojar equipamiento para cumplir el rol P, PE y

AN de la red. En algn caso podr incluir tambin equipamiento con rol SH,
IGW y/ L2.
Nodo Secundario: es el que inicia y/o finaliza un subtendido. Incluye
equipamiento de rol AN
Nodo Subtendido: es el que alojar equipamiento para cumplir el rol AN de
la red y/o equipamiento con rol L2.
A continuacin se definen cada uno de los roles:

Rol P: cualquier router o switch que soporta MPLS y corre el protocolo LDP (Label
Distribution Protocol) y es capaz de renviar paquetes basado sobre una etiqueta
impuesta. Este es requerido en el presente concurso.
Rol PE: cualquier router o switch que soporta MPLS y que corre el protocolo LDP e
impone etiquetas, anteponiendo una o ms de una al paquete IP, con el fin aplicar
un servicio a los paquetes de los clientes. Este es requerido en el presente
concurso. Este es requerido en el presente concurso.
Rol AN: es el primer y ultimo router o switch que procesa paquetes de cliente a
nivel de capa 2 o ms alto, emulando los servicios a nivel MPLS. Este no es
requerido en el presente concurso.
Rol L2: switch con funcionalidad L2 en referencia al modelo OSI.
Rol SH: equipamiento que habilita o escala el plano de control de servicio. Los SH
no reenvan datos de clientes. Ejemplos de SH seran los RR (Route Reflector) de
BGP (requerido en el presente concurso), dispositivos AAA, etc.
Rol IGW: equipamiento que procesa paquetes desde y hacia Internet. Este es
requerido en el presente concurso.
Rol SA: cualquier equipamiento que brinda servicio de acceso a las puertas de
consola seriales e interfaces de red de otros equipamientos por una red aparte a la
que brindar servicio IP/MPLS.
Rol NMS: software que permite el gerenciamiento de todos los elementos que
componen el presente concurso.
Pgina 8 de 80
No se admitir que un determinado equipamiento cumpla ms de un determinado

rol simultneamente [O]. Por ejemplo, equipamiento que cumple el rol P no puede
cumplir al mismo tiempo el rol PE.
Se definirn Clases de Servicio que se aplicaran en toda la red MPLS para las cuales
se definirn parmetros como ancho de banda, prioridad, latencia y jitter para cada
una de ellas.
5.1.
Arquitectura de referencia
En la figura 1, se muestra un esquema genrico de los principales roles de la red.

Los mismos debern tomarse como referencia, en los casos que sea necesario, para
la presentacin de la oferta.
TRONCAL MPLS
Nodo Primario N
Rol P
Nodo Primario Y
Rol P
Rol P
Rol P
Servicio 1 / Lambda X
ADM
Servic
Ser
v
io 5 /
icio
4/
Lamb
da
r
Se
cio
vi
am
/L
Se
cio
r vi
3/
aZ
bd
Lam
a
bd
Z
Nodo
Secundario X
Rol AN
ADM
DWDM
ACCESO
MPLS
Rol AN
Rol AN
Nodo Subtendido X
Rol PE
Lam
bda
Z
DWDM
Rol PE
bda Z
ADM
Rol PE
Servicio 4 / Lam
Rol PE
Ser
v
DWDM
5/
Lam
bd
aZ
Nodo Secundario Z
ADM
ADM
DWDM
DWDM
Rol AN
Rol AN
icio
Rol AN
Rol AN
Rol AN
Rol AN
Rol AN
Rol AN
Cliente C
Subtendido-Vinculo por par
de fibra 2
Cliente A
Cliente B
Cliente C
Cliente B
Cliente D
Cliente A
Vinculo por lambda de

DWDM en par de fibra 1
Figura 1
El detalle de la cantidad de sitios y equipamiento involucrado, se encuentra en el

Anexo II Lista de Sitios y Roles a Servir en Troncal del PET.
La ubicacin de los nodos primario, secundario y subtendido, corresponde con
localidades que se encuentran sobre la traza, o prxima a esta, La vinculacin entre
nodos primarios, y entre nodo primario y nodo secundario, se realiza por un par de
fibra ptica monomodo. Sobre este par de fibra se obtienen enlaces indicados como
servicio/lambda a partir de una plataforma DWDM (fibra coloreada). La vinculacin
de nodo secundario con nodo de subtendido, y entre nodos de subtendido, se lleva
Pgina 9 de 80
a cabo por medio de un segundo par de fibra monomodo, sin el soporte de una
plataforma DWDM (fibra oscura).
En la figura 2, se muestra un esquema a completarse en el transcurso del tiempo
de la troncal MPLS donde se incluye solo el ncleo con la ubicacin del
equipamiento con rol P, de los nodos primarios, a ofertar. Los vnculos indicados en
el esquema son provistos por una plataforma DWDM. Esta plataforma permite
proteger los vnculos que estn indicados en distintos colores.
Pgina 10 de 80
P
JUJUY
P
JUJUY
P
RESISTENCIA
P
TUCUMAN
P
POSADAS
P
SANTA FE
P
CORDOBA
P
ROSARIO
P1
BENAVIDEZ
P
MENDOZA
DATACENTER
INTERNET
P2
BENAVIDEZ
TDA
P
RODRIGUEZ
P
NEUQUEN
P
ABASTO
P
BAHIA BLANCA
P
CALETA OLIVIA
Vinculos
Protegidos por
Infraestructura
DWDM
Vinculos Sin
Proteccin
IGW
Tramo III
P
RIO GALLEGOS
Figura 2
Pgina 11 de 80
En la figura 3, se muestra un esquema de la troncal MPLS donde se incluye el

equipamiento con rol PE (agregacin/distribucin) a proveerse en los diferentes
nodos. Los vnculos indicados en el esquema son provistos por la plataforma
DWDM, sobre el mismo par de fibra que en la figura 2.
PE2
PE1
PE1
PE2
PE1
P
RESISTENCIA
P
JUJUY
P
POSADAS
PE2
PE1
PE2
P
SANTA FE
P
TUCUMAN
PE1
PE1
PE1
PE2
PE1
PE2
PE2
PE2
PE1 DC
P
ROSARIO
P
CORDOBA
PE2 DC
P
MENDOZA
DATACENTER
P
BENAVIDEZ
PE1
IGW1
PE2
IGW2
BGP RR
Mendoza
BGP RR
Benavidez
INTERNET
2
PE1 TDA
PE2 TDA
P
NEUQUEN
INTERNET
1
P
BAHIA BLANCA
TDA
P
ABASTO
P
RODRIGUEZ
PE1
PE1
PE2
PE1
PE2
PE1
PE2
PE2
P
CALETA OLIVIA
PE1
PE2
P
RIO GALLEGOS
PE1
PE2
Figura 3
Pgina 12 de 80
5.2.
Sitios a Conectar
Los nodos principales que formarn parte de la Troncal se encuentran detallados en

el Anexo II Lista de Sitios y Roles a Servir en Troncal del PET.
Existen previsiones de ampliacin de dicha Red a otros lugares y localidades, en el
mbito provincial, mediante etapas complementarias de este proyecto y que
formarn parte de otros procesos licitatorios o concursales. Adems, prev
conectarse con sistemas nacionales e internacionales de telecomunicaciones.
Aqu se describen las caractersticas mnimas que debe cumplir la solucin
tecnolgica a ofertar. Se propone un esquema y una plataforma que debe servir de
base a la presentacin de Ofertas del presente Concurso. Particularmente, la red a
proveer estar compuesta por quince (15) Nodos Primarios sobre una plataforma
de routing MPLS, enlazados formando una malla con vnculos de distinta capacidad
y proteccin donde se incluirn 16 (diecisis) equipos P, 32 (treinta y dos) equipos
PE, 2 (dos) equipos IGW y 2 (dos) equipos Route Reflector.
La eficiencia de funcionamiento de la red integral ser alcanzada por la mnima
necesidad de personal requerido para administrar la totalidad del sistema, de forma
centralizada. El soporte y mantenimiento de esta funcionalidad es parte integral de
esta contratacin, por lo que el Oferente deber prever las necesidades de
equipamiento y programas normalizados de administracin y gestin de la red.
La OBRA se entregar con todos los servicios funcionando que fueren necesarios.
La Contratista deber hacerse cargo de la realizacin de la documentacin ejecutiva
segn lo determinado en este documento.
5.3.
Descripcin de la Topologa de la Red
La red ser implementada en redes malladas pticas distribuidas en regiones. Cada

regin formar una red mallada compuesta por anillos pticos, de tal manera que
asegure mxima redundancia de conexin.
Es importante notar que la solucin est concebida por regiones, tanto desde el
punto de vista de trfico, de implementacin, proteccin y segurizacin.
Dada la vasta extensin de la red, el equipamiento ofrecido deber poder interoperar con redes construidas con equipos de otros fabricantes, el oferente deber
indicar las opciones de acoplamiento entre redes y garantizar su funcionalidad. [O]
5.3.1.
Arquitectura de la Red
La red, basada en tecnologa DWDM, cuenta con dos pares de pelos de FO en una
red mallada.
Para la red Core se utilizar un par de pelos de fibra ptica que vincularn los
nodos Primarios y Secundarios.
Pgina 13 de 80
Se utilizar el segundo par de pelos de fibra ptica para vincular los nodos del
subtendido de la red para la agregacin de trfico que actuar como tributario del
backbone de la red.
La topologa de la totalidad de la red, presenta un esquema jerrquico con tres
niveles.
A continuacin se presenta un esquema:
BACKBONE
CORE
PE
PE
AGREGACION/
DISTRIBUCION
PE
ACCESO
5.3.1.1.
AN
AN
AN
AN
Nivel Core
Se define as al nivel de transporte de largo alcance (LA), conformado por los Nodos
definidos como primarios y que actuarn como concentradores de trfico donde
tributar todo el trfico con destino Nacional e Internacional. Estos nodos adems
tendrn la funcionalidad de distribuir el trfico regional (equipamiento a instalar
debe cumplir el rol P).
El equipamiento a instalar en un nodo primario estar preparado para cursar el
siguiente tipo de trfico.
1. Trfico con otros nodos del Core.
2. Colectar trfico Local y regional
Pgina 14 de 80
3. Colectar y distribuir trfico de los nodos secundarios y sub-nodos.
El nodo primario Benavidez, tendr adicionalmente la gestin del trfico

internacional, de acceso a los servicios del Datacenter, y Televisin Digital Abierta
(TDA).
5.3.1.2.
Nivel de Agregacin/Distribucin
Est conformado en los Nodos Primarios, por medio del equipamiento de rol PE. El
equipamiento deber cursar el siguiente tipo de trfico.
1. Trfico con equipamiento con rol P.
2. Trfico con nodos de subtendido, a travs de nodos secundarios.
3. Colectar y distribuir trafico con el nivel de acceso.

5.3.1.3.
Nivel de Acceso
Est conformado por el equipamiento con rol AN, ubicados en los nodos de subtendido
Un nodo de subtendido estar preparado para cursar el siguiente tipo de trfico.
1. Trfico con nodos secundarios (Agregacin/Distribucin de trfico).
2. Colectar trfico Local.
3. Trfico con otros nodos de subtendido.
6. CARACTERISTICAS
REQUERIDAS
6.1.
TECNICAS
PRESTACIONES
Caractersticas Tcnicas
a. Los equipos que conforman un determinado rol, debern ser parte de una
sola familia de equipos con el fin de poder intercambiar placas y/o mdulos
entre ellos.[O]
b. La nueva red estar soportada en su totalidad bajo el protocolo TCP/IP
donde los equipos ser de naturaleza MPLS/IP [O]. Seguidamente se
detallan caractersticas generales que debern cumplir tanto los equipos
solicitado para el Backbone como aquellos de Acceso.
c. Se deber presentar un esquema general detallando los bloques
componentes del equipo propuesto en cada rol (procesador, matriz de
conmutacin, bus, placa de lnea, etc.), indicando la funcionalidad especfica
de cada uno de los mismos y su interrelacin. [O]
6.1.1.
Caractersticas Generales del Equipamiento
Las caractersticas detalladas a continuacin son de cumplimiento para todo el

equipamiento solicitado.
Pgina 15 de 80
A. Especificar el modelo de cada uno de los equipos propuestos para cada uno de
los roles.[O]
B. Se deber especificar y detallar si el equipo se basa en procesamiento
centralizado (placas especficas para procesar el trfico) o en procesamiento
distribuido (procesamiento en las placas de interfaz). [O].
C. El oferente deber presentar un diagrama general indicando las dimensiones
mecnicas de los equipos [O].
D. En la solucin presentada el oferente deber indicar detalladamente la versin
y relase de software del equipo como as tambin de cada uno de los mdulos
que lo integren. [O]
E. El oferente deber indicar la posicin en el equipo/bastidor de cada bloque de
funcionamiento; tarjeta sub-bastidor, etc.[O]
F. El oferente deber presentar las planillas de clculo de consumo elctrico y
disipacin trmica para cada uno de los equipos presentados de acuerdo a la
configuracin de hardware. [O]
G. El oferente deber indicar el consumo elctrico y disipacin trmica mxima
para cada uno de los equipos presentados. [O].
H. Se requiere como obligatorio [O] que los equipos P, PE, IGW y RR presentados
sean del tipo Carrier Class para alta disponibilidad.
I. Se requiere como obligatorio [O] que los equipos P, PE, IGW y RR presentados
soporten alimentacin de corriente continua de 48 volts, indicando la tolerancia
mnimas y mximas. Excepto en Nodo Benavidez.
J. El oferente deber describir adicionalmente las opciones de alimentacin
soportadas por los equipos P,PE, IGW y RR incluyendo sus respectivas
tolerancias [O]
K. El oferente deber detallar las condiciones ambientales de operacin de cada
equipo presentado [O].
L. El oferente deber indicar las caractersticas de temperatura, humedad y
estndares internacionales a los que responde [O]
6.1.2.
Capacidad de Conmutacin
Contestar por cada modelo de equipo propuesto.

El oferente deber describir detalladamente la capacidad de conmutacin del equipo
y de cada uno de los bloques que lo integre en bit/s (indicando el tamao del
paquete considerado) y pps1. La respuesta presentada debe habilitar la
identificacin de las distintas configuraciones del equipo y la capacidad de carga sin
llegar al estado de congestin [O]. Incluir:
I.
Tipo de procesamiento (centralizado o distribuido)
II.
Capacidad de matriz de conmutacin [Gbps]
III.
Capacidad de backplane, [Gbps]
IV.
Capacidad de conmutacin por slot, [Gbps]
V.
Capacidad de forwarding por chassis [Mpps]
VI.
Capacidad de forwarding por slot, [Mpps]
paquetes por segundo
Pgina 16 de 80
VII.
VIII.
IX.
X.
XI.
XII.
Cantidad mxima de puertos de 1 Gbps operando a velocidad de linea, full

duplex, con encapsulado ethernet. Adicionalmente,
indicar la misma
cantidad asumiento un rendimiento de cada puerto dado por datagramas IP
de 64 bytes con headers ethernet, 802.1q, y 1 label MPLS
indicar la misma
indicar la misma
duplex, con encapsulado Ethernet. Adicionalmente,
indicar la misma
de 64 bytes y 1 label MPLS
Los
valores
de
performance
expresados
debern
ser
validos
independientemente de las funcionalidades implementadas. El oferente
deber indicar los puntos de congestin del equipo para cada uno de los
bloques que lo integren.
El oferente deber indicar la posibilidad de expansin de la capacidad de
conmutacin mediante tecnologas de multi-chasis. En caso de contar con
dicha posibilidad, indicar los valores de capacidad de conmutacin logrados y
la configuracin del sistema resultante.
6.1.3.
Disponibilidad y Redundancia

a. El oferente deber indicar el MTBF del equipo y de cada uno de los
componentes presentados. [O].
b. El oferente deber especificar la posibilidad de redundancia de cada uno de
los bloques descriptos. [O].
c. El oferente deber indicar el proceso llevado a cabo en el equipo al fallar
cada uno de los distintos mdulos que poseen redundancia [O].
d. El oferente deber indicar para el punto c el impacto en los servicios
prestados por el equipo [O].
e. El oferente deber indicar para el punto c si existen mdulos que deben ser
reinicializados, en caso afirmativo deber detallar esos mdulos [O].
f.
El oferente deber indicar, en caso de re inicializacin de mdulos o corte de

servicio, para distintas condiciones (trfico, configuracin, hardware, etc.)
los tiempos tpicos de restablecimiento del servicio [O].
g. La plataforma deber soportar la insercin y remocin en servicio (hotswap) de los mdulos de interfaces de lnea, procesador central, fuentes de
alimentacin, matriz de conmutacin, o de cualquier modulo removible, sin
perdida de paquetes ni disrupcin del servicio. Detallar funcionamiento.[O]
h. La plataforma debe soportar actualizacin de software en servicio (ISSU).
Detallar funcionamiento. [O]
Pgina 17 de 80
6.2.
Requerimientos de rol PE, P,IGW y RR
A continuacin se detallan los requerimientos del equipo para las

funcionalidades de cada tipo de rol.
6.2.1.
Interfaces
Para cada tipo de interfaz y modelo de equipo propuesto (por jerarqua de rol tipo
P, PE, IGW y RR) segn aplique y se indique, se requiere responder punto a
punto:
a. El soporte de las interfaces requeridas.
b. El soporte de la cantidad mnima indicada de interfaces requeridas.
c. La cantidad mxima de interfaces soportadas por el equipo.
d. La cantidad mxima de VLANs (C-VLAN) activas que soporta cada una de las
interfaces.
e. la cantidad mxima de VLANs (S-VLAN) activas que soporta cada una de las
interfaces
f. La cantidad mxima de VLANs (C-VLAN) activas en combinacin con S-VLAN
activas que soporta cada una de las interfaces.
g. La cantidad mxima de direcciones MAC soportadas por interfaz/ slot. Detallar
que ocurre con el trfico cursado cuando las mismas alcanzan sus valores
mximos
h. La cantidad mxima de entradas ARP soportadas por interfaz, slot, chasis. Si se
asume que cada entrada de la tabla de ARP es una direccin MAC, este valor
debera coincidir con lo indicado en g
i.
Valor mximo de MTU configurable
j. El oferente deber especificar la modularidad para cada una de las interfaces

requeridas.
k. El oferente deber especificar la capacidad nominal con respecto al throughput
mximo de cada una de las interfaces requeridas en funcin de paquetes de 64,
128, 256, 512, 1024 y 1500 bytes, en el caso de ser inferior a la interfaz en
cuestin deber detallar dicha limitacin.
l.
El oferente deber especificar la capacidad nominal con respecto al

procesamiento de paquetes mximo de cada una de las interfaces en pps
(paquetes por segundo).
m. El oferente deber indicar el impacto en la performance en el caso de aplicar en

forma simultnea los servicios y funcionalidades requeridas en los puntos
6.3.2,6.2.3, y 6.2.4,. En el caso que se especifique algn tipo de impacto, el
mismo deber detallarse describiendo dicha limitacin.
n. El impacto en la performance del equipo equipado completamente con cada una
de las interfaces requeridas con distintos umbrales de carga, ej. 50%, 80% y
99%.
Pgina 18 de 80
o. El oferente deber indicar sobre la interoperabilidad de cada una de las

interfaces con la de otros fabricantes [O], incluyendo de equipamiento de
transporte.
ROL TIPO PE
6.2.1.1.
Ethernet
6.2.1.1.1.
Capa Fsica (Nivel 1 OSI)
El oferente deber responder punto a punto para cada una de las interfaces
mencionadas lo solicitado en el punto 6.2.1 e indicar las siguientes caractersticas:
-
Cantidad/combinacin de ports incluidos;

Transceivers que soporta (SFPs, XFPs, Xenpack, etc) ;
Tipo de interfaz (alcance) y conector usado (LC, SC, etc.);
Cantidad de colas para QoS;
para cada modelo de linecard que soporta las siguientes interfaces fsicas:
a. Gigabit Ethernet ptica (de acuerdo a IEEE 802.3z). Capacidad : 1 Gbps
operando en modo full duplex con frame Ethernet y VLANs (802.1q ) [O]
b. Fast y/o Gigabit Ethernet Synchronous (de acuerdo a G.8261)
c. 10Gigabit Ethernet ptica (de acuerdo a IEEE 802.3ae). Capacidad : 10
Gbps operando en modo full duplex con frame Ethernet y VLAN (802.1q ).
[O]
d. 40Gigabit Ethernet/100 Gigabitethernet (IEEE 802.3ba) Indicar
modulacin usada y alcances actuales segn corresponda. [O]
e. Indicar en todos los casos que corresponda los modelos de tarjetas que
provean combos de tipos de interfaces [O]
f.
Listar otros tipos de interfaces soportadas por el equipo indicando la

denominacin, nmero de parte y cantidad de puertos [O].
g. Indicar la cantidad de interfaces soportadas por el equipo ofertado [O].
Pgina 19 de 80
6.2.1.1.2.
Protocolo de Nivel 2
El oferente deber responder punto a punto el soporte de :

a) Ethernet (de acuerdo a IEEE802.3) [O]
b) VLANs (802.1q) [O]
c) Stacked VLAN ( Q-in-Q , segn 802.1ad) [O]
d) Link aggregation segn 802.3ad LACP mode. [O]
e) Link aggregation segn 802.3AX, LACP mode. [O]
f)
Jumboframe, indicando el mximo tamao de trama soportado [O]
g) Indicar la cantidad mxima de VLANs (S-VLAN) activas que soporta el chasis

h) Indicar la cantidad mxima de VLANs (C-VLAN) activas que soporta el chasis
i)
La cantidad mxima de VLANs (C-VLAN) activas en combinacin con S-VLAN

La combinacin esta dada por la cantidad de subinterfaces que soporta el
equipo.
j)
Indicar la Cantidad mxima de direcciones MAC que soporta cada chasis.

Detallar que ocurre con el trfico cursado cuando las mismas alcanzan sus
valores mximos.
6.2.1.2.
ATM
6.2.1.2.1.
mencionadas, lo solicitado en el punto 6.2.1
a. E3 elctrica (de acuerdo a: ITU-T G.703 y G.804)
b. TM-1 S1.1 1310nm ptica y elctrica (de acuerdo a: ITU-T G.957, ITU-T
G.783/G.958, ITU-T G.825 y ITU-T G.707).
6.2.1.2.2.

a. ATM UNI 3.1 y 4.0, de acuerdo a: ATM Forum
Pgina 20 de 80
6.2.1.3.
POS
6.2.1.3.1.
mencionadas lo solicitado en el punto 6.2.1.
a.
STM-1 S1.1
1310nm ptica [O] (de acuerdo a: ITU-T G.957, ITU-T
G.783/G.958, ITU-T G.825 y ITU-T G.707)
b. STM-1 L1.2
1550 nm ptica [O] (de acuerdo a: ITU-T G.957, ITU-T
G.783/G.958, ITU-T G.825 y ITU-T G.707)
c. STM-16 ptica S16.1 1310nm (de acuerdo a: ITU-T G.957, ITU-T G.783/G.958,
ITU-T G.825 y ITU-T G.707)
d. STM-16 ptica L16.2 1550nm (de acuerdo a: ITU-T G.957, ITU-T G.783/G.958,
ITU-T G.825 y ITU-T G.707)
6.2.1.3.2.

a. POS (Packet over SONET/SDH), de acuedo a: RFC 2615
b. PPP (Point to Point Protocol) de acuerdo a: RFC 1661
c. PPP in HDLC Framing, de acuerdo a: RFC 1662
d. HDLC Standard
6.2.1.4.
SDH Canalizadas
6.2.1.4.1.
mencionadas lo solicitado en el punto 6.2.1., el soporte de
a. E1 CH elctrica (de acuerdo a: ITU-T G.703)
b. E3 CH elctrica (de acuerdo a:
ITU-T G.703 , ITU-T 6.704)
c. STM-1 CH ptica y elctrica, canalizada en DS0, E1 y E3 (de acuerdo a: ITU-T

G.957, ITU-T G.783/G.958, ITU-T G.825, ITU-T G.703, ITU-T G.704 y ITU-T
G.707)
d. STM-4 CH ptica,, canalizada en DS0, E1 y E3 (de acuerdo a: ITU-T G.957, ITUT G.783/G.958, ITU-T G.825, ITU-T G.703, ITU-T G.704 y ITU-T G.707)
Pgina 21 de 80
6.2.1.4.2.

a. PPP (Point to Point Protocol) de acuerdo a: RFC 1661
b. PPP in HDLC Framing, de acuerdo a: RFC 1662
c. HDLC Standard
d. Compatibilidad con Cisco-HDLC
e. Frame Relay
f. Multilink PPP
g. Multilink Frame Relay
6.2.1.5.
OTRAS
Indicar el soporte de otro tipo de interfaces, respondiendo punto a punto para cada
una de las interfaces lo solicitado en el punto 6.2.1
ROL TIPO P e IGW
6.2.1.6.
ETHERNET
6.2.1.6.1.
mencionadas lo solicitado en el punto 6.2.1.
b. 10Gigabit Ethernet ptica (de acuerdo a IEEE 802.3ae). Capacidad : 10 Gbps
operando en modo full duplex con frame Ethernet y VLAN (802.1q ). [O]
c. 40Gigabit Ethernet/100 Gigabit ethernet (IEEE 802.3ba) Indicar modulacin
usada y alcances actuales segn corresponda. [O]
d. Indicar en todos los casos que corresponda los modelos de tarjetas que provean
combos de tipos de interfaces [O]
e. Listar otros tipos de interfaces soportadas por el equipo indicando la
denominacin, nmero de parte y cantidad de puertos [O].
f.
Indicar la cantidad de interfaces soportadas por el equipo ofertado [O].
Pgina 22 de 80
6.2.1.6.2.
El oferente deber responder punto a punto el soporte de:

a) Ethernet (de acuerdo a IEEE802.3) [O]
b) VLANs (802.1q)
c) Stacked VLAN ( Q-in-Q , segn 802.1ad)
d) Link aggregation segn 802.3ad LACP mode. [O]
e) Link aggregation segn 802.1AX, LACP mode. [O]
f)
Jumboframe, indicando el mximo tamao de trama soportado [O]
g) Indicar la cantidad mxima de VLANs (S-VLAN) activas que soporta el chasis

h) Indicar la cantidad mxima de VLANs (C-VLAN) activas que soporta el chasis
i)

La combinacin esta dada por la cantidad de subinterfaces que soporta el
equipo.
j)
Indicar la Cantidad mxima de direcciones MAC que soporta cada chasis.

valores mximos.
6.2.1.7.
IPoDWDM
6.2.1.7.1.
mencionadas lo solicitado en el punto 6.2.1
a. OC-768c/STM-256c, Tunable WDM POS, Line rate 42.8 Gbps, ITU G.709, FEC
Type: G.975.1 I.4, Online insertion and removal (OIR) without affecting system
traffic, Full C-band tunable laser, Configurable Tx optical power, Tx and Rx
optical power monitoring,
Indicar todos los rangos de potencia soportados, el rango de dispersin
cromtica, el rango de PMD, y el cdigo de modulacin de lnea empleado.
b. OC-192c/STM-64c, Tunable WDM POS, ITU G.709, FEC Type: G.975.1 I.4,
Online insertion and removal (OIR) without affecting system traffic, Full C-band
tunable laser, Configurable Tx optical power, Tx and Rx optical power
monitoring, Indicar todos los rangos de potencia soportados
c. OC-768c/STM-256c, POS, Line rate 42.8 Gbps, ITU G.709, Online insertion and
removal (OIR) without affecting system traffic. Indicar todos los rangos de
potencia soportados
d. OC-192c/STM-64c, POS, ITU G.709, Online insertion and removal (OIR)
without affecting system traffic. Indicar
todos
los rangos de potencia
soportados
6.2.1.7.2.

a. Packet over SONET/SDH (POS)
Pgina 23 de 80
b.
c.
d.
e.
RFC 1619/2615, Point-to-Point Protocol (PPP) over SONET/SDH

RFC 1662, PPP in High-Level Data Link Control (HDLC)-like framing
RFC 2615, PPP over SONET/SDH
HDLC
ROL TIPO RR
6.2.1.8.
ETHERNET
6.2.1.8.1.
mencionadas, lo solicitado en el punto 6.2.1.
b. 10Gigabit Ethernet ptica (de acuerdo a IEEE 802.3ae). Capacidad : 10 Gbps
operando en modo full duplex con frame Ethernet y VLAN (802.1q ). [O]
6.2.1.8.2.

a. Ethernet (de acuerdo a IEEE802.3) [O]
b. VLANs (802.1q y 802.1p) [O]
c. Stacked VLAN ( Q-in-Q , segn 802.1ad)
d. Link aggregation segn 802.3ad LACP mode. [O]
e.
f.
g.
h.
i.
Link aggregation segn 802.1AX, LACP mode. [O]

Jumboframe, indicando el mximo tamao de trama soportado
Indicar la cantidad mxima de VLANs (S-VLAN) activas que soporta el chasis
Indicar la cantidad mxima de VLANs (C-VLAN) activas que soporta el chasis
j. Indicar la Cantidad mxima de direcciones MAC que soporta cada chasis.
valores mximos.
Pgina 24 de 80
6.2.2.
Routing

En el caso que algunas normas se encuentren en estado Draft el oferente deber
garantizar su cumplimiento una vez estandarizadas las mismas. En el caso de las
normas que se hayan publicado en el IETF en carcter de RFC dentro de los
veinticuatro meses inmediatos anteriores a la fecha de publicacin del presente
concurso, y que el proveedor no la haya implementado an, se deber indicar
expresamente la fecha de cumplimiento prevista en su roadmap y el tipo de
compromiso asumido en el mismo.
El oferente deber responder para cada uno de los protocolos y funcionalidades
requeridas los siguientes puntos:
a. El soporte del protocolo de ruteo y funcionalidad.
b. Una descripcin detallada de la implementacin para cada protocolo de ruteo y
funcionalidad.
c. El impacto en la performance del equipo para cada protocolo de ruteo y
funcionalidad soportada como as tambin en la combinacin de los mismos, en
funcin de: CPU, memoria, otros recursos. Especificar
i. Recursos mnimos de memria requeridos para utilizar cada protocolo .
ii.
Recursos mnimos de uso del Procesador utilizados por cada protocolo
Pgina 25 de 80
d. Indicar la versin y release de software para cada una de los protocolos de

ruteo y funcionalidades
soportadas, en el caso que dicho protocolo y/o
funcionalidad se implemente en versiones futuras (en roadmap) indicar la
versin y su fecha comprometida de implementacin.
e. Especificar la relacin entre el hardware y dicha funcionalidad / protocolo de
ruteo, o sea, detallar si est soportada independientemente del hardware
implementado (interfaces, procesador, etc.).
f. Indicar si el equipo requiere hardware adicional (placa o modulo especfico) para
la implementacin de dicha funcionalidad / protocolo de ruteo, en este caso
describir detalladamente el hardware y software necesario.
g. Cantidad mxima de rutas soportadas para cada protocolo de ruteo
h. La cantidad de memoria utilizada en el procesador para el punto anterior.
i.
Cantidad mxima de instancias o procesos de ruteo soportadas en cada

protocolo
j. Una descripcin detallada que explique las razones de los lmites indicados o la
no aplicacin de la funcionalidad al rol del equipamiento en la topologa de red a
implementar.
6.2.2.1.
Protocolos de Ruteo Requeridos
a. Rutas Estticas para IPv4 [O]

b. Rutas estticas para IPv6 [O]
c. RIPv2 (Routing Information Protocol versin 2), de acuerdo a: RFC 2453[O].
Indicar el soporte de las siguientes funcionalidades:
i.
Autenticacin MD5 (RFC 2082)
ii. Autenticacin Criptogrfica (RFC 4822)

iii. Triggered extensions (RFC 2091)
iv. RIP for IPv6 (RIPng)(RFC 2080)
d. BGP (Border Gateway Protocol) [O], EBGP (Exterior Border Gateway Protocol)
[O], IBGP (Interior Border Gateway Protocol) [O], MP-BGP (Multiprotocol
Border Gateway Protocol) [O], de acuerdo a las siguientes RFC / drafts y
funcionalidades:
i. RFC 3107 Carrying label information in BGP-4 [O]
ii. RFC 1700 Assigned Numbers
iii. RFC 3232 Assigned Numbers
iv. RFC 4271 A Border Gateway Protocol 4 (BGP-4) [O]
v. RFC 1772 Application of the Border Gateway Protocol in the Internet [O]
vi. RFC 1997 BGP Communities Attribute
vii. RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option
viii. RFC 2439 BGP Route Flap Damping [O]
ix. RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
Routing
Pgina 26 de 80
x. RFC 4760 Multiprotocol Extensions for BGP-4 [O]

xi. RFC 2918 Route Refresh Capability for BGP-4
xii. RFC 5065 Autonomous System Confederations for BGP [O]
xiii. RFC 5492 Capabilities Advertisement with BGP-4
xiv.RFC 6286 Autonomous-System-Wide Unique BGP Identifier for BGP-4
xv. RFC 4360 BGP Extended Communities Attribute [O]
xvi.RFC 4456
BGP Route Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)[O]
xvii.
RFC 4724 Graceful Restart Mechanism for BGP [O]
xviii. RFC 4781 Graceful Restart Mechanism for BGP with MPLS [O]
xix. RFC 4893 BGP Support for 4-byte ASN.[O]
xx. Draft-rtgwg-bgp-pic-00 BGP Prefix Independent Convergence
e. OSPF (Open Shortest path First)[O], de acuerdo a las siguientes RFC / drafts y
funcionalidades:
i. RFC 1370 Applicability Statement for OSPF
ii.
RFC 2328 OSPF Version 2 [O]
iii.
RFC 2370 The OSPF Opaque LSA Option
iv.
RFC 5340 OSPF for IPv6 (OSPF v3) [O]
v.
RFC 3137 OSPF Stub Router Advertisement
vi.
RFC 3509 Alternative Implementations of OSPF Area Border Routers
vii.
RFC 3623 Graceful OSPF Restart [O]
viii. RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2.

ix.
RFC 5082 The Generalized TTL Security Mechanism (GTSM)
x.
RFC 3906 Calculating Interior Gateway Protocol (IGP) Routes OverTraffic

Engineering Tunnels
xi.
RFC 4124 Protocol Extensions for Support of Diffserv-aware MPLS
xii.
RFC 4136 OSPF Refresh and Flooding Reduction in Stable Topologies
xiii. RFC 4203
OSPF Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)

xiv. RFC 6001 Generalized MPLS (GMPLS) Protocol Extension for Multi-Layer
and Multi-Region Networks (MLN/MRN)
xv.
RFC 6002 Generalized MPLS (GMPLS) Data Channel Switching Capable

(DCSC) and Channel Set Label Extensions
xvi. RFC 4206 Label Switched Paths (LSP) Hierarchy with Generalized MultiProtocol Label Switching (GMPLS) Traffic Engineering (TE)
xvii. RFC 6107 Procedures for Dynamically Signaled Hierarchical Label
Switched Paths
Pgina 27 de 80
xviii. RFC 4552 Authentication/Confidentiality for OSPFv3 [O]

xix. RFC 4576 Using a Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)ownbit Extension
for L3VPN [O]
xx. RFC 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS
xxi. RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)[O]
xxii. RFC
4684
Constrained
Route
Distribution
for
Border
Gateway
Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP)

Virtual Private Networks (VPNs)
xxiii. RFC 5462 -Multiprotocol Label Switching (MPLS) Label Stack Entry "EXP"
Field Renamed to "Traffic Class" Field
xxiv. RFC 4750 OSPF Version 2 Management Information Base
xxv. RFC
4811
OSPF
Out-of-Band
Link
State
Database
(LSDB)
Resynchronization
xxvi. RFC 4812 OSPF Restart Signaling
xxvii. RFC 4813 OSPF Link-Local Signaling
xxviii. RFC 4970 Extensions to OSPF for Advertising Optional Router Capabilities
xxix. RFC 5088 OSPF protocol extensions for Path Computation Element
xxx. RFC 5185 OSPF Multi-Area Adjacency [O]
Indicar:
1. Cantidad mxima de adyacencias [O]
2. Cantidad mxima de entradas en DBase [O]
xxxi. RFC 5187 OSPFv3 Graceful Restart [O]
xxxii. RFC 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates
[O]
xxxiii. RFC 5329 Traffic Engineering Extensions to OSPF Version 3
xxxiv. RFC 5340 OSPF for IPv6 (OSPF v3) [O]
Indicar:
1. Cantidad mxima de adyacencias [O]
2. Cantidad mxima de entradas en LSDB[O]
xxxv. RFC 5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates [O]
f. IS-IS (Intermediate System to Intermediate System) [O], de acuerdo a:

i.
ISO 10589
ii.
RFC 1195 Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments
iii.
RFC 2474 Definition of the Differentiated Services Field (DS Field) in

the IPv4 and IPv6 Headers
iv.
RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP
Pgina 28 de 80
v.
RFC 4301 Security Architecture for the Internet Protocol
vi.
RFC 3260 New Terminology and Clarifications for Diffserv
vii.
RFC 6040 Tunnelling of Explicit Congestion Notification
viii.
RFC 5302 Domain-Wide Prefix Distribution with Two-Level IS-IS
ix.
x.
RFC 5304 IS-IS Cryptographic Authentication

RFC 6232 Purge Originator Identification TLV for IS-IS
xi.
RFC 6233 IS-IS Registry Extension for Purges
xii.
RFC 1142 OSI IS-IS Intra-domain Routing Protocol
xiii.
RFC
5286
Basic
Specification
for
IP
Fast
Reroute:
Loop-Free
Alternates [O]
g. Multicast Routing Protocol, de acuerdo a las siguientes RFC / drafts
funcionalidades:
i. Protocol Independent Source Specific Multicast (PIM-SSM)

a. RFC 4601 Protocol Independent
SM):Protocol Specification [O]
Multicast
Sparse
Mode
(PIM-
b. RFC 5796 Bootstrap Router (BSR) Mechanism for Protocol Independent

Multicast (PIM)
c. RFC 6226 Authentication and Confidentiality in Protocol Independent
Multicast Sparse Mode (PIM-SM) Link-Local Messages
ii. RFC 1112 Host extensions for IP multicasting (IGMP Version 1)
iii. RFC 3376 Internet Group Management Protocol, Version 3 [O]
iv. RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3)
and Multicast Listener Discovery Protocol Version 2 (MLDv2)for Source-Specific
Multicast
v. RFC 2236 Internet Group Management Protocol, Version 2
vi. RFC 2710 Multicast Listener Discovery (MLD) for IPv6 [O]
vii. RFC 3590 Source Address Selection for the Multicast Listener Discovery
(MLD) Protocol
viii. RFC 3446 Anycast Rendevous Point (RP) mechanism using PIM and MSDP
ix. RFC 3569 An Overview of Source-Specific Multicast (SSM)
x. RFC 3618 Multicast Source Discovery Protocol (MSDP)
xi. RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
xii. RFC 4607 Source-Specific Multicast for IP [O]
Pgina 29 de 80
xiii. RFC 5015 Bidirectional Protocol Independent Multicast (BIDIR-PIM)

h. Multicast in MPLS/BGP IP VPNs
(Se debera indicar la arquitectura e
implementacin recomendada por el proveedor).
A.
RFC 4605 Internet Group Management Protocol (IGMP) /Multicast Listener
Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")

B. RFC 4604 Using Internet Group Management Protocol Version 3 (IGMPv3)
and Multicast Listener Discovery Protocol Version 2 (MLDv2)
for SourceSpecific Multicast
C. RFC 4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements
D. RFC 5501 Requirements for Multicast Support in Virtual Private LAN
Services.
E. RFC 5294 Host Threats to Protocol Independent Multicast (PIM).
F.
RFC 4541 Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches

G.
H.
I.
J.
i.
IGMP report suppression.(especificar Implementacion)

IGMP proxy.
Mapeo de IGMPv2 a IGMPv3
Soporte de Multicast Inter- AS.(especificar Implementacin)
Performance y caractersticas en multicast, responder por cada punto:

a. Performance de forwarding de paquetes multicast
b. Impacto de la Replicacin de los paquetes multicast en la performance del
trfico unicast ,en especial en la latencia
c. Indicar cantidad mxima de rutas IPv4 Multicast sobre la tabla global. Cada
una asociada a una adyacencia de PIM establecida.
d. Indicar si las funcionalidades anteriores, estn basadas en software o
hardware y el impacto de CPU.
e. Indicar el mximo de rutas mcast para la MRIB, y el recomendado.
f.
Indicar escalabilidad desde el punto de vista de sealizacin, time-intervals y

distribucin de los trficos multicast para las soluciones requeridas.
g. Indicar la mxima tasa de Joins igmp concurrentes al chasis que puede

soportarse.
h. Indicar la mxima tasa de Joins igmp concurrentes a una interfaz que puede
soportarse.
i.
Indicar otros protocolos soportados tiles/necesarios para la solucin de los

escenarios.
j.
Indicar si el equipo soporta access-list u otro mecanismo para filtro de

grupos mcast.
k. Indicar si el equipo soporta access-list u otro mecanismo para filtro de igmp

joins
6.2.2.2.
Policy Routing
La funcionalidad consiste en la capacidad del equipo para el soporte de ruteo por

origen [O].
Pgina 30 de 80
6.2.2.2.1.
Funcionalidades Policy Routing
a. Describir detalladamente la implementacin de esta funcionalidad

b. Deber soportar el ruteo en base a los siguientes orgenes [O]:
i. Direccin IP
ii. Interfaz
iii. Interfaz lgica (VLAN, PVC, sesin PDP)
iv. Indicar el nmero mximo de instancias de Policy Routing que pueden ser
implementadas simultneamente
6.2.2.3.
Performance en IPv4
a. La cantidad mxima de entradas de tabla de forwarding IPv4.

b. La cantidad mxima de entradas de tablas de ruteo IPv4
c. La cantidad mxima de interfaces de red IPv4 por chasis
d. La cantidad mxima de interfaces de red IPv4 por placa
e. Indicar la cantidad de interfaces IPv4 lgicas mxima por chasis, la mxima
por slot y la mxima por puerto.
f.
Indicar la cantidad de prefijos Ipv4 sobre la tabla global.
6.2.2.4.
Protocolo IPv6
Se debern soportar las facilidades relacionadas a IPv6 de acuerdo a las siguientes

RFC / drafts y funcionalidades:
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
o.
p.
q.
r.
s.
t.
RFC 2460 Internet Protocol, Version 6 (IPv6) Specification .[O]

RFC 4291 IP Version 6 Addressing Architecture .[O]
RFC 5952 A Recommendation for IPv6 Address Text Representation
RFC 6052 IPv6 Addressing of IPv4/IPv6 Translators
RFC 4798. 6PE- IPv6 packets transported from PE to PE inside MPLS network
.[O]
RFC 4213-Basic Transition Mechanisms for IPv6 Hosts and Routers.[O]
RFC 4861 Neighbor Discovery for IP Version 6 (IPv6).[O]
RFC 4311 IPv6 Host-to-Router Load Sharing.
RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet
Prefixes
RFC 4862 IPv6 Stateless Address Autoconfiguration
RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification
RFC 4884 Extended ICMP to Support Multi-Part Messages
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks .[O]
RFC 6085 Address Mapping of IPv6 Multicast Packets on Ethernet
RFC 5095 Deprecation of Type 0 Routing Headers in IPv6
RFC 5722 Handling of Overlapping IPv6 Fragments
RFC 5871 IANA Allocation Guidelines for the IPv6 Routing Header
RFC 6437 IPv6 Flow Label Specification
RFC 6564 A Uniform Format for IPv6 Extension Headers
RFC 3046 DHCP Relay Agent Information Option.
Pgina 31 de 80
u. RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

v. RFC 4361 Node-specific Client Identifiers for Dynamic Host Configuration
Protocol Version Four (DHCPv4)
w. RFC 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP)
x. RFC 6221 Lightweight DHCPv6 Relay Agent
y. RFC 6422 Relay-Supplied DHCP Options
z. RFC 6642 Rebind Capability in DHCPv6 Reconfigure Messages
aa. RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses .
bb. RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
Address
cc. RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast Addresses
dd. RFC 3484 RFC 6724 Default Address Selection for Internet Protocol version 6.
ee. RFC 3587 IPv6 Global Unicast Address Format
ff. RFC 5643 Management Information Base for OSPFv3
gg. Posibilidad de establecer tneles (Ipv6 sobre Ipv4): Automatic 6to4 Tunnels y
Manually Configured IPv6 over IPv4 Tunnel
hh. Soporte de Access control list para IPv6 . [O]
ii. QoS (marcado/clasificacin/encolado) segn el modelo DIFFSERV [O].
jj. Multicast Address Family Support for Multiprotocol BGP para IPv6
kk. PIM Source-Specific Multicast (PIM-SSM)
ll. PIM Sparse Mode (PIM-SM)
mm.
Static Multicast Routing (mroute) for IPv6
nn. RFC 1981 Path MTU Discovery for IP version 6
oo. RFC 4659 6VPE (IPv6 packets transported from PE to PE inside VPN-MPLS
network).[O]
pp. RFC 2472 IP Version 6 over PPP .
qq. RFC 5072 IP Version 6 over PPP
rr. RFC 5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control
Protocol
ss. En forma adicional a los puntos anteriores, indicar el soporte de Ipv6 para
todas las funcionalidades de los equipos propuestos, en el caso que dicha
funcionalidad se encuentre en roadmap indicar su fecha de disponibilidad
comercial.
6.2.2.5.
Performance en IPv6
El oferente deber responder los siguientes puntos:

a. La cantidad mxima de entradas de tabla de forwarding IPv6. Describir que
factor impone el lmite.
b. La cantidad mxima de entradas de tablas de ruteo IPv6
c. La cantidad mxima de interfaces de red IPv6 por chasis
d. La cantidad mxima de interfaces de red IPv6 por placa
e. Cantidad mxima de prefijos VPNv6
6.2.2.6.
Otras Funcionalidades de routing
Detallar funcionalidades adicionales que soporta la solucin.
Pgina 32 de 80
6.2.3.
MPLS (MULTI PROTOCOL LABEL SWITCHING)

El soporte de dicha funcionalidad es de carcter obligatorio [O] donde se indique, y
su funcionamiento deber estar en un todo de acuerdo con las normas establecidas
por el IETF (segn la lista de RFC & drafts siguientes) y el MPLS Forum. En el caso
que algunas normas se encuentren en estado Draft el oferente deber garantizar
su cumplimiento una vez estandarizadas las mismas. En el caso de las normas que
se hayan publicado en el IETF en carcter de RFC dentro de los veinticuatro meses
inmediatos anteriores a la fecha de publicacin del presente concurso, y que el
proveedor no la haya implementado an, se deber indicar expresamente la fecha
de cumplimiento prevista en su roadmap y el tipo de compromiso asumido en el
mismo:
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
ix.
x.
xi.
xii.
xiii.
xiv.
xv.
xvi.
xvii.
xviii.
xix.
xx.
xxi.
xxii.
xxiii.
xxiv.
RFC 2205 Resource Reservation Protocol Version 1 Functional Specification.

[O]
RFC 3936 Procedures for Modifying the Resource reSerVation Protocol
(RSVP)
RFC 4495 A Resource Reservation Protocol (RSVP) Extension for the
Reduction of Bandwidth of a Reservation Flow
RFC 5946 Resource Reservation Protocol (RSVP) Extensions for PathTriggered RSVP Receiver Proxy
RFC 6437 IPv6 Flow Label Specification
RFC 2702 Requirements for Traffic Engineering Over MPLS ,
RFC 3031 Multiprotocol Label Switching Architecture [O],
RFC 6178 Label Edge Router Forwarding of IPv4 Option Packets
RFC 3032 MPLS Label Stack Encoding [O]
RFC 3037 LDP Applicability
RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 3936 Procedures for Modifying the Resource reSerVation Protocol
(RSVP)
RFC 4874 Exclude Routes - Extension to Resource ReserVation ProtocolTraffic Engineering (RSVP-TE)
RFC 5420 Encoding of Attributes for MPLS LSP Establishment Using Resource
Reservation Protocol Traffic Engineering (RSVP-TE)
RFC 6510 Resource Reservation Protocol (RSVP) Message Formats for Label
Switched Path (LSP) Attributes Objects
RFC 5711 Node Behavior upon Originating and Receiving Resource
Reservation Protocol (RSVP) Path Error Messages
RFC 3213 Applicability Statement for CR-LDP
RFC 3214 LSP Modification Using CR-LDP
RFC 3270 MPLS Support of Differentiated Services (E-LSP, L-LSP)
RFC 3443 Time To Live (TTL) Processing in MPLS Networks [O],
RFC 3468 Decision on MPLS Signaling Protocols
RFC 3469 Framework for Multi-Protocol Label Switching (MPLS)-based
Recovery
RFC 3471 Generalized Multi-Protocol Label Switching (GMPLS)
RFC 4328 Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Extensions for G.709 Optical Transport Networks Control
Pgina 33 de 80
xxv.
xxvi.
xxvii.
xxviii.
xxix.
xxx.
xxxi.
xxxii.
xxxiii.
xxxiv.
xxxv.
xxxvi.
xxxvii.
xxxviii.
xxxix.
xl.
xli.
xlii.
xliii.
xliv.
xlv.
xlvi.
xlvii.
xlviii.
xlix.
l.
li.
lii.
liii.
liv.
lv.
lvi.
lvii.
RFC 4872 RSVP-TE Extensions in Support of End-to-End. Generalized MultiProtocol Label Switching (GMPLS) Recovery
RFC 4873 GMPLS Segment Recovery
RFC 6003 Ethernet Traffic Parameters
RFC 6205 Generalized Labels for Lambda-Switch-Capable (LSC)Label
Switching Routers
RFC 3473 Generalized MPLS Signaling, RSVP-TE Extensions
RFC 4003 GMPLS Signaling Procedure for Egress Control
RFC 4783 GMPLS - Communication of Alarm Information
RFC 4873 GMPLS Segment Recovery
RFC 4874 Exclude Routes - Extension to Resource ReserVation ProtocolTraffic Engineering (RSVP-TE)
RFC 3478 Graceful Restart Mechanism for Label Distribution Protocol [O]
RFC 4974 Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in
Support of Calls
RFC 3479 Fault Tolerance for the Label Distribution Protocol (LDP)[O]
RFC 5786 Advertising a Router's Local Addresses in OSPF Traffic Engineering
(TE) Extensions
RFC 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS
Traffic Engineering Metric ( Support for TE and IGP Metrics for CSPF )
RFC3812 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
Management Information Base (MIB)
RFC3815 Definitions of Managed Objects for MPLS LDP [O].
RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels.
RFC 4125 Maximum Allocation Bandwidth Constraints Model forDiffservaware MPLS Traffic
RFC 4127 Russian Dolls Bandwidth Constraints Model for Diffservaware MPLS
Traffic Engineering.
RFC 4201 Link Bundling in MPLS Traffic Engineering (TE)
RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures (LSP PING y TRACEROUTE) [O]
RFC 6424 Mechanism for Performing Label Switched Path Ping (LSP Ping)
over MPLS Tunnels
RFC 6425 Detecting Data-Plane Failures in Point-to-Multipoint MPLS Extensions to LSP Ping
RFC 6426 MPLS On-Demand Connectivity Verification and Route Tracing
RFC 6427 MPLS Fault Management Operations, Administration, and
Maintenance (OAM) [O]
RFC 4905 Encapsulation Methods for Transport of Layer 2 Frames over MPLS
Networks
RFC4447 Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP) [O]
RFC 6073 Segmented Pseudowire
RFC 6723 Update of the Pseudowire Control-Word Negotiation Mechanism
RFC 4875 Extensions to Resource Reservation Protocol - Traffic Engineering
(RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)
RFC 4950 ICMP Extensions for Multiprotocol Label Switching [O],
RFC 5036 LDP Specification [O],
RFC 6720 The Generalized TTL Security Mechanism (GTSM) for the Label
Distribution Protocol (LDP)
Pgina 34 de 80
lviii.
lix.
lx.
RFC 5283 LDP Extension for Inter-Area Label Switched Paths (LSPs)
RFC 5332 MPLS Multicast Encapsulations [O]
RFC 5151 Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource
Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
RFC 5561 LDP Capabilities [O],
RFC 5654 Requirements of an MPLS Transport Profile
RFC 5586 MPLS Generic Associated Channel
RFC 6423 Using the Generic Associated Channel Label for Pseudowire in the
MPLS Transport Profile (MPLS-TP)
RFC 6388 Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths
RFC 5085 Pseudo Wire Virtual Circuit Connectivity Verification (VCCV). [O]
RFC 5884 Bidirectional Forwarding Detection (BFD) [O]
lxi.
lxii.
lxiii.
lxiv.
lxv.
lxvi.
lxvii.
El oferente deber argumentar de manera obligatoria cada uno de los

siguientes puntos:
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
l)
m)
n)
o)
Describir la implementacin de la funcionalidad. [O]

Soporte de encapsulamiento en Ethernet. [O]
Para el MPLS-LDP, indicar los distintos mtodos soportados. [O]
El equipo debe poder soportar la creacin manual de LSPs. [O]
Especificar el impacto en la performance del equipo actuando como edgeLSR, en funcin de: CPU, memoria, otros recursos. [O]
Especificar el impacto en la performance del equipo actuando como LSR, en
funcin de: CPU, memoria, otros recursos. [O]
Especificar el impacto en la performance del equipo actuando como LSR y
edge-LSR simultneamente, en funcin de: CPU, memoria, otros recursos.
[O]
Indicar La cantidad mxima de entradas de labels MPLS de forwarding.
Detallar el o los factores que imponen el limite. [O]
Indicar la cantidad mxima de entradas de labels MPLS. [O]
Indicar La cantidad mxima de MPLS LSPs.. Detallar el o los factores que
imponen el limite. [O]
Indicar los distintos protocolos de ruteo soportados dentro de la
funcionalidad de MPLS, garantizando y describiendo las extensiones de los
mismos de acuerdo a sus respectivas normas, siendo obligatorio el soporte
de: BGP, MP-BGP, OSPF. [O]
Soporte de MPLS-LDP [O]. Especificar los distintos mtodos soportados para
control (unordered, ordered), para distribucin (DU, DoD), para retencin
(Liberal, Conservative) [O]
Adicionalmente indicar otros protocolos soportados por el equipo (MPLSBGP, MPLS-RSVP-TUNNELS y MPLS-CR-LDP), incluyendo el cumplimiento de
las normas asociadas a cada uno de ellos. [O]
Indicar la versin y release de software para el soporte de dicha
funcionalidad. [O]
Especificar la relacin entre el hardware y dicha funcionalidad, o sea,
detallar si dicha funcionalidad esta soportada independientemente del
hardware implementado (interfaces, procesador, etc.). [O]
Pgina 35 de 80
p) Indicar La cantidad mxima de RSVP-TE LSPs. Mximo numero de LSP

(Head End), Mximo numero de LSP (Transit). Mximo numero de LSP
(Egress) [O]
q) Especificar la interoperabilidad con equipamiento de otros fabricantes. [O]
r) Indicar si el equipamiento soporta LSP Punto a Multipunto. [O]
6.2.4.
Funcionalidades
Contestar por cada modelo de equipo propuesto, salvo en los puntos donde se
indique expresamente lo contrario.
En el caso que algunas normas se encuentren en estado Draft el oferente deber
garantizar su cumplimiento una vez estandarizadas las mismas. En el caso de las
normas que se hayan publicado en el IETF en carcter de RFC dentro de los
veinticuatro meses inmediatos anteriores a la fecha de publicacin del presente
concurso, y que el proveedor no la haya implementado an, se deber indicar
expresamente la fecha de cumplimiento prevista en su roadmap y el tipo de
compromiso asumido en el mismo.
6.2.4.1.
Access List
a. Se deber soportar la aplicacin de listas de acceso que permitan la

identificacin del trfico de acuerdo a los siguientes parmetros incluyendo sus
combinaciones [O]:
i. IP origen
ii. IP destino,
iii. Protocolo
iv. Puerto
v. Precedencia / DSCP
b. Se deber soportar la aplicacin de listas de acceso que permitan la

identificacin del trfico de VoIP (Flujos RTP) iniciados por protocolos H.323,
SIP, MGCP, H.248.
c. Indicar y describir otros flujos que pueden ser identificados (ej. FTP Get / Put,
etc.)
d. Detallar todas las funcionalidades que pueden ser aplicadas a una lista de
acceso (permitir / denegar el flujo, aplicar polticas de QoS, etc.)
e. Indicar el nmero mximo de listas de acceso que pueden ser aplicadas a una
interfaz
f. Indicar el nmero mximo de listas de acceso que pueden ser aplicadas a una
sub-interfaz.
g. Indicar el nmero mximo de listas de acceso que pueden ser aplicadas por
placa o modulo de acceso.
h. Indicar el nmero mximo de listas de acceso que pueden ser aplicadas en el
equipo.
Pgina 36 de 80
i.
Especificar el impacto en la performance del equipo, placa e interfaz al procesar

el mximo nmero de listas de acceso soportadas, en funcin de: CPU,
memoria, otros recursos.
j. Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si

dicha funcionalidad esta soportada independientemente
implementado (interfaces, procesador, etc.).
6.2.4.2.
del
hardware
VPN-MPLS
Contestar para roles PE e IGW.

El soporte de dicha funcionalidad es de carcter obligatorio [O], y su
funcionamiento deber estar en un todo de acuerdo con las normas establecidas
por el IETF (segn las RFC requeridas en esta especificacin) y el MPLS Forum. En
el caso que algunas normas se encuentren en estado Draft el oferente deber
garantizar su cumplimiento una vez estandarizadas las mismas.
El oferente deber responder los siguientes puntos:
a) Describir la implementacin de dicha funcionalidad. [O]
b) Indicar el impacto en la performance del equipo, en funcin de: CPU,
memoria, otros recursos. [O]
c) Cantidad mxima de VPNs soportadas por el equipo[O]
d) Cantidad mxima de VRFs con QoS soportadas por el equipo[O]
e) Cantidad mxima de VRFs con QoS y mcast soportadas por el equipo[O]
f) Cantidad mxima de rutas soportadas en cada VPN. [O]
g) Una descripcin detallada que explique las razones de los lmites indicados.
[O]
h) Indicar los protocolos de ruteo soportados por la VPN, o sea, el protocolo
entre el CE (customer equipment) y el edge-LSR. Para estos protocolos
detallar el nmero mximo de instancias y rutas soportadas. [O]
i) Especificar los distintos mtodos de acceso a las VPNs-MPLS, indicando si
soporta el acceso desde cualquier interfaz o si presenta limitaciones al
respecto. Los siguientes mtodos de acceso son: Interfaces y sub-interfaces
(Ethernet). [O]
j) Indicar y detallar el soporte de que clientes de distintas VPNs puedan
acceder a una VPN compartida para obtener algn servicio en particular,
es decir que pueda existir una VPN que brinde servicios a otras VPN [O]
k) Detallar las funcionalidades asociadas a una VRF (ACL por VRF, NAT/PAT por
VRF, etc.). [O]
l) Especificar la relacin entre el hardware y dicha funcionalidad, o sea,
detallar si dicha funcionalidad esta soportada independientemente del
hardware implementado (interfaces, procesador, etc.). [O]
m) Indicar la versin y release de software para el soporte de dicha
funcionalidad. [O]
n) Especificar la interoperabilidad de dicha funcionalidad con equipamiento de
otro fabricante. [O]
o) Especificar el soporte de todo el conjunto de funcionalidades necesarias para
implementar el modelo InterAS VPN opcin A, B y C [O].
p) Se deber poder publicar o importar prefijos de tal manera de poder armar
topologas Hub-Spoke, Full Mesh [O]
Pgina 37 de 80
q) Se deber poder redistribuir dentro de la VPN-L3 prefijos publicados por

ruteo esttico, RIP, eBGP, OSPF, IS-IS. [O].
r) Se debe poder limitar el nmero de prefijos por cada VPN-L3 .[O]
s) Se deber poder realizar los peering de iBGP contra al menos dos equipos
Route Reflector (modalidad activo/standby).
6.2.4.2.1.
Gestin de VPN MPLS
El oferente deber indicar si posee un sistema de gestin propio o de terceros

que realice todas o alguna de las siguientes funcionalidades, indicando cuales:
a. Recoleccin de datos relacionados a MPLS-VPN del equipo propuesto junto a
otros equipamientos con soporte MPLS-VPN.
b. Procesamiento de los datos obtenidos segn el punto a, en forma centralizada.
c. Provisin en el equipo propuesto de la configuracin necesaria para implementar
el nuevo plan calculado en el punto b.
d. El oferente deber indicar las MIBs de MPLS-VPN con que cuenta el
equipamiento.
6.2.4.2.2.
Clase de Servicio y Calidad de Servicio
El soporte de QoS es de carcter obligatorio [O]. El oferente deber responder a

los siguientes puntos:
Contestar para Rol P, Rol PE, Rol IGW
a. Soporte de QoS (marcado, clasificacin, shaping, encolado) aplicado en
interfaces 10 GE y subinterfaz logica[O].
b. Soporte de QoS (marcado, clasificacin, shaping, encolado) aplicado en
interfaces 1 GE y subinterfaz lgica [O].
c. Soporte de QoS (marcado, clasificacin, shaping, encolado) aplicado en
d. Soporte de QoS (marcado, clasificacin, shaping, encolado) aplicado en
e. Soporte de colas de alta prioridad. Detallar cantidad de colas soportadas de este
tipo y su funcionamiento. Indicar la performance de diseo en trminos de
valores de latencia , jitter y descartes de paquetes de cada cola. [O].
f. Soporte de colas con
posibilidad de asignar un ancho de banda mnimo
garantizado en cada una, en condiciones de congeston. [O].
g. Posibilidad de re-utilizacin automtica del ancho de banda mnimo definido en
f. por una clase de servicio diferente a la asignada originalmente a la cola, ante
la ausencia de trafico de sta[O].
h. Posibilidad de asignar un limite superior de ancho de banda a cada cola [O].
i. Jerarqua de calidad de servicio ( Rol PE) [O].
j. Ancho de banda garantizado por C-VLAN y S-VLAN (jerarqua de shapping) [O]
k. Soporte de las funcionalidades de marcado, clasificacion, shaping, encolado por
cada subinterfaz lgica , utilizando un mnimo de 4 colas y 5 clases de servicio
[O]
l. Soporte de WRED en las clases de servicio
aplicadas a las interfaces y
subinterfaces en 100 GigabitEthernet [O]
Pgina 38 de 80
m. Soporte de WRED en las clases de servicio

n. Soporte de WRED en las clases de servicio
o. Soporte de WRED en las clases de servicio
p. Indicar el soporte de WRED en las clases de servicio aplicadas a todas las
intefaces y subinterfaces soportadas
q. Indicar el soporte de Mapeo entre CoS de nivel 2 a DSCP de nivel 3.
r. Indicar el soporte de Mapeo entre DSCP de nivel 3 a CoS de nivel 2.
s. Indicar el soporte de Mapeo entre DSCP de nivel 3 a MPLS EXP. Indicar las
formas de mapeo.
t. Indicar el soporte de Mapeo entre COS de nivel 2 a MPLS EXP. Indicar las
formas de mapeo
u. Describir detalladamente la implementacin de dichas funcionalidades a nivel
plano y para vpn. Describir el funcionamiento por hop.
v. Describir los distintos mecanismos soportados para el manejo de CoS/QoS
implementados.
w. Describir si es posible asignar anchos de banda equitativamente o asignando
pesos entre n usuarios discriminados por IP que se encuentren compartiendo un
mismo vnculo.
x. Describir detalladamente los procesos de: clasificacin, marcado, encolamiento
y scheduling.
y. Describir el manejo de las colas dentro del equipo.
z. Indicar si el equipo soporta asignar colas por:
1. Interfaz fsica
2. Interfaz lgica
3. Placa
4. Chasis
aa. Indicar la cantidad de colas que soporta el equipo por:
1. Interfaz fsica
2. Interfaz lgica
3. Placa
4. Chasis
bb. Indicar si existe alguna limitacin en trminos de escalabilidad entre la cantidad
de colas y la cantidad de sub interfaces, por puerto, por slot, por chasis
cc. Especificar el impacto en la performance del equipo para cada uno de los
mecanismos empleados y para su combinacin, en funcin de: CPU, memoria,
otros recursos.
dd. Especificar si dichas funcionalidades estn implementadas en hardware o en
software.
ee. Indicar la versin y release de software para el soporte de dicha funcionalidad
(por cada mecanismo descripto. En el caso que algunos componentes de dicha
funcionalidad se implementen en versiones futuras (en roadmap) indicar la
versin y su fecha de implementacin.
ff. Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si
dicha funcionalidad (por cada mecanismo descripto) esta soportada
independientemente del hardware implementado (interfaces, procesador, etc.)
gg. Especificar la interoperabilidad de dicha funcionalidad (por cada mecanismo
descripto) con equipamiento de otros fabricantes.
Pgina 39 de 80
6.2.4.3.
DiffServ
El soporte de dicha funcionalidad es de carcter obligatorio [O]. La

implementacin de dicha funcionalidad deber estar en todo de acuerdo a las
normas establecidas por el IETF (RFC 2474, RFC 2475, RFC 2597, RFC 2598,
RFC 3246, RFC 3260). En el caso que algunas normas se encuentren en estado
Draft el oferente deber garantizar su cumplimiento una vez estandarizadas
las mismas. El oferente deber responder a los siguientes puntos:
a. Describir detalladamente la implementacin de dicha funcionalidad.
b. Especificar el impacto en la performance del equipo, en funcin de: CPU,
c. Especificar si dichas funcionalidades estn implementadas en hardware o en
software.
d. Indicar la versin y release de software para el soporte de dicha funcionalidad,
en el caso que dicha funcionalidad se implemente en versiones futuras (en
roadmap) indicar la versin y su fecha de implementacin.
e. Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si
dicha funcionalidad esta soportada independientemente del hardware
implementado (interfaces, procesador, etc.)
f. Especificar la interoperabilidad de dicha funcionalidad con la equipamiento de
otros fabricantes.
6.2.4.4.
DiffServ MPLS
El soporte de dicha funcionalidad es de carcter obligatorio [O]. La implementacin

de dicha funcionalidad deber estar en todo de acuerdo a las normas establecidas
por el IETF (RFC 3270, RFC 5462). El oferente deber responder a los siguientes
puntos:
Pgina 40 de 80
a. Describir detalladamente la implementacin de dicha funcionalidad, indicando

las modalidades soportadas.
b. Describir los distintos mecanismos utilizados para su implementacin.
c. Especificar el impacto en la performance del equipo, en funcin de: CPU,
d. Especificar si dichas funcionalidades estn implementadas en hardware o en
software.
e. Indicar la versin y release de software para el soporte de dicha funcionalidad.
f. Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si
g. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros
fabricantes
6.2.4.4.1.
DiffServ-aware MPLS Traffic Engineering
El soporte de dicha funcionalidad es de carcter obligatorio . La implementacin de

dicha funcionalidad deber estar en todo de acuerdo a las normas establecidas por
el IETF (RFC 4124). El oferente deber responder a los siguientes puntos:
a. Describir detalladamente la implementacin de dicha funcionalidad, indicando
las modalidades soportadas.
b. Describir los distintos mecanismos utilizados para su implementacin.
c. Especificar el impacto en la performance del equipo, en funcin de: CPU,
d. Especificar si dichas funcionalidades estn implementadas en hardware o en
software.
e. Indicar la versin y release de software para el soporte de dicha funcionalidad.
f. Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si
g. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros
fabricantes.
h. Indicar el soporte,
recomendados.
describir
la
implementacin
casos
de
aplicacin
Pgina 41 de 80
6.2.4.4.2.
Mtodos de clasificacin
La funcionalidad consiste en los distintos mtodos de clasificacin de trfico

soportados. El soporte de dicha funcionalidad es obligatorio [O]. El oferente
deber responder a los siguientes puntos:
a. Describir detalladamente la implementacin de dicha funcionalidad.
b. Especificar los distintos mecanismos utilizados para su implementacin
c. Soporte de clasificacin por DiffServ. [O]
d. Soporte de clasificacin por direccin IP. [O]
e. Soporte de clasificacin por puerto fsico (interfaz). [O]
f. Soporte de clasificacin por puerto lgico (sub-interfaz, VLANs, etc.). [O]
g. Clasificacin mediante el uso de 802.1p.
h. Soporte de clasificacin por tipo de protocolo, describir los soportados.
i.
Soporte de reclasificacin, consiste por ejemplo: en recibir un flujo clasificado

por DiffServ o 802.1p y reclasificarlo. [O]
j. Indicar y describir la cantidad mxima de reglas que soporta por interfaz.

k. Especificar el impacto en la performance del equipo para cada uno de los
mtodos empleados y para su combinacin, en funcin de: CPU, memoria, otros
recursos.
l.
Indicar la versin y release de software para el soporte de dicha funcionalidad,

en el caso que algunos componentes de dicha funcionalidad se implementen en
versiones futuras (en roadmap) indicar la versin y su fecha de implementacin.
m. Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si

6.2.4.5.
Alta disponibilidad
Consiste en un conjunto de
distintas funcionalidades que se detallan a
continuacin. El oferente deber responder si cumple con el soporte, describir la
implementacin e indicar los limites de escalabilidad:
a. Non-Stop Forwarding (NSF)
i.
OSPF [O]
ii. BGP [O]

iii. LDP [O]
iv. Multicast[O]
v. IS-IS
vi. RSVP
b.
c.
d.
e.
f.
g.
Stateful Switchover (SSO) [O]

OSPF Graceful Restart [O]
BGP Graceful Restart [O]
LDP Graceful Restart [O]
OSPF Fast Convergence. [O]
MP-iBGP Graceful Restart [O]
Pgina 42 de 80
h. Proteccion de sesiones de protocolos de routing para mantenerlas

activas ante fallas de procesador central [O]y fuentes de energa[O]
i. Bidirectional Forwarding Detection (BFD), en las siguientes modalidades:
i.
BFD para OSPF [O]
ii. BFD para BGP [O]

iii. BFD para LDP [O]
iv. BFD for IPv4 and IPv6 (Single Hop)[O]; RFC 5881.
v. Cantidad de sesiones BFD maxima por tarjeta de lnea
xv. Cantidad de sesiones BFD maxima por chasis.Limitado al numero de
linecard del chassis.
j. Sincronismo entre LDP y OSPF [O]
k. Proteccion de sesiones routing para mantenerlas activas ante fallas de
puerto de linea / modulo de lnea
l.
Sistema Operativo modular
m. In-Service Software Upgrade. Detallar modalidades de actualizacin del

sistema operativo sin interrupcin del servicio ( Rol P, PE e IGW).
n. Herramientas de troubleshooting de MPLS : MPLS OAM (LSP ping/
Traceroute)
o. Non-Stop routing (NSR)
i. OSPF [O]
ii. BGP [O]
iii. LDP [O]
iv. Multicast [O]
Adicionalmente, el oferente deber responder al siguiente punto:
-
Indicar si poseen roadmap o cumplen el soporte de RFC 5885, Bidirectional

Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV), RFC 6478, Pseudowire Status for Static Pseudowires
6.2.4.6.
Traffic Engineering
El oferente deber responder a los siguientes puntos:

a. Describir la implementacin de dicha funcionalidad.
b. Indicar la versin y release de software para el soporte de dicha funcionalidad,
c. Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si
d. Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros
fabricantes
e. Especificar los protocolos IGP-TE que soporta el equipo, junto a los atributos que
el equipo es capaz de propagar de los LSPs correspondientes, por este medio.
Pgina 43 de 80
f. Especificar si el equipo posee algoritmo de CBR (Constraint Base Routing),

indicando a que RFC y/o draft del organismo IETF responde.
g. Especificar si el equipo soporta tuneles MPLS-TE en subinterfases dot1q.
h. Indicar que tipo de sealizacin para la creacin y mantenimiento de tneles
MPLS-TE utiliza el equipo ( RSVP-TE, CR-LDP
i. Indicar si esta funcionalidad responde a otros drafts publicados en la
organizacin IETF, indicando el/los nombre/s del/de los mismo/s.
j. El impacto en la performance del equipo actuando como edge-LSR, en funcin
de: CPU, memoria, otros recursos.
k. El impacto en la performance del equipo actuando como LSR, en funcin de:
CPU, memoria, otros recursos.
l. El impacto en la performance del equipo actuando como edge-LSR (tnnel headend, tnnel tail-end) y LSR (transit tunnel) simultneamente, en funcin de:
CPU, memoria, otros recursos.
6.2.4.6.1.
Traffic Engineering Fast Re Route (TE-FRR)
El oferente deber responder a los siguientes puntos:

a. Describir la implementacin en sus tres modalidades: link/node/Shared Risk
Link Group
b. Tiempo de restauracin medio
c. Cantidad mxima de tuneles de backup admitidos por cada instancia a
proteger
d. Cantidad mxima de tuneles de backup admitidos por el equipo
e. Describir los mtodos de troubleshoting y OAM asociados
f.
Indicar el soporte de RFC 4561 Definition of a Record Route Object (RRO)

Node-Id Sub-Object
g. Indicar el soporte de RFC 6445 Multiprotocol Label Switching (MPLS) Traffic

Engineering Management Information Base for Fast Reroute
6.2.4.6.2.
PWE3 (Pseudo-Wire Emulation Edge-to-Edge)
De acuerdo a las descripciones de los manifiestos RFC 4664 y RFC 4665, el oferente
debera responder sobre PWE3 acorde al marco establecido en estas dos RFC. La
funcionalidad consiste en la emulacin de circuitos (ATM, FR, Ethernet, TDM, etc.)
end to end a travs de la red IP-MPLS . El soporte de dicha funcionalidad es de
carcter obligatorio [O], y su funcionamiento deber estar en un todo de acuerdo
con las normas establecidas por el IETF (segn la lista de RFCs siguientes) y el
MPLS Forum. En el caso que algunas normas se encuentren en estado Draft el
oferente deber garantizar su cumplimiento una vez estandarizadas las mismas
i. RFC 3985 - Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture. [O]

ii. RFC 4385 Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
over an MPLS PSN
iii. RFC 4446 - IANA Allocations for Pseudowire Edge to Edge Emulation (PWE)
para Pseudowired tipo 0x04 (Ethernet Tagged Mode) y Pseudowired tipo 0x05
(Ethernet Raw Mode) [O]
Pgina 44 de 80
iv. RFC 4447 Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)[O]
v. RFC 4448 Encapsulation Methods for Transport of Ethernet over MPLS
Networks [O]
vi. RFC 4717 Encapsulation Methods for Transport of Asynchronous Transfer Mode
(ATM) over MPLS Networks
vii. RFC 4816 Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer
Mode (ATM) Transparent Cell Transport Service.
viii.RFC 5254 Requirements for Multi-Segment Pseudowire Emulation Edge-toEdge
ix. RFC 4619
Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks
x. RFC 4906 Transport of Layer 2 Frames Over MPLS
xi. RFC 5659 An Architecture for Multi-Segment Pseudowire Emulation Edge-toEdge
xii. RFC 5086 Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
Service over Packet Switched Network (CESoPSN)
xiii.RFC 4553 Structure-Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)
xiv. RFC 6310 Pseudowire (PW) Operations, Administration, and Maintenance
(OAM)
xv. RFC 6718 Pseudowire Redundancy. [O]
xvi. draft-IETF-PWE3-REDUNDANCY-BIT - Preferential Forwarding Status bit
definition [O]
El oferente deber responder respecto al equipamiento propuesto , en los

siguientes puntos:
Describir detalladamente la implementacin de dicha funcionalidad, indicando
las normas y/o drafts conformes en su implementacin.
Indicar y detallar las distintas encapsulaciones de capa 2 soportadas
(particularmente ethernet) para el transporte sobre MPLS.
Indicar y detallar el soporte de ethernet Q -in- Q sobre PWE3
El impacto en la performance del equipo, en funcin de: CPU, memoria, otros
recursos.
Indicar la versin y release de software para el soporte de dicha funcionalidad,
Especificar la relacin entre el hardware y dicha funcionalidad, o sea, detallar si
Indicar la cantidad de PWE3 soportados por placa y por chasis
Indicar el soporte de modo los modos de transporte Ethernet Raw Mode

Ethernet Tagged Mode de acuerdo a RFC 4448
Asignacin manual de VC Labels .
Para los tipos PWE Encapsulation tipo 4 y tipo 5 [RFC 4446]; Indicar las
cantidades mximas admisibles de acuerdo a las siguientes combinaciones :
1. Un AC a un Pseudowire. Indicar cantidad mxima de pares AC-PW.
Pgina 45 de 80
2. n AC a un Pseudowire. Indicar cantidad mxima de AC.

3. Un AC a varios Pseudowire. Indicar cantidad mxima de PW.
Indicar la cantidad mxima de PWE soportada por Chasis/ Slot / Ports segn
corresponda. Indicar de (Considerar el numero en forma bidireccional),tambien
describir todos los recursos lgicos que se deben tener en cuenta para realizar
la emulacin de un servicio E-Line sea provisionado localmente o involucre
equipos remotos :
1.
2.
3.
4.
PW Raw Mode
PW Tagged Mode
Attachtment Circuits
Otros
Especificar la interoperabilidad de dicha funcionalidad con equipamiento de otros

fabricantes.
6.2.4.6.3.
VPLS
La funcionalidad consiste en la emulacin de Servicios Ethernet point-to-multipoint,

multipoint-to-multipoint, end to end a travs de una red MPLS .La arquitectura para
proveer la emulacin de los servicios deber estar de acuerdo a la RFC 4762 o RFC
4761, RFC 5462 de acuerdo a la implementacion elegida por el proveedor. Dado
que la emulacin esta orientado al transporte de Ethernet se deber tener en
cuenta las particularidades definidas en RFC 4448 (EoMPLS) para el full mesh de
PEs interviniendo en la VPLS. Para el caso de la sealizacin se debera tener en
cuenta las especificaciones de RFC 4447, RFC 5036 (LDP) y RFC 4760 (BGP).
De acuerdo a lo antes mencionado responder cada uno de los siguientes puntos

incluyendo en el caso que corresponda las recomendaciones y/o drafts
asociados:
Soporte de la arquitectura VPLS [O] .Describir detalladamente la
implementacin de dicha funcionalidad.
LDP RFC 4762 Virtual Private LAN Services using LDP signaling [O]
BGP RFC 4761 BGP Autodiscovery and Signaling for VPLS.
Otros
Indicar los protocolos soportados y el utilizado en la solucin para realizar el
proceso Discovery de los PE Remotos
Indicar la cantidad mxima de Instancias de Switching (Services Instantes,
Bridge Domain, etc) soportadas por Chasis, funcionando en modo Qualified y
Unqualified, ,el numero especificado debe considerar VPLS de al menos 2 peer
(Nro. de PEs=3):
Mximo numero de VPLS Qualified Mode
Mximo numero de VPLS Unqualified Mode
Para el caso del punto anterior indicar los recursos lgicos a tener en cuenta
para determinar las escalabilidad de los mismos (VSI, PWEs para full mesh,etc)
Indicar la cantidad mxima de MACs que puede aprender cada instancia de
Switching (VSI, Bridge Domain, etc).
Indicar el nmero mximo de peer remotos que pueden establecerse por
Instancia VPLS .Tener en cuenta el numero definido en c
Indicar el numero mximo de puntos de acceso por VPLS si corresponde
Pgina 46 de 80
Indicar el soporte para que Link Aggregation Groups puedan conectarse como
puntos de acceso de una VPLS.
Indicar el soporte de Flooding BPDU (SPT, RSPT ,etc) dentro de una VPLS
Indicar el soporte de un mecanismo para configurar una mxima utilizacin de
CPU para el proceso de VPLS.
Indicar el soporte de uno o varios LSP backups al LSP primario que se utiliza
para realizar el peer entre dos PE pertenecientes a las misma VPLS. Detallar el
funcionamiento y el numero de LSP backup soportados y si se le pueden
asignar diferentes prioridades ante un eventual switchover.
Para el caso del punto anterior en el caso de soportarlo, indicar si se puede
realizar LSP Load Balancing entre los LSP pertenecientes a al VPLS peer.Indicar
funcionamiento y en base a que campo se realizar el balanceo
(UDP/TCP,IP,MAC,etc).
Indicar el soporte de un mecanismo para realizar MAC limit.
a. Por VPLS
b. Por port de acceso a VPLS
Indicar el soporte de un mecanismo para controlar el trafico de Brodcast,
Multicast, Unknowk- Unicast packet Limit por VPLS.
Indicar el soporte de modificacion de MAC-ADDRESS Aging y el rango de tiempo
soportado
Indicar y explicar que mecanismo provee la solucin para evitar la duplicacin
de MAC ADDRESS dentro de una instancia VPLS.
Para poder obtener un mejor control del flooding de frames dentro de la VPLS,
indicar el soporte de Split Horizont configurable :
a. Por puerto fsico
b. Por subinterfaz lgica
c. Por Vlan
d. Por Bundle de Vlans
6.2.4.6.4.
Path MTU Discovery
Su funcionamiento deber estar en un todo de acuerdo con las normas establecidas

por el IETF ( segn la lista de RFC siguiente) y el MPLS Forum. En el caso que
algunas normas se encuentren en estado Draft el oferente deber garantizar su
cumplimiento una vez estandarizadas las mismas. De acuerdo a lo antes
mencionado indicar si la implementacin esta de acuerdo
las siguientes
recomendaciones y/o drafts:
a.
RFC 1191
Pgina 47 de 80
6.2.4.6.5.
Virtual Router Redundancy Protocol (VRRP)
Contestar para rol PE, AN

Su funcionamiento deber estar en un todo de acuerdo con las normas establecidas
por el IETF (segn la lista de RFC siguiente) y el MPLS Forum. En el caso que
algunas normas se encuentren en estado Draft el oferente deber garantizar su
cumplimiento una vez estandarizadas las mismas. De acuerdo a lo antes
mencionado indicar si la implementacin esta de acuerdo a las siguientes
recomendaciones y/o drafts:
RFC 5798 [O]
VRRP support for MPLS VPNs [O]
Funcionalidades de rpida convergencia de VRRP.
Indicar el numero de instancias y,o grupos VRRP soportadas por puerto fisco,
por subinterfaz logica, por slot, por chassis [O]
6.2.4.6.6.
Router Virtual
Contestar para rol PE.

Describir e indicar el soporte de cada uno de los siguientes puntos
a. Soporte de mltiples instancias de router virtual en un mismo equipo,
separadas lgicamente. Detallar como se realiza la implementacin.
b. Indicar cual es la cantidad mxima de rutas que se pueden almacenar en
cada tabla de routing de router virtual
c. Indicar si hay alguna limitacin en el tipo y cantidad de interfaces fsicas y
lgicas que se pueden asociar y referenciar a cada router virtual.
d. Indicar si existe alguna limitacin en relacin a los protocolos de ruteo que
se pueden asociar y referenciar a las rutas de cada tabla de routing del
router virtual.
e. Indicar cual es la relacin ente las instancias de router virtual y la cantidad
de memoria que debe tener el equipo. Indicar si se requiere memoria
adicional al equipamiento presentado en el item: Descripcin de equipos.
f. Indicar impacto en la performance del equipo, en funcin de: CPU, memoria,
otros recursos.
g. Especificar, en caso de existir, mecanismos para el ruteo del trfico
internamente entre routers virtuales (como por ejemplo: virtual interface,
ruteo por polticas, etc.).
6.2.4.6.7.
Tunneling

El equipamiento deber soportar los siguientes tipos de tneles:
a.
b.
c.
d.
GRE, Generic Routing Encapsulation, segun RFC 2784, RFC 2890

Generic Routing Encapsulation (GRE) Tunnel Keepalive
L2TPv2 RFC 2661 Layer Two Tunneling Protocol
L2TPv3 RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3)
Pgina 48 de 80
De acuerdo a lo antes mencionado ,por cada funcionalidad de tnel requerida,

describir e indicar el soporte de cada uno de los siguientes puntos:
i.
La capacidad del equipo propuesto para lograr la generacin y/o terminacin

de tneles).
ii. Describir la implementacin de la funcionalidad.
iii. Especificar el impacto en la performance del equipo para cada uno de los
mecanismos empleados y para su combinacin, en funcin de: CPU,
iv. Indicar la cantidad mxima de tneles en forma simultanea, que soporta el
equipo propuesto. Indicar en que condiciones se detalla tal caracterstica.
v. Indicar la cantidad mxima de tneles que puede generar y/o terminar el
equipo por unidad de tiempo (medido en segundos), y el throughput de
datos soportado por cada tnel.
vi. Especificar la existencia o no, de mecanismos para limitar el nmero de
tneles admitidos por el equipo. En caso de existir describirlos
detalladamente.
vii. Especificar, en caso de no existir mecanismo de control que sucede con el
equipo superado el nmero mximo de tneles soportados.
viii. Indicar la versin (release) de software para el protocolo en cuestin en
caso que el mismo fuera implementado en versiones futuras (en hoja de
ruta o roadmap); se deber indicar la versin correspondiente y su fecha
comprometida de implementacin.
ix. En caso que aplique, indicar la existencia de limitaciones entre el hardware
presentado (interfaces, procesador, etc.) y dicha funcionalidad.
6.2.4.6.8.
Tunneling y encripcin de datos mediante IPSEC
A continuacin se detallan los aspectos requeridos sobre IPSec para los equipos
propuestos. Se deber responder punto a punto lo siguiente:
a. La capacidad del equipo propuesto para lograr la generacin y/o terminacin
de tneles IPSec, debiendo este ser compatible con las normas establecidas
por el IETF (RFC 4301, 4302, 4835, 2403, 2404, 2405, 4303, 4835, 5282,
5996, 5998, 4109,2451 y 6040).
b. Describir la implementacin de la funcionalidad de encripcin.
c. Describir para cada equipo propuesto, las modalidades de manejo de llaves
o claves de seguridad soportadas.
d. Indicar la compatibilidad con algoritmos de encripcin DES. Indicar la
compatibilidad con equipos de otros fabricantes.
e. Indicar la compatibilidad con algoritmos de encripcin 3DES (Triple DES) con
longitud de clave de 168 bits. Indicar la compatibilidad con equipos de otros
fabricantes.
f. Indicar la compatibilidad con algoritmos de encripcin AES (Advanced
Encription Standard segn RFC 5246, 5746, 5878, 6176, 3394, 3537, y
3565). Indicar la compatibilidad con equipos de otros fabricantes y describir
adems sus caractersticas.
Pgina 49 de 80
g. Especificar el impacto en la performance del equipo para cada uno de los

mecanismos empleados y para su combinacin, en funcin de: CPU,
h. Indicar la cantidad mxima de tneles IPSec en forma simultnea, que
soporta el equipo propuesto. Indicar en que condiciones se detalla tal
caracterstica.
i. Indicar la cantidad mxima de tneles IPSec que puede generar y/o
terminar el equipo por unidad de tiempo (medido en segundos), y el
throughput de datos soportado por cada tnel.
j. Especificar la existencia o no, de mecanismos para limitar el nmero de
tneles IPSec admitidos por el equipo. En caso de existir describirlos
detalladamente.
k. Especificar, en caso de no existir mecanismo de control que sucede con el
equipo superado el nmero mximo de tneles IPSec soportados.
l. Indicar la versin (release) de software para el protocolo en cuestin. En
caso que el mismo fuera implementado en versiones futuras (en hoja de
ruta o roadmap); se deber indicar la versin correspondiente y su fecha
comprometida de implementacin.
m. En caso que aplique, indicar la existencia de limitaciones entre el hardware
presentado (interfaces, procesador, etc.) y dicha funcionalidad.
6.2.4.7.
Network-based Firewall

A continuacin se debern detallar las funcionalidades de firewall de red requeridas
para los equipos propuestos. Responder punto a punto indicando:
a. Los equipos presentados debern contar con la posibilidad de aplicar

tcnicas de firewalling statefull inspection hasta capa 7(aplicacin)
Describir y Detallar la implementacin.
b. Indicar la cantidad mxima de instancias soportadas por el equipo y
su impacto respecto a performance (memoria, CPU, recursos, etc.).
c. Los equipos presentados debern contar con la posibilidad de aplicar
otras tcnicas de firewalling. Detallar
d. En caso que aplique, indicar la existencia de limitaciones entre el
hardware presentado (interfaces, procesador, etc.) y dicha
funcionalidad
6.2.4.8.
Network-based NAT
Contestar para rol PE

A continuacin se debern detallar las funcionalidades de traslacin de direcciones
de red requeridas para los equipos propuestos. Responder punto a punto indicando:
a. La capacidad del equipo propuesto para lograr la traslacin de

direcciones IP, puertos, y/o protocolos siendo este compatible con las
Pgina 50 de 80
b.
6.2.4.9.
normas establecidas por el IETF (RFC 3022, 2993,3596 y 4966).

Detallar
Indicar para las opciones del punto a, si se trata de translaciones de
tipo esttico y/o dinmico. Detallar.
Control de Aplicaciones
Contestar para rol PE

A continuacin se debern detallar las funcionalidades de control y medicin de la
capa de aplicacin requerida para los equipos propuestos. Responder punto a punto
indicando:
Soporte de funcionalidades onboard para realizar en forma automtica y adaptativa
el control de trfico de aplicaciones. Describir y detallar funcionamiento y
caractersticas principales. Indicar las formas de licenciamiento previstas.
6.2.4.10.
Agente de medicion de performance
Contestar para rol PE e IGW

A continuacin se debern detallar las funcionalidades de agente residente de
medicin de performance requeridas para los equipos propuestos. Responder punto
a punto indicando:
a. Soporte de funcionalidades onboard para realizar en forma automtica
mediciones de parmetros de performance : delay, jitter, prdida de
paquetes. Describir y detallar funcionamiento.
b. Indicar si las mediciones pueden ser parametrizadas por tipo de trfico y
aplicacin.
c. Indicar cmo se generan los reportes a partir de las mediciones realizadas.
d. Indicar las formas de licenciamiento previstas.
e. Indicar si requiere interaccin con plataformas externas de medicin de
performance.
f. Indicar si las funcionalidades empleadas son estndares o propietarias.
6.2.4.11.
Sincronismo

El equipamiento debe estar preparado para soportar el estndar IEEE1588v2 [O]
El equipamiento debe estar preparado para soportar el estndar G.8261
(Synchronous Ethernet).
Pgina 51 de 80
6.2.4.11.1.
FUENTES DE SINCRONISMO

a. Indicar si el equipo es capaz de tomar el sincronismo de una entrada
externa.
b. Indicar si el equipo es capaz de recuperar el sincronismo proveniente de una
red de paquetes (IEEE1588v2) desde cualquier tipo de interfaz.
c. Indicar si el equipo es capaz de generar sincronismo para una red de
paquetes compatible con el estndar IEEE1588v2.
d. Indicar si el equipo se puede cumplir funciones de boundary clock (
regenerar y proveer sincronismo segn estndar IEEE1588v2).
a.
Indicar la cantidad de clientes (OC) que puede soportar.
b.
Indicar si se puede variar y entre que rangos se puede variar el baud
rate de los paquetes de IEEE 1588v2.
c.
Indicar si puede soportar el envio de paquetes Follow Up para
informar el timestamp del paquete Sync
e. Indicar si el equipo se puede cumplir funciones de transparent clock (
corregir tiempo de estadia en equipos ,de paquetes segn estndar
IEEE1588v2).
f. Indicar si el equipo puede equiparse con un mdulo de GPS interno.
g. Indicar si el equipo soporta BITS (Building Integrated Timing Supply).
h. Indicar si el equipo soporta Adaptative Clock Recovery.
i. Adicionalmente a lo indicado en los tems anteriores, indicar otros protocolos
y/o estndares de sincronismo soportados por el equipo.
6.2.4.12.
Operacin, Administracin y Mantenimiento
Contestar para cada modelo de equipo con Rol PE, el soporte de:
6.2.4.13.
MEF ELMI (ETHERNET

INTERFACE)
LOCAL
MANAGEMENT
a. Indicar el soporte de ELMI (Ethernet Local Management Interface)

segn lo especificado en el MEF 16, el cual define el protocolo y
procedimientos necesarios para permitir la auto configuracin de los
dispositivos CE y los medios para la notificacin del estatus de los
EVCs y de la UNI.
b. Indicar si el ELMI es implementado por hardware o por software.
c. Indicar cuantas instancias de ELMI son soportadas.
6.2.4.14.
IEEE 802.3AH OAM
d. Indicar el soporte de 802.3ah OAM

e. Indicar la frecuencia mnima de configuracin para el envo peridico
de paquetes para realizar la deteccin de fallas (802.3ah OAM link
monitoring).
f. Indicar el soporte de OAM Remote Loopback.
Pgina 52 de 80
g. Indicar si 802.3ah es un proceso implementado por hardware o por

software.
h. Indicar si se soporta 802.3ah simultneamente con ELMI
6.2.4.14.1.
IEEE 802.1AG (ETHERNET CONNECTIVITY FAULT

MANAGEMENT)
a. Indicar el soporte de 802.1ag, especificando el soporte de los

siguientes protocolos:
i.
Continuity Check Protocol (CCM).
ii.
Loopback Protocol (LBM, LBR)
iii.
Linktrace Protocol (LTM, LTR)
b. Indicar el soporte de RDI en los mensajes CCM.

c. Indicar el soporte de los TLV opcionales: Port Status TLV e Interface
Status TLV.
d. Indicar la cantidad mxima de MEPs, MIPs y MA soportados por
puerto, placa y chasis.
e. Indicar en que tipo de interfaces (untag, VLAN, EoMPLS end point,
ruteados, etc) son soportados los MEPs y MIPs diferenciando por tipo
de MP (UP y DOWN)
f. Indicar si los procesos de 802.1ag son implementados en software o
hardware.
g. Indicar la cantidad de MEPs y MIPs soportados para los siguientes
intervalos de tiempo de envo de los mensajes CCM:
i.
3,3 ms
ii.
10 ms
iii.
100 ms
iv.
1 seg
v.
10 seg
h. Especificar si la base de datos de CCM es soportada en los MIPs

(opcional en el Standard) a fin de que los mensajes LTM lleguen a
destino aunque las MAC hayan sido borradas por aging time.
i. Indicar si existe interoperabilidad probada con equipamiento de otros
fabricantes.
6.2.4.14.2.
ITU Y.1731 (PERFORMANCE FAULT MANAGMENT)
a. Especificar el soporte de las siguientes funciones de monitoreo de

performance:
i. Frame loss ratio
ii. Frame delay
iii. Frame delay variation
iv. Throughput
b. Debido a que los protocolos CCM, LBR/LBM, LTM/LTR no son compatibles
totalmente entre los definidos por la ITU y los definidos por la IEEE 802.1ag,
especifique cuales mensajes (ITU o IEEE) son utilizados para las funciones
del punto anterior.
c. Especifique si se soporta AIS.
Pgina 53 de 80
d. Indicar si existe interoperabilidad probada con equipamiento de otros

fabricantes.
6.2.4.14.3.
a.
b.
c.
d.
Indicar
Indicar
Indicar
Indicar
6.2.4.14.4.
INTEROPERABILIDAD DE OAM.
si
si
si
si
existe
existe
existe
existe
interoperabilidad
interoperabilidad
interoperabilidad
interoperabilidad
entre
entre
entre
entre
ELMI y 802.1ag
802.3ah y 802.1ag
802.1ag y MPLS OAM
802.1ag y BFD
Otras
El oferente deber indicar y detallar todas las funcionalidades que soporte el

equipo.
6.3.
CAPACIDADES DE
ELEMENTO DE RED
GESTIN
PROVISTAS
POR
EL
6.3.1.
INTERFACES GESTION
a. El equipo presentado deber soportar como mnimo [O] las siguientes

interfaces de gestin:
i. Fallas: SNMPv1, SNMPv2 o SNMPv3 y Syslog.
ii. Configuracin: SNMP, TFTP , FTP, Telnet o SSH2 (Secure Shell versin 2).
iii. Performance: SNMPv1, SNMPv2 o SNMPv3.
iv. Accounting: generacin de accounting y redireccin a gestores a definir .
v. Radius, DHCP
vi. Seguridad: Radius o TACACS
b. El oferente deber especificar y detallar otras interfaces de gestin que no
hayan sido indicadas en a) (por ejemplo: Q3, TL1, HTTP, API propietarias ,
etc.), indicando las funcionalidades asociadas para cada una de ellas.
c. Para las interfaces SNMP, detallar las MIBs soportadas por el equipo (MIBII,
Technology-specific MIB, Vendor-specific MIB). Adicionalmente se requiere
una descripcin de la MIB Vendor-specific soportada y sus funcionalidades
asociadas en el equipo.
d. El equipo debe contar con la capacidad de gestionar MIBs RMON y SMON.
Adicionalmente se debern detallar y entregar estas MIBs.
e. El oferente deber entregar para ARSAT la totalidad de las MIBs SNMP y sus
diccionarios (traduccin y descripcin de los campos de la MIB)
correspondientes a los elementos de red y al sistema de gestin propuestos.
f. El equipo deber disponer de un port exclusivo de management. Indicar
otros ports que permitan realizar la gestin mencionada.
g. Debe tener la posibilidad de limitar o restringir todas las funcionalidades de
management (Telnet, SNMP, etc.) a travs de un port / interfaz exclusivo
para tal funcin.
Pgina 54 de 80
6.3.2.
FUNCIONALIDADES
6.3.2.1.
Asociacin entre funcionalidades e interface
Indicar para cada interfaz descripta en el punto anterior las funcionalidades de

gestin asociadas. Completar la siguiente tabla.
Grupo de tareas
SNMP
Telnet
SSH/
SFTP
TFTP/
FTP
Radius/ Otras
Tacacs+
Fallas
a)
b)
Envo de alarmas en forma espontnea

Visualizacin remota del status del
sistema
c)
Visualizacin del histrico de alarmas
presente en el equipo
Configuracin
d)
Configuracin de las VPN-MPLS
e)
Configuracin del servicio VPDN
f)
Configuracin de parmetros de QoS
g)
Configuracin de umbrales (para
funcionalidad de alarmas y
performance)
h)
Carga remota de software, firmware y
configuraciones
Performance
i)
Recoleccin de parmetros de
performance
j)
Configuracin y recoleccin de
resultados de tests
Accounting
k)
Recoleccin de reportes de utilizacin de
puertas
Seguridad
l)
Control de Accesos
Inventario de Elementos
m)
Recoleccin de datos de inventario
6.3.2.2.
Fallas
a. Deber contar con mecanismos para el envo de eventos/mensajes
espontneos de alarmas (ej. traps SNMP) mediante una interfaz
SNMP y/o SysLog. Se deber entregar la descipcin de cada uno de
ellos (incluyendo la descripcin de cada trap SNMP soportado) [O].
b. El oferente deber indicar la cantidad mxima de destinos a los que
un trap SNMP puede ser enviado en forma simultnea.
c. El oferente deber indicar la posibilidad de configurar distintos
destinos para el envo de traps SNMP por grupo de alarmas/eventos.
d. El oferente deber indicar la existencia de un mensaje de cese/fin de
alarma para cada tipo de alarma existente en el equipo.
e. Se debern detallar los diferentes tipos de alarmas indicados (ej.
equipamiento, comunicacin, entorno, procesamiento, QoS, etc.).
Deber entregar una lista con la descripcin de todas las
alarmas/eventos enviados por el Network Element.
f. El oferente deber detallar el formato de alarma utilizado, detallando
las especificaciones particulares del proveedor. El mismo deber
incluir como mnimo la siguiente informacin: Id_Alarma, Id_Origen,
Pgina 55 de 80
Modulo-Sub_Modulo, Fecha_Inicio/Fin, Hora_Inicio/Fin,

Gravedad_Evento, Descripcin_Evento. [O]
g. El oferente deber indicar los mecanismos de pruebas remotas
soportados por el equipo. Detallar estos mecanismos describiendo las
interfaces de testing habilitadas para estas funcionalidades.
6.3.2.3.
Configuracin
a. Cada una de las funciones existente dentro del equipo debern poder
ser configuradas en forma remota [O]. Detallar los mecanismos e
interfaces para cumplir con dicha funcionalidad.
b. El equipo deber disponer de un mecanismo de
activacin/desactivacin de componentes (placas, ports).
c. El equipo debe proveer la posibilidad de realizar download y upload
en forma remota de nuevas versiones de software y configuraciones
[O].
d. Deber detallar el impacto en el equipo al ejecutar un cambio de
software. Detallar el proceso.
e. Deber contar con mecanismos de configuracin de direcciones
(interfaces y loopback). Indicar los mecanismos utilizados en la
gestin de los pools de direcciones.
f. El oferente deber detallar los mecanismos implementados para la
configuracin de las funcionalidades requeridas
6.3.2.4.
Performance
a. El equipo propuesto debe poseer MIBS SNMP que permitan la medicin de

los parmetros de Performance de los mismos [O].
b. Como mnimo debern poder monitorearse los siguientes parmetros:
i. CPU
ii. Memoria
iii. Trafico entrante y saliente por interfaz/sub-interfaz ( expresada en
bits y en paquetes)
iv. Errores por interfaz/sub-interfaz
v. QoS / CoS descriptas en el punto Clase de Servicio y Calidad de
Servicio de esta RFP ( indicando los bytes /paquetes que pasan por
las mismas y los bytes / paquetes descarados)
c. El oferente deber poner a disposicin, de todas las MIBs de los equipos
ofertados. [O].
d. Adicionalmente el oferente deber detallar todas las mediciones de
performance realizadas por el equipo que complementen a las solicitadas en
el punto b. (indicando las variables de la MIB relativas a la performance).
e. El equipo debe contar con un mecanismo de configuracin de umbrales de
activacin/generacin de alarmas de performance. El oferente deber
describir los mecanismos soportados.
f. El oferente deber indicar si el equipo permite la realizacin de mediciones
de performance (latencia, disponibilidad, tasa de error) entre nodos de la
red.
Pgina 56 de 80
6.3.2.5.
Contabilizacin (accounting)
El equipo debe contar con un mecanismo de generacin y almacenamiento de los

datos de uso de los recursos de los elementos de red (discriminando por interfaz
fsica, protocolo, direccin IP, etc.).
6.3.2.6.
Seguridad
a) El equipo deber contar con la posibilidad de definir distintos perfiles de

usuarios.
b) El oferente deber detallar los mecanismos implementados para la definicin
de perfiles. Como mnimo debern existir tres niveles: observador, operador y
administrador.
c) El acceso al elemento de red deber realizarse mediante el ingreso de un
nombre de usuario y de un password. [O]
d) El oferente deber detallar la capacidad de generar alarmas de seguridad
(accesos exitosos, intentos fallidos de login, etc.) al sistema de gestin.
e) El oferente deber detallar la capacidad de almacenar en un log local los
accesos y los comandos efectuados sobre el equipo (auditoria de seguridad).
f) El equipo deber permitir la configuracin de la base de usuarios en forma
remota mediante el empleo del protocolo TACACS o Radius. Indicar el/los
protocolos soportados.
g) El equipo deber permitir restringir el logeo mltiple de un mismo usuario.
h) Debe asegurar las reglas de construccin de password de usuario acordes al
nivel de seguridad solicitado. Por ejemplo, password del tipo alfanumrico y de
longitud mayor o igual a 10 caracteres.
6.3.2.7.
Inventario de Elementos
a. Se deber indicar si el equipo posee la funcionalidad de inventario de
recursos fsicos y lgicos del propio elemento. [O]
b. Para los recursos fsicos (elementos de hardware) el equipo deber
registrar la existencia de cada modulo individual, respetando los
niveles de agregacin propios de la arquitectura del elemento de red,
p. ej. bastidor, sub-bastidor, placa, mdulo, etc.
c. El sistema debe reflejar las versiones de hardware para cada mdulo
individual.
d. El sistema debe reflejar las versiones de firmware y software para
cada modulo individual. Detallar los casos en que aplica
Pgina 57 de 80
6.3.3.
ADMINISTRACIN DE SOFTWARE
a. El oferente deber describir las funcionalidades de administracin de
software implementadas en el elemento de red. [O]
b. El oferente deber indicar si el equipo cuenta con la posibilidad de
mantener dos o ms versiones de software residentes en el equipo
con el objetivo de permitir el cambio de versiones. [O]
c. El oferente deber describir el procedimiento de cambio de versin de
software y firmware.
6.3.4.
REGISTROS (Logs)
a. El equipo deber contar con distintos Registros que permitan soportar
informacin correspondiente a la gestin de comandos, de fallas, de
acceso y de seguridad del sistema completo. [O]
b. Indicar el tipo de estructura implementada para cada tipo de Registro
y tamaos mximos.
c. El equipo deber disponer de una administracin automtica de los
Registros
6.3.5.
COPIA DE RESPALDO (Backup) / RESTAURACIN

(Restore)
a. El Equipo de deber permitir la realizacin de copia de respaldo y
restauracin de los datos de configuracin [O], de fallas y de
performance que se encuentran almacenados en el mismo.
b. El oferente deber detallar los procedimientos de restauracin de la
informacin en caso de prdida de datos.
c. El oferente deber indicar si el equipo dispone de la posibilidad de
manejar backups automatizados
Pgina 58 de 80
6.3.6.
ROADMAP GESTION
a. El oferente detallar el roadmap respecto a las capacidades de
gestin provistas por el equipo [O], en cuanto a:
b. Interfaces
c. Funcionalidades / servicios
d. Escalabilidad
e. Indicando en cada caso el grado de compromiso con las fechas
establecidas (por ejemplo: comprometido, propuesto, conceptual,
etc.). En todos los casos se deber indicar fechas de disponibilidad
comercial.
6.3.7.
ROADMAP EQUIPAMIENTO

Para la respuesta al presente tem, considerar como Roadmap, a todos aquellos
atributos futuros del equipamiento como consecuencia de su evolucin.
Los atributos actuales, debern responderse en los puntos correspondientes de la
especificacin.
El oferente detallar el roadmap del producto en el periodo 2013-2015 [O]
cuanto a:
en
a. Interfaces
b. Funcionalidades / servicios
c. Escalabilidad
Para cada caso, indicar las fechas de disponibilidad comercial, como as tambin su
grado de compromiso (propuesto, comprometido, etc)
6.4.
VALORES MINIMOS DE FUNCIONALIDADES BSICAS

POR TIPO DE NODO (PE, P, RR e IGW) [O]
En Anexo III Parmetros mnimos del equipamiento TRONCAL se presentan los

requerimientos de valores mnimos de las funcionalidades bsicas de la plataforma
que el oferente deber utilizar en forma obligatoria para resolver el escenario
descripto. Los equipos debern ser equipados, como mnimo, con las cantidades de
interfaces que se indican en 7.ESCENARIOS REQUERIDOS
6.4.1.

PARA NODO PE
Ver Anexo III Parmetros mnimos del equipamiento TRONCAL
6.4.2.

PARA NODO IGW
Pgina 59 de 80
6.4.3.

PARA NODO P
6.4.4.

PARA NODO RR
7. ESCENARIOS REQUERIDOS
En la figura 4, se muestra un esquema general de la ubicacin de los roles de
equipamiento que son objeto de cotizacin (roles P y PE). Los roles RR e IGW
tambin son objeto de cotizacin y se ubican en los nodos primarios Benavidez y
Mendoza:
TRONCAL MPLS
Nodo Primario N
Nodo Primario Y
Rol P
Rol P
Servicio 1 / Lambda X
(vincular P)
ADM
Rol PE
ADM
Rol PE
Rol PE
DWDM
Rol PE
Servicio 4 / Lam
bda Z (Vincula
r
Subtendido con
PE)
vic
ar
ul
cc
in
(V )
a Z PE
bd con
m
La ido
4 / nd
io bte
vic Su
Se
r
r
Se
bda Z
Servicio 3 / Lam
dido con PE)
(Vincular Subten
io
Su 3 /
bt La
en m
di bd
do a
co Z (V
n P in
E) cul
ar
DWDM
ACCESO MPLS
ADM
ADM
DWDM
DWDM
Nodo Secundario X
Nodo Secundario Y
INFRAESTRUCTURA DWDM
EXISTENTE
7.1.
OBJETO REQUERIDO: ROL P [O]
Se definen tres tipos: A, B y C, segn los requerimientos de procesamiento de

trfico y mencionado en Anexo III Parmetros mnimos del equipamiento Troncal
del PET. Las cantidades y tipos por sitio se especifican en el Anexo II Lista de Sitios
y Roles a Servir en Troncal del PET.
Pgina 60 de 80
Se debe cotizar interfaces del tipo Ethernet. El cableado a los distribuidores de fibra
ptica o entre equipamiento debe ser en fibra monomodo, excepto en el nodo
Benavidez, donde el cableado hacia los rol PE, IGW y RR ser en fibra multimodo.
Los tipos de interfaces a cotizar por funcin en la red, por cada equipamiento con
rol P, son:
I-P-PE: Interface de P a PE
I-P-P: Interface de P a P
I-P-IGW: Interface de P a IGW
I-P-RR: Interface de P a RR
Las placas de interfaces a utilizar, deben tener como mnimo 8 interfaces (excepto
para el tipo C).
ROL PE
ROL P
I-P-PE
ROL IGW
I-P-P
ROL P
ROL P
I-P-IGW
I-P-PE
I-P-P
I-P-P
I-P-RR
ROL PE
ROL RR
RED DWDM FEDERAL
I-P-PE
ROL PE
7.1.1.
CANTIDAD DE INTERFACES I-P-P [O]
Las interfaces entre rol P se cotizarn en base al siguiente esquema. Las interfaces
a proveer deben estar distribuidas como mnimo en dos placas de lnea diferentes.
Pgina 61 de 80
Todas las interfaces sern de 10 Gbps pticas equipadas para soportar distancias
de hasta 10 km.
El resumen de las interfaces a cotizar se encuentra en el Anexo XIV Tablas de

Interfaces para el Equipamiento Troncal Multiservicio MPLS/IP del PET.
Pgina 62 de 80
P
JUJUY
P
POSADAS
P
RESISTENCIA
1x10Gbps
1x10Gbps
1x10Gbps
P
TUCUMAN
1x10Gbps
1x10Gbps
P
SANTA FE
1x10Gbps
3x10Gbps
3x10Gbps
P
ROSARIO
1x10Gbps
P
CORDOBA
1x10Gbps
DATACENTER
4x10Gbps
4x10Gbps
P
MENDOZA
INTERNET
4x10Gbps
P
BENAVIDEZ
TDA
4x10Gbps
1x10Gbps
4x10Gbps
P
NEUQUEN
1x10Gbps
4x10Gbps
4x10Gbps
P
1x10GbpsABASTO
P
RODRIGUEZ
1x10Gbps
P
BAHIA BLANCA
1x10Gbps
1x10Gbps
1x10Gbps
P
CALETA OLIVIA
1x10Gbps
P
RIO GALLEGOS
7.1.2.
CANTIDAD DE INTERFACES I-P-PE [O]
Las interfaces entre rol P y rol PE se cotizarn en base al siguiente esquema. Las
interfaces a proveer deben estar distribudas como mnimo en dos placas de lnea
diferentes.
Pgina 63 de 80
de hasta 10 km.

Interfaces para el Equipamiento Troncal Multiservicio MPLS/IP del PET. (ver tambin
figura 3 del tem 5.1)
Nodo Primario Remoto
Nodo Primario
ROL PE
ROL PE
ROL PE
ROL PE
I-P-PE
I-P-PE
ROL P
RED DWDM FEDERAL
7.1.3.
CANTIDAD DE INTERFACES I-P-IGW [O]
Las interfaces entre rol P y rol IGW se cotizarn en base al siguiente esquema. Las
diferentes.
de hasta 10 km.

Pgina 64 de 80
ROL IGW 1
ROL P
Benavidez 1
Proveedor
Internet 1
I-P-IGW
I-P-IGW
ROL P
Benavidez 2
I-P-IGW
RED DWDM FEDERAL
I-P-IGW
ROL IGW2
7.1.4.
Proveedor
Internet 2
CANTIDAD DE INTERFACES I-P-PE (Data Center) [O]
Las interfaces entre rol P y rol PE dedicado para acceder al DataCenter de

Benavidez, se deben ofertar en base al siguiente esquema. Las interfaces a proveer
deben estar distribudas como mnimo en dos placas de lnea diferentes.
de hasta 10 km.

Pgina 65 de 80
ROL P
Benavidez 1
ROL PE(DC)
I-P-PE(DC)
I-P-PE(DC)
ROL P
Benavidez 2
I-P-PE(DC)
RED DWDM FEDERAL

I-P-PE(DC)
ROL PE(DC)
7.1.5.
DATA CENTER
CANTIDAD DE INTERFACES I-P-RR [O]
Las interfaces entre rol P y rol RR de los nodos Mendoza y Benavidez, se cotizarn
en base al siguiente esquema. Las interfaces a proveer deben estar distribudas
como mnimo en dos placas de lnea diferentes.
de hasta 10 km.

ROL P
I-P-RR
ROL RR
RED DWDM FEDERAL
Pgina 66 de 80
7.2.
OBJETO REQUERIDO: ROL PE [O]
Se definen dos tipos: A y B, segn los requerimientos de procesamiento de trfico y

mencionado en Anexo III Parmetros mnimos del equipamiento Troncal del PET .
Las cantidades y tipos por sitio se especifican en el Anexo II Lista de Sitios y Roles
a Servir en Troncal del PET.
En el caso del nodo Benavidez, se contar con dos equipamientos rol PE dedicados
a vincular el DataCenter PE(DC).
Benavidez, donde el cableado hacia los rol P, y AN ( I-PE-AN e I-PE-AN Sub) ser
en fibra multimodo.
Las placas de interfaces a utilizar, deben tener como mnimo 8 interfaces.
Los tipos de interfaces a proveer por cada equipamiento con rol PE, son:
I-PE-P: Interface de PE a P
I-PE-AN Sec: Interface de PE a AN del nodo secundario, vinculados por

servicio DWDM.
I-PE-AN Sub: Interface de PE a AN del nodo subtendido, vinculados por fibra

oscura.
I-PE-AN: Interfaces de PE a AN local del nodo primario.
I-PE-DC:Interfaces de PE a equipamiento del DataCenter (ser de las

mismas caractersticas que I-PE-AN)
Pgina 67 de 80
ROL AN
ROL AN
ROL AN
Nodo Subtendido
Nodo Secundario
I-PE-AN
I-PE-AN Sec
I-PE-AN Sub
ROL PE
I-PE-P
CORE P
7.2.1.
CANTIDAD DE INTERFACES I-PE-P [O]
Las interfaces entre rol PE y rol P, se cotizarn en base al siguiente esquema. Las
diferentes.
de hasta 10 km.

Interfaces para el Equipamiento Troncal Multiservicio MPLS/IP del PET.(ver tambin
figura 3 del tem 5.1)
Pgina 68 de 80
Nodo Primario
Nodo Primario Remoto
ROL PE
I-PE-P
I-PE-P
RED DWDM FEDERAL

ROL P
7.2.2.
ROL P
CANTIDAD DE INTERFACES I-PE-AN Sec [O]
Las interfaces entre rol PE y rol AN ubicado en nodo secundario , se deben ofertar
en base al siguiente esquema. Las interfaces a proveer deben estar distribudas
como mnimo en dos placas de lnea diferentes.
Todas las interfaces sern de 10 Gbps y 1 Gbps pticas equipadas para soportar
distancias de hasta 10 km.

Pgina 69 de 80
ROL AN
ROL AN
Nodo Secundario
Nodo Secundario
I-PE-AN Sec
I-PE-AN Sec
Infraestructura DWDM
Infraestructura DWDM
ROL PE
CORE P
7.2.3.
CANTIDAD DE INTERFACES I-PE-AN Sub [O]
Las interfaces entre rol PE y rol AN ubicado en nodo subtendido , se cotizarn en

base al siguiente esquema. Las interfaces a proveer deben estar distribudas como
mnimo en dos placas de lnea diferentes.

Pgina 70 de 80
ROL AN
ROL AN
FO
Nodo Subtendido
Osc
ura
FO
I-PE-AN Sub
ura
Osc
Nodo Subtendido
I-PE-AN Sub
ROL PE
CORE P
7.2.4.
CANTIDAD DE INTERFACES I-PE-AN [O]
Las interfaces entre rol PE y rol AN ubicado en el nodo primario , se cotizarn en

base al siguiente esquema. Las interfaces a proveer deben estar distribudas como
mnimo en dos placas de lnea diferentes.

Pgina 71 de 80
Nodo Primario
ROL AN
FO Oscura
I-PE-AN
ROL PE
CORE P
7.3.
OBJETO REQUERIDO: ROL IGW [O]
La cantidad por sitio se especifica en el Anexo II Lista de Sitios y Roles a Servir en

Troncal
ptica o entre equipamiento debe ser en fibra ptica multimodo (I-IGW-P e I-IGWCI).
Los tipos de interfaces a proveer por cada equipamiento con rol IGW, son:
I-IGW-P: Interface de IGW a P
I-IGW-CI: Interface de IGW a Carrier Internet
Pgina 72 de 80
ROL P
I-IGW-P
ROL IGW
I-IGW-CI
CARRIER INTERNET
7.3.1.
CANTIDAD DE INTERFACES I-IGW-P e I-IGW-CI [O]
Las interfaces entre rol IGW y rol P, y entre rol IGW y el Carrier Internet ubicado en
el nodo primario , se deben ofertar en base al esquema del punto 7.3. Las
diferentes y las placas de interfaces a utilizar deben tener como mnimo 8
interfaces.

Pgina 73 de 80
7.4.
OBJETO REQUERIDO: ROL RR
La cantidad por sitio se especifica en el Anexo II Lista de Sitios y Roles a Servir en

Troncal del PET.
Benavidez, donde el cableado hacia los rol P ser en fibra multimodo.
Los tipos de interfaces a proveer por cada equipamiento con rol RR, son:
I-RR-P: Interface de RR a P
ROL P
I-RR-P
ROL RR
7.4.1.
CANTIDAD DE INTERFACES I-RR-P [O]
Las interfaces entre rol RR y rol P, se deben ofertar en base al esquema del punto
7.4.
Pgina 74 de 80
de hasta 10 km.
El resumen de las interfaces a cotizar se encuentra en el
Anexo XIV Tablas de
7.5.
OBJETO REQUERIDO: MAQUETA [O]
Con el fin de que personal tcnico de ARSAT pueda realizar pruebas de

funcionamiento, operacin y mantenimiento del sistema a instalar,
se deber
ofertar equipamiento extra que permita reproducir el escenario encontrado en

produccin.
Para esto, se solicita ofertar 2 (dos) equipos rol P tipo B (siempre que todos los
tipos sean de la misma naturaleza) y 4 (cuatro) equipos rol PE tipo A (siempre que
todos los tipos sean de la misma naturaleza).
La cantidad de interfaces para cada equipo son:
I-P-P: 20 interfaces de 10Gbps en dos placas
I-P-PE: 20 interfaces de 10 Gbps en dos placas
I-PE-P: 20 interfaces de 10 Gbps en dos placas
I-PE-AN: 20 interfaces de 10 Gbps en dos placas y 20 interfaces de 1 Gbps

en dos placas.
Los equipos deben estar equipados de tal forma de cumplir con lo requerido en el
punto 6.4.
VALORES MINIMOS DE FUNCIONALIDADES BSICAS POR TIPO DE
NODO
Pgina 75 de 80
8. VISTA DE RACK
A los efectos de facilitar la evaluacin de la solucin tcnica ofertada, el oferente
deber representar una vista de rack frontal, trasera y lateral de cada uno de los
equipos propuestos por rol y por nodo.
[O]
9. ALCANCE DEL SUMINISTRO Y SERVICIOS [O]

A los efectos de la presentacin de la propuesta, la misma deber considerar a los
equipos, elementos, materiales principales, y servicios que se detallan a
continuacin, y todo otro suministro y servicio que se considere necesario para la
adecuada operacin del sistema, de acuerdo a las normas indicadas en el presente
documento.
9.1.
ALCANCE DE SUMINISTRO
a. El suministro deber contemplar, como mnimo, la provisin de:

b. Los equipos (roles PE, P , RR, IGW) requeridos a instalar en los sitios
definidos en el Anexo II Lista de Sitios y Roles a Servir en Troncal del PET.
c. Las herramientas e instrumental necesarios para asegurar la adecuada
operacin y mantenimiento de la red, justificando su eleccin e indicando
aplicaciones.
d. Todos los materiales y accesorios de instalacin (incluyendo racks, cables de
alimentacin, bandejas, etc.) necesarios para la instalacin.
e. Todos los patchcords necesarios para la correcta interconexin de los
equipos, previendo un adicional del 20% por cada tipo provisto.
f. Los repuestos para los sistemas propuestos.
i. Manuales descriptivos de equipos, conteniendo como mnimo la
descripcin general y el diagrama en bloques, la descripcin detallada de
cada una de las interfaces, sus funciones y sus relaciones; resumen de
datos tcnicos y planos esquemticos de circuitos, etc.
ii. Manuales de instalacin, operacin, administracin y mantenimiento de
los equipos y Plataforma de Aplicaciones.
iii. Documentacin tcnica del software, ya sea software de base como
software de aplicacin (descriptivos, diagramas de flujo, manuales, etc.)
actualizado de acuerdo a la ltima versin instalada en los equipos.
Nota: La documentacin tcnica estar escrita preferentemente en castellano (de
no ser as, en idioma ingls), y corresponder a lo efectivamente instalado.
10.
DOCUMENTACION EJECUTIVA [O]
Los servicios debern incluir, como mnimo, la ejecucin de:

a.
b.
c.
a.
La Ingeniera de sistema.
La Ingeniera de detalle de instalacin.
Los planos conforme a obra.
Los trabajos de montaje e instalacin de los equipos y los elementos
asociados. En este concepto se debern considerar los servicios de montaje e
Pgina 76 de 80
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
instalacin de partes componentes de los equipos (ej. placas, bastidores,

cableados, etc.).
Los trabajos de desmonte y desinstalacin de los equipos y los elementos
asociados. En este concepto se debern considerar los servicios de desmonte y
desinstalacin de partes componentes de los equipos (ej. placas, bastidores,
cableados, etc.).
Los trabajos de conexionado correspondientes.
La conexin al tablero de energa, cuando as corresponda.
Las pruebas de puesta en marcha y pruebas de aceptacin de los equipos,
accesorios y materiales de acuerdo a protocolos de prueba a acordar con
ARSAT.(a realizarse en un plazo de por lo menos 10 das hbiles)
Lista de equipos, elementos y materiales a instalar (incluido la Plataforma de
Aplicaciones).
Layout de los equipos y elementos en la central.
Documentacin con la programacin o configuracin de los equipos.
Planillas de cableado.
Planillas de consumos de los equipos para capacidad inicial y final.
Cmputo de equipos, elementos y materiales a instalar.
Seccin del cableado de alimentacin segn el consumo del equipo.
Capacidad de llaves trmicas.
11.
CRONOGRAMA DE EJECUCION DE TRABAJOS [O]
Se deber cumplir con el cronograma de ejecucin de los trabajos del ANEXO VII
del PET.
12.
PROYECTO TCNICO DE LA PRESENTACIN [O]
Con el objeto de efectuar la evaluacin tcnica de cada propuesta, las mismas

debern incluir los proyectos tcnicos correspondientes, conteniendo como mnimo
los siguientes puntos:
Esquema de la solucin incluyendo el diagrama en bloques completo, justificando
las configuraciones adoptadas en base a las caractersticas de los equipos
empleados.
Clculo de los consumos de los equipos a nivel de -48Vcc / 220Vac, discriminando
los consumos en condicin stand-by o cursando trfico.
Clculo de los BTU necesarios para refrigeracin (en el caso de que el equipo la
necesite para su normal funcionamiento).
Esquema de conexin bsica del equipamiento propuesto.
Caractersticas completas de los equipos involucrados en las soluciones propuestas.
Listado detallado y planillas de cmputo correspondientes a la composicin de los
equipos que integran el sistema, a nivel de bastidores, sub-bastidores, tarjetas e
interfaces respectivas.
Pgina 77 de 80
Planillas de materiales, con el respectivo cmputo.

Para los equipamientos y materiales propuestos se debern indicar marca, modelo
y eventualmente nmero de catlogo del fabricante, adjuntando las hojas de datos
y folletos asociados en cada caso.
13.
CURSOS DE CAPACITACIN [O]
Ver Anexo XIII del PET.
14.
PRUEBAS DE CALIFICACION [O]
ARSAT se reserva el derecho de solicitar una prueba funcional previo a la etapa de

adjudicacin, como medida habilitante y de aptitud tcnica para la etapa siguiente
del presente concurso. Las pruebas de calificacin incluirn los tems de esta
especificacin pero orientado a verificar la funcionalidad de la solucin en forma
integrada y su escalabilidad
Los puntos a verificarse podrn incluir las siguientes pruebas:
IGP : Separacin de Dominios Administrativos, Sumarizacion y Redistribucin de
Prefijos, Tiempos de Convergencia Intradominio e interdominio.
LDP: Distribucion de Etiquetas DoD y/o DU. Distribucion de etiquetas Interdominio
e Intradominio.
UNI: Provision de la interfaz del usuario .Clasificacion, Priorizacion y Scheduling del
Trafico cliente. Seguridad de la Interfaz UNI( MAC Limit, Definicion de BW,etc)
Escalabilidad de Servicios L2VPN (E-Line e E-Lan), L3VPN (Full Mesh y H&S),Acceso
Internet.
Verificacion de escalabilidad de modelo Carrier Supporting Carrier.
SISTEMA DE GESTION: configuracin de SLA, monitoreo de performance, provision
de servicios L2VPN, L3VPN, alarmas, inventario.
15.
PRUEBAS DE HOMOLOGACION Y STRESS [O]
Las pruebas se realizarn posterior a la adjudicacin para garantizar que el equipo (

PE,P,IGW,RR ) cumple lo solicitado en las Especificaciones Tcnicas.
Aquellos proponentes que dispongan del sistema PE, IGW, P y RR con
anticipacin a la fecha solicitada, debern indicarlo expresamente.
Las pruebas de homologacin consistirn en pruebas de carcter exhaustivo, cuyo
contenido tcnico ser desplegado a criterio de ARSAT.
Las pruebas efectuadas para la Homologacin, NO excluyen en modo alguno las
pruebas para aceptacin de las partidas que se entreguen una vez que el producto
haya sido adjudicado.
Pgina 78 de 80
Las pruebas de homologacin consistir de dos fases:
Pruebas Funcionales y de Interoperabilidad (si correspondiera).

Pruebas de Stress.
Adicionalmente, ARSAT se reserva la decisin de agregar una tercera fase de

pruebas consistente en una prueba de campo con clientes en servicio como parte
de las pruebas de Homologacin. En caso de ejecutarse sta prueba, los resultados
de la misma se considerarn obligatorios.
El oferente deber presentar un modelo de protocolo de homologacin que incluya
como mnimo las pruebas funcionales, de interoperabilidad y stress solicitadas en el
punto 15.1 y 15.2.
15.1. PRUEBAS FUNCIONALES Y DE INTEROPERABILIDAD

Se requiere la disponibilidad de un sistema de iguales caractersticas al propuesto
(PE, P, IGW,RR) sobre el que se deber poder verificar las prestaciones descriptas
en la propuesta tcnica.
Por consiguiente se deber disponer de un equipo por cada tipo de nodo ofertado
(PE, P, IGW , RR) como minimo, con todos los modelos de placas (interfaces,
procesadores, etc.) utilizadas para la resolucin de los escenarios, as como cables
para instalacin, patchcords, etc., y todo lo que se considere necesario para el
correcto funcionamiento de las pruebas.
Se requiere, adems, un juego de los manuales tcnicos necesarios durante el
transcurso de las pruebas, as como la disponibilidad exclusiva de personal tcnico
idneo para el soporte durante la realizacin de las mismas.
El oferente deber asegurar interoperabilidad con otros proveedores basada en los
estndares abiertos a nivel de los principales protocolos solicitados en el presente
concurso, como ser OSPFv2, OSPFv3, IS-IS, IS-ISv3, BGPv4, BGPv4+, LDP, 6PE,
6VPE, PW, MPLS.
15.2. PRUEBAS DE STRESS

Se deber garantizar la disponibilidad de un sistema de iguales caractersticas al
propuesto (PE, P, IGW , RR) sobre el que se deber poder verificar las prestaciones
descriptas en la propuesta tcnica.
Las pruebas de stress consisten en pruebas que verifiquen la performance y
confiabilidad de los equipos al implementar simultneamente todos los servicios
que el mismo soporta con trfico a niveles de saturacin de las interfaces, mdulos
y procesadores del mismo.
Debido a las caractersticas de estas pruebas, el lugar de desarrollo de las mismas
ser a convenir entre el proponente y ARSAT.
Pgina 79 de 80
16.
GARANTIA DE DISEO [O]
El oferente es el nico responsable por que los nuevos equipos ofertados en la

arquitectura de red cumplan con los requerimientos, por lo que cualquier error
falla ser de su exclusiva responsabilidad y, consecuentemente, estar obligado a
subsanarlo luego de la identificacin del problema por personal tcnico de ARSAT.
Incluyendo los aspectos referidos a funcionalidad, performance, disponibilidad,
dimensionamiento, escalabilidad y seguridad para todo el conjunto como servicio
integral.
En caso que la propuesta sea presentada a travs de canales, stos debern
presentar una carta de aval por parte del vendor que participara en su propuesta,
avalando la solucin presentada ya que se considera al vendor el responsable final
del diseo y performance de los equipos de la red ofertados.
La responsabilidad en el diseo e ingeniera no finaliza con la emisin del acta de
recepcin definitiva de toda la red que es objeto de este concurso, sino que
extiende durante toda la vida til de la red.
Toda
vez
que
se
presente
cualquier
problema
en
el
diseo y/o ingeniera de la solucin, y siempre que la misma se encuentre
funcionando dentro de los parmetros de diseo de mxima informados por el
proveedor en la propuesta, este estar obligado a solucionarlo en conjunto con el
vendor, sin que esto implique ningn costo adicional para ARSAT (garanta del
diseo en s mismo, sin lmite de tiempo, mientras se mantenga dentro de las
condiciones de contexto requeridas).
Por lo tanto, se exige de forma obligatoria que en caso que un canal realice las
tareas de instalacin , puesta en marcha, optimizacin y mantenimiento de la
solucin ofertada cuente con las ms altas certificaciones del vendor al igual que su
personal interviniente.
Pgina 80 de 80

ANEXO I Especificaciones Técnicas Red Troncal MPLS IP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ANEXO I Especificaciones Técnicas Red Troncal MPLS IP

Uploaded by

Copyright:

Available Formats

Anexo I

Proyecto red IP/MPLS ARSAT SA

METODOLOGA DE RESPUESTA. ..................................................................................................... 7

DESCRIPCION DE LA SOLUCION TECNOLOGICA A COTIZAR ............................................................. 7

ARQUITECTURA DE REFERENCIA ................................................................................................. 9

SITIOS A CONECTAR .................................................................................................................. 13

DESCRIPCIN DE LA TOPOLOGA DE LA RED ............................................................................. 13

ARQUITECTURA DE LA RED .................................................................................................. 13

NIVEL CORE ....................................................................................................................... 14

NIVEL DE AGREGACIN/DISTRIBUCIN ............................................................................ 15

NIVEL DE ACCESO .............................................................................................................. 15

CARACTERISTICAS TECNICAS Y PRESTACIONES REQUERIDAS ....................................................... 15

CARACTERSTICAS TCNICAS .................................................................................................... 15

CARACTERSTICAS GENERALES DEL EQUIPAMIENTO ............................................................. 15

CAPACIDAD DE CONMUTACIN ........................................................................................... 16

REQUERIMIENTOS DE ROL PE, P,IGW Y RR .................................................................. 18

CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 19

PROTOCOLO DE NIVEL 2.................................................................................................... 20

CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 20

PROTOCOLO DE NIVEL 2.................................................................................................... 20

CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 21

PROTOCOLO DE NIVEL 2.................................................................................................... 21

SDH CANALIZADAS ............................................................................................................ 21

CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 21

PROTOCOLO DE NIVEL 2.................................................................................................... 22

Proyecto red IP/MPLS ARSAT SA

CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 22

PROTOCOLO DE NIVEL 2.................................................................................................... 23

CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 23

PROTOCOLO DE NIVEL 2.................................................................................................... 23

CAPA FSICA (NIVEL 1 OSI) ................................................................................................. 24

PROTOCOLO DE NIVEL 2.................................................................................................... 24

PROTOCOLOS DE RUTEO REQUERIDOS ............................................................................. 26

POLICY ROUTING .............................................................................................................. 30

FUNCIONALIDADES POLICY ROUTING ............................................................................ 31

PERFORMANCE EN IPV4 .................................................................................................... 31

PROTOCOLO IPV6 ............................................................................................................. 31

PERFORMANCE EN IPV6 .................................................................................................... 32

OTRAS FUNCIONALIDADES DE ROUTING........................................................................... 32

MPLS (MULTI PROTOCOL LABEL SWITCHING) ....................................................................... 33

ACCESS LIST ...................................................................................................................... 36

GESTIN DE VPN MPLS ..................................................................................................... 38

CLASE DE SERVICIO Y CALIDAD DE SERVICIO ..................................................................... 38

DIFFSERV MPLS .............................................................................................................. 40

DIFFSERV-AWARE MPLS TRAFFIC ENGINEERING .............................................................. 41

MTODOS DE CLASIFICACIN ........................................................................................... 42

ALTA DISPONIBILIDAD ...................................................................................................... 42

TRAFFIC ENGINEERING ...................................................................................................... 43

TRAFFIC ENGINEERING FAST RE ROUTE (TE-FRR) .............................................................. 44

PWE3 (PSEUDO-WIRE EMULATION EDGE-TO-EDGE) ......................................................... 44

PATH MTU DISCOVERY ..................................................................................................... 47

VIRTUAL ROUTER REDUNDANCY PROTOCOL (VRRP) ......................................................... 48

ROUTER VIRTUAL .............................................................................................................. 48

Proyecto red IP/MPLS ARSAT SA

TUNNELING Y ENCRIPCIN DE DATOS MEDIANTE IPSEC ................................................... 49

NETWORK-BASED FIREWALL ............................................................................................. 50

NETWORK-BASED NAT ...................................................................................................... 50

CONTROL DE APLICACIONES ............................................................................................. 51

AGENTE DE MEDICION DE PERFORMANCE ........................................................................ 51

FUENTES DE SINCRONISMO .......................................................................................... 52

OPERACIN, ADMINISTRACIN Y MANTENIMIENTO ........................................................ 52

MEF ELMI (ETHERNET LOCAL MANAGEMENT INTERFACE) ................................................ 52

IEEE 802.3AH OAM............................................................................................................ 52

IEEE 802.1AG (ETHERNET CONNECTIVITY FAULT MANAGEMENT) ................................. 53