Juniper NorthStar Controller

Juniper NorthStar Controller
Colby Barth, DE, Juniper Networks JDI February 2nd, 2015 In collaboration with: Tony Le, Naresh Kumar, Sudhir Cheruathur, Ping Wang, Rendo Wibawa Juniper Confidential

1 1 2 1 3 1 4 1 5 AGENDA INTRO. TO PCE ARCHITECTURE - STRATEGY
NORTHSTAR 1.0 COMPONENTS 1 3 JUNOS CLIENT – PCCD – BGP-LS 1 4 NORTHSTAR 1.0 APPLICATIONS – FEATURES 1 5 NORTHSTAR 1.0 MISC. – WRAP-UP

? ? ? 1 1 2 1 3 Challenges with current networks
How to Make the Best Use of the Installed Infrastructure? ? 1 How do I use my network resources efficiently? ? 1 2 How can I make my network application aware? ? 1 3 How do I get complete & real-time visibility?

NorthStar: Traffic Engineering w/ a Global View
Address real networking problems Bin Packing or Network Defragmentation Optimizations that require global orchestration Multi-layer (not just IP + Optical) Reduce JUNOS complexity Large computations An API for network Scheduling / Calendaring Solve hard problems Predictability Adaptive TE Control Loops Inter-domain Routing Global Concurrent Optimization Off-load Rtr Control-plane Network Lifecycle Management Integrate with Applications

PCE: Evolutionary approach Active Stateful PCE Extensions
PCE dynamically learns the network topology PCCs report the LSP state to the PCE Via the PCEP, the PCE can update LSP B/W & path attributes, if the LSP is *controlled* The PCE can *create* LSPs on the PCC, ephemerally PCE: Evolutionary approach Active Stateful PCE Extensions Real-time Awareness of LSP & network state P2MP LSP path computation & P2MP tree diversity Disjoint SRC/DST LSP path diversity Multi-layer & multiple constraints LSP attribute updates Create & tear-down LSPs HARDER PROBLEMS OFFLOADED FROM NETWORK ELEMENT * No persistent configuration is present on the PCC

What are the components?
PCE architecture A Standards-based Approach for Carrier SDN What is it? What are the components? A path Computation Element (PCE) is a system component, application, or network node that is capable of determining and finding a suitable route for conveying data between a source and a destination Path Computation Element (PCE): Computes the path Path computation Client (PCC): Receives the path and applies it in the network. Paths are still signaled with RSVP-TE. PCE protocol (PCEP): Protocol for PCE/PCC communication RFC 4655 defines PCE model RFC 5440 defined PCEP Several drafts currently in circulation We support a standards-based approach to PCE PCE PCEP PCC PCC PCC

Active Stateful PCE A centralized network controller
The original PCE drafts (of the mid-2000s) were mainly focused around passive stateless PCE architectures: More recently, there’s a need for a more ‘Active’ and ‘Stateful’ PCE NorthStar is an active stateful PCE This fits well to the SDN paradigm of a centralized network controller What makes an active Stateful PCE different: The PCE is synchronized, in real-time, with the network via standard networking protocols; IGP, PCEP The PCE has visibility into the network state; b/w availability, LSP attributes The PCE can take ‘control’ and create ‘state’ within the MPLS network The PCE dictates the order of operations network-wide. NorthStar Report LSP state Create LSP state MPLS Network

SOFTWARE-DRIVEN POLICY
NorthStar components & Workflow SOFTWARE-DRIVEN POLICY Open APIs ANALYZE OPTIMIZE VIRTUALIZE Topology Discovery Path Computation State Installation Routing Application Specific Alg’s PCEP PCEP TE LSP discovery IGP-TE, BGP-LS TED discovery (BGP-LS, IGP) LSDB discovery (OSPF, ISIS) PCEP Create/Modify TE LSP One session per LER(PCC) RSVP signaling

