Live-Live: A Network Solution Without Packet Loss

Transcription

1 Live-Live: A Network Solution Without Packet Loss BRKIPM-3061 Follow us on Twitter for real time updates of the #CLEUR

2 Housekeeping We value your feedback- don't forget to complete your online session evaluations after each session & the Overall Conference Evaluation which will be available online from Thursday Visit the World of Solutions and Meet the Engineer Visit the Cisco Store to purchase your recommended readings Please switch off your mobile phones After the event don t forget to visit Cisco Live Virtual: Follow us on Twitter for real time updates of the #CLEUR 2

3 Session Objectives At the End of the Session, I Hope You Will Discover what Live-Live is Know the applications and networks Live-Live is mostly useful for Understand the different pieces that comprise a Live-Live solution Be familiar with various options to build a Live-Live network Be proficient with routing solutions Cisco offers to support Live-Live Feel good and give a good mark 3

4 Agenda All About Live-Live The theoretical stuff The practical stuff The important stuff 4

5 Live-Live: The Theoretical Stuff

6 What, Why Live-Live is a solution that builds on a technique using dual transmission to recover from packet loss within a bounded delay - Reliability v.s. Resiliency The push for a resilient network demands us to improve, enhance and standardize the solutions 6

7 Reliability Revisited Three main elements contribute to transport reliability - Packet loss - Packet reordering - Packet duplicates TCP is a reliable transport protocol UDP is not PGM is an attempt to improve reliability for multicast 7

8 Reliable Transport Comes at a Cost Host OS has to keep a large buffer - Multiple senders/receivers aggravate resource contention Retransmission incurs a delay Hard to scale to thousands of receivers or more while maintaining relative fairness - N v.s. 2 copies 8

9 Considering Real-Time Applications Market data, video, others Need to deliver data to many receivers (consumers) Need to maintain fairness A late packet is as good as a lost one - For video, a late packet causes the same playback artifact as a lost packet - For market data, a late packet delivers stale information that cannot be used - There are other examples 9

10 Building a Resilient Network Minimize or even eliminate packet loss - Accept duplicates in some cases as a trade-off/cost Minimize delay for repair packet in case of loss Application/OS re-order packets if needed - Can also be done by routers in near future Scale, scale, scale

11 Live-Live Is About Dual Streaming Two packet streams flow in the network - They can, (but don t have to) be identical Transmitted concurrently, or interleaved with a delay. Any single stream is sufficient to support the application More than two streams work fine (but less common) 11

12 Live-Live Is About Dual Streaming The redundant stream can be generated by - Applications - Host OS/Drivers - First hop router - Ingress edge router Duplicate packets can be removed or merged by - Egress edge routers - Last hop routers - Applications 12

13 Spatial Redundancy Two streams have different network addresses or encapsulations and flow concurrently in network Network provides (guarantees) diverse paths Paths should have similar forwarding delay In theory, there is no delay between the original packet and the repair packet If there is a failure to one path causing packet loss, it is extremely unlikely the repair packet on the other path will be lost as well 13

14 An Example of Spatial Redundancy Stream #1 Stream #2 Path 1 Video Source Video Receivers DCMG Path 2 DCMG or VQE Application (DCM) generates two identical streams with different network addresses Application removes duplicates 14

15 An Example of Spatial Redundancy When There Is a Failure Path 1 Video Source Video Receivers DCMG Path 2 DCMG or VQE Single failure affects only one stream Packet loss is repaired with minimum latency 15

16 Temporal Redundancy Two packets carrying the same content (or one original, one repair) are transmitted with a delay - Network addresses may be the same - Packets from two streams are interleaved - Separation between the streams should exceed the worst case outage expected (e.g., 0 ms) The network is not required to build diverse paths If one packet is lost, its repair is expected to arrive around 0 ms - Unless there are two network failures, or - The network cannot converge within 0ms upon one failure 16

