This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
PCE ARCHITECTUREA Standards-based Approach for Carrier SDN
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
PCEP
PCC PCC
PCC
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
ACTIVE STATEFUL PCEA 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 .
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;
As previously mentioned, NorthStar consists of multiple ‘machines’: JUNOS Virtual Machine Path Computation Server (PCS) & REST ServerEach ‘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
TOPOLOGY ACQUISITION – BGP-LSVarious 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 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
NorthStar
ASBRs/ABRs
IGP Adj(s) over GRE tunnels
cbarth@vrr-84# show interfaces greunit 0 { tunnel { source 84.105.199.2; destination 84.0.0.101; } family inet { address 2.2.2.2/30; } family iso; family mpls;
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
Association of PCE provisioned LSPs with a template using a regex based name matchingAligned with how many customers use apply-groups in JUNOS today for applications like COS based forwarding
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
cbarth@vmx101-07> show path-computation-client lsp
CONFIGURATION (CONTINUED)The default policy of BGP is only to export routes, which are known via BGPIn 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 10.0.0.0/8 orlonger; } then accept;
Creation of a Diversity GroupMaintaining diversity for delegated LSPs
Diversity at LSP CreationDiversity 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 LSP SUPPORTAutomated 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 Secondary /
Standby path
NorthStar
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
PCE CREATED SYMMETRIC LSPSLocal association of LSP symmetry constraint
Symmetric LSPs
NorthStar
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>)
MAINTENANCE-MODE RE-ROUTINGAutomated 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
XX
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
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:1. Operator pre-provisions a calendar event, either through the calendaring
function native to NorthStar or through the path provisioning API2. NorthStar schedules the LSP provisioning event3. The LSP path is calculated at the scheduled point in time and the path is
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 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
MPLS AUTO BANDWIDTHSmart 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
NorthStar Auto-bandwidth (phase 1) Example – 5 minute adjust interval
-- schedule reroute for [email protected], Receive auto_bw requestprovision of tunnel 7.0.0.101:To-vmx104-auto-bw is scheduledprovisioning order placed at Mon Jan 5 16:58:37 2015
-- schedule reroute for [email protected], Receive auto_bw requestprovision of tunnel 7.0.0.101:To-vmx104-auto-bw is scheduledprovisioning order placed at Mon Jan 5 17:03:37 2015
cbarth@vmx101-07> show mpls lsp autobandwidth Lspname Last Requested Reserved Highwater AdjustTime LastAdjust BW BW BW mark Left (sec) To-vmx104-auto-bw 1.19323Mbps 3.78647Mbps 3.78647Mbps 3.78647Mbps 3 sec Mon Jan 5 13:58:36 2015
cbarth@vmx101-07> show mpls lsp autobandwidth Lspname Last Requested Reserved Highwater AdjustTime LastAdjust BW BW BW mark Left (sec) To-vmx104-auto-bw 3.78647Mbps 1.4055Mbps 1.4055Mbps 3.78647Mbps 175 sec Mon Jan 5 14:03:37 2015
LSP [delegation, creation, optimization] of inter-domain LSPs Single active PCE across domains, BGP-LS for topology acquisition JUNOS Inter-AS requirements & constraints
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 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
MONITORING MODEVerify/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
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 ( 50-250 Nodes) Large ( 250+ Nodes)
CPU: 64-bit dual 1.8GHz Intel® Xeon® E5 family equivalent
PCEP: http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-07 https://tools.ietf.org/html/draft-crabbe-pce-pce-initiated-lsp-03 http://tools.ietf.org/html/draft-ananthakrishnan-pce-stateful-path-protection-00 http://tools.ietf.org/html/draft-minei-pce-association-group-00 RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP) RFC 7190: Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol