NS-052 (Metro Ethernet Specs_Issue-III_Nov_ 2012)

7/29/2019 NS-052 (Metro Ethernet Specs_Issue-III_Nov_ 2012)

1/21

PAKISTAN TELECOMMUNICATIONCOMPANY LIMITED

SE NS-052SYSTEM ENGINEERING WINGOF PTCL

November , 2012

SERIES NS: NEW TECHNOLOGIES

Specifications of New Technologies and Data Equipment

Metro Ethernet

PTCL Specifications NS-052


2/21

NS-052

Issue-III (Nov 2012) Metro Ethernet Page 2 of 21

Change History

The table below lists the significant, product-impacting changes to the document.Editorial changes and cosmetic changes are not listed.

Issue Date Revised By Description of

Change

Section or

table

I 30-Mar-2010 Muhammad Nasir Khan

Faheem Ul Hassan

Initial Version

II 21-Oct-2011 Muhammad Nasir Khan Updated Version 1, 2, 5, 6 & 7

III 09-Nov-2012 Muhammad Nasir Khan Updated Version 1


3/21

NS-052


Contents

1 Technical Requirements 04

2 Network Management System (NMS) Specifications (attached) 103 Firewall/ Security And Threat Response Manager Specifications 104 Rack Specifications 125 DC Power Systems and UPS Specifications (attached) 13

6 General Requirements 137 Information Template 19


4/21

NS-052


1. TECHNICAL REQUIREMENTS

1.1. PTCL intends to install and deploy Metro/Carrier Ethernet based transportsolution in the PTCL network.

1.2. The objective of this specification is to define and fix standards for

equipment/services required for Metro Ethernet solution. The proposed solutionconsists of different capacity Metro Ethernet nodes, Network Management

System (NMS), auto service provisioning systems and other network components.

1.3. The services shall include NGN VoIP, PTP (Point-to-Point), PTMP (Point-to-Multipoint), Uni-cast, Multi-cast, active Ethernet, CDMA WLL VoIP, Wimax, IP

Centrex, Internet services, Triple play services (voice, video, data), VoD, DSL,

VPN, VPLS and other Multi Protocol Label Switching (MPLS) services etc.1.4. The offered solution shall support ring, hub-and-spoke (star), full and partial mesh

topology.

1.5. The network shall be deployed in hierarchy having core, distribution(aggregation) and access layers.

1.6. Following are the Architecture requirements:1.6.1. Core Aggregation Metro Node (High End Node)

i). Minimum slots: 10ii). Slot capacity: Minimum 100 Gbpsiii). Chassis backplane capacity: Minimum 2 Tbps

1.6.2. Core Metro Node (Medium End Node)i). Minimum slots: 6ii). Slot capacity: Minimum 100 Gbpsiii). Chassis backplane capacity: Minimum 1 Tbps

1.6.3. Access Metro Nodesi). Minimum slots: 2 or Fixed configuration

ii). Uplink: Gbps (Multiple)iii). Uplink: 10 Gbps (Multiple)Note: The bidder shall quote for both uplink configurations

1.6.4. The offered equipment shall be modular and scalable. The bidder shall providethe basic/ultimate capacity of the offered system.

1.7. Carrier-class reliability:1.7.1. The offered system shall have redundant processors/ control units and fans.1.7.2. The offered system shall have redundant hot-swappable power supplies.1.7.3. Key modules including system control units and power supply shall adopt 1:1

mode backup. The high reliability shall be ensured through the hitless protection.

It shall be highly reliable with high figures of MTBF.

1.8. Large capacity and high performance:1.8.1. The offered system shall support non-blocking switching capability and packetforwarding capability shall be sufficient to meet the requirements.

1.8.2. The offered system shall have Port-based and MAC-based VLAN support.1.8.3. The bidder shall mention the values of Switching capability, Packet Forwarding

Rate, L3 Route Entries, L2 MAC addresses and number of VLANs supported.1.9. The offered system shall have the following attributes as per MEF:
http://en.wikipedia.org/wiki/Ring_networkhttp://en.wikipedia.org/wiki/Hub-and-spokehttp://en.wikipedia.org/wiki/Mesh_networkinghttp://en.wikipedia.org/wiki/Network_topologyhttp://en.wikipedia.org/wiki/Network_topologyhttp://en.wikipedia.org/wiki/Mesh_networkinghttp://en.wikipedia.org/wiki/Hub-and-spokehttp://en.wikipedia.org/wiki/Ring_network


5/21

NS-052


i). Standardized Servicesii). Scalabilityiii). Reliabilityiv). QoSv). Service Management

1.10. The offered system shall support the following services:i). Dataii). Videoiii). Voiceiv). MPLS Core: IP/MPLSv). MPLS Layer 3 VPNs (end to end)vi). MPLS Layer 2 VPNs (end to end)vii). Virtual Private Wire Services (VPWS)viii). Virtual Private LAN Service (VPLS)ix). Ethernetx). E-Line (EPL, VPL, Ethernet Internet Access (EIA), IP VPNs, etc.)