17 An Example of Temporal Redundancy Block #1 Block #2, offset 0 ms Video Source Video Receivers Two streams follow the same path if using the same network addresses Application removes duplicates 17

18 An Example of Temporal Redundancy Block #1 Block #2, offset 0 ms Video Source Video Receivers If there is a packet loss, the repair arrives around 0 ms later 18

19 Spatial vs. Temporal Redundancy Requirement Spatial Temporal Bandwidth X 2 X 2 Network Addresses Must be different Can be the same Diverse Routing Required Not required Repair Delay Almost zero Some Minimum Application Awareness Sender Receiver (for different destination addresses) Sender 19

20 Live-Live and IP Multicast Scale to many receivers - It appeared the one casualty was the federal website intended to keep Canadians informed about earthquakes. Last time there was a temblor in the region, last June, it froze the website for Earthquakes Canada. Predictable forwarding delay - No retransmission Fairness in the presence of a large fanout - Network, not individual host/router, performs packet replication Mar 16, html 20

21 Live-Live and IP Multicast Flexible forwarding algorithms - Either destination, or source and destination based - Perfect match for establishing diverse path to support spatial redundancy - If using different source addresses, minimum change needed for application on receiver side to support spatial redundancy Live-Live can be accomplished with a unicast transport too 21

22 Live-Live: The Practical Stuff

23 The Practical Stuff How to build a live-live network Applications Networks - Access - Edge - Core 23

24 Things To Consider Application Considerations - Can the application survive packet loss elegantly? - Can the application handle application/content failure AND network failure? - Should application based signaling be visible to routers or only between the hosts? - Should a standard based transport protocol (e.g. RTP) be used? Bandwidth Requirement Is there enough bandwidth at the access/edge network? Should the first/last hop network carry original content and repair traffic, or just original? 24

25 A View from the Top Sender Receiver Application Application OS/Driver First Hop Router Last Hop Router OS/Driver Ingress Edge Egress Edge Live-Live Network 25

26 Live-Live Aware Application Typical applications that can benefit from live-live - Video, IP-TV - Financial data Standard v.s. custom transport protocol - E.g., RTP 26

27 Live-Live Aware Application: DCMG Primary Stream Video Source DCMG Primary Stream DCMG Video Receivers Due to network delay differences the two received streams are misaligned Input Buffer Size = 4 Output Misalignment is compensated for in the DCM Gateway receiver up to 0ms, and a hitless switchover between the two feeds is performed in case of detected failures. 27

28 Live-Live Aware Application Receiver Know what sender sends - Session announcement/discovery - Other management tools Merge two streams - Repair loss - Discard duplicates - Duplicates might be generated by sender, OS/Driver, first hop router, ingress edge router Correct ordering Adjust timing 28

29 Live-Live Aware OS/Driver Replicate packet streams on sender host Require two sockets if different destination addresses and/or ports are used, But rarely used to merge streams on receiver host Application doesn t mean application software - OS/Driver is perceived as application from the view point of network 29

30 Sender Duplication Sender Application OS/Driver Sender generates two streams Receivers discard duplicates Redundant first/last hop networks Core network offers diverse routing Receiver Application OS/Driver 30

31 Sender OS Duplication Sender Application OS/Driver Sender generate a single stream OS duplicates streams Receivers get two copies and discard duplicates Core network offers diverse routing Receiver Application OS/Driver 31

32 Live-Live Aware Networks Access or edge networks - Duplicate streams, aka split - Remove duplicates, aka merge - Recover from packet loss Core networks - Set up diverse path Many choices 32

33 First Hop Router Duplication with Receiver Merge Sender Application OS/Driver First hop router generates a redundant stream Receiver application performs merging Core network offers diverse routing Receiver Application OS/Driver 33

34 Ingress Router Duplication with Receiver Merge Sender Application OS/Driver Ingress edge router generates a redundant stream Receiver application performs merging Core network offers diverse routing Receiver Application OS/Driver 34

