1. Purpose and Scope
This document defines the connectivity planning framework for GridCore campuses. It is not a carrier contract, telecom service order, fiber IRU, dark fiber agreement, SLA, construction permit, network design certification, latency guarantee, or serviceability commitment.
It is intended to align campus developers, carriers, tenants, network engineers, facility operators, security teams, OT teams, construction teams, and commercial teams around a structured approach to connectivity planning. Actual network availability, diversity, costs, routes, cross-connect fees, service levels, and delivery dates must be confirmed through project-specific diligence and direct carrier engagement.
2. Connectivity Planning Premise
AI/HPC campuses require more than generic internet access. Customers may need diverse carriers, cloud on-ramps, private fiber, dark fiber, IP transit, transport, out-of-band management, remote access, WAN interconnection, and low-latency routes to key markets. Connectivity planning must be structured with the same discipline applied to power and cooling.
Network planning must include physical route diversity, logical segmentation, demarcation design, cross-connect workflows, security boundaries, operational procedures, and documentation. Planning must also clearly distinguish tenant production networks, carrier networks, corporate IT, physical security networks, building systems, and OT/ICS networks — each with separate access, monitoring, and operating authority.
3. Connectivity Domains Overview
| Domain | Function | Typical GridCore Treatment | Project-Specific Variables |
|---|---|---|---|
| Carrier entry | Physical path for carrier infrastructure to reach campus | Conduit, manhole, designated entry points | Number of carriers, entry separation, permitting |
| Diverse route pathways | A/B physical separation for resiliency | Independent conduit routes, separate trenches | Available paths, crossing requirements, land rights |
| Meet-me rooms | Carrier demarcation and cross-connect point | MMR A and MMR B in separate locations | Room size, power, environmental, carrier requirements |
| Building demarcation | Entry point for each building on campus | Building MDF/IDF rooms, diverse entry where feasible | Building design, entry path availability |
| Inter-building fiber | Campus backbone connecting MMRs to buildings | High-count fiber, A/B routes | Route separation, duct bank design, spare capacity |
| Cross-connects | Logical connections between customer and carrier ports | Documented work order process, cable management | Pricing model, authorization, turnaround time |
| Tenant network handoff | Customer demarcation within building or cage | Patch panel, ODF, labeled and documented | Offering model, customer requirements |
| Dark fiber | Un-lit fiber strands for customer or operator use | Campus-owned or leased, documented strand assignments | Availability, IRU terms, lit/dark customer choice |
| Lit transport | Active wavelength or circuit services | Carrier-provided or operator-managed | Carrier availability, service levels, pricing |
| IP transit | Internet routing for tenants or campus | Carrier-provided at demarcation | Provider selection, redundancy, peering options |
| Cloud on-ramp | Direct or virtual private connection to cloud providers | Carrier-facilitated or exchange-based | Provider availability at site, lead time, pricing |
| Out-of-band management | Separate management network independent of production | Isolated management plane, console servers | Carrier for OOB, redundancy requirements |
| Corporate IT network | Campus operator internal network | Separate from tenant and OT networks | Security posture, remote access model |
| Security/CCTV/access control | Physical security systems network | Dedicated VLAN, isolated from tenant and OT | Camera count, access points, monitoring integration |
| BMS/EPMS/SCADA/OT | Operational technology systems network | Air-gapped or tightly segmented, controlled access | OT vendor requirements, remote access controls |
| Customer portal/API | Tenant-facing management and monitoring access | Authenticated, read-only default, logged | Customer integration requirements |
| Wireless/LTE/satellite backup | Out-of-band or backup connectivity where scoped | Project-specific, documented as primary/backup | Coverage, bandwidth, cost, failover triggers |
| Network monitoring | Active monitoring of network health and events | SNMP/syslog, NOC integration, alerting | Coverage scope, escalation thresholds |
| Documentation and records | Circuit inventory, maps, cross-connect records | Maintained as living document set | Version control, owner assignment, review cadence |
4. Carrier Entry Strategy
The carrier entry strategy defines how telecommunications infrastructure reaches the campus from outside the property boundary. The number of physical entry points, the separation between them, and the conduit pathway design all determine whether claimed network diversity is real or theoretical.
Planning considerations include the number and physical separation of carrier conduit entries, manhole and handhole placement along entry routes, high-count spare conduit for future carriers, route diversity verification through physical path analysis rather than carrier representations, railroad/highway/utility corridor crossing requirements and permitting, splice location management, potential carrier huts or on-campus points of presence, landlord/campus access license terms, and maintenance window coordination.
5. Meet-Me Room and Demarcation Planning
| MMR Element | Purpose | Planning Consideration | Operating Evidence |
|---|---|---|---|
| Carrier entrance conduit | Bring external fiber into the MMR | Separate conduit routes for MMR A and MMR B | As-built record, conduit labeling |
| OSP splice point | Transition from outside plant to inside plant fiber | Splice case location, access, weatherproofing | Splice record, OTDR baseline |
| ODF / fiber panel | Terminate and manage fiber within the MMR | Port count, connector type, labeling standard | Port assignment log, splice record |
| Carrier cabinet | House carrier equipment within the MMR | Carrier-specific power/space requirements, access rights | Power circuit record, carrier access log |
| Meet-me rack | Neutral cross-connect location between carriers and customers | Position relative to carrier and customer ports | Cross-connect log, port assignment record |
| Cross-connect field | Manage physical connections between ports | Cable management, bend radius, labeling | Cross-connect work order archive |
| Cable tray / ladder rack | Organize and protect cables within MMR | Load capacity, routing, separation from power | Installation record, inspection log |
| Labeling scheme | Identify every cable, port, panel, and device uniquely | Labeling standard documented, consistently applied | Label audit, deviation log |
| Access control | Restrict entry to authorized personnel | Badge/PIN access, carrier escort rules, visitor log | Access event log, escort records |
| Power and grounding | Provide clean, reliable power and proper ground | Dedicated circuits, UPS where required, grounding bus | Power circuit record, grounding test report |
| Environmental monitoring | Detect temperature, humidity, and water leaks | Sensor placement, alarm routing, retention | Sensor log, alarm test record |
| As-built records | Document the final installed state | Required before first carrier tenant activation | As-built drawing package, update process |
Diverse MMR placement — physically separated MMR A and MMR B rooms served by independent conduit routes and served from different directions if possible — is a fundamental design objective for campuses serving critical tenant requirements. Critical tenant accounts may require dual demarcation points with independent path verification.
6. Campus Fiber Distribution
| Fiber Distribution Topic | Reference Approach | Risk Controlled | Required Record |
|---|---|---|---|
| A/B backbone | Dual independent fiber routes across campus | Single-point-of-failure cable cut | Route map, duct bank record |
| Building entrance diversity | Two physically separate conduit entries per building where feasible | Building entry cut disrupting all connectivity | Entrance conduit record, separation documentation |
| Spare conduit | Additional empty conduits pre-installed | Future carrier or customer expansion delays | Conduit inventory, fill status record |
| Spare strand capacity | Unlit fiber strands held in reserve | Fiber exhaust forcing new construction | Strand assignment log, utilization tracking |
| Handhole placement | Access points for splicing, maintenance, and expansion | Inability to repair or expand without major excavation | Handhole map, lid labeling |
| Fiber labeling | Consistent tube/strand identification from end to end | Incorrect strand activation or maintenance on wrong fiber | Labeling standard, splice matrix |
| Route map | Accurate GIS or drawing of all campus fiber routes | Excavation damage, incorrect locate | Route drawing, version history |
| Splice record | OTDR and splice loss documentation per splice point | Undetected degradation, troubleshooting delay | OTDR traces, splice loss log |
| OT/IT separation | Physical or logical isolation of OT fiber from tenant/carrier paths | OT network exposure via fiber path | Separation design document |
| Maintenance access | Access to all splice points and manholes for maintenance | Inability to perform emergency repair | Maintenance route record, access rights documentation |
| Emergency repair path | Pre-identified alternate routing for emergency restoration | Extended outage from single cable cut | Emergency restoration plan, spare cable staging |
7. Inter-Building Fiber and Tenant Handoff
| Offering Model | Connectivity Interface | Typical Customer Responsibility | Campus Responsibility | Evidence Required |
|---|---|---|---|---|
| Powered Land | Fiber demarcation at parcel boundary or building entry | All connectivity beyond demarcation point | Conduit/fiber to demarcation, documented handoff | Parcel connectivity exhibit, OTDR baseline |
| Powered Shell | Fiber terminated in building MDF/IDF room | Customer internal distribution from MDF | Campus backbone to building MDF, patch panel termination | Building fiber record, as-built, activation test |
| Turnkey Colocation | Cage/suite-level demarcation, cross-connects to MMR | Customer circuits ordered through cross-connect process | Cross-connect fulfillment, patch panel, MMR access | Cross-connect record, circuit test, LOA if applicable |
| Dedicated Building | Building-level fiber, separate MDF room | Customer controls from MDF inward | Building fiber, access to MMR, cross-connect support | Building handover package, fiber record |
| Carrier POP | Carrier equipment housed in MMR, fiber handed to carrier equipment | Carrier installs and manages equipment | MMR space, power, conduit, escort rules | Carrier access agreement, power circuit record |
| Managed Connectivity Add-On | Campus-managed circuit delivery to customer demarcation | Customer accepts delivered circuit | Full circuit delivery, testing, documentation | Circuit delivery record, test results, SLA documentation |
8. Cross-Connect Process
Cross-connect fulfillment must follow a documented, auditable process. Unauthorized cabling is strictly prohibited. Every physical connection in the MMR, cross-connect field, or building demarcation room must be associated with an authorized work order, documented in the circuit inventory, and accepted by the requesting party.
9. Network Segmentation Framework
A GridCore campus must not collapse operational, tenant, carrier, corporate, and security networks into a single logical fabric. Segmentation is an operational control, not an optional design preference. Each network domain requires its own access model, monitoring scope, and escalation path.
| Network Domain | Purpose | Should Be Separated From | Access Control Principle | Monitoring / Logging Need |
|---|---|---|---|---|
| Tenant production | Customer IT workload traffic | All campus and other tenant networks | Customer-controlled within demarcation | Border monitoring, anomaly detection |
| Tenant management | Customer IPMI, iDRAC, management plane | Tenant production and campus networks | Customer-controlled, out-of-band preferred | Access logging at campus demarcation |
| Carrier meet-me | Carrier equipment and cross-connect field | All other network domains | Carrier-controlled within MMR cage/cabinet | MMR access log, carrier visit records |
| Corporate IT | Campus operator internal systems | Tenant, OT, and carrier networks | MFA, RBAC, endpoint controls | Full EDR, SIEM integration |
| Visitor Wi-Fi | Guest internet access | All other domains | Captive portal, isolated to internet only | Traffic logging, session records |
| CCTV | Physical security camera network | All other networks | Security operations only, no remote access without MFA | Camera health, recording continuity monitoring |
| Access control | Physical access credential systems | All other networks | Access control admin only, encrypted comms | Access event log, admin change log |
| BMS | Building management system | All other networks, especially tenant and corporate | OT admin only, controlled remote access | Change log, alarm history |
| EPMS | Electrical power monitoring system | All other networks | OT admin only, read-only for dashboards | Metering data log, alarm history |
| SCADA / OT | Generation and critical process controls | All other networks — most strictly isolated | Jump host only, MFA, logging, no direct internet | Full command log, anomaly detection |
| Generation controls | Generation plant control systems | All other networks — air gap or equivalent preferred | Plant operator only, vendor under strict escort | Full audit trail, session recording where feasible |
| Customer portal/API | Tenant status and monitoring views | OT and production networks | Authentication, RBAC, read-only default | Session log, API call log |
| Out-of-band management | Console and management access to campus infrastructure | Production and tenant networks | MFA, dedicated OOB path, session recording | Session log, command log |
10. OT/IT Cybersecurity Boundary
OT networks for BMS, EPMS, SCADA, generation controls, and other critical systems must be separated from corporate IT, tenant networks, and all external access pathways except under tightly controlled conditions. The OT boundary is a safety control, not just a security control — unauthorized access to or disruption of OT systems can create physical risk to personnel, infrastructure, and tenants.
Key OT/IT boundary controls include physical and logical network separation, jump host architecture for all remote OT access, multi-factor authentication for all OT system access, comprehensive session and command logging, formal change management for OT configuration changes, vendor access restricted to scheduled maintenance windows with escort and logging, defined patch windows that align with campus maintenance procedures, backup and recovery procedures tested on schedule, and incident response procedures that include OT-specific scenarios.
Frameworks such as NIST guidance, IEC/ISA concepts, SOC controls, or customer-specific security requirements may be considered where applicable, but this reference does not claim certification or compliance. Project-specific cybersecurity obligations must be defined by qualified practitioners.
11. Carrier Serviceability and Diligence
Carrier serviceability claims must be converted into verified facts before being represented to customers or embedded in commercial commitments. Near-net coverage on a carrier map does not mean the carrier can deliver at the required capacity, timeline, or price without additional construction. Route diversity assumptions must be validated — not assumed.
| Diligence Area | What to Verify | Common Risk if Not Verified |
|---|---|---|
| Carrier list | Which carriers have active on-campus POPs or can deliver without new construction | Overstating available carrier count to customers |
| Route maps | Physical path of each carrier route from core network to campus | Assumed diversity on a shared physical path |
| Distance to existing fiber | Actual measured distance from carrier fiber to campus entry point | Construction cost and timeline surprise |
| Available services | What specific services each carrier offers: dark fiber, lit wavelength, IP transit, Ethernet, cloud on-ramp | Customer commitment before service availability confirmed |
| Lit/dark fiber options | Whether customer can obtain dark fiber or only lit services from each carrier | Pricing and flexibility mismatch with customer requirements |
| Construction requirements | Whether make-ready, permitting, or new build is required | Extended delivery timeline for first carrier installation |
| Route diversity evidence | Physical path separation confirmation, not just carrier assurance | Single-path exposure despite two-carrier claim |
| Latency estimates | Round-trip latency from campus to key customer endpoints, by provider | Latency-sensitive customer disappointed post-installation |
| Cloud on-ramp availability | Whether cloud on-ramp is direct, exchange-based, or requires additional carrier | Additional procurement steps not in customer scope |
| Service level terms | Carrier SLA for the specific service type and delivery path | Campus SLA to customer exceeds carrier SLA backing it |
| Install interval | Carrier lead time from order to delivery for each service type | Customer go-live delay due to circuit procurement timeline |
| Access requirements | What access rights, escort rules, and work permits carriers require on campus | Carrier unable to install due to unresolved access terms |
| Maintenance procedures | Carrier maintenance window notification requirements | Unplanned outage due to undisclosed carrier maintenance |
| Demarcation responsibilities | Who owns and maintains the demarcation point and cross-connect field | Dispute over trouble ticket ownership on circuit issues |
| Pricing assumptions | MRC, NRC, cross-connect fees, make-ready charges | Customer pricing based on assumptions not yet verified with carrier |
12. Latency and Market Reach
Latency-sensitive workloads — including edge inference, distributed GPU clusters, data replication, cloud connectivity, and where applicable financial or trading applications — require specific attention to path length, network provider selection, routing policies, and measurement methodology.
Backhaul to major metropolitan markets, cloud regions, and peering exchanges depends on which carriers are available, what services they offer, and whether the required routes exist without additional construction. Campus materials should not represent latency to specific markets without verified and current path analysis.
13. Connectivity for AI/HPC Workloads
AI and HPC workloads place different demands on campus connectivity than traditional enterprise IT. Large data ingest, dataset staging, model checkpoint movement, distributed training across multiple sites, storage replication, and remote GPU cluster management all require careful WAN planning. Customer requirements for bandwidth, route diversity, cloud on-ramp, and out-of-band management should be captured in the onboarding process — not discovered after equipment installation.
GridCore campus connectivity planning does not replace tenant cluster network design. Tenant InfiniBand fabrics, RoCE networks, Ethernet storage networks, and internal cluster switching are typically customer or system integrator scope unless specifically included in a managed offering. The campus connectivity boundary ends at the tenant demarcation point.
14. Monitoring, Documentation, and Records
A campus connectivity program is only as reliable as its documentation. Carrier circuit inventories, cross-connect records, fiber route maps, port assignments, tenant demarcation records, MMR access logs, and network diagrams must be maintained as living documents — updated after every change, not reconstructed after an incident.
Key records include fiber route drawings, cross-connect work order archives, circuit inventory with A/B endpoints, carrier contact list with escalation paths, port assignment logs per panel, tenant demarcation records per customer, OTDR baseline traces, change logs with version history, incident tickets, maintenance notifications, service test records, and customer portal access logs.
15. Operating Model and Escalation
| Connectivity Issue | First Owner | Supporting Party | Escalation Trigger | Customer Communication |
|---|---|---|---|---|
| Carrier outage | Campus network ops / NOC | Carrier NOC | SLA threshold reached or customer reports impact | Proactive notification per SLA/MSA terms |
| Cross-connect failure | Campus facilities / network ops | Carrier if carrier-side, customer if customer-side | Circuit down or customer reports issue | Immediate notification, ticket number |
| Fiber cut | Campus network ops / facilities | OSP contractor, carrier | Loss of service on affected path | Customer notification, estimated restoration |
| Port assignment dispute | Campus network ops / MMR admin | Customer and carrier | Customer or carrier reports incorrect connection | Investigation, resolution, record update |
| MMR access issue | Security / campus operations | Carrier or vendor requiring access | Carrier or vendor unable to perform scheduled work | Work rescheduling, access process review |
| Latency concern | Customer-raised, campus network ops reviews | Carrier, customer network team | Customer SLA threshold or workload performance issue | Investigation, path analysis, carrier engagement |
| Packet loss concern | Campus network ops / NOC | Carrier, customer network team | Customer-reported threshold or monitoring alert | Investigation, escalation per SLA |
| Security event | Security operations | IT security, OT security if applicable | Anomaly detected, intrusion indicator | Per incident response plan, not public communication |
| OT network alarm | OT/controls team | Facilities, engineering | OT alarm generated, controls anomaly | Internal only unless customer-impacting |
| Customer portal issue | Campus IT / ops | Customer | Customer cannot access portal or data is incorrect | Immediate notification, incident ticket |
| Planned carrier maintenance | Carrier provides advance notice | Campus ops, customers | Customer SLA maintenance window requirements | Pre-notice to affected customers per SLA/MSA terms |
| Unauthorized cabling | Security / campus facilities | Customer, contractor management | Discovery of cable not in work order system | Customer notification, removal, access review |
16. Project-Specific Connectivity Exhibits
Each GridCore project should produce the following connectivity documentation as part of its project package. These are not templates — they must be developed for the specific site, carrier environment, customer mix, and operating model.
- Carrier availability report with current serviceability status
- Carrier route diversity analysis with physical path verification
- MMR layout drawings for MMR A and MMR B
- Campus fiber distribution plan with route separation documentation
- Building demarcation exhibit per building
- Powered land parcel connectivity exhibit
- Cross-connect process and work order procedure
- Network segmentation diagram distinguishing all network domains
- OT/IT boundary diagram
- Carrier access rules and escort procedures
- Circuit inventory template and management process
- Serviceability assumptions register (with status and verification dates)
- Managed connectivity SOW if operator-provided connectivity is in scope
- Customer connectivity responsibility matrix by offering model
- Network incident escalation matrix
Framework Disclaimer: This reference describes a connectivity planning framework only. Actual carrier availability, path diversity, latency, construction timelines, service levels, demarcation rights, cross-connect fees, access rights, and network responsibilities must be verified and documented in project-specific agreements, carrier orders, technical exhibits, and approved operating procedures.
Implementation Notice
This reference describes a framework model. It is not a substitute for project-specific engineering, permitting, interconnection approval, environmental review, safety review, legal documentation, procurement, commissioning, or operating procedures. All capacity, availability, timeline, and commercial terms are project-specific and subject to applicable approvals and agreements.