xi). E-LAN (Multipoint L2 VPN, transparent LAN Services, Multicastnetworks)

xii). E-Tree (Point to multi Point)xiii). Ethernet over MPLS (EoMPLS)xiv). Ethernet: Q-in-Q, MAC-in-MAC, and MPLS TE

1.10.1.The offered solution shall be used to:i). Deliver L2/L3 VPN services through existing service

activator/provisioning system to:

a. Ethernet to the home (ETTH)b. Ethernet to the business (ETTB)c. Ethernet between offices

d. Existing DSLAM aggregation via MPLS core deployments based onMPLS VPNsii). Deliver Converged data via MPLS VPNs, voice via MPLS VPNs and

video via L2 or IP or MVPN P2MP LSP (Triple-play) services based on

MPLS VPNs on 2*10GE Broadband Network Core enable with RSVP-

TE and Diffserv TE.iii). Redundancy solution for DSLAM aggregation with VRRP or Multi

chassis cluster solution

iv). Backhauling different traffic types including CDMA and upcoming LTEand GPON technologies

1.10.2.The offered system shall implement the port-/application-/flow-based bandwidth

control mode. The solution shall inter-work with MPLS VPN service of devicesfrom other mainstream vendors.1.11. High port density with full duplex processing power and wire speed routing and

switching.

1.11.1.The offered system shall support the following Interfaces:i). 100BASE-FX/1000BASE-X (SFP).ii). 10GE


6/21

NS-052


iii). 40GEiv). 100GE

1.11.2.PTCL has planned to transform SDH based metro network to IP based network inphased manner. Bidders to state whether the support of following interfaces is

available in the offered solution.i). STM1ii).STM4iii).STM16iv).STM64

1.11.2.1. If support of above interfaces is available, bidder to state how they plan toimplement.

1.11.2.2. If support of above interfaces is not available, bidder to state how this TDMinterfaces, if required, can be transported over Metro Ethernet network

1.11.3.Optical/electrical interfaces support is required.1.12. Enhanced QoS and Synchronization support:

1.12.1.The offered system shall have MPLS, QoS, Multicast and IPv6 features providingGigabit Ethernet access for both fiber and copper deployments. The offered

system shall have QoS features including Layer 2 QoS 802.1p, HQoS, DSCP/IP

Precedence trust and marking.1.12.2.The offered system shall have support for Time-based QoS, Profile-based QoS,

Policy-based QoS, Layer 2 and Layer 3 QoS facilitating tiered Ethernet service

offerings through rate limiting and traffic shaping.1.12.3.The offered system shall provide mechanisms such as hardware-based flow

classification, accounting, multicast and rate restriction etc.

1.12.4.Priority queuing, flow metering and policing (IEEE 802.1Q), congestionnotification (IEEE 802.1au), drop precedence (802.1ad), precision time

synchronization (IEEE 1588 latest version), and packet network frequencysynchronization (ITU-T G.8261), or their latest versions.

1.13. Traffic Control Functions:1.13.1.The offered system shall support Port Mirroring, Class of Service (CoS), Rate

Limiting (based on source and destination IP address, source and destination

MAC address, Layer 4 TCP/UDP information, or any combination of these fields,using QoS ACLs), Broadcast Strom Control, IGMP Snooping and Extended

Access Control List (ACL) etc.

1.13.2.The offered system shall have traffic shaping, traffic engineering and TrafficManagement features.

1.13.3.The offered system shall have Hierarchical QoS feature.

1.14. Network Management:1.14.1.The offered system shall have different Management options including CLI, GUIand web based Management.

1.14.2.The offered system shall have in-band as well as out-of-band managementcapability via Telnet mode (CLI) and SNMP (GUI), in addition to having FCAPS

capability.1.14.3.The offered system shall support Ethernet OAM (802.1ag, 802.3ah and E-LMI).


7/21

NS-052


1.14.4.The offered system shall be possible to export Performance and Fault data tothird-party management systems including HP OpenView and ComputerAssociates Unicenter software, to provide a complete consolidated view of

network operations.

1.14.5.The offered system shall support Static routing and Routing protocols including

RIPv1/v2, OSPF, BGP and IS-IS.1.15. Ethernet OAM and Management support:1.15.1.IEEE802.1ag (Connectivity Fault Management (CFM), ITU-T Recommendation

Y.1731 (OAM functions and mechanisms for Ethernet based networks),Restoration technologies (e.g., xSTP, IEEE 802.1aq), ITU-T Recommendation

G.8031 (Ethernet linear protection switching), G.8032 (Ethernet ring protection

switching) or equivalent.1.15.2.MPLS OAM support.1.16. Bidirectional Forwarding Detection (BFD) Support:1.16.1.The offered system shall support Bidirectional Forwarding Detection (BFD) and

Virtual Router Redundancy Protocol (VRRP) or equivalent.

1.16.2.The offered system shall be able to support fast failure detection in terms of BFDin hardware and software, independently of media, data protocols and different

routing protocols including.

i). BFD for MPLS LSPs (draft-ietf-bfd-mpls-02.txt or equivalent)ii).BFD for Multihop Paths (draft-ietf-bfd-multihop-03.txt or equivalent)iii).BFD for IPv4 and IPv6 (Single Hop) (draft-ietf-bfd-v4v6-1hop-04.txt or

equivalent)1.16.3.The vendor shall list all the client protocols which use BFD.1.17. Multicast Routing Protocol Support:1.17.1.The offered solution shall support at least the following multicast routing