35 First Hop Router Inserts / Last Hop Router Removes Duplicates Sender Application OS/Driver First hop router generates a redundant stream Last hop router removes duplicates Core network offers diverse routing Receiver Application OS/Driver 35

36 Ingress Router Inserts / Egress Router Removes Duplicates Sender Application OS/Driver Ingress edge router generates a redundant stream Egress edge router removes duplicates Core network offers diverse routing Receiver Application OS/Driver 36

37 How To Build Live-Live Aware Networks Most common techniques - MoFRR Multicast-only FRR - MT Multi-Topology - MIP Multi-IGP-Process Key Steps - Determine protection domain - Define diverse path technique (MoFRR/MT/MIP etc) - Define path selection policy - Define forwarding methods - All apply to both IP and MPLS transport - Some may happen faster than others 37

38 Protection Domain The key to build a network to support Live-Live (especially Spatial Redundancy) is to achieve path diversity within protection domain Protection domain - Between source and receiver hosts (applications) - Between first hop and last hop routers - Between ingress and egress edge routers - Or other combinations Between first hop router and receiver hosts Between ingress edge router and receiver hosts 38

39 Path Diversity Path diversity means the two paths packets travel along do not share the same physical link or node - E.g., if the protection domain is between source and receiver hosts, there are no overlapping link/nodes from the first hop network to the last hop Path diversity doesn t mandate separate networks (or IGP) under different administrative entities - It is ok to share the same IGP instance 39

40 Establishing Diverse Paths ECMP (Equal Cost Multiple Path) - Easy to deploy but more susceptible to routing change Multi-Topology Routing - Require protocol enhancement Multiple IGP processes Explicit path signaling - RSVP/TE P2MP And more 40

41 Choosing Different Paths (RPF) Multiple RPF interfaces for single flow - E.g. MoFRR Source/Destination address based path selection - E.g., select a routing topology using source and/or destination addresses FEC based path selection - E.g., used in mldp Head-end explicit path selection - E.g., RSVP/TE P2MP 41

42 Forwarding Using Diverse Paths Native IP multicast - Same network addresses - Different network addresses Encapsulation/Tunneling - IP multicast (as in MVPN) Label based 42

43 Summary Path Discovery Path Selection(RPF) Forwarding 43

44 Multicast Only FRR (MoFRR)

45 Multicast Only FRR (MoFRR) Backup Path - Set up by PIM from downstream router - Support native IP multicast forwarding - Leverage dual plane (or ECMP) topology Re-routing - Ingress router always duplicates packets - Packets duplication between ingress and egress router Egress router - Accept packets from primary RPF interface - Discard packets from secondary RPF interface - Switch to secondary if primary fails 45

46 MoFRR Topology Primary path from source to receiver is A E F - D Ingress Router E F Egress (MoFRR)Router A Dual Plane (ECMP) D B C Secondary path from source to receiver is A B C -- D 46

47 Without MoFRR PIM Joins E F A Data Packets D B C Only one path is used At any time, only one stream of packets are in transit 47

48 Without MoFRR E F A PIM Joins D B C Data Packets If the primary path fails, the entire backup path has to be rebuilt from beginning before data can flow again 48

49 How MoFRR Works E F A Dual Plane ECMP D B C Only egress router (D) needs to be configured to run MoFRR D sends PIM Joins to both upstream neighbors 49

50 How MoFRR Works E F A PIM Joins D B C PIM Joins are forwarded hop by hop Two forwarding trees are built A, B, C, E, F not aware of MoFRR 50

51 How MoFRR Works E F A Data Packets D B C Data packets are forwarded down both paths D forwards packets received from primary path and discards those received from secondary path 51

52 How MoFRR Works E F A Data Packets D B C If the primary path fails, D switches to forward packets received from the secondary path The secondary path has already been pre-built. 52

53 How MoFRR Works E F A Data Packets D B C When primary path restores, D switches back to accept packets from the primary path and discard those received from the secondary 53

