Download - High Availability for IPTV
1© 2005 Cisco Systems, Inc. All rights reserved. Cisco Confidential
High Availability for IPTV
Søren AndreasenCCIE #3252Cisco DK
2© 2005 Cisco Systems, Inc. All rights reserved.
Agenda
• IPTV Architecture overview
• High Availability (HA) in the core and edge– Router Level HA with SSO
– Protocol HA with NSF/GR (IGP, BGP, Multicast)
– MPLS HA (LDP NSF/GR, BGP + label NSF, FRR, PW Redundancy)
– Fast Convergence (Multicast FC, Fast channel change, LDP-IGP sync, LDP session protection)
• Video Source Redundancy
• Conclusion
3© 2005 Cisco Systems, Inc. All rights reserved.
Tripleplay world
EthernetAccess
iFrame Cache
Policy and Service Management Layer
Identity Subscriber Database
PortalBilling Policy
Definition
IP / MPLS Core
CORECORELocal CO
PE-R / PE-S
DSL
Cable
PON
Distributed:L2 PW, VPLSL3 VPN
Centralized:H-VPLSL3 VPN
Service/Application Layer
Ethernet
Metro COPE-R
ServiceControl Engine
BroadbandPolicy Manager
ETTx
IP / MPLS / Ethernet Aggregation
SiSi
Residential
STB
RGW
STB
ISG/BRAS
Video BroadcastVoIPVoDHosted Business Apps
(Storage, Centrex, Security, Gaming)
4© 2005 Cisco Systems, Inc. All rights reserved.
Agenda
• IPTV Architecture overview
• High Availability (HA) in the core and edge– Router Level HA with SSO
– Protocol HA with NSF/GR (IGP, BGP, Multicast)
– MPLS HA (LDP NSF/GR, BGP + label NSF, FRR, PW Redundancy)
– Fast Convergence (Multicast FC, Fast channel change, LDP-IGP sync, LDP session protection)
• Video Source Redundancy
• Conclusion
5© 2005 Cisco Systems, Inc. All rights reserved.
High Availability
• End-to-end protection against network failures
• Preserve end-to-end network service connectivity
• Isolate control plane failures from forwarding plane
• Separation of control and forwarding plane should allow forwarding to continue while control plane recovers (NSF)
6© 2005 Cisco Systems, Inc. All rights reserved.
HA Mechanisms
• Component and Device Level Resiliency– Hardware and software component resiliency
• Distributed line cards, route processors, Modular operating software
– Stateful Switch-Over between RPs (SSO)
– Control/forwarding plane decoupling; Non-Stop Forwarding (NSF)
– Graceful Restart of protocols (GR)
• Network Level Resiliency– Optimized convergence algorithms, speeding up network
recovery
7© 2005 Cisco Systems, Inc. All rights reserved.
Device Level HA:NSF With SSO
• Stateful Switch-Over (SSO): zero interruption to protocol sessions
– Active RP synchronizes information with standby RP
– Session state maintained for high availability-aware protocols on standby RP
– Standby RP takes control when active RP is compromised
• Non-Stop Forwarding (NSF): minimal or no packet loss
– Packet forwarding continues during reestablishment of peering relationships
– No route flaps between participating neighbor routers
ACTIVE STANDBY
Line Cards
Bus
Route Processors
RP2RP1
8© 2005 Cisco Systems, Inc. All rights reserved.
SSO in action
HA-Router(config)#redundancy
HA-Router(config-red)#mode ?
rpr Route Processor Redundancy
rpr-plus Route Processor Redundancy Plus
sso Stateful Switchover (Hot Standby)
HA-Router(config-red)#mode sso
HA-Router#show redundancy
Active GRP in slot 0:
Standby GRP in slot 9:
Preferred GRP: none
Operating Redundancy Mode: SSO
Auto synch: startup-config running-config
switchover timer 3 seconds [default]
9© 2005 Cisco Systems, Inc. All rights reserved.
Agenda
• IPTV Architecture overview
• High Availability (HA) in the core and edge– Router Level HA with SSO
– Protocol HA with NSF/GR (IGP, BGP, Multicast)
– MPLS HA (LDP NSF/GR, BGP + label NSF, FRR, PW Redundancy)
– Fast Convergence (Multicast FC, Fast channel change, LDP-IGP sync, LDP session protection)
• Video Source Redundancy
• Conclusion
10© 2005 Cisco Systems, Inc. All rights reserved.
GR/NSF Fundamentals
• NonStop Forwarding (NSF) is a way to continue forwarding packets while the control plane is recovering from a failure.
• Graceful Restart (GR) is a way to rebuild forwarding information in routing protocols when the control plane has recovered from a failure.
11© 2005 Cisco Systems, Inc. All rights reserved.
GR/NSF Fundamentals (uden GR/NSF)
• Router A loses its control plane for some period of time.
• It will take some time for Router B to recognize this failure, and react to it.
Control Data A
Control Data B
12© 2005 Cisco Systems, Inc. All rights reserved.
GR/NSF Fundamentals (uden GR/NSF)
• During the time that A has failed, and B has not detected the failure, B will continue forwarding traffic through A.
• Once the control plane resets, the data plane will reset as well, and this traffic will be dropped.
• NSF reduces or eliminates the traffic dropped while A’s control plane is down.
Control Data A
reset
Control Data B
13© 2005 Cisco Systems, Inc. All rights reserved.
GR/NSF Fundamentals
• If A is NSF capable, the control plane will not reset the data plane when it restarts
• Instead, the forwarding information in the data plane is marked as stale.
• Any traffic B sends to A will still be switched based on the last known forwarding information.
Control Data A
no reset
Control Data B
mark forwardinginformation as stale
14© 2005 Cisco Systems, Inc. All rights reserved.
GR/NSF Fundamentals
• While A’s control plane is down, the routing protocol hold timer on B counts down....
• A has to come back up and signal B before B’s hold timer expires, or B will route around it.
• When A comes back up, it signals B that it is still forwarding traffic, and would like to resync.
Hold Timer: 1514131211109876
Control Data A
Control Data B
15© 2005 Cisco Systems, Inc. All rights reserved.
GR/NSF Design Goals
• No Link Flap
• CEF table sync to the standby RP
• LC CEF Table not cleared on switchover
• Packet forwarding during switchover while routing is converging on Standby RP
• Maintain peer relationship, no adjacency flapping with peers
• Limit restart to be local event, not network wide
Ultimate Goal: Achieve 0% Packet Loss
16© 2005 Cisco Systems, Inc. All rights reserved.
IS-IS GR/NSF
• Use the nsf command under the router isis configuration mode to enable graceful restart.
• Show isis nsf can be used to verify graceful restart is operational.
A
B
router isisnsf....
router isisnsf....
router#show isis nsf
NSF is ENABLED, mode 'cisco'
RP is ACTIVE, standby ready, bulk sync complete
NSF interval timer expired (NSF restart enabled)
Checkpointing enabled, no errors
Local state:ACTIVE, Peer state:STANDBY HOT, Mode:SSO
17© 2005 Cisco Systems, Inc. All rights reserved.
OSPF GR/NSF
• Use the nsf command under the router ospf configuration mode to enable graceful restart.
• Show ip ospf can be used to verify graceful restart is operational.
A
B
router ospf 100nsf....
router ospf 100nsf....
router#sh ip ospfRouting Process "ospf 100" with ID 10.1.1.1
....
Non-Stop Forwarding enabled, last NSF restart 00:02:06 ago (took 44 secs)
router#show ip ospf neighbor detailNeighbor 3.3.3.3, interface address 170.10.10.3....Options is 0x52LLS Options is 0x1 (LR), last OOB-Resync 00:02:22 ago
18© 2005 Cisco Systems, Inc. All rights reserved.
BGP GR/NSF
• Use the bgp graceful-restartcommand under the router bgpconfiguration mode to enable graceful restart.
• Show ip bgp neighbors can be used to verify graceful restart is operational.
A
Brouter#show ip bgp neighbors x.x.x.x....Neighbor capabilities:....Graceful Restart Capabilty:advertised and receivedRemote Restart timer is 120 secondsAddress families preserved by peer:IPv4 Unicast, IPv4 Multicast
router bgp 65000bgp graceful-restart....
router bgp 65501bgp graceful-restart....
19© 2005 Cisco Systems, Inc. All rights reserved.
Line
Car
d
Line
Car
d
Line
Car
d
Line
Car
d
AC
TIVE
STA
ND
BY
Failure
AC
TIVE
How Triggered PIM Join(s)work when Active Route Processor Fails:
Periodic PIM Joins 1 Active Route Processor receives periodic PIM Joins in steady-state
2 Active Route Processor fails
“Special” PIM Hello
4 “Special” PIM Hello is sent out
Triggered PIM Joins
5 Triggers adjacent PIM neighbors to resendPIM Joins refreshing state of distribution tree(s) preventing them from timing out
3 Standby Route Processor takes over
Multicast HA :PIM/SSM in the Core
20© 2005 Cisco Systems, Inc. All rights reserved.
Multicast HA:IGMP at the edge
AC
TIVE
STA
ND
BY
Failure
AC
TIVE
IGMPData
Structures
IGMPData
Structures
globalsync
periodic
syncs
How it works:
1 Global sync of IGMP Data Structuresoccurs when standby Supervisor comes online
2 Periodic syncs are performed as changes occur
3 Active Supervisor fails
4 Standby Supervisor takes over
5 Synced IGMP Data Structures are utilizedto provide Layer-2 Non-Stop Forwarding (NSF)of multicast traffic
Provides Seamless Forwarding of Multicast Traffic During Supervisor Switchovers
21© 2005 Cisco Systems, Inc. All rights reserved.
Agenda
• IPTV Architecture overview
• High Availability (HA) in the core and edge– Router Level HA with SSO
– Protocol HA with NSF/GR (IGP, BGP, Multicast)
– MPLS HA (LDP NSF/GR, BGP + label NSF, FRR, PW Redundancy)
– Fast Convergence (Multicast FC, Fast channel change, LDP-IGP sync, LDP session protection)
• Video Source Redundancy
• Conclusion
22© 2005 Cisco Systems, Inc. All rights reserved.
MPLS HA – Component Resiliency
• MPLS HA features extend NSF with SSO for:– LDP (for L3VPNs and L2VPNs)
– BGP (L3VPNs)
– RSVP (for TE)
• Minimal disruption to MPLS forwarding plane due to route processor control plane failures– Includes MPLS control plane failures (LDP, BGP, RSVP)
23© 2005 Cisco Systems, Inc. All rights reserved.
MPLS HA – Network Resiliency
• MPLS control plane protocol enhancements to improve failure detection time and network convergence
• Graceful Restart (GR)– LDP, BGP, RSVP
• Fast Convergence– LDP (IGP sync), LDP session protection
• TE FRR – Link protection– Node protection
• Pseudowire Redundancy
24© 2005 Cisco Systems, Inc. All rights reserved.
MPLS Graceful Restart + NSF/SSO
LSPs
Control Plane
Data Plane
Control Plane
Data Plane
Control Plane
Data Plane
No MPLS HA support
MPLS HA Support: NSF/SSO + Graceful Restart
1
2 2
LSPs
33 3
3
PE P PE
LSPs
Control Plane
Data Plane
Control Plane
Data Plane
Control Plane
Data Plane
1
2 2
LSPsPE P PE
25© 2005 Cisco Systems, Inc. All rights reserved.
LDP NSF/GR
• LDP NSF/SSO/GR is also known as LDP NSF• LDP NSF allows a route processor to recover from
disruption in LDP control plane without losing its MPLS forwarding state
• LDP NSF works with LDP sessions between directly connected peers as well as with targeted sessions
• LDP HA Key Elements– Checkpointing local label bindings (synkronisering mellem
RP’s)• On devices with route processor redundancy
– LDP graceful restart capability• On participating PEs, RRs, and P routers
26© 2005 Cisco Systems, Inc. All rights reserved.
LDP NSF/GR Key Elements:Checkpointing Local Label Bindings
• The checkpointing function is enabled by default
• The checkpointing function copies active RP’s LDP local label bindings to the backup RP
• For the first round, all the labels are copied from active to back up RP
• Periodic incremental updates are done to reflect new routes that have been learned or routes that have been removed and/or when labels are allocated or freed
• Label bindings on backup RP are marked checkpointed
• This marking is removed when it becomes active RP
Line Card Line CardLine Card
RP RP
IPC
Checkpointing
RP B(Standby)
RP A(Active)
Local Label Bindings
27© 2005 Cisco Systems, Inc. All rights reserved.
LDP NSF/GR Operation
• LDP paths established, LDP GR negotiated• When RP fails on LSRb, communication between peers is lost; LSRb encounters a LDP restart, while
LSRa and LSRc encounter an LDP session reset• LSRa and LSRc mark all the label bindings from LSRb as stale, but continue to use the same
bindings for MPLS forwarding• LSRa and LSRc attempt to reestablish an LDP session with Rb• LSRb restarts and marks all of its forwarding entries as stale; at this point, LDP state is in restarting
mode• LSRa and LSRc reestablish LDP sessions with Rb, but keep their stale label bindings; at this point,
the LDP state is in recovery mode• All routers re-advertise their label binding info; stale flags are removed if a label has been relearned;
new LFIB table is ready
AB
CStandbyPrimary
LDP Restart
LDP Reset
LDP Reset
Rb(config)#mpls ldp graceful-restartLDP GR: 20.0.0.0/8:: updating
binding from 1.1.1.1:0, inst 1:: marking stale; LDP Adj
UPLDP Adj UP
LDP GR: 20.0.0.0//8:: refreshing stale binding from
1.1.1.1:0, inst 1 -> inst 2
LDP GR: 10.0.0.0//8:: refreshing stale binding from
1.1.1.1:0, inst 1 -> inst 2
LDP GR: 10.0.0.0/8:: updating binding from 1.1.1.1:0, inst 1::
marking stale;
28© 2005 Cisco Systems, Inc. All rights reserved.
Enable MPLS Nonstop Forwarding on an Interface that Uses BGP as the Label Distribution Protocol (Inter-as and CsC Environment)
mpls bgp forwarding
BGP NSF/GR for Inter-AS and CSC
AS #100 AS #200
ASBR-1 ASBR-2
eBGP IPv4 + Labels AS2_PE1AS1_PE1
mpls bgp forwardingmpls bgp forwarding
29© 2005 Cisco Systems, Inc. All rights reserved.
MPLS TE Fast Re-Route (FRR)
• IP routing protocols (e.g., OSPF, BGP) may be tuned to convergence within a few seconds
• Some traffic (e.g. voice) will require more aggressive convergence time – Typically 50 ms or less
• MPLS TE FRR offers protection against network failures– Link protection
– Node protection
R1 R2
R9
R7 R8R6
R5R4R3
R1 R2 R5R4
R3
Link Protection
Node Protection
Protected Path Backup Path
30© 2005 Cisco Systems, Inc. All rights reserved.
FRR Link Protection
• Creation of Next-hop Backup Tunnel– Parallel path around
protected link to next hop
• On link failure detection Point of Local Repair (PLR) swaps label and pushes backup label– Traffic sent over backup
path
• PLR notifies TE Head End (HE), which triggers global TE path re-optimization
R3
R1 R2
R5
R6R41010
2020
Label for the protected LSP
11111111
Label for the backup LSP
1111
xx
xx
PLR
Protected Path Backup Path
HE
31© 2005 Cisco Systems, Inc. All rights reserved.
FRR Node Protection
• Creation of Next-next-hop Backup Tunnel– Parallel path around
protected node to next-next-hop
• Node failure triggers Point of Local Repair (PLR) to swap label and push backup label– Traffic sent over backup
path around failed node
• PLR notifies TE Head End (HE), which triggers global TE path re-optimization
Label for the protected LSP
Label for the backup LSP
xx
xx
Protected Path Backup Path
1010
2020 1212
1111R1 R2
R9
R7 R8
R6R5
R4R3
1212
2121 1212
1212PLRHE
32© 2005 Cisco Systems, Inc. All rights reserved.
FRR in triple play with P2MP-TEBasic RSVP-TE P2MP Tunnel Setup
MPLS CoreSourceSource ReceiverReceiver
Layer 2Switch
Layer 2Switch
PEPE
P P
P P
Service EdgeDistribution/
AccessCore
Primary RSVP Tunnel
Backup RSVP Tunnel
CE CEPE
Source Receiver
Multicast Packet
Multicast Packet + MPLS Label
33© 2005 Cisco Systems, Inc. All rights reserved.
Multiple Points of Failure Still Exist
MPLS CoreSourceSource ReceiverReceiver
Layer 2Switch
Layer 2Switch
PEPE
P P
P P
Core
Primary RSVP Tunnel
Backup RSVP Tunnel
CE CEPE
Source Receiver
X X X X X X X X X X X
Service EdgeDistribution/
Access
34© 2005 Cisco Systems, Inc. All rights reserved.
Pseudo Wire HA
• Failure in the provider core mitigated with link redundancy and FRR• PE router failure–Another PE or NSF/SSO • PE-CE Attachment Circuit failure–need pair of attachment Circuits
end-to-end• CE Router failure–redundant CEs
CE1
CE2
PE1
Site1
PE3
Site2
PE1
PE2 PE4
P1
P2
PE
P4
35© 2005 Cisco Systems, Inc. All rights reserved.
Pseudowire Redundancy
CE1
CE2PE1
Site1PE2
PE3
P2
PE
P4Site2
P1PE1
pe1(config)#int e 0/0.1pe1(config-subif)#encapsulation dot1q 10pe1(config-subif)# xconnect <PE3 router ID> <VCID> encapsulation mplspe1(config-subif-xconn)#backup peer <PE4 router ID> <VCID>
xPE4
CE3
36© 2005 Cisco Systems, Inc. All rights reserved.
MPLS HA
• Link failures—solved using redundancy in network design and MPLS TE FRR and/or Fast IGP
• Node failures—solved using redundant nodes and meshing of connections– Also using MPLS TE FRR node protection
• Line card failures– Hardware redundancy—line card redundancy (1+1, 1:N, 1:1)
• PE router (RP) failures– Dual RP systems NSF/SSO– HA software provides seamless transition…
PE1
Site1
P2 P4 Site2
P3P1
PE2
StandbyPrimary
10.1.1.0/24
10.1.1.0/24
10.1.2.0/24
10.1.2.0/24
x
PE3
PE4
37© 2005 Cisco Systems, Inc. All rights reserved.
HA in MPLS L3VPN Environment
• LDP and BGP use TCP as a reliable transport mechanism for its protocol messages
• The TCP session between two LDP/BGP peers may go down due to HW/SW failure (RP switchover)
• Use IGP, BGP, LDP NSF/GR
PE1
10.1.1.0/24
10.1.1.0/24
10.1.2.0/24
10.1.2.0/24
StandbyPrimary
PE1
StandbyPrimary
RR1 RR2
P2 P4
LDPiBGP
P1 P3
38© 2005 Cisco Systems, Inc. All rights reserved.
HA in L2VPN Networks
• The TCP session between two LDP peers may go down due to HW/SW failure (RP switchover)
• If PE3 fails, traffic will be dropped
• Use PW-redundancy, LDP NSF/GR and IGP NSF/GR
PE1
Site1P1 PE
Site2
Standby
P4
Primary
Primary
Primary
PE3
PE4
P2
39© 2005 Cisco Systems, Inc. All rights reserved.
Agenda
• IPTV Architecture overview
• High Availability (HA) in the core and edge– Router Level HA with SSO
– Protocol HA with NSF/GR (IGP, BGP, Multicast)
– MPLS HA (LDP NSF/GR, BGP + label NSF, FRR, PW Redundancy)
– Fast Convergence (Multicast FC, Fast channel change, LDP-IGP sync, LDP session protection)
• Video Source Redundancy
• Conclusion
40© 2005 Cisco Systems, Inc. All rights reserved.
Fast Convergence:☺
• Too much to cover, not possible in 45 mins• Layer 2 tuning
– SONET alarms– Interface timers
• CEF optimizations• IGP FC
– Fast IGP timers, iSPF, fast flooding, fast hellos, etc• BGP FC
– Next Hop Tracking, BGP timers• BFD (bidirectional forwarding)• Multicast Fast Convergence
– Multicast timers, fast channel change• LDP
– LDP (IGP sync), LDP session protection
41© 2005 Cisco Systems, Inc. All rights reserved.
Multicast Subsecond Convergence
So What is it?
First, what it’s NOT:A single feature or set of CLI’s
Various components seamlessly working together to provide an end-to-end fast convergence solution
Achieve and meet requirements for sub-second channel change, pause, resume, etc.
Objective:
42© 2005 Cisco Systems, Inc. All rights reserved.
Multicast Subsecond Convergence: The Video Challenge - Channel Change Time & Source Redundancy
1 Set Top Box (STB) performance in processing channel change request
4 DSLAM Signaling latency to terminate previous IP video feed
5 Network Signaling latency to rebuild tree(s) during link/node failures in the core
3 Delay incurred if using encryption
Set Top Box(STB)
DSLAM
MulticastDistribution
TreeBuilding
2 Network Signaling latency to join or resume new IP video feed
6 Time for video feed to recover during primary source failover
Network Components: Channel Change Delay and Slow ConvergenceContributors:
VideoSources
primary backup
43© 2005 Cisco Systems, Inc. All rights reserved.
Multicast Subsecond Convergence
Areas Addressed Today:
2 Network Signaling latency to join or resume new IP video feed
5 Network Signaling latency to rebuild tree(s) in the core
6 Time for video feed to recover during primary source failover
• Multicast Fast Join/Leave for Fast Channel Change
• Anycast Sources (and other related methodologies)
• IGP timers • RPF Interval timer - ip multicast rpf interval <seconds> [list <acl> | route-map route-map>])• PIM RPF Failover timer - ip multicast rpf backoff <min> <max> [disable]• PIM Router Query interval timer - ip pim query-interval <period> [msec]• PIM Triggered Join(s)• IGMP High Availability
1 Set Top Box (STB) performance in processing channel change request
• Vendor dependent
3 Delay incurred if using encryption• Vendor dependent
4 DSLAM Signaling latency to terminate previous IP video feed• Vendor dependent
44© 2005 Cisco Systems, Inc. All rights reserved.
Fast Join/Leave for Faster Channel Change
Problem Description:
Solution:
Benefits:• Faster channel changing without BW oversubscription• Improved diagnostics capabilities
In networks where bandwidth is constrained between multicast routers and hosts (like in xDSL deployments), fast channel changes can easily lead to bandwidth oversubscription, resulting in a temporary degradation of traffic flow for all users.
Reduce the leave latency during a channel changeby extending the IGMPv3 protocol.
45© 2005 Cisco Systems, Inc. All rights reserved.
Multicast Fast Join/Leave for Faster Channel Change
• Relies on IGMPv3
• Router tracks both User and Channel(s) being watched
• When user leaves channel no one else is watching, router immediately prunes the channel off the interface compared to IGMPv2 (up to 3 seconds) and IGMPv1 (up to 180 seconds)!
interface Ethernet 0ip pim sparse-mode
ip igmp version 3ip igmp explicit-tracking
interface Ethernet 0ip pim sparse-mode
ip igmp version 3ip igmp explicit-tracking
E0
Channel User10.0.0.1, 239.1.1.1 “David”10.0.0.1, 239.2.2.2 “John”
How it works: “David” “John”
10.0.0.1, 239.3.3.3 “David”
igmp
igmp
igmp
IntE0E0E0
igmp
Configuration:
First introduced in 12.0(29)S
46© 2005 Cisco Systems, Inc. All rights reserved.
Fast Convergence:LDP-IGP sync => LDP Down but IGP Still Up
1. Data stream between CE1 and CE2 traversing SP cloud2. LDP Adjacency goes down between P4 and P3 but IGP still points
to P3 as the best path3. LDP Adjacency goes down between P4 and P3 but IGP still points
to P3 as the best pathRR1
CE1
RR2
CE2
P1 P3
P2
P4StandbyPrimary
PE1
StandbyPrimary
PE4
Network x Network y
47© 2005 Cisco Systems, Inc. All rights reserved.
LDP down but IGP Still Upwith IGP-LDP Synch Feature
1. Data stream between CE1 and CE2 traversing SP cloud2. LDP Adjacency goes down between P4 and P3 but IGP still
points to P3 as the best path3. P1 chooses P2 as the preferred IGP path because of the
lower metricRR1
CE1
RR2
CE2
P1 P3
P2
P4
PE2 PE3
StandbyPrimary
PE2 PE3
PE1
StandbyPrimary
PE4
Network x Network yMax-metric advertised
48© 2005 Cisco Systems, Inc. All rights reserved.
IGP-LDP Sync
• IGP-LDP Synch features synchronizes the state of IGP and LDP between two routers
• If an LDP adjacency between two routers goes down then these routers would advertise a max-metric for the link connecting them via IGP
• This way upstream router can choose an alternate path if available
• Following configuration needs to be enabled on the routers
– P4(config)# router ospf 1
– P4(config-router)# mpls ldp sync
– P4(config)# mpls ldp igp sync holddown <msecs>
– If no holddown is configured then no timeout is applied i.e. IGPs will wait forever.
49© 2005 Cisco Systems, Inc. All rights reserved.
Fast Convergence:LDP Session Protection
• There are two discovery mechanisms for LDP peers 1. LDP Basic Discovery—Discovery of directly connected neighbors via link hellos 2. LDP Extended Discovery—Discovery of non-directly connected neighbors via Targeted Hellos
• If the session protection is enabled, the establishment of a directly connected LDP session triggers Extended Discovery with the neighbor
• With targeted hellos, session stays up even when the link goes down• No need to re-establish an LDP session with the link neighbor and
relearn prefix label bindings when the link recovers
P1 P3
P2
P4Basic Discovery
Extended Discovery
p1(config)#mpls ldp session protection ?duration Period to sustain session protection after loss of link discoveryfor Access-list to specify LDP peersvrf VRF Routing/Forwarding instance information
mpls ldp session protection
50© 2005 Cisco Systems, Inc. All rights reserved.
Agenda
• IPTV Architecture overview
• High Availability (HA) in the core and edge– Router Level HA with SSO
– Protocol HA with NSF/GR (IGP, BGP, Multicast)
– MPLS HA (LDP NSF/GR, BGP + label NSF, FRR, PW Redundancy)
– Fast Convergence (Multicast FC, Fast channel change, LDP-IGP sync, LDP session protection)
• Video Source Redundancy
• Conclusion
51© 2005 Cisco Systems, Inc. All rights reserved.
Uses 2x network bandwidthUses required bandwidth
Two copies of the multicast packets will be in the network at any instant
Two Multicast trees on almost redundant Infrastructure
Only one copy is on the network at any instant
Single Multicast tree is built per the unicastrouting table
Receiver is smarter:Is aware/configured with two feeds (s1,g1), (s2,g2) / (*,g1), (*,g2)
Joins both and is always receiving both feeds
Receiver’s functionality simpler: Aware of only one src, fail-over logic handled between sources.
This approach does not require fast IGP and PIM convergence
This approach requires the network to have fast IGP and PIM convergence
Two sources, both are active and src’ingmulticast into the network
No Protocol between the two sources
Two sources, One active (src’ing content), Second in standby mode (not src’ing content)
Heartbeat mechanism used to communicate with each other
Hot-HotPrimary-Backup “Heartbeat”
Video Source Redundancy : Two Approaches
52© 2005 Cisco Systems, Inc. All rights reserved.
Regional Backbone
RegionalBackbone
Service Edge National BackboneSource ResidenceRegional Backbone
RegionalBackbone
Primary Source 1
P
P
Secondary Source 1
Hea
rtbe
at
Primary Source 2
Secondary Source 2
Hea
rtbe
at
Primary Source 3
Secondary Source 3
Hea
rtbe
at
PE
PE
PEP
P
P
P
P
P
PE
PE
X
PE
PE
Video Source Redundancy:Heartbeat Model
53© 2005 Cisco Systems, Inc. All rights reserved.
Video Source Redundancy:Hot-Hot Video Delivery Model
National Backbone Regional BackboneService EdgeSource
Source 2
Source 3
Source 1
PP
P
P
PE PE
PE
PE
PE
PE
PEPE
PE
PEPE
Source 2
PP
P
P
PE
Source 3
Source 1
54© 2005 Cisco Systems, Inc. All rights reserved.
Multicast Source RedundancyUsing Anycast Sources
Anycast Sources
1.1.1.1 1.1.1.1
I will send jointo the nearest1.1.1.1/32
v2 join
STB STB
SFSF NYNY
XXR1 R2
R3 R4
How is source redundancy achieved in the network?
• Enable SSM on all routers
• Have R1 and R2 advertise sameprefix for each source segment.
• R3 and R4 follow best path towards source based on IGPmetrics.
• Let’s say R3’s best path to SF isthrough R1. The source in SF now suddenly fails.
• R3’s IGP will reconverge andtrigger SSM joins towards R2 in NY.
55© 2005 Cisco Systems, Inc. All rights reserved.
Conclusion
• High Availability involves many more components in Metro Ethernet, DSL/PON deployments, Authentication/Application Servers– Distributed DSLAMs
• Slowest component is a bottleneck for the entire system
• Careful when using High Availability versus Fast Convergence. Race Conditions possible!!
56© 2005 Cisco Systems, Inc. All rights reserved. 565656© 2005 Cisco Systems, Inc. All rights reserved.RST-310811055_05_2005_c1