protocols:

i). IGMP (all versions including v1, v2, v3)ii).PIM-SM (Protocol Independent Multicast-Sparse Mode)iii).PIM-SSM (Protocol Independent Multicast-Source Specific Multicast)iv).PIM-DM (Protocol Independent Multicast-Dense Mode) (optional)v). Bi-Directional PIM (Preferable)vi).DVMRP (Distance Vector Multicast Routing Protocol)vii). MSDP (Multicast Source Discovery Protocol)

1.17.2.PIM-SM (RFC 2362 + IETF Draft), PIM-DM (IEFT Draft), IGMPv1, v2, v3(RFC 3376), SSM (RFC 3569), MBGP (RFC 2858), MSDP (RFC 3618), IGMPsnooping, IGMP filtering.

1.18. Standards Compliance:

1.18.1.The offered system shall be MEF (Metro Ethernet Forum) compliant.1.18.2.It shall be Network Equipment Building Standards Level 3 (NEBS3) and ETSIcompliant or equivalent.

1.18.3.The offered solution shall comply the following standards:i). MEF Standards (MEF 9, MEF 10, MEF 14 etc.)ii). IEEE (1588v2) complianceiii). IETF


8/21

NS-052


iv). ITU-Tv). MFA Forumvi). DSL Forum (TR-101, TR-059, TR-069) compliancevii). TMF Forum

1.18.4.The offered solution shall comply to the following IEEE 802 Standards and

protocols:i). IEEE 802.1D Spanning Tree Protocolii). IEEE 802.1P CoS classificationiii). IEEE 802.1Q (Q-in-Q) VLANiv). IEEE 802.1s Multiple instances of Spanning Tree Protocol (MSTP)v). IEEE 802.1w Rapid reconfiguration of Spanning Tree Protocolvi). IEEE 802.1x Port Access Controlvii). IEEE 802.3ad Link Aggregation Control Protocolviii). IEEE 802.3ah Ethernet in the First Mileix). IEEE 802.1agx). IEEE 802.3x full duplex on 100BASE-TX and 1000BASE-T ports

xi). IEEE 802.3u 100BASE-Txii). IEEE 802.3ab 1000BASE-Txiii). IEEE 802.3z 1000BASE-Xxiv). Management: SNMP versions 1, 2, and 3

1.18.5.The offered solution shall comply to the following IETF Standards support:i). RFC 2544 Benchmarking Methodology for Network InterconnectDevicesii). RFC 768 User Datagram Protocoliii). RFC 783 TFTP Protocol (revision 2)iv). RFC 791 Internet Protocolv). RFC 792 Internet Control Message Protocol

vi). RFC 793 Transmission Control Protocolvii). RFC 826 Ethernet Address Resolution Protocolviii). RFC 854 Telnet Protocol Specificationix). RFC 1157 Simple Network Management Protocol (SNMP)x). RFC 1256 ICMP Router Discovery Messagesxi). RFC 1907 Management Information Base for Version 2 of the SimpleNetwork Management Protocol (SNMPv2)

xii). RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4,IPv6 and OSIxiii). RFC 2236 Internet Group Management Protocol, Version 2xiv). RFC 2863 The Interfaces Group MIB

xv). RFC 2668 Definitions of Managed Objects for IEEE 802.3 MediumAttachment Units (MAUs)xvi). RFC 2737 Entity MIB (Version 2)xvii). RFC 2495 Definitions of Managed Objects for the DS1, E1, DS2 andE2 Interface Types

xviii). RFC 4252 he Secure Shell (SSH) Authentication Protocolxix). RFC 4253 The Secure Shell (SSH) Transport Layer Protocol


9/21

NS-052


xx). RFC 2096 IP Forwarding Table MIBxxi). RFC 2668 Definitions of Managed Objects for IEEE 802.3 MediumAttachment Units (MAUs)

xxii). RFC 1213 Management Information Base for Network Managementof TCP/IP-based internets: MIB-II

xxiii). RFC 2737 Entity MIB (Version 2)xxiv). RFC 2863 The Interfaces Group MIBxxv). RFC 2495 Definitions of Managed Objects for the DS1, E1, DS2 andE2 Interface Typesxxvi). RFC 2558 Definitions of Managed Objects for the SONET/SDHInterface Type

1.19. IPv6 Support:1.19.1.The offered system shall support IPv6 protocol technologies, including IPv4 and

IPv6 dual protocol stacks, with transition technology when moving from IPv4 to

IPv6 such as manual or automatic configuration tunneling. It shall support IPv6

static routing, dynamic routing protocols such as BGP4/BGP4+, RIPng, OSPFv3