54 MoFRR - Triggers Two Triggers to Switchover RIB based - Forward packets received on secondary path after RIB detects primary path unavailable - Control-plane driven Flow based Forward packets received on secondary path if incoming packet rate on primary path drops below threshold Data-plane driven 54

55 Inside an MoFRR Router RIB Based D 55

56 Inside an MoFRR Router RIB Based D 56

57 Inside an MoFRR Router Flow Driven D 57

58 Inside an MoFRR Router Flow Driven D 58

59 Summary of MoFRR Modification to PIM only Requires a dual-plane network - ECMP, Multi-Topology (MT) -IGP or Multiple IGP processes Needed only at the egress edge of protection domain - Only one router is required to be upgraded Near-zero loss switchover - Potential loss is a result of switching RPF interfaces to accept and forward packets - If per-packet merging is used, zero packet loss can be achieved 59

60 Comparing TE-FRR and MoFRR TE-FRR MoFRR Backup path Initiation By head-end router By egress router Backup path setup RSVP/TE or LDP PIM When to send packets to backup path How to handle packets from backup (secondary) path Topological Dependency Upon detecting failures Always accept and forward None Always Discard packets Upon detecting failures of primary RPF, accept and forward packets from secondary RPF Dual Plane Interoperability Domain wide Single router 60

61 Multi-Topology (MT) for Multicast

62 Benefits of Multicast Topology A separate multicast topology makes it easier to create incongruent paths - It is not a new idea - MBGP was introduced many years ago to do so in the Internet Creating an incongruent multicast topology allows one to manage network resource more efficiently - Path and metric engineering - Interwork with TE better - Not affected by asymmetric metric Creating multiple multicast topologies to improve resilience - Live-Live 62

63 Multi-Topology for IP Multicast Create separate topologies - Unicast topology for routing unicast packets and building TE tunnels - Multicast topologies for RPF and forwarding multicast packets - One or more multicast topologies depending on requirement Build multicast topologies by - Excluding links used for unicast only, or - Defining a different metric/cost for multicast IGPs support MT: IS-IS, OSPF, EIGRP - Not all enabled on all platforms 63

64 Path Diversity Using MT-IGP Create multiple multicast topologies using, e.g. MT-ISIS Use different topologies to build forwarding trees for each live-live stream - If one topology has a failure, the stream in the other topology is not affected Supported by both IOS and XR 64

65 Forwarding Support for Multi-Topology MT for multicast doesn t rely on separate MRIB or MFIB tables - Network addresses are used to identify the forwarding table - Only a single forwarding table is required - The semantics of TOS/DHCP bits are preserved - There is no new requirement on hardware 65

66 Topology Selection Using group addresses - Different group addresses for streams intended to use different protection path (topology) - Good for both SSM and ASM service model Using source addresses - Different source address must be used for streams intended to use different protection path - Best suited for SSM Using both group and source addresses Selection rules are flexible but must be consistent across network 66

67 Topology Selection Using PIM Group/Source based topology selection rules are configured on ingress and egress routers A router encode MT-ID in PIM Join/Prune packets to notify its upstream router which topology to use for RPF check when processing the Join/Prune packets - PIM has its own MT-ID space, independent of that of IS-IS/OSPF If MT-ID is not included, upstream router chooses RPF topology based on its own configuration 67

68 Example: Set up base topology 15 Unicast Routing Cost E F Source Receiver A1 D1 G A2 B C D2 The base topology includes all nodes and links in the network and announced by IS-IS 68

69 Example: Create multicast topologies E F Source Receiver A1 D1 G A2 B C D2 Different multicast topologies are created and announced in IS-IS Each includes a subset of nodes/links in network 69

70 Example: Define path selection policy E F Source Receiver A1 D1 G A2 B C D2 Routers choose which topology to RPF based on source addresses, group addresses or both - G1 uses Red and G2 uses Yellow - (S1, G1) uses Red and (S2, G1) uses Yellow 70

