MS Word document
advertisement
North Florida Broadband Authority NFBA Project Office 1500 Mahan Drive, Suite 100 Tallahassee, FL 32308 Phone: 850-325-1125 Fax: 850-325-1128 Email: nfbamail@portal.airewire.com North Florida Broadband Authority Request for Proposals Data Center Equipment NFBA RFP #2011-05 October 01, 2010 NFBA RFP #2011-05 Page 1 North Florida Broadband Authority Table of Contents Section 1: Notice to Prospective Respondents .................................................................................................. 3 Section 2: Project Overview ............................................................................................................................... 3 Section 3: Issuing Entity .................................................................................................................................... 4 Section 4: Prime Equipment .............................................................................................................................. 4 Section 5: NFBA Procurement Process ............................................................................................................. 7 Section 6: Proposal Guidelines ........................................................................................................................ 10 Section 7: Proposal Evaluation Criteria ............................................................................................................ 12 Section 8: Requirements ................................................................................................................................. 12 Attachment A: Proposed Contract Form ....................................................................................................... 40 Attachment B: Certification ........................................................................................................................... 48 Attachment C: References ........................................................................................................................... 49 Attachment D: Public Entity Crimes (For Information Purposes Only) .......................................................... 50 Attachment E: Drug – Free Workplace Certification (Optional) ..................................................................... 51 Attachment F: Equal Opportunity Employer (EOE) Statement ...................................................................... 52 Attachment G: MBE/WBE/DBE Business Participation ................................................................................ 53 Attachment H: Conflict of Interest Statement ................................................................................................ 54 Attachment I: Business and Technical Resources........................................................................................ 55 Attachment J: Pricing Information ................................................................................................................ 56 Attachment K: Product Component Data Sheets.......................................................................................... 57 Attachment L: Requested Responses .......................................................................................................... 58 MBE/WBE/DBE businesses are encouraged to participate. The North Florida Broadband Authority supports Equal Opportunity Employment and Drug Free Workplace policies NFBA RFP #2011-05 Page 2 North Florida Broadband Authority Section 1: Notice to Prospective Respondents 1.1 Notice is hereby given that the North Florida Broadband Authority (the “NFBA”) will accept proposals from qualified respondents for Data Center Equipment. Sealed proposals will be accepted at: North Florida Broadband Authority c/o: NFBA General Manager - Government Services Group 1500 Mahan Drive, Suite 250 Tallahassee, FL 32308 1.2 Proposals will be accepted until 5:00 PM EDT, November 1, 2010. 1.3 The North Florida Broadband Authority is an inter-governmental utility authority. In 2009, the NFBA applied for funding under the American Recovery and Reinvestment Act (ARRA) to build a Wireless Broadband Middle Mile Network (the “Network”) to serve 15 counties in north central Florida. In early 2010, the National Telecommunications and Information Administration (NTIA), Department of Commerce, awarded ARRA BTOP funds to the NFBA to deploy the new network. 1.4 The current estimated time-frame for completion of the Network is in the next 18-24 months. Therefore, time is of the essence in selecting qualified respondents to provide products and services necessary for successful deployment of the Network. Section 2: Project Overview 2.1 The NFBA Wireless Broadband Middle Mile Network will be owned and operated by the NFBA. The Network will be mainly a microwave system offering: • High speed, high capacity Ethernet backhaul throughout the Network’s service area; • Multiple inter-connection points to one or more fiber networks supporting the public internet; and • Inter-connection points to local (last mile) service providers, anchor institutions, and other Network tenants. 2.2 The Network will support ubiquitous broadband Internet access and other IP communications services for local communities, governmental entities, businesses, anchor institutions (schools, health care, libraries, public buildings, public safety, etc.), and last mile providers within or near the Network’s service area consisting of its member counties. The main purpose of the Network is to provide non-discriminatory, affordable, and scalable fixed broadband wireless infrastructure supporting Internet access for all constituencies as well as last mile providers who implement local access connections to the Network. 2.3 The NFBA is working to deploy the Network at the lowest practicable cost to provide affordable high quality, high speed Internet connectivity where it is currently unavailable or inaccessible in the service area. NFBA RFP #2011-05 Page 3 North Florida Broadband Authority Section 3: Issuing Entity 3.1 NFBA Organization 3.1.1 Counties Baker Gilchrist Levy Taylor The North Florida Broadband Authority members include the following: Municipalities City of Cedar Key City of Perry Bradford Lafayette Madison Union Columbia Hamilton Putnam Wakulla Dixie Jefferson Suwannee City of Lake City City of Worthington Springs City of Live Oak Town of Cross City City of Monticello Town of White Springs 3.1.2 Government Services Group, Inc., located in Tallahassee, FL, serves as the NFBA General Manager. 3.1.3 AireWire, Inc., located in Tallahassee, FL, is the NFBA Project Manager (including the NFBA Project Management Office or “PMO”). 3.1.4 Rapid Systems, Inc., located in Tampa, FL, is the NFBA Network Engineer. 3.2 For additional information about the NFBA, the federal award, and the proposed wireless broadband Middle Mile Network, please visit the NFBA’s website at www.nfba-fl.org. 3.3 The NFBA Board of Directors holds public meetings on the second Wednesday of every month at 2:00 PM in the Suwannee River Water Management Office, 9225 County Road 49, Live Oak, FL 32060. The agenda for each upcoming meeting and the minutes from each previous meeting can be found at the NFBA website. Section 4: Prime Equipment 4.1 This document outlines the “Data Center Equipment” requirements, to support the North Florida Broadband Authority’s Network. 4.2 This document outlines the requirements for the Data Center Equipment for approximately 2 core data center located in the NFBA service territory. The core data centers are part of a fixed wireless network and all installations shall adhere to the highest telecom industry standards. 4.3 The respondent shall provide price quotes for 4.3.1 Firewall Each datacenter will have a highly redundant and scalable firewall. The firewall will protect the NFBA’s DNS architecture, time servers, and other equipment that needs to be secured. The firewall should run at wire speed with virtually no latency. The system also has to be highly reliable with replaceable fan trays and redundant power supplies. A management application will be utilized to correlate events between data centers. Four (4) Highly Redundant firewall appliances with a centralized management application each with: a. Two (2) 10 gig Ethernet interfaces or four 1 gig Ethernet interfaces NFBA RFP #2011-05 Page 4 North Florida Broadband Authority NFBA RFP #2011-05 Page 5 North Florida Broadband Authority 4.3.2 Intrusion Detection / Prevention Systems Each datacenter should have a highly redundant Intrusion Prevention / Detection system. The system should be able to integrate into the network so it represents less than 1 ms latency in parallel or pass through mode to total system latency. The system has to be highly reliable with replaceable fan trays and redundant power supplies. A management application will be utilized to correlate events between datacenters. a. Four (4) Highly Redundant intrusion detection systems with a centralized management application each with b. Two (2) 10 gig Ethernet interfaces or four (8) 1 gig Ethernet interfaces 4.3.3 Carrier Class Routers The North Florida Broadband Authority has two geographically diverse network datacenters interconnected by multi-gigabit and 10 gigabit Ethernet handoffs. Each datacenter will act as part of a highly redundant dual resilient core design attached to a minimum of four protected Ethernet rings, with a primary path located at the primary datacenter and a protected path located at a secondary datacenter. Two (2) Highly Redundant next-generation service provider routers each with: a. Sixteen (16) 10 gigabit Ethernet ports on a minimum of 2 separate blades b. Thirty two (32) 1 gigabit Ethernet ports on a minimum of 2 separate blades Each datacenter will also have multiple connections to different tier 1 internet service providers. The complete design is to offer 99.999% availability or greater . NFBA RFP #2011-05 Page 6 North Florida Broadband Authority Section 5: NFBA Procurement Process 5.1 Proposal Submission Process 5.1.1 Proposals must be received by the date and time specified below: 5.1.2 Proposals Due: 5:00 PM EDT on November 1, 2010. 5.1.3 Proposals received after the due date and time will not be accepted and will be returned to the respondent. 5.1.4 Delivery Instructions: Please send one (1) signed original marked “Original” and eight (8) copies marked ”Copy” of the entire proposal. All printed copies of the proposal must be delivered in a sealed envelope with the notation NFBA RFP #2011-05 and the address below clearly shown on the face of the envelope to: North Florida Broadband Authority c/o NFBA System Manager-Government Services Group 1500 Mahan Drive, Suite 250 Tallahassee, FL 32308 5.1.5 5.2 Respondents wishing to submit proposals for multiple NFBA Equipment RFPs are required to submit separate responses to each RFP. Procurement Schedule Release of RFP Pre-Proposal Conference Deadline for Written Questions Deadline for Submission of Proposal Proposal Opening Date Anticipated Selection Committee Meeting If needed 2nd Selection Committee Meeting NFBA Board Approval October 1, 2010 October 8, 2010 October 15, 2010 November 1, 2010 November 2, 2010 November 18, 2010 November 29, 2010 December 8, 2010 5.2.1 The NFBA will host a Pre-Proposal Conference starting at 10:00 a.m. EDT on October 8, 2010 at the Monroe Street Conference Center, 2714 Graves Road, Tallahassee, Florida, and attendance at the PreProposal Conference is not mandatory. The Pre-Proposal Conference may be attended in person or by webex. Please visit the NFBA website on October 04, 2010 for information about the Pre-Proposal Conference agenda, when this specific RFP will be discussed during the Conference, and to obtain instructions for joining the Pre-Proposal Conference by webex (which will include a call-in number for conference call participants). 5.2.2 NFBA Selection Committee will meet in two public meetings at the Suwannee River Water Management District Office, 9225 County Road 49, Live Oak, Florida NFBA RFP #2011-05 November 18, 2010 starting 10:00 a.m. EST Page 7 North Florida Broadband Authority 5.3 5.4 5.5 November 29, 2010 starting 10:00 a.m. EST 5.2.3 The NFBA selection committee will announce its recommendations at the NFBA Board of Directors Meeting starting at 2:00 p.m. EST on December 8, 2010. The meeting will be held at the Suwannee River Water Management Office, 9225 County Road 49, Live Oak, Florida . 5.2.4 After the release of the RFP on October 1, 2010, please visit the NFBA website to determine if there are any changes to the meeting dates, venues, or instructions cited above. Communications Guidelines for Respondents/Cone of Silence 5.3.1 Any questions should be emailed to Faith Doyle at fdoyle@govmserv.com or faxed to 407-629-6963. All questions must be received by Faith Doyle by October 15, 2010, 5:00 PM Eastern Daylight Time. Answers to all questions will be promptly posted to the NFBA website by October 20, 2010, 5:00 PM Eastern Daylight Time. 5.3.2 Contact with any NFBA official including members of the NFBA Board of Directors, members of the Proposal Selection Committee, other NFBA officials (including staff), the NFBA General Manager, the NFBA Network Engineer (including staff), and the NFBA Project Manager (including staff), except as otherwise provided herein, is prohibited and may be grounds for disqualification. 5.3.3 After the proposal is issued, all communication by or with the NFBA and its representatives will cease, except for the scheduled meetings and written questions in the schedule outlined above, until ranking of the selected proposals has been approved by the Board of Directors. This “quiet period” or “cone of silence” will be rigorously enforced. If any respondent violates the quiet period, the respondent’s proposal will be disallowed. Addenda 5.4.1 The NFBA will record responses to inquiries and any additional submittal instructions in the form of written addenda to this RFP. All such information will be posted to the NFBA website. 5.4.2 If revision to the RFP becomes necessary for any reason, the NFBA will provide written addenda which will be posted on the NFBA website. 5.4.3 It is the responsibility of all respondents to visit the NFBA website regularly to obtain any updates. Each respondent should check the website on a daily basis. All respondents shall indicate by signing the Certification Page (Attachment B) that they have received and read the addenda posted on the website. Proposal Evaluation Process 5.5.1 The NFBA will evaluate all proposals received by the date and time due, and will select one or more qualified proposals. 5.5.2 The NFBA will evaluate all complete on-time proposals and will select the proposal(s) that, solely at the NFBA’s discretion, best meet the interests of the NFBA. 5.5.3 The NFBA maintains the right to request clarifications of information submitted and to request additional information of any respondent. The NFBA shall be the sole judge of its own best interest and the qualifications of respondents. 5.5.4 Proposals will be scored and ranked using the evaluation criteria established in this RFP by an impartial NFBA selection committee. If necessary, qualified independent third-party reviewers may be engaged to provide subject matter expertise as required. NFBA RFP #2011-05 Page 8 North Florida Broadband Authority NFBA RFP #2011-05 Page 9 North Florida Broadband Authority 5.5.5 The selection committee may request additional information from a respondent only for the purpose of clarifying the respondent’s proposal. Such additional information will be requested in writing (electronic and/or hard copy) including an explanation as to the nature of the inquiry, instructions for responding, and deadline for submitting a response. Information submitted after the deadline for responding, will not be considered by the evaluation committee. 5.5.6 If the selection committee determines that additional information should be obtained from all valid respondents, all respondents will receive an identical request for information following the process described above. 5.5.7 At the conclusion of the selection committee’s evaluation, the committee will submit its findings and recommendations along with all scoring and ranking data to the NFBA Board. 5.5.8 Proposal rankings and award recommendations will be presented by the evaluation committee at the regular public meeting of the NFBA Board of Directors on December 8, 2010 (which is scheduled to begin at 2PM in the Suwannee River Water Management NFBA Office, 9225 County Road 49, Live Oak, FL 32060). At the meeting, the NFBA Board will vote on the selection of one or more awardees and proposed contracts are not final until approved by the board. 5.5.9 All decisions made by the NFBA Board will be final. 5.5.10 Final selection and contract negotiations will be governed by the laws and procurement regulations of the NFBA, the State of Florida, the BTOP and ARRA Programs and any other applicable regulations. 5.5.11 A proposed form Master Equipment Purchase Agreement is included herein as Attachment A for convenience. Respondents should review the proposed contract form and indicate any objections or requested changes to those standard terms and conditions within the proposal. Section 6: Proposal Guidelines 6.1 Proposal Requirements 6.1.1 The NFBA reserves the right to reject any or all proposals, or to waive any non-substantial irregularities in submittals whenever such rejection or waiver is in the best interest of the NFBA. In the event that all proposals are rejected or waived, the NFBA reserves the right to re-solicit for other qualified respondents. 6.1.2 All proposals must meet the requirements as they are stated and /or described in this RFP. 6.1.3 The deployment of the NFBA Network is contingent upon the continued receipt of ARRA BTOP funds. Although the disruption of funds is unlikely, all prospective respondents should be aware that this possibility exists. In the event of funds disruption: (a) the NFBA project schedule may be modified; (b) the project may be suspended, extended, or cancelled; and/or (c) the NFBA may delay or terminate contracts or orders as necessary. 6.1.4 Proposals received after the deadline set forth in Section 5.1 will be returned unopened to the respondent. Respondents may withdraw their submissions by notifying the NFBA in writing at any time prior to the deadline. 6.1.5 This RFP does not constitute an offer or a contract with the respondent. A contract or agreement is not implied until a contract is approved and executed by the NFBA. 6.1.6 The NFBA may choose, in the sole exercise of its discretion, to select all, some, or none of the proposals. NFBA RFP #2011-05 Page 10 North Florida Broadband Authority 6.2 6.1.7 Neither the NFBA nor its representatives will be liable for any expenses incurred by respondents in connection with preparation of a proposal pursuant to this RFP. Respondents should prepare their proposals simply and economically, providing a straight-forward, succinct, and concise description of equipment, prices, terms, and their ability to meet the requirements. 6.1.8 All proposals are subject to Public Records disclosure consistent with Chapter 119, Florida Statutes. Required Format 1. Letter of Transmittal - The letter should be brief and introductory in nature. The letter should state the name of the individual authorized to make commitments for the firm. The letter should also include a description of all partnerships, joint ventures and sub-contractors who will be part of the respondent’s team and an explanation of the exact nature of the relationship. 2. Table of Contents – Clearly identify the material by page number 3. Executive Summary – Brief summary of the proposal. Discuss the respondent’s experience and capabilities including information pertaining to the respondent’s ability to perform. 4. Attachment A: Proposed Contract Form 5. Attachment B: Certification 6. Attachment C: References 7. Attachment D: Public Entity Crimes(For Information Only) 8. Attachment E: Drug Free Workplace Certification(Optional) 9. Attachment F: Equal Opportunity Employer (EOE) Statement 10. Attachment G: MBE/WBE/DBE Business Participation 11. Attachment H: Conflict of Interest Statement 12. Attachment I: Business and Technical Resources 13. Attachment J: Pricing Information 14. Attachment K: Product Component Data Sheets 15. Attachment L: Requested Responses 16. A statement describing any special conditions or terms offered or required by the respondent. 17. Respondents may provide supplemental documentation to amplify or clarify information about their products and services. However, respondents may not furnish corporate brochures, marketing materials, sales collateral, annual reports, press releases, news articles, or other extraneous information about their firm or their products and services. NFBA RFP #2011-05 Page 11 North Florida Broadband Authority Section 7: Proposal Evaluation Criteria 7.1 7.2 Evaluation: Weighted Criteria Matrix CRITERIA WEIGHT Pricing 25% Ability to Meet Technical/Performance Requirements 30% Product Availability 15% Warranties 15% References 15% If a respondent to this RFP is currently a State of Florida contractor with a valid price/rate schedule currently in force, the NFBA expects to receive proposals from such respondents with pricing and financial terms (discounts, payment, etc.) that are consistent with or better than the respondent’s State of Florida contract. Such respondents are encouraged to: Identify any State of Florida contract(s): o o o Propose pricing and financial terms that are consistent with or better than the State contract(s). Identify any deviations from the State contract(s) that are specific to this RFP. Attach the specific State of Florida price/rate schedules with their proposal. Section 8: Requirements 8.1 The following section provides the technical requirements for the Data Center Equipment as required for the NFBA Network Project. Respondents must clearly describe how their products meet or exceed the requirements as stated. 8.2 Respondents offering specific components should clearly identify the components in their proposals, how the components meet the requirements stated in this RFP, and itemized pricing for each component. 8.3 Respondents must offer pricing that will remain firm for three years from the execution date of a Contract. There must be no price level increase for the 3 year period. 8.4 Discounts for volume purchases, minimum order quantities, or other financial incentives are invited and should be clearly described by the respondent in the proposal. 8.5 Proposals must itemize all additional (add-on) costs, if any, related to equipment warranties, maintenance, support, and other services not included in system/component pricing. Warranty periods and conditions should be clearly described. If the respondent offers special maintenance and/or support programs, such programs should also be clearly described with respondents pricing in Attachment “J” NFBA RFP #2011-05 Page 12 North Florida Broadband Authority NFBA RFP #2011-05 Page 13 North Florida Broadband Authority 8.6 All prices must include delivery free on board (FOB) to: North Florida Broadband Authority Field Office C/O Rapid Systems 1155 US Highway 17 Wauchula, Florida 33873 8.7 Delivery of all material, components, and equipment must be capable of being completed within 6 weeks after receipt of a purchase order to the address listed above in Wauchula, Florida. 8.8 The North Florida Broadband Authority is not subject to taxes and all pricing must reflect this. 8.9 Intentionally Left Blank 8.10 Intentionally Left Blank 8.11 Requirements for Firewall 8.11.1 Operational Environment Unified Platform – FW, VPN, IPS Maximum Firewall Throughput -10 Gbps (real-world HTTP), 20 Gbps (jumbo frames) Concurrent Sessions - 2,000,000 Security Contexts - Up to 50 Virtual Interfaces (VLANs) - 100 High Availability - Active/Active & Active/Standby Redundant Power Day-zero attack protection IP options as conformance to RFC 2113 IPS with IPv6 Detection SSL, DTLS, and IPSec-based full network access Network-aware site-to-site VPNs Supports port-based rules for IPv4 and network/IP access control lists (ACLs) for IPv6 Policy mapping from RADIUS and LDAP IPv6 support for IKEv1 LAN-to-LAN VPN connections Interface-Independent Access Policies Supports strong encryption, including AES-256 and 3DES-168 Layer 2-7 inspection Full stream reassembly Protocol decoding Tunneling protocol inspection Vulnerability-based protection Day-zero worm protection Protocol anomaly detection Statistical anomaly detection Application anomaly detection Evasion protection Custom signatures Block attacker Block connection Dynamic default blocking Real-time risk rating Signature updates 8.11.2 Input/output Ports and Connectors Two (2) - 10 Gig Ethernet ports Four (4) -1 Gigabit Ethernet ports NFBA RFP #2011-05 Page 14 North Florida Broadband Authority 8.11.3 Authentication options RADIUS RADIUS with Password Expiry (MSCHAPv2) to NT LAN Manager (NTLM) RADIUS one-time password (OTP) support (state/reply message attributes) RSA SecureID Embedded Certificate Authority (CA) Digital Certificate / Smartcard (including Machine Certificates for Cisco AnyConnect) LDAP with password expiry and aging Generic LDAP support Combined certificate and username/password multifactor authentication SSL VPN virtual keyboard authentication 8.11.4 Compliance FIPS 140-2 Level 2. In process: Common Criteria EAL4+ US DoD Application-Level Firewall for MediumRobustness Environments, and Common Criteria EAL4 for IPSec/SSL VPN UL 60950 FCC Part 15 Class A EN55022 Class A EN61000-3-2 EN61000-3-3 8.12 Operational Environment Requirements for IPS 8.12.1 Input/output Ports and Connectors Two (2) - 10 Gig Ethernet ports Four (4) - 1 Gig Ethernet ports 8.12.2 Management Requirement for IPS A single management platform to support IPS devices. 8.13 Requirements for Carrier Class Router 8.13.1 System Architecture Requirements 8.13.1.1 Modularity - all modules are field replaceable Modular HW Configuration Interface module Switch Controller Main Processors Switch Fabric Power Supply All required line-cards must support line card processing 8.13.1.2 Power Supply The platform supports redundant power supplies Power Supplies are Hot Swappable Power Supply Redundancy 1+1, 2+1 8.13.1.3 Cooling Fans In the case FANs are use used, the platform supports redundant cooling fans The platform has cooling fans with speed regulation depending on system temperature in order to reduce noise and power consumption NFBA RFP #2011-05 Page 15 North Florida Broadband Authority The cooling fans use EC (Electronically Commutated) motors in order to reduce power consumption 8.13.1.4 Installation Platform must fit into a standard 19'' rack (ETSI ETS 300 119-3) Indicate how many 19" units are needed for the platform. Provide the maximum number of units per 19'' rack (ETSI ETS 300 1193), taking powering, cooling and cable management into account The equipment must be NEBS Level 3 compliant 8.13.2 Operation & Management Requirements 8.13.2.1 Management Access & Protocols All Protocols for Management purposes support IPv4 All Protocols for Management purposes support IPv6 Platform is directly managed from external (not dedicated) management systems (OSS/BSS) via open interfaces Support of out-band and in-band management facilities The platform provides a local craft (console, serial) port for out-band management access Availability of an 10/100Base-T Ethernet Port for out-band Management The platform must support a CLI for in-band and out-band management purposes The platform supports TELNET and TACACS+ for authentication The platform supports SSHv2 for management purposes The platform supports Web based in-band management The platform supports at least 100 simultaneous remote access sessions Management prioritization: In-band and out-band management is not impacted by customer traffic (even under full load condition) Management prioritization: Describe the prioritization of the in-band and out-band management process versus customer traffic forwarding The platform supports TL1 for management purposes The platform supports MTNM for management purposes The platform supports RADIUS for management purposes The platform supports DIAMETER for management purposes 8.13.3 High Availability 8.13.3.1 Hardware Redundancy Platform must have redundancy in switch fabric. Loss of a single switch fabric element must not impact forwarding or router capacity, except for a brief loss of traffic, traffic loss must be less than 100 milliseconds. Platform must have redundant route processors. Hardware failure of the primary route processor must trigger a failover to the backup route processor without any intervention required. Hardware failure of the backup route processor must not impact operation of the primary route processor or forwarding of packets in the router. Platform must automatically synchronize the router configuration between the primary and redundant route processors. Platform must support online insertion and removal of all interface cards and all other redundant cards including redundant switch fabric cards redundant route processors redundant controller cards redundant fans redundant power supplies Insertion or removal of a card must only impact that specific card, with forwarding and control functions on other cards unaffected. This includes interface cards that are inserted and removed NFBA RFP #2011-05 Page 16 North Florida Broadband Authority from a host card, such as a SIP or FPC. Insertion and removal of these subtending cards must not impact other cards on the host card. 8.13.3.2 Software Upgrades The Platform Firmware/Software and configuration data is written in a storage media (as Flash Card, Hard Disk), that is easily exchangeable and upgradeable. Central server: Support of operating system and firmware download from a central server. Operating system and firmware upgrade on standby control blade can be performed without service interruption (customer impact). 8.13.3.3 Update/Upgrade Support of Stateful Failover Switchover from active to backup control blade can be manually triggered. 8.13.4 Platform Architecture Requirements All 10/100/1000TX Ethernet interfaces must support all required CoS functionality. Refer to separate CoS section of the requirements for all required CoSfunctionality. Platform must support 10/100/1000 TX Ethernet interfaces. Platform must support Ethernet, Fast Ethernet and Gigabit Ethernet over copper. Media and connectors supported must include copper twisted-pair using RJ-45 copper connector. Platform must support 10/100/1000 TX Ethernet interfaces, with auto MDI/MDI-X setting, auto speed negotiation (10, 100, and 1000 Mbps) and duplex mode (half or full) negotiation with attached devices Platform must support 10/100/1000 SFP based Ethernet interfaces with pluggable optics. Platform must support 10/100/1000 TX Ethernet interfaces, with Point to Point and Multicast switching technology support. Please refer to separate Multicast Section of the requirements for all required Multicast functionality. Platform must support 10/100/1000 TX Ethernet interfaces, with IPv6 support equal to IPv4 performance and scale. Please refer to separate IPv6 Section of the requirements for all required IPv6 functionality Platform must support Gigabit Ethernet interfaces. Platform must support pluggable optics for SX, LX, and LH interface types. Platform must support 10 Gigabit Ethernet interfaces. Platform must support pluggable optics. Pluggable optics for the following interface types must be available: LR, SR, and ER. Pluggable optics must NOT be respondent specific. Platform must support 10GE interfaces, with Point to Point and Multicast switching technology support. Please refer to separate Multicast Section of the requirements Platform must support Loopback Interface Platform must have the ability to recognize and report an up/up looped condition when a loopback is present for GE and 10 GE interfaces. Platform must support rate limiting inbound and outbound on 10/100/1000 TX, GE and 10 GE interfaces in increments of: 2-4-6-8-10, 15, 20-100 (in 10Mbps increments), 100Mbps- 1GE (in 100Mbps increments), 1GE-10GE (in 1GE increments) All Ethernet interface types (10/100/1000 and 10,000 must support jumbo frames of at least 9000 bytes. To be compliant, all Ethernet interfaces required for the platform must support 9000 byte jumbo frames. Platform must have the ability to combine layer-2 and layer-3 sub-interfaces on the same physical interface Platform must have the ability to support local VLAN's/port Platform must support Aggregate Ethernet for Gigabit Ethernet ports. The platform must support aggregate Ethernet bundles consisting of at least 6 active GE links per bundle. Aggregate Ethernet must support efficient distribution of Internet traffic over the GE elements of the Aggregate Ethernet bundle for IPv4, IPv6 traffic. NFBA RFP #2011-05 Page 17 North Florida Broadband Authority Platform must support Aggregate Ethernet for Gigabit Ethernet ports. The platform must support at least 32 separate aggregate Ethernet link bundles per chassis. Platform must support LACP for aggregated GigE bundles. Platform must support LACP for aggregated 10 GigE bundles. Platform must support Aggregate Ethernet for 10 Gigabit Ethernet ports. The platform must support aggregate Ethernet bundles consisting of at least 8 active 10GE links per bundle. Aggregate Ethernet must support efficient distribution of Internet traffic over the 10 GE elements of the Aggregate Ethernet bundle for IPv4 traffic and for MPLS encapsulated IPv4 and IPv6 traffic. Platform must support port mirroring 8.13.5 CoS 8.13.5.1 All functionality required in this section must be supported for all proposed interfaces. When providing responses, please provide the information related to performance at the interface line rate. All exceptions must be noted 8.13.5.2 Classifiers and schedulers Platform must have the ability to classify and schedule traffic based on COS Platform must have the ability to classify and schedule traffic based on IPv4 TOS Platform must have the ability to classify and schedule traffic based on IPv6 TOS Platform must have the ability to classify and schedule traffic based on IPv4 DSCP Platform must have the ability to classify and schedule traffic based on IPv6 DSCP Platform must have the ability to classify and schedule traffic based on MPLS EXP bits Platform must have the ability to classify and schedule traffic based on Source IP address Platform must have the ability to classify and schedule traffic based on Destination IP address Platform must have the ability to classify and schedule traffic based on Source UDP Platform must have the ability to classify and schedule traffic based on Destination UDP port Platform must have the ability to classify and schedule traffic based on Source TCP port Platform must have the ability to classify and schedule traffic based on Destination TCP port Platform must have the ability to classify and schedule traffic based on Source MAC address Platform must have the ability to classify and schedule traffic based on Destination MAC address Platform must have the ability to classify and schedule traffic based on VLAN ID. Platform must have the ability to classify and schedule traffic based on inner QinQVLAN tag Platform must have the ability to classify and schedule traffic based on outer QinQVLAN tag Platform must have the ability to classify and schedule traffic based on combination of inner and outer QinQ VLAN tag 8.13.5.3 Traffic Policing / Rate Limiting Platform must support Rate Limiting / policing for all proposed ingress interfaces Platform must support Rate Limiting / policing for all ingress VLANs Platform must support Rate Limiting / policing for all proposed egress interfaces Platform must support Rate Limiting / policing for all egress VLANs Platform must support policing of traffic based on VLAN ID Platform must support policing of traffic based on CoS Platform must support policing of traffic based on DSCP Platform must support policing of traffic based on TOS Platform must support policing of traffic based on MPLS EXP Platform must support policing of traffic based on Source IP address Platform must support policing of traffic based on Destination IP address Platform must support policing of traffic based on Source UDP port Platform must support policing of traffic based on Destination UDP port Platform must support policing of traffic based on Source TCP port Platform must support policing of traffic based on Destination TCP port Platform must support policing of traffic based on Source MAC address NFBA RFP #2011-05 Page 18 North Florida Broadband Authority Platform must support policing of traffic based on Destination MAC address Platform must support policing of traffic based on any combination of above. Platform must have ability to enforce bandwidth limitations for specific LSP's 8.13.5.4 Queuing and Shaping Platform must support ability to apply QoSpolicies on ingress interfaces Platform must support ability to apply QoSpolicies on egress interfaces Platform must support traffic queuing/shaping for all proposed ingress interfaces at interface line rate Platform must support traffic queuing/shaping for all supported ingressVLANs at interface line rate Platform must support traffic queuing/shaping for all proposed egress interfaces at interface line rate Platform must support traffic queuing/shaping for all supported egress VLANs at interface line rate Platform must support at least 8 CoS queues on all proposed interfaces Platform must support at least 8 CoS queues on all VLANs. Platform must support RED on all proposed interfaces in hardware. Platform must support WRED on all proposed interfaces in hardware. Platform must support WFQ on all proposed interfaces in hardware. Must support traffic shaping and policing in the same QoSpolicy Platform must support multiple drop profiles within each traffic class Platform must support priority queuing Platform must support starvation queuing Platform must support starvation queuing within a bandwidth limit Platform must support low-latency queuing Platform must support 4 priority queues on the same port. Platform must support 4 priority queues in the same QoSpolicy. Platform must have ability to shape trafficking going into an LSP Platform must support automated CoS policy mapping to specific LSPs Platform must have ability to enforce and shape within bandwidth limitations for specific LSPs Platform must have ability to enforce and shape within bandwidth limitations for any proposed interface type Platform must have ability to enforce and shape within bandwidth limitations for any VLAN ID 8.13.5.5 Marking Platform must have the ability to mark or re-mark traffic based on any combination of VLAN, COS, TOS, DSCP, EXP, source / destination IP, MAC address, UDP, TCP ports. Platform must support mapping/setting the EXP bits on a per LSP basis in hardware. Platform may support EXP marking based on any other information. Platform must support re-marking CoSand transmitting traffic exceeding policed rate Platform must support re-marking TOS and transmitting traffic exceeding policed rate Platform must support re-marking DSCP and transmitting traffic exceeding policed rate Platform must support re-marking MPLS EXP and transmitting traffic exceeding policed rate Platform must support marking IP QoS fields for upstream and downstream traffic based on policy configuration. Platform must support CoSto EXP mapping Platform must support TOS to EXP mapping Platform must support DSCP to EXP mapping Platform must support EXP to COS mapping Platform must support EXP to TOS mapping Platform must support EXP to DSCP mapping Platform must support TOS to 801.P mapping Platform must support 801.P to TOS mapping Platform must support re-marking COS and transmitting traffic exceeding policed rate NFBA RFP #2011-05 Page 19 North Florida Broadband Authority Platform must support re-marking DSCP and transmitting traffic exceeding policed rate Platform must support re-marking MPLS EXP and transmitting traffic exceeding policed rate 8.13.5.6 Hierarchical QoS Platform must support hierarchical QoSpolicies Platform must support hierarchical policers Platform must support nested hierarchical QoSpolicies Platform must support multiple rate and color hierarchical policers. Platform must support hierarchical shaping, scheduling, and policing for the control upstream and downstream traffic Platform must support RED for policing in a hierarchical scheduler Platform must support RED for shaping in a hierarchical scheduler Platform must support WRED for policing in a hierarchical scheduler Platform must support WRED for shaping in a hierarchical scheduler Platform must support WFQ for policing in a hierarchical scheduler Platform must support WFQ for shaping in a hierarchical scheduler Platform Scalability / Performance Platform must support 128k queues per interface line card. Please list the maximum number of priority queues supported per line card Please list the maximum number of queues supported per chassis Please list the maximum number of priority queues supported per chassis Please list the maximum number of priority queues supported in the same QoS policy 8.13.5.7 Forwarding Platform must support line rate forwarding on and between any interfaces in the router Platform must support line rate forwarding on and between any interfaces in the router on all interfaces proposed for this application for MPLS packets. Line rate forwarding must operate with standard internet packet size mixes with MPLS FRR encapsulation, EXP based CoS queuing and uRPF running simultaneously on the interface. Platform must support line rate forwarding on and between any interfaces in the router on all interfaces proposed for this application for MPLS encapsulated packets, with no performance impact based on the number of flows or number of LSPs running over the interface. Platform must support line rate forwarding of MPLS packets on and between any interfaces in the router for all interfaces proposed, with no performance impact with 5,000 LSPs. Platform must support line rate forwarding on and between any interfaces in the router on all interfaces proposed for this application for IPv4 packets and IPv6 packets Line rate forwarding must operate with standard internet packet mixes. Line rate forwarding must operate with standard internet packet mixes with packet filtering, flow monitoring, and uRPF running simultaneously on the interface. Platform must support line rate forwarding on and between any interfaces in the router on all interfaces proposed for this application for IPv6 packets. Line rate forwarding must operate with standard internet packet mixes with packet filtering, flow monitoring, and uRPF running simultaneously on the interface. Platform must provide a counter of uRPF failures per-interface. The counter must be available via SNMP. Platform must support uRPF loose and uRPF strict and have the ability to independently configure ports with either of the two options. Platform must support line rate forwarding on and between any interfaces in the router on all interfaces proposed for this application for IPv4 and IPV6 packets with no performance impact for uRPF, both loose and strict. Platform must support packet forwarding through the router with packet filters, MPLS FRR push or pop, and uRPF in operation simultaneously with an overall forwarding delay (exclusive of serialization or queuing delay) of 100us or less. NFBA RFP #2011-05 Page 20 North Florida Broadband Authority Platform must support packet forwarding through the router with packet filters, MPLS FRR push or pop, and uRPF in operation simultaneously with a overall forwarding jitter (exclusive of queuing jitter) of 100us or less. The use of IPv6 prefixes longer than /64s must not degrade platform forwarding performance. Platform must allow configuration to ignore all IPv6 extension headers. Platform must support processing IPv6 extension headers. Platform must have link state LEDs on all interfaces proposed for this application. Platform must have a non-blocking switch fabric. Platform must support all forwarding features listed above on aggregated Ethernet interfaces. Platform must support static routes Platform must support static routes with a next hop that is not on a local subnet Platform must support static routing to a null interface or discard bucket Platform must support GRE tunnels Platform must support Routed VLAN (SVI) Platform must support Switched VLAN 8.13.5.8 ISIS Platform must support "standard" set of ISIS features as deployed in the IP network. Platform must support full interoperability with the Juniper ISIS implementation on M, MX and T series routers. Platform must support full interoperability with the Cisco ISIS implementation on GSR, Legacy 65xx, 76xx, CRS series routers. Platform must support full interoperability with the other Core router respondents. Platform must support L1/L2 for ISIS Platform must support L1 to L2 route leaking, and support selective L2 to L1 route leaking via the policy language. Platform must support ability to set administrative distance for ISIS routes. Platform must support dynamic hostname exchange for ISIS. Platform must support at least 2000 routers per level. Platform must support ability at least 20k routes in ISIS table. Platform must support at least 100 ISIS adjacencies per router. Platform must support setting overload bit on reboot. o The timeout on the overload bit must be configurable. o A command line option for setting the overload bit must be available. Platform must support ability to selectively redistribute static, connected and BGP routes into ISIS via the policy language. Platform must support ISIS wide metrics. Platform must support MD5 authentication on ISIS sessions. Platform must support ability to set ISIS hello, hold, keep-alive, and SPF recalculation timers. Platform must support ISIS over broadcast networks. Platform must support ISIS on aggregated Ethernet interfaces. Platform must support the ability to advertise an LSP in ISIS Platform must support LSP Fragmentation. Platform must support ISIS Graceful restart. Platform must support ISIS Traffic Engineering Extensions. Platform must support use of ISIS MPLS shortcuts. Platform must support ISIS point-to-point on o GE o 10GE o Aggregated Ethernet Interfaces. Platform must support ISIS passive interfaces. Platform must support all ISIS features listed above on aggregated Ethernet Interfaces. Routing in Intermediate System to Intermediate Systems (IS-ISs). Platform must support BFD NFBA RFP #2011-05 Page 21 North Florida Broadband Authority Platform must support ISIS BFD 8.13.5.9 IPv6 All platform routing policies types (policy map) for IPv4 must also be supported for IPv6 (BGP, ISIS, etc.) Platform must allow configuration to ignore all IPv6 extension headers. Platform must support processing IPv6 extension headers. Respondent must list which IPv6 extension headers are processed. Platform must support IPv6 ISIS single topology TLVs (draft-ietf-isis-ipv6-07). Platform must support IPv6 MTU signaling. Platform must support a mechanism to display IPv6 learned link-local addresses and neighbor discovery state. Platform must support multiple IPv6 addresses per interface/sub-interface. Platform must support IPv6 ping/trace route that enables the IPv6 source address to be specified. Platform must have support for IPv6 Inter-AS (options a/b/c) 8.13.5.10 L2 requirements Platform must support VRRP A minimum of 10 VRRP instances must be supported. Minimum of 64k MAC address per line card are required. Platform must support 4kVLANs per access port (GE or 10GE). 8.13.5.11 L2 functionality support Platform must support multiple IP and L2 VLAN sub-interfaces against the same Layer 2 802.1q Trunk interface. Platform must support the ability to logically cross-connect ports at L2 Platform must Support rate Limiting for Ethernet interfaces Platform must Support Shaping/Policing for Ethernet interfaces as specified in the COS Section Platform must support rate Limiting for VLANs Platform must Support rate Limiting for QinQVLANs Platform must Support Policing/Shaping for VLANs as specified in the COS Section Platform must Support Policing/Shaping for QinQVLANs as specified in the COS Section Platform must support jumbo frame on Ethernet interfaces Platform must support Port mode QinQ Platform must support VLAN QinQ Platform must support VLAN translations 1 to 1 Platform must support VLAN translation 2 to 1 Platform must support VLAN translations 1 to 2 Platform must support VLAN translations 2 to 2 Platform must support the ability to translate VLAN ID on ingress per port Platform must support the ability to translate VLAN ID on egress per port Platform must support tunneling of Spanning-tree BPDU frames including 802.1d, 802.1w and 802.1s 802.1d, 802.1w and 802.1 Platform must support tunneling of CDP frames Platform must support tunneling of VTP frames Platform must support tunneling of UDLD frames Platform must support tunneling of LACP frames Platform must support tunneling of PAgPframes Platform must support QinQ tunneling of Spanning-tree BPDU frames including 802.1d, 802.1w and 802.1s Platform must support QinQ tunneling of CDP frames Platform must support QinQ tunneling of VTP frames Platform must support QinQ tunneling of UDLD frames NFBA RFP #2011-05 Page 22 North Florida Broadband Authority NFBA RFP #2011-05 Platform must support QinQ tunneling of LACP frames Platform must support QinQ tunneling of PAgP frames Platform must support 802.3ad link aggregation on GIGE interfaces Platform must support 802.3ad link aggregation on 10 GIGE interfaces Platform must support 802.3ad bundle member links on different line cards Platform must support 802.1Q Platform must support Dynamic ARP Platform must support for RARP and Promiscuous ARP Platform must support 802.1x Platform must support standards based 802.3ah Connectivity and Fault Management Platform must support 802.3ah Connectivity Fault Messages Link Trace message, Loopback Message, Alarm Indication Signal Platform must support 802.3ah Connectivity Check, L2 Ping, and L2 Trace route Platform must support 802.3ah Maintenance End Point and Maintenance Intermediate Points on the same physical or Logical interfaces Platform must support Standards based 802.1ag Ethernet Link OAM Platform must support Y.1731 Ethernet Performance Monitoring Platform must support Y.1731 Ethernet Alarm Indication Signal (ETH-AIS) Platform must support Y.1731 Ethernet Remote Defect Indicator (ETH-RDI) Platform must support Y.1731 Ethernet Lock Signal (ETH-LCk) Platform must support Y.1731 Ethernet Loss Measurements (ETH-LM) Platform must support Y.1731 Ethernet Delay Measurement (ETH-DM) Platform must support Y.1731 Ethernet Frame Variation Measurement Platform must support flow control on GE interfaces Platform must support keep-alives on GE interfaces Platform must support ability to turn on or off Auto-negotiation on all GE interfaces Platform must support ability to turn on or off Auto-negotiation on all Copper and Fiber FE interfaces Platform must support L2 broadcast control Platform must support L2 Multicast Control Platform must support RFC 3768 Virtual Route Redundancy Protocol (VRRP) Provider must provide documentation of Metro Ethernet Forum (MEF) level certification Platform must have the capability to add a description on all L2 interface types Platform must have capability to gather statistics for all required virtual interfaces (VLANs, SVIs, and EVCs). Please refer to regular interface statistics requirements Platform must support multiple Interface/VLAN sub-interfaces or Service Instance binding to one L2 VPN Virtual Forwarding Instance When binding multiple interfaces/sub- interfaces to the same VFI. BGP Platform must support full range of BGP features typically used in Internet Core BGP routers Platform must support iBGP peering. Please provide the maximum number of iBGP peers per system Platform must support iBGP peering with an IPv4 based session supporting both the IPv4 and IPv6 address families. Platform must support eBGP peering. Please provide the maximum number of eBGP peers per system Platform must support separate eBGP sessions for the IPv6 address family using IPv6 as transport. Platform must support 2 eBGP sessions per interface/sub-interface, with one eBGP session IPv4 based distributing IPv4 prefixes, and a second session IPv6 based distributing IPv6 prefixes. Platform must have configurable keep-alive and hold timers in at least 1 second increments Platform must support BGP Route Refresh (RFC 2918) Platform must support redistribution of Static, Connected and ISIS routes into BGP Page 23 North Florida Broadband Authority NFBA RFP #2011-05 Platform must support a flexible Route map or Policy language to control/define BGP routing policies. Platform must have ability to set maximum prefix limits on a per-BGP neighbor basis Platform must support a configurable hold-down timer for a max-prefixes violation. The timer must be have a configuration option that disables the session for a configurable number of seconds or leaves the BGP session disabled until reset manually. A manual reset of a session in hold-down must be available from the command line. Platform must have BGP peer group support or standard BGP session settings that are inherited by peers assigned to that group. Platform must have BGP community support and BGP extended community support, including the ability to selectively set, clear, append, act on and control advertisement of through a policy language. Platform must have support for MD5 Authentication on BGP sessions Platform must have support for eBGPMultihop Platform must have support for eBGP Multipath Platform must have support for Community strings and new community format (A:B where A and B are 16-bit values) Platform must have support for setting, acting, or clearing the local preference through the policy language Platform must support acting on, setting, and clearing MEDs through the policy language. Platform must support acting on, setting, and clearing the origin code through the policy language. Platform must support AS Prepending on a selective basis through the policy language Platform must support BGP for Four-octet AS Number Space as per RFC 4893. Platform must support AS4_PATH and AS4_AGGREGATOR BGP special attributes as per RFC 4893. Platform must support AS_TRANS BGP special attributes as per RFC 4893. Platform must support Reserved AS '23456' to peer between a 2 byte AS to any 4 byte AS. Platform must support BGP Dampening Platform must support setting the next hop of routes to a specified loopback address if defined in the policy language. Platform must support next-hop self Platform must be able to act as a BGP Route Reflector Server Platform must support BGP Confederations Platform must make BGP routing decisions according to the standard BGP decision process. If BGP decision algorithm deviates from standard algorithm, please state the decision algorithm in its entirety. Platform must have ability to set administrative distance for iBGP and eBGP Platform must have extensive show command support for BGP debugging Platform must have ability to interoperate with Juniper/Cisco BGP implementations Platform must support full interoperability with the Juniper BGP implementation on M and T series routers. Platform must support full interoperability with the Cisco BGP implementation on GSR and 76xx series routers. Platform must support Graceful Restart Platform must have the ability to create route aggregates and suppress more specific routes. The ability to selectively aggregate routes must be configurable through the policy language. Platform must support route announcement filtering based on community, aspath, and prefix through the policy language. Platform must support cluster-id using IP address notation Platform must have BGP ORF Support Platform must support BGP over IPSec tunnels Platform must support Soft reconfiguration of the peering session, inbound and outbound Platform must be able to tune BGP metric and distance values Page 24 North Florida Broadband Authority Platform must have ability to turn synchronization on and off Platform must support 1M forwarding entries. Platform must support 1M individual routes. Platform must support at least 250k eBGP peers Platform must support at least 1k iBGP peers Platform must support RFC 1657 - Definitions of managed objects for the fourth version of the BGP using SMIv2 Platform must support RFC 1771 - BGP-4 Platform must support RFC 2796- BGP route reflection Platform must support RFC 1997 - BGP Communities attribute Platform must support RFC 1998 - An application of BGP community attribute in Multi home routing Platform must support RFC 2858 - Multiprotocol Extensions for BGP Platform must support RFC 2385 - Protection of BGP sessions via TCP MD5 signature option Platform must support RFC 2439 - BGP route damping Platform must support CIDR Platform must support RFC 2519 - A framework for Inter-Domain route aggregation Platform must support RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Platform must support RFC 2842 - Capabilities Advertisement with BGP-4 Platform must support RFC 2918 - Route Refresh Capability for BGP-4 Platform must support RFC 3107 - Carrying Label Information in BGP-4 Platform must be able to display BGP routes in CLI Platform must be able to display specific BGP routes in CLI Platform must be able to display BGP databases in CLI Platform must be able to display BGP neighbors in CLI 8.13.5.12 MPLS Platform must support "standard" set of MPLS features. Platform must support full interoperability with the Juniper MPLS implementation on M and T series routers. Platform must support full interoperability with the Cisco ISIS implementation on GSR, Legacy 65xx, 76xx, CRS series routers. Platform must support RSVP. Platform must support LDP. Platform must support MD5 authentication for MPLS LDP Platform must support setting the EXP bit on LDP and RSVP Platform must support setting the administrative distance for RSVP Platform must support MD5 authentication for RSVP Platform must support setting the refresh and reoptimize timers for RSVP in 1 second or smaller intervals. Platform must support setting the RSVP timers up to at least 3 minutes. Platform must support naming LSPs. Platform must support LSP paths defined by a combination of 0 or stricter and 0 or more loose hops, in any order. Platform must support penultimate hop popping. Platform must support ultimate hop popping. Platform must support at least 500 ingress and egress LSPs. Platform must support 5000 transit LSPs. platform must support explicit hop LSPs platform must support loose hop LSPs platform may support policers to control the amount of traffic forwarded through an LSP platform may support Multiple LSP policers per LSP platform must be able to reserve bandwidth for LSPs platform must support RSVP signaling for MPLS LSPs NFBA RFP #2011-05 Page 25 North Florida Broadband Authority platform must be able to create zero bandwidth RSVP signaled LSPs platform must be able to dynamically build protecting LSPs (vs. manually configuring) platform must support point-to-multipoint LSP platform must support traffic engineering for p2mp LSP platform must support fast reroute for p2mp LSP platform must support Fast Reroute Link Protection for p2mp LSP platform must support Fast Reroute Node Protection for p2mp LSP platform must be able to reserve bandwidth for detour LSPs for p2mp LSP Platform must support setting the TE metric on a per LSP basis platform must have ability to use traffic engineering to build detour paths for p2mp LSP platform must have ability to reserve Bandwidth across the network for P2mp LSP Platform must support MTU signaling for RSVP for IPv4 and IPv6 platform must support RFC 4090 - Fast Reroute Extensions to RSVP-TE for LSP Tunnels Platform must support make before break for re-optimized LSPs. Platform must support MPLS RSVP on aggregated Ethernet interfaces. Platform must support soft preemption. Platform must support RSVP bandwidth reservation. Platform must adjust the advertised bandwidth for RSVP bandwidth reservation when an element of an aggregated link has failed or an element is added. Platform must support setting TTL decrement for RSVP and LDP on a per LSP basis. When TTL decrement is turned off, the TTL of the packet is not decrement on transit hops in the LSP. Platform must support RSVP refresh reduction. Platform must support RRO. Platform must have the ability to support static labels Platform must support label stacks at least 5 labels deep. Platform must support all MPLS features on all proposed interfaces. Platform must support all MPLS features listed above on aggregated Ethernet interfaces. All listed features not supported on aggregated Ethernet interfaces must be listed. Platform must support MPLS FRR for all required interfaces Platform must support MPLS FRR restoration with a total loss of traffic of 50ms plus latency or less. This switch time must be supported with 2000 LSPs switching from a failed primary path to a backup FRR path in the router. Platform must support MPLS Fast Reroute Bypass as implemented by Juniper and Cisco. Platform must support Dynamic primary LSP path calculation Platform must support Dynamic protect tunnel path calculation (link, node, node & link) Auto-Templates for LSP characteristics and tunnel building (primary and backup LSPs) must be supported. Auto-discovery of primary LSP tunnel tails (ACLs, IGP, and BGP) must be supported. Platform must support MPLS TE Dynamic Path Protection (AKA Juniper secondary LSPs Platform must support CSPF calculation of Path protect tunnels, avoiding links and nodes of primary LSP path, if possible. Simultaneous support of MPLS TE/FRR with non-stop-forwarding (NFS) and stateful- switchover (SSO) for deployment (aka PE router) with dual control modules Platform must have support for Inter-AS (options a/b/c) Platform must support Inter-AS Traffic Engineering/Fast Re-Route 8.13.5.13 VPLS - VPWS Platform must support 15K VPLS instances Platform must support 15K VPWS instances Maximum MAC addressed per VPLS instance Platform must support VPWS Platform must be compatible with existing respondents VPWS implementation Platform must support VPLS NFBA RFP #2011-05 Page 26 North Florida Broadband Authority NFBA RFP #2011-05 Platform must be compatible with existing respondents VPLS implementation Platform must support VPLS BGP Auto discovery Platform must support VPLS on a full port Platform must support VPLS with a VLAN sub-interface Platform must support VPWS on a full port Platform must support VPWS on a VLAN sub-interface Platform must support any combination of VPLS, VPWS and L3VPN on the same interface Platform must support the ability to translate a VLAN on an interface/sub-interface participating in VPLS Platform must support the ability to translate a single VLAN tag to a QinQ tagged frame on a interface/sub-interface participation in VPLS Platform must support the ability to translate to outer VLAN of a QinQ tagged interface/subinterface participating in VPLS Platform must support the ability to translate to inner VLAN of a QinQ tagged on a interface/sub-interface participating in VPLS Platform must support the ability to translate to inner and outer VLAN of a QinQ tagged on a interface/sub-interface participating in VPLS Platform must support the ability to translate to QinQ tagged frame to a single VLAN tag on an interface/sub-interface participating in VPLS Platform must support the ability to translate a single VLAN tag to a QinQ tagged frame on a interface/sub-interface participation in VPWS Platform must support the ability to translate a VLAN on an interface/sub-interface participating in VPWS Platform must support the ability to translate to outer VLAN of a QinQ tagged interface/subinterface participating in VPWS Platform must support the ability to translate to inner VLAN of a QinQ tagged on interface/subinterface participating in VPWS Platform must support the ability to translate to inner and outer VLAN of a QinQ tagged on a interface/sub-interface participating in VPWS Platform must support the ability to translate to QinQ tagged frame to a single VLAN tag on an interface/sub-interface participating in VPWS Platform must be able to show detail status of VPLS VC. Platform must be able to show detail status of VPWS VC. Platform must maintain L2 Mac address separation between VPLS VC instances Platform must support termination of a VPLS instance into a VPWS instance Platform must support both spit horizon and non split horizon implementation Platform must have the capability to assign virtual connection ID for VPWS Platform must have the capability to add a description on VPLS virtual connections Platform must have the capability to add a description on VPWS virtual connections Platform must support ability to MAP traffic to an MPLS pseudo wire based on L3 header information Platform must support ability to MAP traffic to an MPLS VPLS based on L3 header information Platform must have ability to terminate multiple pseudo wires on the same VLAN / interface Platform must support an MPLS pseudo wire redundancy mechanism Platform must have Inter-AS L2 VPN support for ATOM and VPLS (options a/b/c) VPLS BGP Auto Discovery with Inter-AS Option C. Platform must support L2 broadcast control within the VPLS/VPWS instance Platform must support L2 multicast control within the VPLS/VPWS instance Device must support spoke pseudo wires and the associated replication per section 10 of RF4762 for efficient replication of broadcast and multicast packets. Device must support per service broadcast and multicast controls for spoke/h- vpls attachment circuits. Device must h-vpls/spoke connections per section 10 of RFC4762 to support dual-homed PEs with the appropriate MAC flush functions. Page 27 North Florida Broadband Authority 8.13.5.14 L3VPN Platform must have support for Virtual Routing and Forwarding (VRF). RFC 2547bis (4364) Compliance to this requirement is required in order for the RFQ response to be reviewed Platform must support RFC 4659 BGP-MPLS extensions for IP VPN. (6VPE). Platform must have the capability to route and forward IPv4 in all VRF instances at line rate on all proposed interfaces Platform must have the capability to route and forward IPv6 in all VRF instances at line rate on all proposed interfaces Platform must have the capability to route and forward both IPv4 and IPv6 in the same VRF instance at line rate on all proposed interfaces Platform must support the capability to have a common route-target across both the IPv4 and IPv6 address families. Platform must support the capability to support per address family route-targets for IPv4 and IPv6. Platform must support static routing within the VRF instance Platform must support BGP routing within the VRF instance Platform must support 2 BGP sessions within the VRF instance, one for IPv4, one for IPv6. Platform must support customer termination into VRF for all requested interface types Platform must have the ability to bind all required virtual interfaces to VRF instances. Platform must support multiple Interface binding to one VRF instance Platform must support multiple sub-interface binding to one VRF instance Platform must support multiple sub-interface (which are part of the same customer access circuit) binding to multiple VRF instances Platform must support "Route Leaking" between multiple VRF instances. Platform must support packet filtering (ACL) within VRF instances Platform must support VPN-BGP policy to allow/block propagation or receipt of specific prefixes Platform must support hub/spoke and full mesh topology by multiple BGP VPN sessions in the same chassis. Platform must have the ability to dampen customer routes within the VRF Platform must support VRF multicast via PIM-SM, DM, and Source Specific Multicast (SSM). VRF Multicast PIM-SM and PIM-DM and Source Specific Multicast (SSM). Platform must have the ability to poll VRF for following statistics: number of routes, number of withdrawn routes, number of sent prefixes, number of received prefixes, damped routes, number of damping instances, interfaces bound to VRF and corresponding interface counters, subinterfaces bound to VRF and corresponding sub-interface counters 8.13.5.15 Scalability 8.13.5.16 Multicast Platform must support IETF draft-rosen-vpn-mcast. Both PIM-P and PIM-C instances to be supported. Platform must support PIM-SM, DM, and Source Specific Multicast (SSM) in PIM-C instances. Platform must support PIM-SM in PIM-P Platform must support capability to build a Default MDT tree that can be triggered to a Data MDT tree based on bandwidth triggers. Platform must support multicast scope addressing RFC 2365, 3171, 3180 Platform must support IGMPv3. Platform must handle PIM Register messages at line rate Platform must support at least 100k multicast forwarding entries Platform must support PIM-snooping and IGMP snooping on IP interface Platform must support PIM snooping and IGMP snooping on VPLS instances. Platform must support Rendezvous point generation (PIM-RP) and PIM Bootstrap (BSR). NFBA RFP #2011-05 Page 28 North Florida Broadband Authority Platform must support the SSM mapping functionality Platform must forward all multicast packets at line rate on all proposed interfaces Platform must forward or discard all packets greater than MTU in at line rate on all proposed interfaces. Platform must support Multicast P functionality to support Rosen Aggarwal MPLS multicast as defined in the latest version of "draft-ietf-l3vpn-2547bis-mcast". Platform must support P functionality to implement Aggregate Inclusive Trees as defined in the latest version of "draft-ietf-l3vpn-2547bis-mcast. Platform must support PE functionality to implement point to multipoint MPLS LSPs to implement Aggregate Inclusive Trees as defined in the latest version of "draft-ietf-l3vpn- 2547bis-mcast. Please provide the maximum number of IGMP join/leave requests per second system can handle from IGMP hosts Platform must support ability to rate limit multicast flows. Platform must support ability to filter multicast flows Platform must support ability to display multicast routing table in CLI Platform must support ability to display multicast groups in CLI Platform must support ability to display multicast group members in CLI Platform must support ability to display IGMP snooping forwarding table in CLI 8.13.5.17 Management Platform must support In Band management. Platform must support Out of Band management Platform must support installation of software from and out of band interface. Platform must support saving multiple configuration versions locally on the router with the ability to rollback to an earlier version. Platform must support Local Craft interface. Platform must support the SNMP or collection of the following performance metrics per system per physical port per logical port (interface or sub-interface) per flow on a minimum 5 minute periodicity: availability/uptime latency and jitter throughput packet loss and congestion-related discards PPP statistics connection time timeout values errors individual QoS queues on both ingress and egress to the network Platform must report hardware part information (e.g.- part number, model number, revision, etc.) via SNMP for all field replaceable units (FRU) and the platform chassis shelf Platform must support DNS Client Support for resolving trace routes. Platform must support DNS lookups for hostname and in-addr resolution. Platform must have SSH v1 and v2 support Platform must support 8 concurrent SSH sessions. Platform must have FTP support to and from the router for software images and configuration files. Platform must have SCP support to and from the router for software images and configuration files Platform must support automatic backup of the configuration via remote scripts using SCP. Platform must support automatic restoration of a configuration via remote scripts using SCP. Platform must have the ability to send logs to a syslog server Platform must have ACL/Policy counters showing hits against a specific term NFBA RFP #2011-05 Page 29 North Florida Broadband Authority NFBA RFP #2011-05 Platform must support 64 bit counters for interface statistics. Specifically,; ifHCInOctets ifHCOutOctets ifHCInPackets ifHCInUcastPkts ifHCInMulticastPkts IfHCInBroadcastPkts ifHCOutPackets IfOutUcastPkts ifHCOutMulticastPkts ifHCInBroadcastPkts ifHCInDiscards IfHCOutDiscards IfHCInErrors ifHCOutErrors Platform must support real time monitor command for interface counters Platform must support counters on packet filter elements with counts of the number of packets matching each packet filter policy. Platform must provide a command line interface with periodically updated interface statistics. Platform must support NTP as both a server and a client. Platform must support IP Ping and Trace Route Platform must support L2 OAM Ping Platform must support LSP Ping Platform must support SNMP v2 (version 2c) Platform should support SNMP version 3 with individually encrypted passwords (community strings) and restrictions on which MIBS can be accessed based on username/community string. Platform must support SNMP read-only and read-write access. Platform must support generating and logging SNMP traps. Platform must support 8 concurrent SNMP community strings for any combination of RO and RW. Platform must support 64 concurrent SNMP query hosts. Platform must support 32 SNMP trap destinations without loss Platform must support functionality equivalent to Cisco's SNMP-server if Index persist. Platform must have the ability to configure SNMP trap forwarding based on category - interface, environmental, etc. Platform must support SNMP agent restart able without router reload Platform must Support SNMP collection of detailed QoSstatistics Platform must support Diagnostic and monitoring information including syslog Platform must support standard Unix syslog logging levels: Platform must support 10 syslog destinations without loss. Platform must have the ability to configure syslog forwarding by message severity. Each software release version must contain full MIB, SNMP Notification and Inform dictionaries. Platform must support the Entity MIB. Platform must be fully MIB-II Compliant Platform must support ISIS MIB Platform must support Full Interface MIB Platform must support RSVP MIB Platform must support LDP MIB Platform must support MPLS FRR MIB Platform must support CoS MIB Platform must support Hardware Components MIB Platform must support Packet Filter MIB Platform must support PIM MIB Platform must support IGMP v1,2,3 MIB Platform must support PW MIB Page 30 North Florida Broadband Authority NFBA RFP #2011-05 Platform must support IPv4 MIB Platform should support VRRP MIB Platform must support User-level customization and accounting Platform must support Dynamic Changes Platform must support rfc2547 MIB Platform must support Ability to poll VRF for the following statistics number of routes number of withdrawn routes number of sent prefixes number of received prefixes damped routes number of damping instances interfaces bound to VRFand corresponding interface counters Traps must be sent on LSP transitions of up/down or topology change Platform must support account and traffic stat. marking and collection for different CoS On a given interface or sub interface that is supporting both IPv4 and IPv6, the respondent must support per address family counters that answer the question of how much IPv4 and IPv6 traffic is flowing through the interface or sub interface. Platform must support IPV6 stats (MIB OID 1.3.6.1.2.1.55) and IPV4 stats (MIB OID 1.3.6.1.2.1.4) on a per logical interface/sub interface level. Such statistics must also be viewable real time through the CLI. Platform must support CLI access for running external scripts. Platform must support display of ISIS routes in CLI Platform must support display of specific ISIS routes in CLI Platform must support display of ISIS databases in CLI Platform must support ISIS debugging options Platform must support display of BGP routes in CLI Platform must support display of specific BGP routes in CLI Platform must support display of BGP route table in CLI Platform must support display of BGP neighbors in CLI Explain BGP debugging options in CLI Platform must support display of RIB in CLI Platform must support display of FIB in CLI Platform must support display of specific routes in CLI Platform must support display of static and connected routes in CLI Platform must support display of specific static and connected routes in CLI Platform must have support for TACACS+ Platform must have support for display of VLAN and PVST counters via CLI Platform must have support for wide-metrics Platform must have support for configurable mac and arp timers Platform must have support for spanning tree protection (I.e. BPDU guard or root guard) A trap must be sent if any hardware component on the device fails. A trap must be sent if any hardware component on the device is removed or inserted, e.g. a card A trap must be sent if any fail-over to a backup hardware component occurs within a device A trap must be sent if a link (sub channel, logical or physical link) on the device is disabled or goes down A trap must be sent when/if various security events occur, i.e. illegal access, port scan attempts, etc. A trap must be sent if an SNMP query is made to the device with an incorrect community string. A trap must be sent if disk utilization reaches a critical threshold or increases rapidly on the device A trap must be sent if memory utilization reaches a critical threshold or increases rapidly on the device. A trap must be sent if CPU utilization reaches a critical threshold on the device. Page 31 North Florida Broadband Authority NFBA RFP #2011-05 A trap must be sent if a critical process dies on the device A trap must be sent if memory utilization by a critical process reaches a critical threshold or increases rapidly. A trap must be sent when the SNMP agent on the device exits/re-starts. Environmental traps must be sent (e.g. temperature, fan functionality) Traps must be sent for software/configuration changes A trap must be sent if any fail over to a backup device occurs, e.g. from one router to another using VRRP. Platform must be able to customize the log features. Platform must be able to customize the log buffers. Platform must be able to timestamp (NTP) each message and the source IP address. Platform must send SNMP Traps for interface state changes Platform must send SNMP Traps for IS-IS neighbor state changes Platform must send SNMP Traps for BGP neighbor state changes Platform must send SNMP Traps for BGP prefix limit reached Platform must send SNMP Traps for LDP neighbor state changes Platform must send SNMP Traps for RSVP neighbor state changes Platform must send SNMP Traps for LDP tunnel state changes Platform must send SNMP Traps for RSVP tunnel state changes Platform must send SNMP Traps for PIM neighbor state changes Platform must send SNMP Traps for IGMP DR changes Platform must send SNMP Traps for multicast RPF failures Platform must send SNMP Traps for PIM RP changes Platform must be pre-certified for discovery and polling by Concord Network Health Platform must provide data collection capabilities for all device supported interface types (logical and physical) from OC12 - OC192 Ethernet Fast Ethernet GigE 10GE And all supported protocols in SNMP and log file output formats. Platform must support RFC 1213 MIB II Platform must support RFC 1902 SMI for SNMPv2 Platform must support RFC 1157 Structure and Identification for Management Info for TCP/IP. Platform must support RFC 1657 BGP4-MIB. MIB II only Platform must support RFC 2037 Entity MIB Platform must support RFC 2096 IP Forwarding Platform must support RFC 1471/1473 PPP Platform must support RFC 1284 Ethernet Platform must support MIB for IS-IS System must support standard UNIX syslog logging levels Platform must provide connection trace capabilities for the logical and physical path Network nodes and cards must be automatically discovered or updated by the NMS Platform must be able to mirror specified traffic to multiple ports. Platform must be able to mirror specified traffic from multiple source ports to multiple destination ports Platform must be able to mirror multicast traffic streams to multiple ports Platform must be able to mirror multicast control traffic (IGMP, PIM) from multiple source ports to multiple destination ports Platform must be able to mirror traffic to a destination port and filter on MAC addresses, IP addresses, ports numbers Platform must be able to mirror only L2 headers to a destination port Platform must be able to mirror only L3 headers to a destination port Page 32 North Florida Broadband Authority Platform must be able to mirror traffic from source VLAN's over to a destination port Platform must be able to mirror traffic over to a destination VLAN Platform must support MPLS LSP PING Platform must support MPLS LSP Trace route Platform must support the ability to register an Interface MIB IFXTable "if Alias" field string of up to 255 characters. 8.13.5.18 Security Platform must provide the ability to specify an idle timeout value on management sessions. Platform must disconnect any sessions that have been idle longer than the timeout. Any uncommitted actions performed by that session must be discarded. Platform must provide the ability to display a login banner for all management login methods. Platform must provide the ability to upgrade the software at the application and operating system levels. A complete software upgrade is considered compliance. The respondent must provide the security related patches and updates in a secure and timely manner. Platform must support passwords of at least 8 alphanumeric characters. Platform must provide secure end-to-end channels for all network traffic and protocols used to support management functions. The encryption used should be "strong". Encryption should use or be equivalent or stronger than a 128 bit key symmetric encryption using the Advanced Encryption Standard algorithm. Platform CLI must utilize existing authentication methods. Platform must support the ability to install new software while the device is disconnected from all public IP networks. Platform must provide a means to store the system configuration to a remote server. The stored configuration must have sufficient information to restore the device to its operational state at the time the configuration was saved. Platform must provide a means to remotely save a copy of the system configuration file or files in a human readable form. It must not be necessary to use a proprietary program to view the configuration. Platform must provide a means to display all services that are listening for network traffic directed at the device from any external source. The device must display the interfaces on which each service is listening including open standards based and respondent proprietary services. Platform must provide a means to turn off any externally listening services. Platform MUST provide a means that allows the user to specify the source address used for all outbound connections or transmissions originating from the device. It MUST be possible to specify source addresses independently for each type of outbound connection The default configuration of the device MUST ensure that it will not respond to any directed broadcasts to any broadcast domains of which it is a member. It will not propagate any directed broadcasts to any broadcast domains to which it is directly connected. Platform MUST be able to control the flow of traffic based on source and/or destination IP address or blocks of addresses such as Classless Inter-Domain Routing (CIDR) blocks Platform MUST provide a logging facility that conforms to open standards. Platform MUST be capable of logging to a remote server. It MUST be able to log to multiple servers Platform MUST time-stamp all log messages. The time-stamp MUST be accurate to within a second or less. The time-stamp MUST include a time zone Log messages MUST contain relevant IP addresses Platform MUST provide a facility to perform authentication of all user access to the system. Each authentication mechanism supported by the device MUST support the authentication of distinct, individual users Platform MUST support multiple simultaneous connections by distinct users, possibly at different authorization levels. Platform MUST provide a means of disabling all local accounts NFBA RFP #2011-05 Page 33 North Florida Broadband Authority Platform MUST support a method of centralized authentication of all user access via standard authentication protocols. Platform MUST support the ability to configure the order in which supported authentication methods are attempted. Authentication MUST "fail closed” Platform MUST perform authentication without the unencrypted transmission of reusable plaintext passwords across a network. It MUST be possible to define arbitrary subsets of all management and configuration functions and assign them to groups or "privilege levels". Platform MUST be able to assign a defined set of authorized functions, or "privilege level," to each user once they have authenticated themselves with the device. The default privilege level MUST only allow read access to device settings and operational parameters Platform MUST re-authenticate a user prior to granting any change in user authorizations Platform MUST support a mechanism to allow authorized individuals to recover full privileged administrative access in the event that access is lost. Use of the mechanism MUST require physical access to the device. Platform MUST be able to store a record of at least the following events: Failed logins Successful logins All Commands executed by the user during their session, including via the management/serial port and interactions with an underlying OS (e.g. Unix) Platform MUST provide a method to change the SNMP community strings. Platform MUST permit read or write SNMP functionality to be disabled independently. Platform MUST support multiple simultaneous SNMP community strings to allow easy SNMP community string changes. Platform MUST support multiple simultaneous SNMP community strings with the ability to set and enforce separate packet filters for access to each community string. Platform must pass the SNMP PROTOS testing. Platform supports SNMP v3 with individual encrypted passwords and restrictions on MIBS based on username. SSH v2must be supported. Platform must support a configuration option that restricts SSH access from a user defined set of network addresses. Platform must comply with draft-ietf-filtering-caps http://www.ietf.org/internet- drafts/draft-ietfopsec-filter-caps-04.txt Platform must provide support for GTSM. At a minimum GTSM must be supported for LDP and RSVP. Platform must provide a mechanism for monitoring system health including CPU utilization. Platform must provide support MD5 authentication for LDP and RSVP. Platform should provide the ability to apply a firewall policy to protect the CPU resources. Platform must have the ability to granularly define protocols/ports to allow/disallow Platform must have the capability to implement access lists for Ethernet and trunk interfaces with public IP addresses The platform must support the ability to customize the route-targets Platform must support traffic isolation on a VLAN and VRF basis to prevent intra-VPN leakage and VLAN hopping. Platform must support MAC filtering: based on source/destination MAC address, 8.13.5.19 TCO Respondent must provide hardware warranty of a minimum of 3 years and all pricing must reflect this requirement. Respondent must provide software warranty of a minimum of 3 years and all pricing must reflect this requirement. Respondent must provide Advance Replacement for all performance impacting Equipment (next day) during warranty period. All pricing must reflect this requirement. NFBA RFP #2011-05 Page 34 North Florida Broadband Authority Warranty period for repaired/replaced products will be 3 years, or the same as the replaced product whichever is longer. Warranty period must include TAC/TAS, On-Site Support, Repair (Advanced Replacement), and Software Support (Updates - bug fixes, patches, remedies). Respondent must provide TAC support at no charge during the warranty period. Respondent should have web portal access. Respondent must be able to provide training equipment and EFI at no charge. Respondent must provide hands-on training in a lab facility, if required. Respondent must provide 1 complete system for lab equipment during the certification period. Respondent must provide a detailed test and acceptance plan for all Systems, Architectures, and Topologies as directed by the NFBA Systems Engineer. Shortening the intervals to deliver the NFBA network is another important factor to the NFBA. Please describe any methods you will use to help the NFBA reduce its time to market All "Network Electronics" must have a CLEI code associated with them. 8.13.5.20 System Architecture 8.13.5.21 Platform Performance Support Total Switch Fabric bandwidth of at least100Gbps full duplex. Maximum available switch fabric - specify the supported switch fabric performance in Gbps full duplex and in Mpps. 8.13.5.22 Layer 2 Filtering Filtering of incoming frames based on Source/Destination MAC Address. The following conditions apply to the requirement: Filtering is independent on the upper layers protocols (IP, IPv6 etc.) information contained in the frame Filtering is independent on the EVC type (EPL, EVPL, EPLAN, EVPLAN, EPTREE, EVPTREE) Filtering of outgoing frames based on Source/Destination MAC Address. Filtering of incoming frames based on Ethertype Support of filtering on broadcast and multicast destination MAC Addresses. Following conditions apply to the requirement: Support for limiting the rate of incoming multicast/broadcast traffic. 8.13.5.23 VLAN ID Manipulation The platform must map to the EVC original frame without modification of S-Tag. Incoming Ethernet frames on the ingress Interface must be manipulated before they get mapped to the appropriate EVC. The platform must be able to support 1 Tag manipulation of outgoing VLAN-Tagged 8.13.5.24 UNI UNI-N General Requirements Access Concentrator 1GE and 10GE Physical Medium Support UNI-N L1 Service Attributes 1GE Physical Medium support o UNI-N supports Physical Medium 1000Base-SX, 1000Base-LX and 1000Base-ZX. Indicate optical pluggable form factor (distinguish if necessary pro Platform). o UNI-N supports of Physical Medium 10/100/1000Base-T. o UNI-N supports the capability to disable the Auto-negotiation function for 1000Base-X interface. NFBA RFP #2011-05 Page 35 North Florida Broadband Authority o o 10GE Physical Medium Support o UNI-N supports Physical Medium 10GBase-SR, 10Gbase-LR and 10GBase-ER. Indicate optical pluggable form factor (distinguish if necessary pro Platform). o Indicate which other 10GBase interfaces are supported by UNI-N. (10GBASE-LX4, 10GBASE-SW, 10GBASE-LW, 10GBASE-EW) o UNI-N 10GE interfaces support Ethernet jumbo size (>8000bytes) o The 10G line card and optical for UNI-N support optical power measurements. UNI-N Traffic Accounting UNI-N traffic statistics per port o Rate o Byte counters o Packet counters o Counters are accessible in-band and out-band. UNI-N Traffic Mirroring o Support for local UNI-N Port Mirroring o Support for remote UNI-N Port Mirroring (all traffic entering or exiting a specific UNI-N port is mirrored on a remote Platform) o Mirroring can be selective per S-VLAN ID UNI-N Filtering o Filtering of incoming frames based on Source/Destination MAC Address. o Filtering of outgoing frames based on Source/Destination MAC Address. o Filtering of incoming frames based on Ethertype o Support of filtering on broadcast and multicast destination MAC Addresses. The following conditions apply to the requirement: Filtering is independent on the upper layers protocols (IP, IPv6 etc) information contained in the frame Filtering is independent on the EVC type (EPL, EVPL, EPLAN, EVPLAN, EPTREE, EVPTREE) o Support for limiting the rate of incoming multicast/broadcast traffic. 8.13.5.25 UNI-N 1GE interfaces support Ethernet jumbo size (>8000bytes). The 1G line card and optical for UNI-N support power measurements. ELAN The respondent proposed solution must have the capability to support MEF 6.1 compliant E-LAN and E-LINE service types. These include: EPL: Ethernet Private Line EVPL: Ethernet Virtual Private Line EVP-LAN: Ethernet Virtual Private LAN EP-LAN: Ethernet Private Line Each of the MEF compliant service types listed above should support the following UNI interface types and speeds 10/100/1000 BT UNI Maximum line rate 100 Mbps Sub rate speed increments of 1 Mbps o 1GE UNI Maximum line rate 1 Gbps Sub rate speed increments of 10 Mbps o 10GE UNI Maximum line rate 10 Gbps Sub rate speed increments of 100 Mbps NFBA RFP #2011-05 Page 36 North Florida Broadband Authority 8.13.5.26 Network Management System Number of Network Elements Supported Number of Concurrent supported User Sessions Provisioning System details Network Inventory and Service Audit details Network Element GUI support Alarm Management Interface details North-bound Support for Management Systems 8.13.5.27 Other Requirements Respondent will be responsible for providing the following at no cost to NFBA o Detailed test plan of their solution o Test plan will have to be validated with NFBA Personnel o All required Chassis and Line cards o Management systems and associated hardware requirements that have been proposed within the RFQ o Installation of all equipment and software o Support personnel and all associated travel costs required for the duration of the testing period 8.13.5.28 Service Provider Deployment Information Respondent shall provide examples of the proposed solution already deployed and in service within a large carrier deployment of similar size to NFBA. In the response respondent should make every attempt to indicate the architecture and scale of the deployment of the service provider in question. The response should also indicate service providers who have deployed this solution in both a single and multi-respondent environment. Respondent will describe whether or not licenses are required to cover the operating software of the equipment. The respondent will describe the pricing for the software releases if applicable. Applicable software charges will be a one time (non-recurring) fee. Respondent will confirm that the applicable software release will be supported for a minimum timeframe of 5 years. Respondent will confirm that the applicable software release will be provided with bug fixes for a minimum timeframe of 3 years. Respondent will confirm that all software upgrades will be backwards compatible and interoperable with all prior hardware or software releases. New software upgrades will be able to co-exist with prior releases. Respondent will confirm whether or not a new software release or defect fix can be loaded while remaining in-service. 8.13.5.29 Testing Support Respondent will provide sufficient equipment at no charge (including warranty) to the NFBA Systems Engineering labs for certification purposes. If the proposed solution requires an EMS solution, the EMS software must be included in the certification / evaluation process Respondent will provide the same maintenance, support and warranty levels on test equipment as provided on production equipment. Respondent will deliver the documentation necessary to support testing (method of procedure, installation instructions, test plans, anticipated test results, test data, configuration documentation, etc) prior to test start date. Respondent will provide on-site technical support to facilitate certification of equipment in NFBA Network Engineers’ environment on-demand. 8.13.5.30 Production Support Respondent will provide on-site technical support to facilitate certification of equipment in the finalized datacenter environment. NFBA RFP #2011-05 Page 37 North Florida Broadband Authority Respondent will provide on-site technical support to facilitate certification of equipment in the NFBA environment on-demand and will fix hardware and/or software defects found in production within reasonable timeframes based on an agreed SLA based on trouble severity levels. Resolution time shall be measured from the moment NFBA notifies the respondent. The respondent will provide on-site technical support to facilitate certification of equipment until the full restoration of services. Production support will be available free of additional charge during the warranty period. Options beyond the warranty period will be described. Warranty and Maintenance The Respondent will provide on-site technical support to facilitate certification of equipment in NFBA’s environment on-demand will provide at least a 1 year zero cost warranty. Warranty will include: equipment maintenance; repair and return; TAC support (possibly on-site support); equipment upgrades; software upgrades and defect fixes. The term of the warranty will begin when equipment or software is declared operationally ready by NFBA Project Management office. 8.13.5.31 Continuity of Supply Respondent shall provide continuity of supply of the proposed equipment for a period of five years. Support - Technical Support, Maintenance Support, Product Support as well as Spare Parts must be available for 5 years following the product end of life. Respondent will provide MFBA Project Management office with a list of recommended spares, by part number. NFBA RFP #2011-05 Page 38 North Florida Broadband Authority Attachments RESPONDENTS ARE REQUIRED TO INCLUDE ATTACHMENTS (A) – (L) WITH THEIR PROPOSAL. PLEASE PLACE THE ATTACHMENTS IN YOUR PROPOSAL IN THE ORDER THEY ARE PRESENTED IN THIS RFP. Respondents should review the proposed contract form. Proposed deviations from the standard terms and conditions set forth in the form Agreement as it is provided in Attachment A must be submitted with the respondent’s proposal in a separate document that identifies the part of the Agreement to which the deviation applies and a reason for any such deviation. Any proposed deviations in terms will be considered in the evaluation of the proposal. NFBA RFP #2011-05 Page 39 North Florida Broadband Authority Attachment A: Proposed Contract Form MASTER EQUIPMENT PURCHASE AGREEMENT STANDARD TERMS AND CONDITIONS The following Master Equipment Purchase Agreement is entered into as of this _______ day of ______________, 20___ by an between the North Florida Broadband Authority, a legal entity and public body created by interlocal agreement pursuant to Section 163.01(7)(g), Florida Statutes (the “Buyer”) and [INSERT VENDOR NAME], a [INSERT STATE/ENTITY] (the “Seller”). The Buyer and the Seller, for the consideration herein set forth, agree as follows: Section 1. Contract Documents. The Contract Documents consist of this Agreement, the Legal Advertisement for NFBA RFP #2011-___ (the “RFP”), the RFP, including any addenda, the Seller’s Response to the RFP including all attachments and any duly executed and issued amendments relating thereto. All of the foregoing Contract Documents are incorporated by reference and made a part of this Agreement (all of said documents including the Agreement sometimes being referred to herein as the "Contract Documents" and sometimes as the "Agreement"). A copy of the Contract Documents shall be maintained by Seller at all times during the performance of the Agreement. Section 2. Equipment Purchases. The Seller agrees to furnish __________________ equipment as described in the Contract Documents and pursuant to the Unit Pricing Schedule attached hereto as Exhibit “A” and incorporated herein by reference (the “Equipment”) pursuant to Purchase Orders issued by Buyer during the term of this Agreement. Section 3. Agreement Term. The Equipment required under this Agreement shall be provided for the period beginning immediately upon execution of this Agreement by both parties and ending five (5) years from the date hereof, subject to extension by written agreement of both parties. Section 4. Notices. All notices required or made pursuant to this Agreement by either party shall be in writing to the addresses shown below: North Florida Broadband Authority c/o Government Services Group, Inc. 1500 Mahan Drive, Suite 250 Tallahassee, Florida 32308 [SELLER ADDRESS] Either party may change its above noted address by giving written notice to the other party in accordance with this Section. Section 5. Terms and Acceptance Thereof. No provisions printed or otherwise contained in any acknowledgment hereof which are inconsistent with or in addition to the terms and conditions herein stated, NFBA RFP #2011-05 Page 40 North Florida Broadband Authority and no alteration of this Agreement, shall have any force or effect unless the Buyer expressly agrees to them in writing through a duly authorized agent of the Buyer. IF ANY OTHER TERMS AND CONDITIONS ARE PUT FORWARD BY THE SELLER OF THE EQUIPMENT (THE “SELLER”), THEY ARE OBJECTED TO BY THE BUYER AND SHALL HAVE NO FORCE OR EFFECT UNLESS THE BUYER EXPRESSLY AGREES TO THEM IN WRITING. Section 6. Termination. The Buyer may terminate this Agreement, in whole or in part, for convenience at any time upon five (5) days written notice to Seller. Unless directed otherwise in the notice of termination, the Seller shall incur no further obligations in connection with this Agreement upon receipt of such notice. Section 7. Purchase Orders. The Buyer will not accept any Equipment pursuant to this Agreement unless a duly authorized and signed Purchase Order, in substantially the form attached hereto as Exhibit “B” has been issued for such Equipment. The Purchase Order number must appear on all invoices, packing slips and all correspondence regarding the order. Quantities specified in a Purchase Order cannot be changed without the Buyer’s written approval. Equipment shipped in excess of the quantity designated in a Purchase Order may be returned at Seller’s expense. Section 8. Taxes. Buyer is a local government exempt from federal and state taxes. Section 9. Pricing Schedule/Continuity of Supply. Seller agrees to provide the Equipment at the fixed unit prices stated in the attached Pricing Schedule, including the costs of delivery to Buyer, for three years from the date of execution of this Agreement, with no increase. Seller shall provide continuity of supply of the Equipment and spare parts for a period of five years following the product’s end of life. Section 10. License of Software. Seller hereby grants Buyer a nonexclusive, nontransferable and perpetual license to use any and all software that is embedded in the Equipment covered by this Agreement and any and all software that is otherwise pre-installed by the Seller on the Equipment covered by this Agreement at the time of delivery, together with the documentation under each program element thereof. Section 11. Invoices, Due Dates and Payments. The Seller must submit an invoice to the Buyer before any payment will be processed. The Seller’s invoices shall be forwarded to the Buyer at the address noted in Section 4 herein and all line items must show the Buyer’s Purchase Order number, the Equipment that is the subject of the invoice and any other required information. Section 12. Shipping and Deliveries. The price shall be Free on Board to: North Florida Broadband Authority Field Office c/o Rapid Systems 1155 US Highway 17 Wauchula, Florida 33873 unless otherwise expressly indicated on any associated Purchase Order. Seller shall retain title and assume all responsibility, liability and risk for the Equipment during transit and shall be responsible for filing of claims for loss or damages resulting until the Equipment has been Accepted by Buyer pursuant to Section 13. NFBA RFP #2011-05 Page 41 North Florida Broadband Authority In the event that the FOB delivery address is changed by Buyer during the three year fixed price term of the Agreement, Seller shall document any additional shipping charges required as a result of such change in an amendment to this Agreement signed by both parties. No additional amounts shall be chargeable to the Buyer because of taxes or excises, presently or hereafter levied on the Seller with the exception of applicable sales and use taxes and customary applicable custom fees. Unless otherwise agreed to in writing by the Buyer, all currency amounts shall be United States dollars. Unless otherwise expressly consented to in writing by the Buyer, no payment will be made for packing, boxing, drayage or storage. The Buyer reserves the right to cancel all or any part of this order if Equipment is not delivered on the date or dates specified herein; acceptance in such cases shall in no way bind the Buyer to accept further deliveries on any order. Partial delivery on time will not excuse non-delivery. All deliveries are to be made Monday through Friday, excluding holidays, unless otherwise stipulated in a Purchase Order. Section 13. Acceptance. Equipment delivered hereunder shall be deemed to have been accepted (“Acceptance”) when all of the following have occurred: a. The Equipment (including any licensed and operating software acquired in connection therewith) has been properly received, inspected and deemed ready for use by the Buyer. b. The Equipment (including any licensed and operating software acquired in connection therewith) operates in accordance with the Seller’s specifications and documentation provided to Buyer and any additional published specifications of the Seller and any other manufacturer of the Equipment or developer of any licensed and operating software acquired in connection therewith and the Buyer has confirmed to the Seller in writing that it has accepted the Equipment. In the event that the Buyer does not accept the Equipment in the manner set forth above, the Buyer may request the removal of the Equipment and the software, and the Buyer shall have no liability under these terms and conditions, and the Seller will return any monies paid to such date by the Buyer. In no event shall use of any piece of the Equipment prior to acceptance, constitute Acceptance of any piece of the Equipment or part of the software by the Buyer. Section 14. New Equipment. The Seller covenants and warrants that the Equipment and all of its parts and components are new and unused. Section 15. Seller’s Warranties. The Seller warrants that (i) the Equipment being purchased pursuant to these terms and conditions will conform to and perform in accordance with any and all performance specifications and documentation published by the Seller, any and all warranties, performance specifications and documentation otherwise delivered by the Seller to the Buyer in connection with the Contract Documents, securing the related Purchase Order and any and all expanded specifications put forward by the Buyer and identified by the Buyer, and to the extent that agreed specifications may not be complete, the Equipment being purchased pursuant to these terms and conditions will also conform to the specifications standard in the industry, (ii) the Equipment being purchased pursuant to these terms and conditions will be free from defects in material and workmanship, and (iii) all statements on the packing lists shall be accurate and the Buyer may rely thereon. The Seller further represents and warrants and guarantees that the Equipment being purchased pursuant to these terms and conditions complies with all applicable provisions of laws, ordinances, codes and regulations, including those of the United States, the states of the United States and localities within such states. Section 16. Remedies for Breach of Warranty. The Buyer may reject any Equipment and any software which do not conform to the Seller’s warranties, including those set forth in Section 15, at any time after delivery and before or after acceptance, when such breach of warranty becomes known to the Buyer, in any manner including recognition of latent defects (“non-conforming goods”); and the Seller shall be liable for all direct costs, damages and losses suffered by the Buyer by reason of such non-conforming goods but, absent gross negligence or willful misconduct on the part of the Seller, shall not be responsible for any indirect, NFBA RFP #2011-05 Page 42 North Florida Broadband Authority punitive, exemplary or consequential damages. If the Buyer learns that non-conforming goods have been delivered, the Buyer shall have the right to do any one, or all, of the following: (i) cancel any undelivered portion of the Purchase Order and, at the Buyer’s option, return either all of the equipment and any software or only the non-conforming goods at the Seller’s risk and expense for (at the Buyer’s option) credit or prompt replacement at the invoice price, (ii) repair and use the non-conforming goods, deducting the cost incurred in such repair and use from any sums due the Seller, or on demand, the Seller will reimburse the Buyer for all such costs, (iii) upon notice to the Seller, hold the non-conforming goods for a reasonable time and resell or return them according to the Seller’s instructions (the net proceeds of any such resale shall be credited to the Seller’s account), and (iv) exercise any other remedies that may be available under applicable law. Section 17. Indemnification Including Patent Indemnity. The Seller agrees to indemnify, defend and hold harmless the Buyer, its officers, agents and employees, against and from all claims, suits, damages, costs, expenses and losses (including without limitation: all incidental and consequential damages, economic loss, property damage, personal injury or death) (i) which arises out of a breach by the Seller of these terms and conditions or any warranties applicable to the Equipment and any licensed and operating software acquired by the Buyer from the Seller in connection with the Equipment acquired hereunder, or which result from any nonconforming delivery (including late deliveries or incomplete deliveries), or any infringement of any copyright, patent, trademark, or design or the like (whether or not registered) based on the manufacture, use or sale of any of the Equipment and any licensed and operating software acquired by the Buyer from the Seller in connection with the Equipment, or (ii) which in any manner result from any defect in the Equipment and any licensed and operating software acquired by the Buyer from the Seller in connection with the equipment, nonconformity to or non-compliance with any law, rule or regulation relating to the safety, quality or design of the Equipment and any licensed and operating software acquired by the Buyer from the Seller in connection with the Equipment, and any and all of the Buyer’s reasonable costs and expenses, including professional fees and costs, of investigating, settling or defending any suit, action or claim. Each defense obligation stated herein is hereby deemed a separate and distinct obligation, fully severable from any other duty stated herein. Nothing in this Agreement shall be construed to affect in any way the Buyer’s rights, privileges and immunities as set forth in Section 768.28, Florida Statutes. This section of the Agreement will extend beyond the term of the Agreement. Section 18. Public Records. Any information submitted relating to this Agreement will become a public record subject to disclosure pursuant to Chapter 119, Florida Statutes. Section 19. No Use of Brand Equity Without Permission. Without obtaining prior written permission from an officer of the Buyer, the Seller may not utilize the Buyer’s name in the promotion of its business or its products. Section 20. Insurance. The Seller shall procure and maintain products liability insurance acceptable to Buyer and shall furnish to the Buyer certificates thereof in connection with this Agreement. Section 21. Non-Waiver; Remedies not Exclusive. The Buyer’s waiver of any breach or failure to enforce any of the terms or conditions of this Agreement at any time shall in no way affect, limit or waive its rights hereafter to enforce strict compliance with this Agreement. Section 22. Assignment. The Seller shall not delegate or assign any duties or claims under this contract without the Buyer’s prior written consent. NFBA RFP #2011-05 Page 43 North Florida Broadband Authority Section 23. Entire Agreement; Amendment. This agreement represents the entire agreement of the parties. No amendment, modification or release from any provision hereof, shall arise out of a course of action or mutual agreement unless such agreement is in writing, signed by both parties. Notwithstanding any terms put forth by Seller (including any online terms and conditions on any of Seller’s websites) the terms of this document shall govern all transactions between the parties. Section 24. Governing Law and Venue. Any questions concerning validity, interpretation or performance of this contract shall be governed by the internal laws of the State of Florida and venue of any legal proceeding shall be in the state or federal courts of Leon County, Florida. Section 25. Special Grant Award Conditions. Seller acknowledges that Buyer’s purchase of Equipment pursuant to this Agreement is in connection with a project to be funded with federal stimulus grant funds pursuant to Grant Award Number NT10BIX5570023 awarded to the NFBA on February 18, 2010 (the “Grant”). The Seller agrees to be bound by the special grant award conditions outlined in Exhibit “C” attached hereto and incorporated herein for any Purchase Orders issued pursuant to this Agreement that will be funded with Grant monies. In witness whereof, the parties evidence their agreement through the execution of this Agreement by their duly authorized signatories. NORTH FLORIDA BROADBAND AUTHORITY By:___________________________________ Stephen G. Fulford, Chairman Date: _________________________________ Approved as to Form: By:____________________________ Crystalyn Carey, General Counsel Attest: By: ___________________________ Faith Doyle, Board Clerk [SELLER] Witness______________________ Print Name: __________________ NFBA RFP #2011-05 By: _____________________________ Name: __________________________ Title: ___________________________ Page 44 North Florida Broadband Authority Witness: _____________________ Print Name: __________________ EXHIBIT A PRICING SCHEDULE NFBA RFP #2011-05 Page 45 North Florida Broadband Authority EXHIBIT B PURCHASE ORDER FORM NFBA RFP #2011-05 Page 46 North Florida Broadband Authority EXHIBIT C SPECIAL GRANT CONDITIONS By its execution of this agreement, the Seller and all of Seller’s sub-contractors, agree that they have read and will comply with all provisions and terms and conditions of award #NT10BIX5570023 and all applicable federal and state statutes, including, but are not limited to, the following Award Documents: Department of Commerce Financial Assistance Standard Terms and Conditions Award Specific Special Award Conditions 15 CFR Part 24, Uniform Administrative Requirements for Grants and Agreements with States and local governments OMB Circular A-87 OMB Circular A-133 DOC American Recovery Act Award Terms 74 FR 33104, 74 FR 41676, 74 FR 42644 American Recovery and Reinvestment Act of 2009 2 CFR Part 1326, Subpart C “Government wide Debarment and Suspensions” 15 CFR Part 28, “New Restrictions on Lobbying” Copeland Anti-Kickback Act Davis Bacon Act Sections 103 and 107 of the Contract Work hours and Safety Standards Act Notice of Funds Availability, July 9, 2009, 74 FR 130 Notice of Limited Waiver of Section 1605 (Buy American Requirement), July 1, 2009, 74 FR 31402 In addition, the following requirements will be met, as applicable: Seller shall provide any information needed for NFBA reporting to the NTIA, to meet all reporting deadlines. Failure to provide the information on a timely basis could impact the approval of any pending pay requests. All procurement is to be conducted in compliance with state and federal procurement regulations. All Equipment to be provided by Seller under the Agreement to be paid from grant proceeds shall be eligible for payment with federal funds as specified in the Award Documents Payment of funds to Seller under this Agreement is solely contingent on the receipt of grant funds as disbursed and made available to the NFBA in the form of grant draws. Any past, present or potential conflicts of interest, whether real or in appearance shall be avoided as provided in 15 CFR Part 24. NFBA RFP #2011-05 Page 47 North Florida Broadband Authority Attachment B: Certification Date Issued: RFP #: RFP For: Issued By: Proposals Due: October 01, 2010 NFBA RFP #2011 - 05 Data Center Equipment North Florida Broadband Authority 5:00PM EDT on November 01, 2010 Proposals received after the due date and time will not be accepted and will be returned to the respondent. The undersigned hereby offers and agrees to furnish the equipment, materials, and/or services described in the attached proposal in compliance with the attached RFP. The undersigned represents that the information provided in the attached proposal is complete and accurate. Name of Firm: _____________________________________________________ Address: ______________________________________________________ ______________________________________________________ Date: ______________________________________________________ Printed Name of Authorized Representative: ______________________________________________________ Signature of Authorized Representative: ______________________________________________________ Phone: ______________________________________________________ Email: ______________________________________________________ Acknowledgement of Addenda Acknowledge receipt of all the addenda issued by the NFBA for this RFP by identifying the addendum number and its issue date below: Addendum Number Date _________________ ______________ ________________________ _________________ ______________ ________________________ _________________ ______________ ________________________ _________________ ______________ ________________________ _________________ ______________ ________________________ _________________ ______________ ________________________ _________________ ______________ ________________________ NFBA RFP #2011-05 Signature Page 48 North Florida Broadband Authority _________________ Attachment C: References ______________ ________________________ Please provide the following information (three references) describing your experience with projects similar to the NFBA project as well as the specific requirements described in this RFP. You may provide additional information as necessary to demonstrate your actual capabilities or the suitability of your equipment for use in the NFBA network. Name of Client NFBA RFP #2011-05 Project (What, When, Where) Client Contact Information (Name, Phone, Email) Page 49 North Florida Broadband Authority Attachment D: Public Entity Crimes (For Information Purposes Only) The following paragraph contains a statement informing persons of the provision of paragraph (2)(a) of Section 287.133, Florida Statutes: A person or affiliate who has been placed on the convicted vendor list following a conviction for a public entity crime may not submit on a bid contract to provide and goods or services to a public entity, may not submit a bid on a contract with a public entity for the construction or repair of a public building or public work, may not submit a bid on leases of real property to a public entity, may not be awarded or perform work as a contractor, supplier, subcontractor, or consultant under a contract with any public entity, and may not transact business with any public entity in excess of the threshold amount provided in Section 287.017, for CATEGORY TWO for a period of 36 months from the date of being placed on the convicted vendors list. The respondent certifies by submission of this proposal, that neither it nor its principals is presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participating in this transaction by any State or Federal department/agency. NFBA RFP #2011-05 Page 50 North Florida Broadband Authority Attachment E: Drug – Free Workplace Certification (Optional) DRUG-FREE WORKPLACE CERTIFICATION Preference shall be given to businesses with drug-free workplace programs. Pursuant to Section 287.087, Florida Statutes, whenever two or more competitive solicitations that are equal with respect to price, quality, and service are received by the NFBA, a response received from a business that certifies that it has implemented a drug-free workplace program shall be given preference in the award process. Established procedures for processing tie responses will be followed if none of the tied providers has a drug free workplace program. In order to have a drug-free workplace program, a business shall: 1. Publish a statement notifying employees that the unlawful manufacture, distribution, dispensing, possession, or use of a controlled substance is prohibited in the workplace and specifying the actions that will be taken against employees for violations of such prohibition. 2. Inform employees about the dangers of drug abuse in the workplace, the business's policy of maintaining a drug-free workplace, any available drug counseling, rehabilitation, and employee assistance programs, and the penalties that may be imposed upon employees for drug abuse violations. 3. Give each employee engaged in providing the commodities or contractual services that are under proposal a copy of the statement specified in Subsection (1). 4. In the statement specified in Subsection (1), notify the employees that, as a condition of working on the commodities or contractual services that are under proposal, the employee will abide by the terms of the statement and will notify the employer of any conviction of, or plea of guilty or nolo contendere to, any violation of Chapter 894, Florida Statutes, or of any controlled substance law of the United States or any state, for a violation occurring in the workplace no later than five (5) days after such conviction. 5. Impose a sanction on any employee who is so convicted or require the satisfactory participation in a drug abuse assistance or rehabilitation program as such is available in the employee's community. 6. Make a good faith effort to continue to maintain a drug-free workplace through implementation of applicable laws, rules and regulations. As the person authorized to sign the statement, I certify that this firm complies fully with the above requirements. BUSINESS NAME_________________________PROVIDER'S SIGNATURE__________________________ NFBA RFP #2011-05 Page 51 North Florida Broadband Authority Attachment F: Equal Opportunity Employer (EOE) Statement EQUAL OPPORTUNITY STATEMENT By submitting a proposal in response to this solicitation, the respondent agrees to: Not discriminate against any employee or job applicant because of their race, creed, color, sex, marital status or national origin; Post a copy of this pledge in a conspicuous place, available to all employees and job applicants. Place or cause to be placed a statement in all solicitations or advertisement for job applicants, including subcontracts, that the Respondent is an “Equal Opportunity Employer”. Respondent hereby agrees to and complies with this pledge. Name: _________________________________________ Date: _________________________________________ Signature: _________________________________________ NFBA RFP #2011-05 Page 52 North Florida Broadband Authority Attachment G: MBE/WBE/DBE Business Participation Minority Business Participation Minority Business Enterprise (MBE), Women Owned Business Enterprise (WBE), Disadvantaged Business Enterprise (DBE) participation is encouraged. It is the goal of the NFBA to consider (a) a respondent’s qualification as an MBE/WBE/DBE and/or (b) the respondent’s commitment to utilize other MBE/WBE/DBE in fulfilling its obligations on the NFBA project. The suppler may provide an MBE/WBE/DBE Participation Statement within the RFP response: An explanation/narrative of how the respondent and/or its subcontractors qualify as an MBE/WBE/DBE for the project. List of the locally certified MBE /WBE/DBE firms that will be utilized on the project including the services or equipment they are able to provide. Describe the methodology for monitoring the MBE/WBE/DBE participation on a continuing basis. Respondent qualifies as an MBE/WBE/DBE Participant – Yes [ ] No [ ] Name: _________________________________________ Date: _________________________________________ Signature: _________________________________________ NFBA RFP #2011-05 Page 53 North Florida Broadband Authority Attachment H: Conflict of Interest Statement By submitting a proposal in response to this solicitation, the respondent agrees that: Respondent does not and shall not have any employment or agreement, oral or written, with any third party relating to any interests which are in conflict with or otherwise inconsistent with any interest or position of the NFBA or its representatives Respondent shall not accept, during the term of any contract arising from this RFP, any retainer or employment from a third party whose interests appear to be conflicting or inconsistent with those of the NFBA. Respondent hereby agrees to and complies with this pledge. Name: _________________________________________ Date: _________________________________________ Signature: _________________________________________ NFBA RFP #2011-05 Page 54 North Florida Broadband Authority Attachment I: Business and Technical Resources Respondents are requested to provide the following information about their business, and technical resources to demonstrate how they have the capacity and capability to meet the requirements of this RFP. Please provide comments as appropriate. Category Statement Number of years in business Number of employees Location of headquarters Offices in Florida Type of business Public or privately held All respondents must have a DUNS Number please provide Primary products/services Major customers Technical strengths State of Florida Contracts NFBA RFP #2011-05 Page 55 North Florida Broadband Authority Attachment J: Pricing Information Use additional sheets if required Firewall Base Qty 4 4 Qty w/ spares 0 0 0 0 Model # Description Optional Equipment Optional Equipment Total Basic Total w/ other items recommended by respondent Bid Price Bid Price per unit Extended $ $ $ $ $ $ $ $ $ - Intrusion Base Qty 4 4 Qty w/ spares 0 0 0 0 Model # Description Optional Equipment Optional Equipment Total Basic Total w/ other items recommended by respondent Bid Price Bid Price per unit Extended $ $ $ $ $ $ $ $ $ - Carrier Class Router Base Qty 2 2 Qty w/ spares 0 0 0 0 Model # Description Optional Equipment Optional Equipment Total Basic Total w/ other items recommended by respondent NFBA RFP #2011-05 Bid Price Bid Price per unit Extended $ $ $ $ $ $ $ $ $ - Page 56 North Florida Broadband Authority Attachment K: Product Component Data Sheets Please provide product specification data sheets for all components: NFBA RFP #2011-05 Page 57 North Florida Broadband Authority Attachment L: Requested Responses Response Request for IPS/IDS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. Does the IPS include support for virtual sensors? How many virtual sensors does a single IPS device support? What mechanisms are in place to configure virtual sensors? Does the IPS use “Protocol and Application Anomalies” as detection techniques? Does the IPS use “Statistical Anomalies” as a detection technique? What types of tunneling protocols are supported by The IPS? Does IPS use statistical analysis to recognize DoS attacks? Do IPS appliances use stateful analysis to ensure accuracy? Is slow state maintained between two IPS appliances? Does the IPS handle various “Evasion Techniques?” If so, which ones does it handle? Does the IPS support “hot standby” mode for failover scenarios? Are the IPS devices certified by NSS Testing? Does the IPS use hard disks? Can the IPS detect and remove invalid packets from those flowing through the system? Does The IPS provide single interface traffic blocking? Does the IPS block unknown (zero days) attacks? Does the system protect against vulnerabilities with one or two signatures, or does it protect against individual attacks with many signatures? Can the IPS block attacks using protocols that are using non-standard ports? Can the system protect against “generic” attack indications such as remote “shell code”? Does it protect against encrypted attacks? Can the IPS be installed in asymmetric network environments? Does the system provide volume DoS protection? When mitigating a DoS attack does the IPS block legitimate new connections? If no how does it distinguish “good” traffic? Is DoS protection applied to the entire IPS segment or to individual systems or groups of systems? Can policies be applied to specific traffic flowing through the IPS, on an IP address, VLAN or subnet basis? Can policies provide different responses for traffic flowing inbound vs. outbound? Can the IPS device support multiple active policies per device? Can the IPS allow for ACL-type blocking to exclude or include specific traffic by service or port number? Can ACLs be specified on an IP address, subnet or VLAN basis? Can exceptions be setup to filter out, fine-tune or adjust the actions for specific attacker or destination IP on a per signature basis? Can the ports be configured for different types of connections; In-line, Span, Tap? Can the operator change from active (inline) mode to passive mode remotely? Does the IPS system offer an automatically scheduled mechanism to update signature files? Are new signatures automatically included in existing security policies? What tools does this product offer that let you measure baseline traffic norms? Does the IPS use stateful analysis at all times to ensure accuracy? Does the IPS respondent offer a “default blocking policy”? Can specific responses be configured for certain signatures? If so, what are the different responses that can be configured? Does sensor work in-line only, or can it support passive monitoring of switch SPAN port too? If passive monitoring is supported, what is the maximum number of ports that can be monitored by a single sensor? What is the maximum number of in-line connections (port pairs) that can be monitored by a single sensor? What features are available to prioritize alerts after an alert action is taken place? What type (copper/fiber) and speed of network connection are supported by the sensor (include default configuration plus any options)? What High Availability (HA) features are built in to the product by default? What High Availability (HA) features are available as extra cost options? NFBA RFP #2011-05 Page 58 North Florida Broadband Authority 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. List required open ports on sensor and their use Regex supported when creating custom signatures? Can the administrator define custom attack signatures? What infrastructure does the respondent have behind the signature update process (i.e. dedicated team of engineers? How many? Does it have a name?) How are new attacks signatures obtained and deployed? Frequency of signature updates? What network protocols are analyzed? What application-level protocols are analyzed? Can the product perform protocol decodes? Are there any examples of how decoded information adds value in the IPS sensor? Can you define a default operating system that will be used in the attack relevance calculation? Can the product perform protocol anomaly detection? Is anomaly detection learning always turned on? Does the IPS have zero day attack protection? Can sensor support both normal and asymmetric network configurations? Is the detection engine “stateful”? If so, please explain how this works. If stateful - how many open connections can be tracked? Is this value configurable? If stateful - for how long are partially opened connections tracked? Is this configurable? If stateful - for how long are fully opened connections tracked if not used? Is this configurable? What is the default action when system resources run low or state tables are filled - block or permit all new connections? Is this default action configurable? What is the default action when power fails or the system is powered down - block or permit all traffic? Is this default action configurable? Does the IPS product perform deobfuscation? Does the IPS product perform packet/stream reassembly? What is the default action when the sensor is unavailable for any length of time (i.e. during policy download or software update - block or permit all traffic? Is this default action configurable? Will the detection engine block/alert on ALL suspicious activity, or only when an attack is made against a vulnerable server? Detect/block SYN floods? Manual or automatic thresholds? Configurable? How is SYN flood protection implemented Ability to monitor user-defined connections (i.e. report on an FTP connection to a specific server?) Is all traffic scrubbed/normalized/reordered as it passes through the sensor? Can you record entire sessions for “forensic” investigation? Where is this data stored? How is it secured from tampering? List all prevention features available. How is fragmented traffic handled by the sensor? Does the IPS have packet capture capabilities? Are IPS device(s) signatures/filters categorized and searchable? Does the IPS have Passive IDS listeners (no transmit)? Does the IPS have Network Tap Support for IDS devices or other was to fail over sensors? Are signature based filters tunable? Does the IPS have the ability to trigger events based on specific Source and/or destination IP Address? Does the IPS have the ability to trigger events based on specific Source and/or destination port? Does the IPS have the ability to trigger events based on Traffic direction? Are IPS devices able to identify RFC anomalies? Are IPS devices susceptible to attack evasion techniques What are the MTBF numbers in hours of the appliance? Is latency less than 1 millisecond with attack traffic and all signatures and detection methods enabled? Does the IPS pass traffic at the full “wire speed” of the connected segment? Does the IPS pass traffic at full rated speed with all signatures and detection engines enabled? Is the stated full rate measured for bi-direction or uni-directional traffic? Do the IPS sensors support full sensor virtualization? How is the product licensed? How is the license enforced? NFBA RFP #2011-05 Page 59 North Florida Broadband Authority Response Request for Router High Availability 1. Hardware Redundancy - Specify the total available Slots for Line Cards in the case where Main Processors and Switch Fabric Modules are rolled-out with full redundancy. 2. Specify slot usage restrictions for line cards, if any. Update/Upgrade 3. Specify minimum and maximum downtime in case of a full Firmware/Software Update/Upgrade (assuming the redundant control and forwarding blade are in place). 4. Which SW components are supported with in-service Firmware/Software Update/Upgrade? (i.e. Routing protocols, Switching, Dynamic states, etc)? 5. Indicate support for in service Software Patching (bug fixing without full box reload but with partial software upgrade). 6. Specify maximum Duration of Service Interruption for Stateful Failover (if applicable). 7. Detail the software and firmware upgrade procedure of the Platform including any service interruption time. Platform Architecture Requirements All 10/100/1000TX Ethernet interfaces must support all required CoS functionality. Refer to separate CoS section of the requirements for all required CoSfunctionality. 8. Respondent must list total 10/100/1000 Ethernet interfaces per router with the platform fully populated with the proposed Gigabit Ethernet cards. 9. Respondent must list total 10/100/1000 Ethernet interfaces per router with the platform fully populated with the proposed Gigabit Ethernet cards. 10. Respondent must list total Gigabit Ethernet interfaces per router with the platform fully populated with the proposed Gigabit Ethernet line cards. 11. Respondent must list total 10 Gigabit Ethernet interfaces per router with the platform fully populated with the proposed Gigabit Ethernet cards. Note that the density on the platform for 10 GE ports that meet all other requirements will be very important decision criteria. 12. Platform must support Aggregate Ethernet for Gigabit Ethernet ports. The platform must support aggregate Ethernet bundles consisting of at least 6 active GE links per bundle. Aggregate Ethernet must support efficient distribution of Internet traffic over the GE elements of the Aggregate Ethernet bundle for IPv4, IPv6 traffic. Respondent must describe the packet elements used to determine distribution of flows to link bundle elements. 13. Respondent must describe the packet elements used to determine distribution of flows to link bundle elements. 14. Respondent must list total power requirements of the platform with a chassis fully loaded with the proposed interfaces, and modules. 15. Respondent must provide details for any deviations or exceptions on support for any of the features listed above CoS 16. All functionality required in this section must be supported for all proposed interfaces. 16a. When providing responses, please provide the information related to performance at the interface line rate. 16b. All exceptions must be noted . 16c. For each item listed below for which you answered yes explain/list any hardware in your proposal that does not perform the indicated function Platform must support both L2-CoS and L3-CoS over the same port/interface type. Platform must support applying the CoS policy per VLAN interface, where multiple VLAN interfaces are expected per port/Interface Classifiers and schedulers Platform must have the ability to classify and schedule traffic based on COS Platform must have the ability to classify and schedule traffic based on IPv4 TOS Platform must have the ability to classify and schedule traffic based on IPv6 TOS NFBA RFP #2011-05 Page 60 North Florida Broadband Authority Platform must have the ability to classify and schedule traffic based on IPv4 DSCP Platform must have the ability to classify and schedule traffic based on IPv6 DSCP Platform must have the ability to classify and schedule traffic based on MPLS EXP bits Platform must have the ability to classify and schedule traffic based on Source IP address Platform must have the ability to classify and schedule traffic based on Destination IP address Platform must have the ability to classify and schedule traffic based on Source UDP port Platform must have the ability to classify and schedule traffic based on Destination UDP port Platform must have the ability to classify and schedule traffic based on Source TCP port Platform must have the ability to classify and schedule traffic based on Destination TCP port Platform must have the ability to classify and schedule traffic based on Source MAC address Platform must have the ability to classify and schedule traffic based on Destination MAC address Platform must have the ability to classify and schedule traffic based on VLAN ID. Platform must have the ability to classify and schedule traffic based on inner QinQVLAN tag Platform must have the ability to classify and schedule traffic based on outer QinQVLAN tag Platform must have the ability to classify and schedule traffic based on combination of inner and outer QinQ VLAN tag 17. Please describe any other (not listed above) traffic classifying/scheduling capability that the platform supports. For directly connected VPLS customers that are not sending us VLAN ID we will not have the information. The platform must provide the capability to look down into the IP header in order to classify traffic on all ingress interfaces, and subsequently map TOS into the EXP bit. 18. Platform must support policing of traffic based on any combination of above. Please explain 19. Queuing and Shaping 19a. Platform must support at least 8 CoS queues on all proposed interfaces. Please list any limitations 19b. Platform must support at least 8 CoS queues on all VLANs. Please list any limitations 19c. Platform must support 4 priority queues on the same port. Please list full capabilities 19d. Platform must support 4 priority queues in the same QoSpolicy. Please list full capabilities 20. Marking - Platform must have the ability to mark or re-mark traffic based on any combination of VLAN, COS, TOS, DSCP, EXP, source / destination IP, MAC address, UDP, TCP ports. Please explain in detail. 21. Platform may support EXP marking based on any other information. Please explain 22. Hierarchical QoS - Platform must support multiple rate and color hierarchical policers. Please describe in detail 23. Forwarding - Line rate forwarding must operate with standard internet packet size mixes with MPLS FRR encapsulation, EXP based CoS queuing and uRPF running simultaneously on the interface. Respondent must provide forwarding performance information for all packet sizes 64-4000 bytes. 24. Forwarding performance must include % of maximum bandwidth at that packet size. 25. Line rate forwarding must operate with standard internet packet mixes. Respondent must provide forwarding performance information for all packet sizes 64-4000 bytes. Respondent must provide detailed information about packet forwarding rates, including any saw tooth forwarding points above 64 bytes that are below line rate. Packets must be delivered in sequence. 26. Line rate forwarding must operate with standard internet packet mixes with packet filtering, flow monitoring, and uRPF running simultaneously on the interface. Respondent must provide detailed information about packet forwarding rates, including any saw tooth forwarding points above 64 bytes that are below line rate. Packets must be delivered in sequence, uRPF must not affect forwarding rate. 27. Respondent must list any packet forwarding functions that in IPv4 are hardware/ASIC based that are software/CPU based for IPv6 packets. 28. Platform must support all forwarding features listed above on aggregated Ethernet interfaces. All listed features not supported on aggregated Ethernet interfaces must be listed. 29. ISIS - Platform must support at least 100 ISIS adjacencies per router. Respondent must list the maximum ISIS adjacencies supported. 30. All listed features not supported on aggregated Ethernet interfaces must be listed. NFBA RFP #2011-05 Page 61 North Florida Broadband Authority 31. Routing in Intermediate System to Intermediate Systems (IS-ISs). Respondent must indicate which families are supported. 32. Please provide the information about the Minimum BFD hello timer 33. Please provide the information about the Minimum recommended BFD hello timer 34. Please provide the information about the Minimum BFD multiplier 35. Please provide the information about the Minimum recommended BFD multiplier 36. Please describe in detail all supported ISIS fast convergence functionality 37. IPv6 - Respondent must list any packet forwarding functions that in IPv4 are hardware/ASIC based that are software/CPU based for IPv6 packets. 38. 39. 40. 41. 42. 43. 44. L2 functionality support - Please provide maximum number of links in an 802.3ad link bundle Please provide the Maximum Number of CFM domains, as supported by your platform Respondent must provide details on how long does it take to detect link down on 10 gig Ethernet interface Please provide the maximum number of BGP routes in RIB Please provide the maximum number of BGP routes in FIB Please describe behavior when prefix limits are reached Platform must have BGP peer group support or standard BGP session settings that are inherited by peers assigned to that group. Please explain 45. Please list all BGP RFCs that your switch/router complies with 46. Please describe any other important core routing functions, capabilities, or innovations that might be in your product. 47. 48. 49. 50. 51. 52. 53. 54. 55. MPLS - Please provide the max number of LDP labels supported on this platform Please provide the max number of LDP neighbors supported on this platform Please provide the maximum number of LDP LSPs What is the maximum number of RSVP LSPs supported on this platform Platform must support MPLS FRR restoration with a total loss of traffic of 50ms plus latency or less. This switch time must be supported with 2000 LSPs switching from a failed primary path to a backup FRR path in the router. If this requirement is not supported, please provide the results when FRR for 2000LSP was tested Please describe known FRR interop issues with major respondents (Alcatel, Juniper, and Cisco). Platform must support MPLS Fast Reroute Bypass as implemented by Juniper and Cisco. Please describe known FRR interop issues with major respondents (Alcatel, Juniper, and Cisco). Auto-Templates for LSP characteristics and tunnel building (primary and backup LSPs) must be supported. Please include details of your implementation. Platform must support MPLS TE Dynamic Path Protection (AKA Juniper secondary LSPs). If this support is not available, please provide roadmap information and plans to support it in the future. 56. VPLS - VPWS - What is the maximum number of Peers per VPLS instance 57. What is the maximum number of attachment circuits per VPLS instance 58. Describe your pseudo wire redundancy mechanism in detail 59. Scalability- Please provide the number of VRFs supported per system. 60. When binding multiple interfaces / sub-interfaces to the same VRF, please provide the maximum number of interfaces / sub-interfaces that can be associated with the same VRF. 61. Please provide the number of IPv4 routes supported per VR / VRF 62. Please provide the number of IPv4 routes supported per system 63. Please provide the number of IPv6 routes supported per VR / VRF 64. Please provide the number of IPv6 routes supported per system 65. Please describe how the IPv4 and IPv6 address table allocation sizes are handled 66. 67. 68. 69. Multicast - Please provide the maximum number of multicast routes Please provide the maximum number of multicast group joins Please provide the maximum multicast replication capacity per line-card What is the maximum multicast replication capacity per switch NFBA RFP #2011-05 Page 62 North Florida Broadband Authority 70. Platform must support ability to rate limit multicast flows. Please provide a full description of your capability for both L2 and L3 71. Platform must support ability to filter multicast flows. Please provide a full description of your capability for both L2 and L3 72. Explain any options for multicast stream redundancy 8.13.5.17 Management 73. What built-in test capabilities and loopback functions are provided? NFBA RFP #2011-05 Page 63