and ISISv6.1.19.2.The recently published IETF standards shall be followed.1.20. Security Features Support:1.20.1.The offered system shall have security features including Access Control Lists

(ACLs) and IEEE 802.1x authentication. ACLs on source and destination IP

addresses, protocol, port numbers etc. (capacity of the offered system to be

quoted).1.20.2.It shall provide security control functions based on user, address, application, and

port. It shall support port-based queues with different priorities, flow-based

ingress and egress bandwidth restriction, uRPF, anti-DDOS attack, SSH2.0

security management, 802.1x access authentication and transparent transmission,

and security functions such as VLAN ID, MAC address, port number, and IPaddress bundling. It shall also support Port Isolation, Packet filtering and DoS

attack prevention.1.20.3.Management Access Security:

i). AAA for RADIUS and TACACs+ii).SNMP V2c and SNMP V3

1.20.4.It shall have ability to generate logging information for security violations.1.20.5.Peer authentication at the start of session e.g. MD5 authentication for BGP, OSPF

etc.1.20.6.It shall have in-band security for DOS attack and hacking through filters, rate

limiting and session resource limiting.

1.20.7.It shall have port mirroring capability for monitoring purposes.1.20.8.It shall have capable to prevent MPLS label spoofing i.e. rejection of spoofedlabels.

1.21. Other Requirements:1.21.1.The convergence time shall be 50ms or less. Details of the same shall be

provided.1.21.2.The offered solution shall be supplied with the manufacturer-built or branded


10/21

NS-052


racks with perforated walls/doors in accordance with relevant ETSI specification.

The cabinets shall also have fans and temperature monitoring system.1.21.3.The bidder shall submit system functional block diagram of all main units of the

offered systems indicating the function of each block.

1.21.4.The bidder shall provide mechanisms for available technical assistance, escalation

levels etc. The bidder shall provide online high-level support/technical assistanceaccounts (if applicable).

1.21.5.It shall have Congestion avoidance capabilities and different service-levelagreements (SLAs) options.

1.21.6.Provisioning E2E with policy server or equivalent.1.21.7.Monitoring, logging and reporting for services that have been provisioned.1.21.8.Solution shall be provided with Service Activator (or equivalent) to provision

circuits.

1.21.9.Open NBI should be provide so that third party activator can be integrated.1.21.10. SNMP interface of the offered solution shall be opened for any third party

provisioning system.

1.21.11. Fully compliance of MPLS enabled applications with emerging developments.1.21.12. Graceful restart, failover and version or patch upgrade or any other mechanism.

2. NETWORK MANAGEMENT SYSTEM (NMS) SPECIFICATIONS

2.1.1. The bidder shall offer comprehensive NMS with Fault, Configuration,Accounting, Performance and Security (FCAPS) functionalities. All the offeredsolution components shall be manageable from offered NMS.

2.1.2. The offered NMS shall be based on North-Bound architecture and interface withthe PTCL Central Management NOC/Integrated NMS. It shall support the

standard interfacing protocols, like, CORBA, SNMP, etc.

2.1.3. For detailed Network Management System specifications, refer to currentPTCL specifications No. TR244.

3. FIREWALL/ SECURITY AND THREAT RESPONSE MANAGERSPECIFICATIONS

3.1. Architecture Requirements:3.1.1. Events per second: 10,000 or above.3.1.2. Flows per minute: 350,000 or above.3.2. Feature Requirements:3.2.1. Event collection, flow collection event processing, flow processing, correlation

and analysis.3.2.2. Real-Time security and network visibility.3.2.3. Data collection and providing network security, application and identity

awareness.

3.2.4. Embedded intelligence, effective threat management.3.2.5. Log management and reporting.3.2.6. Archive los and integrate with existing storage systems.


11/21

NS-052


3.2.7. Correlation rules.

3.3. Firewall Architecture Requirements3.3.1. Performance: 10 Gbps or above3.3.2. Concurrent sessions: 2 Million

3.3.3. 3 DES/AES VPN throughput: 1 Gbps3.4. Feature Requirements:3.4.1. The offered firewall shall permit, deny, encrypt, decrypt, orproxy all traffic

between different security domainsbased upon a set of rules and other criteria.3.4.2. The offered firewall shall have features including Packet filter, Application

gateway, Circuit-level gateway and Proxy server.

3.4.3. The offered firewall shall provide application layer filtering, proxy and Networkaddress translation.

3.4.4. The firewall shall have state-full inspection technology for application layercontrol policies. It should be able to support the blockage of TCP, UDP, and

RPC-based services securely. The firewall should employ application-layer

awareness to be able to block the services that utilize dynamically allocated ports.3.4.5. State-full packet filtering engine, which provides network access control and VPN

processing.

3.4.6. Support for routing mode - Functionality like proxies in routing mode:i). HTTP proxy that allows or denies connections based on source and

destination addresses, and provides filtering functions such as passing or

dropping Java applets cookies requests and responses and Active Xcontents.

ii). TELNET proxy should provide a virtual terminal relay, allows or deniesconnections based on source and destination addresses and performs user