PCE Control & Ephemeral State
LSP delegation, control, & creation PCE controlled LSPs A PCC may delegate control of an LSP to the PCE Subsequent changes of an LSP’s attributes MUST be made by the PCE PCE provisioned LSPs PCE may create an LSP LSP state is referred to as ephemeral PCE provisioned LSPs are also PCE controlled LSPs Data-plane does not change [edit protocols] mpls { label-switched-path PCC1-to-PCC2 { lsp-external-controller NorthStar; pcep { pce NorthStar { delegation-cleanup-timeout <sec>; [edit protocols] pcep { pce NorthStar { lsp-provisioning; lsp-cleanup-timer <sec>;

NorthStar major components
NorthStar consists of several major components: JUNOS Virtual Machine(VM) Path Computation Server (PCS) Topology Server REST Server Component functional responsibilities: The JUNOS VM, is used to collect the TE-database & LSDB A new JUNOS daemon, NTAD, is used remote ‘flash’ the lsdist0 table to the PCS The PCS has multiple functions: Peers with each PCC using PCEP for LSP state collection & modification Runs application specific Algs for computing LSP paths The REST server is the interface into the APIs JUNOS VM PCE NTAD REST_Server RPD Topo_Server PCS KVM Hypervisor Centos 6.5 BGP-LS/IGP PCEP PCC MPLS Network

Northstar as a black-box
User Interface 3rd Party Applications The JunosVM is used to peer with the network for topology acquisition using: BGP-LS Direct ISIS or OSPF adjacency ISIS or OSPF adjacency over a GRE tunnel PCCs connect to the PCEServer via PCEP for LSP reporting PCEP sessions are established from each LSP head-end to the PCE Server TCP PCS HTTP Web Server Auth Module REST_Server PC Server PCE_Server JUNOS VM RPD BGP-LS/IGP PCEP PCC MPLS Network

NorthStar northbound API
Integration with 3rd Party Tools and Custom Applications Standard, custom, & 3rd party Applications NorthStar pre-packaged applications Bandwidth Calendaring, Path Diversity, Premium path, auto-bandwidth / TE++, etc… REST REST REST Topology API Path computation API Path provisioning API Topology Discovery Path Computation Path Installation PCEP IGP-TE / BGP-LS Application specific algorithms PCEP

NorthStar northbound API Example
curl -X POST -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d \ '{ "name" : ”LSP_0815", "from" : {"topoObjectType" :"ipv4","address": ”<Node_A_IP>"}, "to" : {"topoObjectType" :"ipv4","address": ”<Node_Z_IP>"}, "pathType" : "primary", "plannedProperties" : { "setupPriority" : 7, "holdingPriority" : 7, "bandwidth" : "100m" } }' \ Create an LSP from node_A to node_Z curl -X GET -H "Content-Type: application/json" -H "Cache-Control: no-cache” Retrieve LSP properties REST = REpresentational State Transfer: REST is more a collection of principals rather than a set of standards Uses standard HTTP / HTTPS – GET / POST /PUT / DELETE operations One of the key concepts of REST is that of “statelessness” – each request provides the full state information and the response provides the full response – no “state” information is maintained between requests Create a resource for every service Identifies each resource using a URL

NorthStar northbound API
Supported Functionality NorthStar PCC Network management REST APIs PCEP BGP-LS Topology API Get a snapshot of the full topology Retrieve a node and its relationships like edges, LSPs, flows, etc… Retrieve a path and its properties Path Provisioning API Provision a path with a given set of attributes Modify a path’s bandwidth or ERO Path Computation API Compute the path between a set of endpoints, for a given set of constraints Compute two diverse paths for a given LSP Split a given LSP into multiple LSPs based on a given traffic event Re-optimize an LSP or all LSPs under different constraints Re-route around a node / link (e.g. for maintenance purposes)

NorthStar 1.0 high availability (HA)
Active / Standby for delegated LSPs NorthStar 1.0 supports a high availability model only for delegated LSPs: Controllers are not actively synced with each-other Active / standby PCE model with up to 16 back-up controllers: PCE-group: All PCE belonging to the same group LSPs are delegated to the primary PCE Primary PCE is the controller with the highest delegation priority Other controllers cannot make changes to the LSPs If a PCC looses connection with its primary PCE, it will immediately use the PCE with next highest delegation priority as its new primary PCE ALL PCCs MUST use the same primary PCE [configuration protocols pcep] pce-group pce { pce-type active stateful; lsp-provisioning; delegation-cleanup-timeout 600; } pce jnc1 { pce-group pce; delegation-priority 100; pce jnc2 { delegation-priority 50; jnc1 jnc2 PCEP PCEP PCC

NorthStar deployment As previously mentioned, NorthStar consists of multiple ‘machines’: JUNOS Virtual Machine Path Computation Server (PCS) & REST Server Each ‘machine’ requires reachability within the network JUNOS VM connects to the network via a hypervisor vSwitch PCS connects to the network via the native Centos interface Each require separate addressing Internally, the components are self addressed at system startup JUNOS VM PCE NTAD REST_Server RPD PCS KVM Hypervisor vSwitch Centos 6.5 em0 em1

BGP-LS speaker/Hierarchy
Topology acquisition – BGP-LS Various deployment options are supported Using BGP-LS, allows an operator to ‘tap’ into all of BGP’s deployment & policy flexibility to support network architectures of all types: Supports various inter-area and Inter-domain deployment options Allows for fewer topology acquisition ‘sessions’ with NorthStar NorthStar NorthStar BGP-LS session(s) BGP-LS session(s) BGP-LS speaker/Hierarchy ASBRs/ABRs

Redundant IGP Speakers
Topology acquisition – ISIS, OSPF & gre Tunneling Native protocol topology acquisition NorthStar can also be deployed where it peers with the network via its native IGP: ISIS and OSPFv2 are supported GRE tunneling is also supported to increase deployment flexibility Multi-area, multi-level & multi-domain networks MAY require many IGP adjacencies & GRE tunnels show interfaces gre unit 0 { tunnel { source ; destination ; } family inet { address /30; family iso; family mpls; show protocols isis interface gre.0 { point-to-point; level 2 metric 50000; } interface lo0.0; NorthStar NorthStar IGP Adj(s) over GRE tunnels IGP Adj(s) Redundant IGP Speakers ASBRs/ABRs

Multi-vendor support for BGP-LS / PCEP
Successful Demonstration of WAN SDN Controller Interworking Isocore - Final-Press Release.pdf

JUNOS PCE Client implementation New JUNOS daemon, pccd
Enables a PCE application to set parameters for a traditionally configured TE LSPs and create ephemeral LSPs PCCD is the relay/message translator between the PCE & RPD LSP parameters, such as the path & bandwidth, & LSP creation instructions are received from the PCE are communicated to RPD via PCCD RPD then signals the LSP using RSVP-TE PCE PCEP PCCD RPD MPLS Network JUNOS IPC RSVP-TE

JUNOS multi-template support
protocols { mpls { lsp-external-controller pccd { pce-controlled-lsp *-EF { label-switched-path-template ef-lsp; } pce-controlled-lsp *-AF { label-switched-path-template af-lsp; pce-controlled-lsp *-BE { label-switched-path-template be-lsp; label-switched-path ef-lsp { link-protection; template; label-switched-path af-lsp { ldp-tunneling; least-fill; label-switched-path be-lsp { Association of PCE provisioned LSPs with a template using a regex based name matching Aligned with how many customers use apply-groups in JUNOS today for applications like COS based forwarding protocols { mpls { lsp-external-controller pccd { pce-controlled-lsp <regex> {

JUNOS Multi-template Support (cont.)
Once a PCE provisioned LSP is created and associated with a template it inherits the properties of the template If subsequent changes to the template are made, the existing provisioned LSP(s) will not inherit the new changes Only new PCE provisioned LSPs will inherit the properties of the changed template If changes to the template are made after a LSP is created via NorthStar, the changes will NOT be applied to the already created LSPs Subsequent new LSPs will inherit the new attributes of the template show path-computation-client lsp Name Status PLSP-Id LSP-Type Controller Template LSP_to_vmx Primary(Act) ext-provised jnc default_pvc To-vmx104-EF Primary(Act) ext-provised jnc ef-lsp To-vmx104-BE Primary(Act) ext-provised jnc be-lsp To-vmx104-AF Primary(Act) ext-provised jnc af-lsp LSP_to_vmx Primary(Act) ext-provised jnc default_pvc

Topology Discovery with BGP-LS
Each link entry in the TED is “shadowed” as a prefix in the lsdist.0 RIB, such that it can be picked up by a BGP export policy The shadowing process is explicitly enabled & only TED entries which conform to the specific policies will have RIB shadows Policy control allows both creation/duplication & virtualization of the network topology NorthStar Topology Discovery Topology API Routing BGP-LS Session TED shadowing policy BGP-LS Export policy TED lsdist.0

BGP-LS Configuration Enabling of the traffic-engineering address family generates a MP AFI Capability code to be negotiated with peers Each link entry in the TED gets “shadowed” as a prefix in the lsdist0 RIB, such that it can be picked up by a BGP export policy protocols { bgp { family { traffic-engineering unicast; protocols { mpls { traffic-engineering { database { import [policy1 policy2];

Configuration (continued)
The default policy of BGP is only to export routes, which are known via BGP In order to advertise an entry leaked from TED, an export policy is required which matches against non-BGP routes in the lsdist0 RIB policy-options { policy-statement isis-link-bgp { term 1 { from { protocol isis; source-address-filter /8 orlonger; } then accept;

NorthStar console Launch NorthStar-PCE or NorthStar-Simulation from a single interface

NorthStar simulation mode
NorthStar vs. IP/MPLSview NorthStar NorthStar Simulation IP/MPLSview Topology Discovery MPLS capacity planning ‘Full’ Offline Network Planning LSP Control/Modification Exhaustive Failure Analysis FCAPs (PM, CM, FM) Real-Time Network Functions MPLS LSP Planning & design Offline Network Planning & Management Dynamic Topology updates via BGP-LS / IGP-TE Dynamic LSP state updates via PCEP Real-time modification of LSP attributes via PCEP (ERO, B/W, pre-emption, …) Topology acquisition via NorthStar REST API (snapshot) LSP provisioning via REST API Exhaustive failure analysis & capacity planning for MPLS LSPs MPLS LSP design (P2MP, FRR, JUNOS config’let, …) Topology acquisition & equipment discovery via CLI, SNMP, NorthStar REST API Exhaustive failure analysis & capacity planning (IP & MPLS) Inventory, provisioning, & performance management

Basic Topology & LSP Visualization
Nodes/Links/LSP/SRLGs ‘tabs’ Rearrangeable fields Sorting/searching Table Export LSP path details LSP type & attributes LSP path (reported RRO) Primary/secondary associations Diversity associations LSP logs

Basic Topology & LSP Visualization (cont.)
Visual RRO display for selected LSP Nodes/Links/Tunnels/SRLGs ‘tabs’ Rearrangeable fields Sorting/searching Table Export Tunnel path details LSP type & attributes LSP path (reported RRO) Primary/secondary associations Diversity associations LSP logs Link details Reserved/Unreserved B/W (A->Z & Z->A) RSVP utilization IP addressing, metric, subscription B/W Auto-b/w LSP PCE initiated Primary/2ndary LSPs PCE LSP Type

Basic Topology & LSP Visualization(cont.)
SRLG details SRLG attributes learned from the IGP Links that comprise the SRLG Node details PCEP enabled IP addressing, node ID, hostname, IGP Network Summary Number of LSPs, … NorthStar console Status of PCServer Activity logging

Diverse path computation Automated Computation of end-to-end diverse paths
Network-wide visibility allows NorthStar to support end-to-end LSP path diversity: Wholly disjoint path computations; Options for link, node and SRLG diversity Pair of diverse LSPs with the same end-points or with different end-points SRLG information learned from the IGP dynamically Supported for PCE created LSPs(at time of provisioning) and delegated LSPs(though manual creation of diversity group) NorthStar Warning! Shared Risk Shared Risk Eliminated CE CE Primary Link Secondary Link

Creation of a Diversity Group Diversity at LSP Creation
2 methods of diversity association Creation of a Diversity Group Maintaining diversity for delegated LSPs Diversity at LSP Creation Diversity for PCE provisioned LSPs The Delegated LSP must be already configured on the router and reported to NorthStar Select 2 or more delegated LSP from the tunnel window Click "modify" button Click "type" button Go to "design" tab Choose the "diversity level" Enter a name for the "diversity group" Click "OK" Re-Provision those LSPs NorthStar is being used to create diversely routed LSPs Click ”Add" button Select “Diverse Tunnel Pair …” Select PCC-A & PCC-Z pairs for each Tunnel Select Diversity “type“ Click “show path” Click "OK” Provision the LSPs

Secondary / Standby path
Secondary / Standby LSP support Automated Computation of Secondary/Standby Paths NorthStar supports secondary / standby LSP for PCE created and delegated LSPs: draft-ananthakrishnan-pce-stateful-path-protection-00 draft-minei-pce-association-group-00 Client assigned group IDs, automatically allocated ID space NorthStar Secondary / Standby path The operator can specify different attributes and / or constraints for the primary and secondary / standby paths: Delegated LSPs require no additional JUNOS configuration Multiple 2ndary LSPs, with various path constraints & attributes, may be created NorthStar ‘activates’ the 2ndary LSP in the case of inactive standby LSPs

Symmetric LSP creation
PCE created symmetric LSPs Local association of LSP symmetry constraint NorthStar supports creating symmetric LSPs: Does not leverage GMPLS extensions for co-routed or associated bi-directional LSPs Unidirectional LSPs (identical names) are created from nodeA to nodeZ & nodeZ to nodeA Symmetry constraint is maintained locally on NorthStar (attribute: pair =<value>) Symmetric LSP creation NorthStar Symmetric LSPs

In maintenance mode: LSP paths are automatically (make-before-break)
maintenance-mode re-routing Automated Path Re-computation, Re-signaling and Restoration Automate re-routing of traffic before a scheduled maintenance window: Simplifies planning and preparation before and during a maintenance window Eliminate the risk that traffic is mistakenly affected when a node / link goes into maintenance mode Reduced need for spare capacity through the optimum use of resources available during the maintenance window After the maintenance window finished paths are automatically restored to the (new) optimum path 1 Maintenance mode tagged: LSP paths are re-computed assuming affected resources are not available X 2 In maintenance mode: LSP paths are automatically (make-before-break) re-signaled 3 Maintenance mode removed: all LSP paths are re-stored to their (new) optimal path NorthStar

LSP path provisioning at scheduled time
bandwidth calendaring Time-based LSP Provisioning 1 Bandwidth calendaring allows network operators to schedule the creation/deletion/modification of an LSP: An LSP may be scheduled for creation or deletion at some point in the future An LSP may be scheduled for modification as some point in the future B/W calendaring is built into all the LSP add/modify UI ‘s Example: Operator pre-provisions a calendar event, either through the calendaring function native to NorthStar or through the path provisioning API NorthStar schedules the LSP provisioning event The LSP path is calculated at the scheduled point in time and the path is provisioned in the network Operator loads calendar event NorthStar 2 LSP path provisioning at scheduled time 3

Global re-optimization
Global Concurrent Optimization Optimized LSP placement NorthStar enhances traffic engineering through LSP placement based on a network wide visibility of the topology and LSP parameters: CSPF ordering can be user-defined, i.e. the operator can select which parameters such as LSP priority and LSP bandwidth influence the order of placement High priority LSP Low priority LSP Net Groom: Triggered on demand User can choose LSPs to be optimized LSP priority is not taken into account No pre-emption Path Optimization: Triggered on demand or on scheduled intervals (with optimization timer) Global re-optimization toward all LSPs LSP priority is taken into account Preemption may happen New Path request Bandwidth bottleneck! CSPF failure Global re-optimization NorthStar

Statistics collection
Mpls Auto bandwidth Smart LSPs with Auto-Bandwidth / TE++ Auto-b/w LSP creation with NorthStar 1.0: Dependent on JUNOS templates that define the auto-b/w policy PCC driven LSP B/W modification: auto-b/w policy & LSP statistics collection are distributed PCE based path computation (ERO, bandwidth, etc…) Auto-bandwidth and TE++ are vendor-specific implementations and will only work with a Juniper PCC: NorthStar discovers that a PCC is JUNOS and that a given LSP is an auto-b/w or TE++ sub-LSP via PCEP vendor-specific attributes NorthStar 1.0 only supports delegated TE++ LSPs, where sub-LSPs are associated through a PCC generated association-group ID. Path computation NorthStar PCC Policy definition Statistics collection

Mpls auto-bandwidth Auto-Bandwidth Example 3
JUNOS PCC will collect auto- bandwidth LSP statistics Every adjustment interval the PCC will send a PcRpt message with a LSP bandwidth request NorthStar will compute a new ERO for the requested B/W NorthStar will send a PcUpdate message with the new ERO & bandwidth NorthStar 4 PcUpdate Message PCC 2 PcRpt Msg, b/w=12m PcRpt Msg, b/w=14m PcRpt Msg, b/w=15m PcRpt Msg, b/w=16m 1 B/W time Adj_Interval B/W_Sample(s)

NorthStar Auto-bandwidth (phase 1) Example – 5 minute adjust interval
NorthStar console -- schedule reroute for Receive auto_bw request provision of tunnel :To-vmx104-auto-bw is scheduled provisioning order placed at Mon Jan 5 16:58: provisioning order placed at Mon Jan 5 17:03: LSP Head-end show mpls lsp autobandwidth Lspname Last Requested Reserved Highwater AdjustTime LastAdjust BW BW BW mark Left (sec) To-vmx104-auto-bw Mbps Mbps Mbps Mbps 3 sec Mon Jan 5 13:58: To-vmx104-auto-bw Mbps Mbps Mbps Mbps 175 sec Mon Jan 5 14:03:

Inter-Area Traffic-Engineering Inter-AS Traffic-Engineering
Inter-Domain Traffic-engineering Optimal Path Computation & LSP Placement LSP [delegation, creation, optimization] of inter-domain LSPs Single active PCE across domains, BGP-LS for topology acquisition JUNOS Inter-AS requirements & constraints lsps.html NorthStar NorthStar Area 3 Area 0 AS 200 Area 1 AS 100 Area 2 Inter-Area Traffic-Engineering Inter-AS Traffic-Engineering

Premium path optimization Application-aware Path Computation
Optimum path is decided based on application specific requirements: Today only a single set of metrics are used for shortest path computation, often based on number of hops (minimize port cost) and / or distance (minimize transport cost and latency) NorthStar can use additional ‘cost’ functions for path computation, stored in a separate topology file, to decided the optimum path for each LSP The path computation API can use this capability to optimize path computation based on application requirements, e.g. latency for voice and cost for web data NorthStar Lowest cost path (-) and back-up path () Lowest latency path (-) and back-up path ()

LSP log history A Per LSP log is maintained
Accessible by right clicking on an LSP & ‘show LSP events’ Select date range

NorthStar-Simulation
NorthStar simulation mode Offline Network Planning & Modeling NorthStar builds a near real-time network model for visualization and off-line planning through dynamic topology / LSP acquisition: Export of topology and LSP state to NorthStar simulation mode for ‘off-line’ MPLS network modeling Add/delete links/nodes/LSPs for future network planning Exhaustive failure analysis, P2MP LSP design/planning, LSP design/planning, FRR design/planning JUNOS LSP config’let generation Year 1 Year 3 Year 5 NorthStar-Simulation Extension Year 1

Monitoring mode Verify/Compare NorthStar computations, record and replay network events Monitor mode archives the network / LSP state and allow play-back on a timeline: The operator can select time/date range to record No specific event monitoring (trap collection), but at regular time intervals Monitoring mode operates in passively, and does not imply that NorthStar has control of any LSPs in the network A User can stop the reply, save a snapshot and then open the snapshot in NorthStar simulation to do tunnel design and/or any failure simulation X

Distributed CSPF Assumptions Centralized Path Calculation Assumptions
A real customer example – pce value Centralized vs. distributed path computation Up to 15% reduction in RSVP reserved B/W Link Utilization (%) Distributed CSPF Assumptions Centralized Path Calculation Assumptions TE-LSP operational routes are used for distributed CSPF RSVP-TE Max Reservable BW set BW set to 92% Modeling was performed with the exact operation LSP paths Convert all TE-LSPS to EROs via PCE design action Objective function is Min Max link utilizations Only Primary EROS & Online Bypass LSPS Modeling was performed with 100% of TE LSPS being computed by PCE

NorthStar 1.0 FRS delivery NorthStar FRS is targeted for March-23rd:
(Beta) trials / evaluations already ongoing First customer wins in place Target JUNOS releases: 14.2R3 Special * 14.2R4* / 15.1R1* / 15.2R1* Supported platforms at FRS: PTX (3K, 5K), MX (80, 104, 240/480/960, 2010/2020, vMX) Additional platform support in NorthStar 2.0 * Pending TRD Process NorthStar packaging & platform: Bare metal application only No VM support at FRS Runs on any x86 64bit machine that is supported by Red Hat 6 or Centos 6 Single hybrid ISO for installation Based on Juniper SCL 6.5R3.0 Recommended minimum hardware requirements: 64-bit dual x86 processor or dual 1.8GHz Intel Xeon E5 family equivalent 32 GB RAM 1TB storage 2 x 1G/10G network interface

Northstar 1.0 H/w Requirements
Subscription based pricing for NorthStar There is no dependency on Motherboard, NIC cards etc as we support CentOS6.5 as Host OS, verify it with CentOS6.5 supported hardware portal No preference on Vendor Small ( 1-50 Nodes) Medium ( Nodes) Large ( 250+ Nodes) CPU: 64-bit dual 1.8GHz Intel® Xeon® E5 family equivalent CPU: 64-bit Quad Intel® Xeon® Processor E5520 (2.26 GHz, 8MB L3 Cache) equivalent CPU: 64 bit Quad core Intel® Xeon® Processor X5570 (2.93 GHz,8MB L3 Cache) equivalent RAM: 16GB Hard Drive: 250GB Network Port: 1/10GE ( CSE2k matches this spec) RAM: 64GB Hard Drive: 500GB RAM: 128GB Hard Drive: 1TB

NorthStar demo options
NorthStar Beta Version is installed and available for POC testing at: Sunnyvale POC Lab Herndon POC Lab Westford POC Lab Amsterdam POC Lab SE’s can schedule a quick demo with Customers using: Juniper Cloud Labs ( JCL) Contact: Nancy Cohen Open Labs, NJ

Additional information
Internal Resources: ebsite/SitePages/Home.aspx PCEP: RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP) RFC 7190: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol BGP-LS:

Support contacts NorthStar PLM Naresh Kumar Tony Le Colby Barth lists to ask questions: High-IQ networking CoE Didier Bousser Chris Bowers Julian Lucek Dirk van den Borne Marketing Contact Donyel Jones-Williams

Thank you

Juniper NorthStar Controller

Similar presentations

Presentation on theme: "Juniper NorthStar Controller"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Juniper NorthStar Controller

Similar presentations

Presentation on theme: "Juniper NorthStar Controller"— Presentation transcript:

Similar presentations

About project

Feedback