71 Example: Control packets flow E F Source Receiver A1 G D1 G1 A2 B C D2 The receiver send IGMP reports or PIM Join to draw two traffic flows Disjoint paths are established in the network between two topologies 71

72 Example: Data packets flow E F Source Receiver A1 G D1 G1 A2 B C D2 Source generates two streams with different addresses Receiver gets two streams and merges locally 72

73 Multi-Topology Summary Goal is to provide path protection - Using MT-IGP to build multiple multicast topologies - Forward data onto different paths - Zero (transport loss) in the presence of single failure Network doesn t perform split or merge of streams - Done by hosts, especially for discarding duplicates Most ideal for - Video - Market data - Any application demanding zero packet loss Always requires twice the bandwidth 73

74 Support Path Diversity Using Multiple IGP Processes

75 Multiple IGP Processes Core network runs multiple IGP processes - Can be from different IGPs but not as common Each core router may run only a single IGP or IGP process An edge router runs multiple IGP processes Source prefixes are injected into different IGP processes Path selection can only be achieved based on source addresses 75

76 Multiple IGP Processes E F Source Receiver A D B C The Red links, and E, F belong to IGP-1 The Yellow links, and B, C belong to IGP-2 A and D run both IGP processes 76

77 Multiple IGP Processes E F Source S1 Receiver A D S2 B C S1 is announced in IGP-1, reachable via E/F S2 is announced in IGP-2, reachable via B/C D can reach both, 77

78 Multiple IGP Processes E F Source S1 Receiver A D S2 B C Receiver can Join G (using ASM) or (S1,G)/(S2,G) using SSM D selects the path based on reachablity, S1 via F and S2 via C 78

79 Multiple IGP Processes E F Source S1 Receiver A D S2 B C The end result is similar to the case of multi-topology 79

80 Multiple IGP Processes Summary Very similar to multi-topology case - Similar means to create independent topologies and multicast forwarding paths - Similar resilience in the presence of single failure Egress router (when running both IGP processes) may become a single point of failure Most ideal for - Video - Market data - Any application demanding zero packet loss Always requires twice the bandwidth 80

81 At-A-Glance Comparison MoFRR Multi-Topology Multi-IGP Processes IGP Dependency Dual Plane (ECMP) Multi-topology Multiple IGP processes Backup path setup PIM only MT-IGP create topologies PIM build redunant paths IGP creates topologies Paths merge at edge PIM build redundant paths Path Selection Primary/Secondary RPF interfaces Source/Destination based Source based Stream Duplication By ingress router Same IP headers By content source Different IP headers By content source Different source addresses Stream Merging By egress router By host By host Interoperability Single router Upgrade egress router only Domain wide All routers participate Edge router supporting multiple IGP processes Packet loss Very small

82 Here Comes The Important Stuff

83 What We Have Learned Live-Live is a solution, not a specific protocol Live-Live improves application resilience - Especially if an application requires zero, or near zero loss while demanding minimum delay for loss recovery Live-Live solution encompasses applications, OS, and network Cisco routing solutions give you a head-start to build a resilient network supporting Live-Live 83

84 Why You Should Be Thinking About It What you have today is not what you had years ago What you have years from now is not going to be the same as what you have today Make the network more intelligent and resilient Bill Melohn, VP/CTO, Cisco NSSTG 84

85 Recommended Reading Please visit the Cisco Store for suitable reading.

86 Please complete your Session Survey We value your feedback Don't forget to complete your online session evaluations after each session. Complete 4 session evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Live T-shirt Surveys can be found on the Attendee Website at which can also be accessed through the screens at the Communication Stations Or use the Cisco Live Mobile App to complete the surveys from your phone, download the app at 1. Scan the QR code (Go to for QR code reader software, alternatively type in the access URL above) 2. Download the app or access the mobile site 3. Log in to complete and submit the evaluations 86

87 87

88 Thank you. 88