authentication.

iii). FTP proxy that functions as a relay for ftp and controls connections basedon source and destination addresses and performs user authentication. Theproxy should limit access to certain commands such as put or get based onthese same criteria.

iv). SMTP proxy that provides a relay for electronic mail, and makes accessdeterminations based on source and destination addresses. Anti Spamfeatures should also be included.

3.4.7. Network Address Translation (NAT) for control over address translation.3.4.8. High Availability (HA) - Firewall software should rollover to second host without

losing screen or encryption sessions.

3.4.9. Log Management shall be available.

3.4.10.Graphical User Interface shall be available.3.4.11.Management from NMS. Details of the same shall be provided.3.4.12.Unlimited user license.3.4.13.Network attack detection.3.4.14.DoS and DDoS protection.3.4.15.TCP reassembly for fragmented packet protection.3.4.16.Brute force attack mitigation.
http://en.wikipedia.org/wiki/Encrypthttp://en.wikipedia.org/wiki/Decrypthttp://en.wikipedia.org/wiki/Proxy_serverhttp://en.wikipedia.org/wiki/Security_Domainshttp://en.wikipedia.org/wiki/Packet_filterhttp://en.wikipedia.org/wiki/Application_gatewayhttp://en.wikipedia.org/wiki/Application_gatewayhttp://en.wikipedia.org/wiki/Circuit-level_gatewayhttp://en.wikipedia.org/wiki/Proxy_serverhttp://en.wikipedia.org/wiki/Application_layer_firewallhttp://en.wikipedia.org/wiki/Application_layer_firewallhttp://en.wikipedia.org/wiki/Proxy_serverhttp://en.wikipedia.org/wiki/Circuit-level_gatewayhttp://en.wikipedia.org/wiki/Application_gatewayhttp://en.wikipedia.org/wiki/Application_gatewayhttp://en.wikipedia.org/wiki/Packet_filterhttp://en.wikipedia.org/wiki/Security_Domainshttp://en.wikipedia.org/wiki/Proxy_serverhttp://en.wikipedia.org/wiki/Decrypthttp://en.wikipedia.org/wiki/Encrypt


12/21

NS-052


3.4.17.SYN cookie protection.3.4.18.Zone-based IP spoofing.3.4.19.Malformed packet protection.3.5. Firewalls and IPS should work in complete failover mode (Active/Active or

Active/Standby).

3.6. Routing protocol (Static/Dynamic) may be configured between securityappliances and routers (Public and Private)/core switches.

3.7. Necessary access control should be applied at the security appliances (Firewalland IPS) and core switches.

4. RACK SPECIFICATIONS

4.1. Following are the minimum requirements:

Rack SizeBranded Enterprise Server 42U Rack with Cables, Rails, PDUs,cable routing & power management

KVM Switch Min 8 Port Switch with required cables

Rack Console17 TFT 1 U Rack Console Purpose built with Touchpad Mouse &

Keyboard

Blank Panels As and where required

4.2. Server racks shall be of 19 inch standard Steel ETSI racks.4.3. The racks will use natural airflow in such a way that there is no need for forced

air cooling of the system.

4.4. The racks shall be capable of accepting top or bottom power cable and top orbottom signal cable entry.

4.5. The Racks shall be capable for access to the equipment from front side.4.6. The Racks shall have Lockable doors and side panels to provide physical security

and help prevent unauthorized access to critical equipment.4.7. Doors and side panels shall be accessible with a single key, for increased security

the key cannot be removed in open / unlocked position. Both front and back doors

and side panels should be removable.4.8. The Racks shall have in built cable channels to allow systematic and easy routing

of data and power cables.

4.9. The Racks shall have two cable access slots in bottom and top for routing thecables and cords.

4.10. The Racks shall have exhaust fans (220V operated) on the top and in-flow fansunder bottom for forced air flow to keep the equipment under normal specific

environmental conditions.4.11. The Racks shall have adjustable mounting rails and removable doors and quick

release side panel.

4.12. The Racks shall be compatible with rack-mount servers of all major servermanufacturers such as Dell, Sun, Compaq, HP, and IBM.

4.13. The Racks shall be easy to mount hardware by means of screws, cage nuts, bolts


13/21

NS-052


washers and brackets, the bidder shall provide all type of accessories required for

mounting with each rack.4.14. The Racks shall be compatible with industry standard EIA 310-D specification.4.15. The bidder shall provide the hard painted racks with color matching of I.T

equipment.

5. DC POWER SYSTEMS AND UPS SPECIFICATIONS

5.1. DC Power systems and Allied equipment:5.1.1. For detailed Power systems specifications; refer to current PTCL specifications

No. SW-030.

5.2. Uninterruptible Power Supply (UPS):5.2.1. For detailed UPS specifications; refer to current PTCL specifications No. SW -

058.

6. GENERAL REQUIREMENTS

6.1. DELIVERY OF COMPLETE SYSTEM

6.1.1. The System to be delivered by successful bidder must be complete system in itselfincluding all installation material required for installation of the system. Any item

required necessarily for a complete system according to PTCL specifications /

bidders compliance statement, if found short, must be delivered to PTCL withoutadditional cost to PTCL.

6.1.2. The bidder must include in his proposal the detailed technical information,drawing and functional descriptions of the offered equipment to support the

Compliance to the technical requirement. The bidder shall mention in theproposal, the types of interfaces available along with port densities in the offered

equipment.6.1.3. The bids will be evaluated on the basis of compliance statement. The successful

bidder will be required to deliver equipment in accordance with the compliancestatement.

6.1.4. For the execution of the works the bidder undertakes to supply all hardware andsoftware including equipment, installation material, interfacing units, mountingracks etc, as detailed in these specifications that shall be necessary for a complete

functioning entity. Any other fittings or accessories like jumper wire etc under

scope of work which may not have specifically been mentioned in the contract,

but which are necessary to meet the specifications shall be provided by thecontractor without any extra charges to PTCL.

v). Hardwarevi). Softwarevii). Power cablingviii). Network synchronizationix). Spare Partsx). Installation materials


14/21

NS-052


xi). Services (Engineering, Installation.)xii). Trainingxiii). All other necessary items (Documentation etc.)xiv). Management of storage accommodation for goods, equipment and

material at site.

xv). Tool, jigs, fixtures & appliances for installation, Testing.xvi). Input output Devices.

6.2. CLAUSE BY CLAUSE COMPLIANCE STATEMENT

6.2.1.The Bidder must furnish a clause-by-clause compliance for each and everyclause / sub-clause of the technical specification as well as Scope of Work (SoW)attached with this RFP. As far as possible, the bidder must provide the detailed

technical description for each compliance statement. The page number shall be

indicated whenever an attached document is referred. More over the softcopy of

the compliance statement shall contain the hyperlinks to the reference documents.

6.2.2. The following terms must be used for preparation of compliance statement:i). FULLY COMPLIANT, if the systems and functions offered fully meet

the tender requirement. If any ambiguous comment is added in front of

FULLY COMPLIANT then PTCL may interpret it as PARTIALLYCOMPLIANT or NON-COMPLIANT.

ii). PARTIALLY COMPLIANT, if the systems and functions offeredpartially meet the tender requirement. The reason why the offer is partiallycompliant must be stated. If the bidder is able to fulfill the specified

requirement later, the time schedule for this must also be stated. In such

cases, the bidder must clearly mention the extent to which other

requirements or specifications are affected.

iii). NON COMPLIANT, if the systems and functions offered cannot meetthe requirements, the bidder must also state the reasons for it.6.2.3. In case of absence or unclear statements of compliance for any specified

requirement, PTCL will interpret that particular requirement as being NON

COMPLIANT.

6.2.4. The bidder shall submit clause-by-clause technical compliance according to theformat as under with the bid:

Clause

No.

Complied Non

Complied

Partially

Complied

Deviation/Details

in case of Partially

Compliance

Hyperlinks to

the referenced

documents (of

soft copy).

6.2.5. For every clause, the bidder must mention in the same table the reference ofdocument (document name/number and page number) where evidence has been

provided in support of the Clause. If the evidence section is left blank, then theclause will be considered as "Non-Compliant. The bidder shall include in his


15/21

NS-052


proposal the detailed technical information, drawings and functional descriptions

of the offered equipment to provide the compliance to the technical requirements.6.2.6. The documents submitted with the bid shall be in appropriate format and well

organized. A table of contents must be attached in the beginning of the document.

6.2.7. Responses from the bidders shall be a valid part of the contractual commitment

process. Any clarification against a query if received and agreed by the PTCL willstand as a condition of the contract for which potential penalties could be

levied if it is felt necessary and contractually correct.

6.2.8. The Query shall be submitter according to the following format:i). Tender/contract No:ii). Title of Project:iii). bidder's Name:iv). Query No:

S No. RelevantDocument

ClauseNo /Page

No

OriginalStatement

Question Response

6.2.9. PTCL may ask any bidder to raise the standard and capability of its offeredsystem to match with better standard or capability of the system offered by its

competitor for PTCL required network.6.2.10.PTCL reserves the right to add (on the quoted price) or drop any item in the order

placed on the successful bidder.

6.2.11.Along the statement of compliance the bidder shall submit in the technicalproposal an un-priced BoQ of the offered items for technical evaluation.

6.3. TRAINING6.3.1. The bidder shall conduct in-depth training to PTCL staff in installation, operation

and maintenance of the offered system for a period of 2 weeks.6.3.2. The course shall include items including technology, system architecture,

installation, configuration, troubleshooting, QoS, security, capacity planning

techniques and integration with PTCL network.6.3.3. The training shall be done by certified/ experienced instructor.6.3.4. Installation/configuration/testing of at least one complete system must be

demonstrated during training.6.3.5. Hard and soft copies of training material shall be provided to each trainee.

6.4. SUPPLY RECORD

6.4.1. The offered system must be field-proven, employing sound engineering practices,state of the art technology and capable of operating continuously with a very high

degree of reliability.

6.4.2. The bidder must provide record of supply to show past experience of the"supplier". The record of supply must include information on the count year of


16/21

NS-052


installation, the type of system supplied, and capacity of the system application

detailing:i). Names and address of the operator: A brief introduction of the operator

must be presented along with its total subscriber lines. Official web site of

the operator must be provided.

ii). Date of supply / commissioningiii). Equipment details or type of systemiv). System capacity

6.4.3. Documentary evidence must be provided by the bidder that the solution is incommercial operation with telecommunication operators of repute for at least two

years. Two years will be counted from the date of cut over of the system. The

certificate for satisfactory working of the system from the telecommunicationoperators shall be appended. PTCL reserves the right to reject any proposal,

which has poor record of supply and to investigate/ask for more detailed

information on any records and the bidder must respond promptly.

6.5. ENVIRONMENTAL CONDITIONS

6.5.1. The offered system shall operate and guarantee the stated performancerequirements under the following environmental conditions:i). Ambient temperature: 0C to 45Cii). Relative Humidity: Up to 95% (non condensing)iii). Storage temperature: -30 to 55C

6.5.2. The bidder shall mention the temperature and humidity range of the offeredsystem.

6.6. POWER SUPPLY REQUIREMENTS

6.6.1. The offered equipment shall operate on DC Power Supply -48V DC. However,the option of AC power supply (220 VAC; 50 to 60 Hz) should also bementioned.

6.6.2. The guaranteed performance of the equipment must be maintained for thefollowing variations of power supply (as measured at the power input to eachrack):

i). Voltage variation: 20%ii). AC ripple: Up to 0.5V peak to peak

6.6.3. The power consumption of the system (fully equipped) must be stated by thebidders.

6.6.4. For the power systems refer to PTCL specifications No.SW-030 (attached).6.6.5. For the UPS refer to PTCL specifications No.SW-058 (attached).

6.7. PROTECTION AND EARTHING


17/21

NS-052


6.7.1. The equipment power earths must be connected to the stations earth terminal.6.7.2. The system supplied shall be protected from damage caused by accidental

reversal of power supply polarity.

6.7.3. The offered equipment shall, without permanent damage or degradation ofperformance, withstand surges applied at power input terminals and all interfaces

in accordance with ITU-T and FCC standards. The bidder shall specify thestandards that their offered equipment complied to.

6.8. WARRANTY

6.8.1. The warranty provided must be for one year from the date of PAC (with parts andlabor).

6.8.2. The supplier must be required to arrange repair of faulty modules for a period of10 years after expiry of warranty period, at cost to PTCL indicated in the bid.

6.9. HANDBOOKS AND DOCUMENTATION

6.9.1. The handbooks and documentations must contain all relevant information on thesystem architecture/ components, operations, trouble shooting, fault diagnosis,

routine and preventive maintenance procedures.6.9.2. Design Diagrams including Installation drawings showing complete equipment

installation, location and dimensions, equipment nomenclature or other reference

materials used in installation and working of the system shall be supplied.6.9.3. Site-wise network connectivity and single line diagrams of offered solution,

power systems/ UPS shall be provided.

6.10. MAINTENANCE SUPPORT AND SPARE PARTS

6.10.1.The bidder must recommend and list full details of spare parts required for themaintenance of the system for a period of five years.

6.10.2.The bidder must provide spares needed for replacement of faulty modules duringthe warranty period at its own cost. These spares must be handed over to PTCL to

be used during warranty period.6.10.3.5% of each kind of modules supplied must be offered as spares, which must be

included in evaluation.

6.10.4.The bidder should have local competence in Pakistan to support PTCL during andafter implementation.

6.10.5.Refer to TOR-07 for further details (This document is generic guidelines for the

potential bidders defining the scope of Operation and Maintenance (O&M) andRepair services that would further elaborate the maintenance and repairrequirements in term of level, response time and turnaround time for repair of

modules).

6.10.6.The bidder shall ensure maintenance and repair of offered third party equipmentincluding power systems (D.G Sets, batteries, Rectifiers, UPS, air Conditioners


18/21

NS-052


etc.) and IT equipment (Servers, Local Maintenance terminals, desktop etc.) after

the expiry of warranty period. Details of the same shall be provided.

6.11. PROVISIONAL ACCEPTANCE TESTING (PAT)

6.11.1.After installation, the offered system/ solution shall be subjected to acceptancetesting according to an agreed procedure.

6.11.2.The bidder shall furnish detailed Acceptance Test Procedure (ATP) well beforethe scheduled testing date for Approval. It shall include tests procedures to beconducted for acceptance. PTCL PAT guidelines GL-05 (latest) shall be followed.

6.11.3.The bidder will be responsible to arrange test equipments and other necessaryassistance required for PAT execution.

6.11.4.The result of Acceptance tests shall be documented to PTCL for approval prior toissuing of the certificate of Acceptance.

6.12. INTEGRATION /INTER-WORKING WITH PTCL NETWORK

6.12.1.The offered system shall integrate with PTCL OSS/BSS/B&CC system, MM&BBcore network and NOC. The bidder shall provide all the necessary interfaces in

accordance with PTCL requirements (prevailing policies and workflows).6.12.2.The bidder shall provide a centralized interface for automated provisioning of

services.

6.12.3.The provisioning interface may be one of the following:i). Web Services (XML/HTTP or XML/TCP socket).ii). Application Programming Interfaces (APIs) / Libraries for Java, C or

CORBA.

iii). Command Line Interfaces (CLIs).

6.12.4.The offered system must have Online CDR capability. The bidder shall explainthe CDR format, which should be in conformity with the PTCL existing billingsystem.

6.13. LAWFUL INTERCEPTION (LI) COMPLIANCE

6.13.1.The offered system shall be Lawful Interception (LI) compliant. Replication androuting of both signaling messages and media flows for lawful intercept

requirements shall be supported.6.13.2.Support for number of monitoring agencies shall be described by the bidder.6.13.3.The handling and assignment of intercepted party shall be accomplished at least

based on Phone Number, IP Address and MAC Address.6.13.4.LI design and features shall support and comply the standard rules andrecommendations including GPP/ETSI/CALEA, ESTI-ES101 671, ETSI ES201

671, 3GPP 33.106, 33.107, 33.108 and CALEA/J-STD-25.

6.13.5.Handover interfaces shall be standard HI1, HI2 and HI3.6.13.6.The offered system must have interoperability with the ATIS systems GmbHs

suite of lawful interception and monitoring solutions which includes interception,


19/21

NS-052


mediation, monitoring and processing / analysis of packet- and circuit-switched

communications networks.

6.14. QUALITY ASSURANCE

6.14.1.The bidder shall guarantee that the quality of the manufactured equipment shall inno way, deviate from International standards and recommendations.

6.14.2.The bidder will ensure that equipment supplied shall be the latest model availablein the market.

6.14.3.The bidder will ensure that no part of the equipment supplied is refurbished.6.14.4.The bidder shall not quote End of sale and End of Life products/services. The

bidder shall also provide life cycle of the offered network components.

6.15. PROOF OF CONCEPT (POC)

6.15.1.PTCL may require conducting a trial run for proof of concept of selected product

for about two months or site visit. The bidder has to concur & fulfill thisrequirement without any cost & obligations to PTCL. Details will be provided

upon requirement.

6.16. RESERVATION OF RIGHTS

6.16.1.PTCL reserves the right to add (on the quoted price) or drop any item in the orderplaced on the successful bidder.

6.16.2.PTCL cannot guarantee that any of the requirements, standards, regulations, andconditions of this specification are not covered or protected by copyright or patent

of a third party.

6.17. REDUNDANCY

6.17.1.The bidder shall specify survivability, configurability & bandwidth controlarchitecture of the offered solution.

6.17.2.The bidder shall specify redundancy/ resiliency architecture of the offered systemincluding sever (CPU/ HDD etc.), power, HVAC, back up media & IP WAN link,

high availability (cluster solution with 99.999% compliance), remote failover and

load balancing of the offered solution.6.17.3.The bidder shall specify system licensing structure for software/ users and shall

specify different user slabs, if it is per user based.

7. INFORMATION TEMPLATE

7.1. The bidder shall provide response to the following Information Template withsupporting documents for each quoted item (in excel format).

INFORMATION TEMPLATE


20/21

NS-052


1. Product Name2. Equipment Model3. Function (Access/ Metro Aggregation/ Core Node)4. Form Factor (unit height)

5. Indoor/ Outdoor unit6. Number of slots7. Slot capacity (Mbps)8. Chassis backplane capacity (Mbps/ Gbps)9. Forwarding Rate/ Throughput (Mpps)10.Interfaces (GE, 10 GE etc.)11.Number of Interfaces per card12.Type of uplinks:

12.1. GE, 10 GE12.2. STM1, STM4, STM16, STM6412.3. 40GE

12.4. 100GE13.Power Supply (AC/ DC)14.System power consumption (Fully loaded)15.Redundancy

15.1. Control unit15.2. Power supply15.3. Fan15.4. Switching fabric/ Routing engine

16.MTBF17.Services support18.Layer 2 Protocols support

19.Routing Protocols support20.IP Multicast support21.Other protocols support22.MPLS support23.DWDM support24.Standards support25.QoS support26.Synchronization support (rfc 1588, ref 1588v2)27.Rfc 2544 support28.Security Features Support:29.Maximum upgradable capacity

30.Network Management System (NMS)31.Hardware/ software platform32.FCAPS functionality33.NMS/NBI interfaces and availability34.Performance Monitoring and Reporting Tools35.Licensing structure and details36.Billing Interfaces and availability


21/21

NS-052


37.LI Compliance38.Convergence time39.IPv6 support40.Third party equipment41.Maintenance and repair of third party equipment

42.Any other additional feature

End of Specifications

NS-052 (Metro Ethernet Specs_Issue-III_Nov_ 2012)

Documents

Transcript of NS-052 (Metro Ethernet Specs_Issue-III_Nov_ 2012)