Towards Multicast Traffic Engineering?

Size: px

Start display at page:

Download "Towards Multicast Traffic Engineering?"

Eunice Daniels
6 years ago
Views:

1 Internatinal Telecmmunicatin Unin Twards Multicast Traffic Engineering? Christian JACQUENET

2 Outline Cntext and mtivatin IP multicast reminder Appraches t multicast-inferred traffic engineering DiffServ and MPLS-TE capabilities Design cnsideratins Cnclusin 2

3 Sme Actrs f Multimedia Services Netwrk peratr Cntent Prvider Netwrk resurces Internet access Availability Cntents Pssible pay-per-view scheme ISP Custmer Internet access Prvided with a (guaranteed) level f quality 3

4 Sample Figures Arund 200 Gbytes f traffic per VOD server per week MPEG2-encded TV traffic at ~4 Mbit/s per channel Access any TV channel in less than 2s Packet lss rate shuld nt exceed 10-7 A three 9 s+ (99,97%) availability MPEG4-encded HD TV is underway 4

5 Why Cnsider IP Multicast? Resurce ptimizatin Mving frm n x P2P cmmunicatins t 1 x P2MP cmmunicatin Data replicatin is perfrmed as clsely t the receivers as pssible Dynamics Finer management f zapping behavirs Tradeff between IGP perfrmance and state maintenance 5

6 Applicatin Spectrum Tree-based multicast netwrk design is smewhat applicatin-dependent 1-t-n Grup Cmmunicatin p-t-n Grup Cmmunicatin SSM PIM-SM Bi-Dir PIM 6

7 Multicast Tree Taxnmy Rendezvus Pint Trees (RPT), a.k.a. shared trees A ruter f the multicast netwrk is the rt f the tree Preferred design in case f numerus surces Optimizes state maintenance in participating ruters Shrtest Path Trees (SPT), a.k.a. surce trees The surce is the rt f the tree Preferred design fr path ptimizatin purpses Assumes a few surces 7

8 PIM-SM Basics Requires a Rendezvus Pint ruter t cnnect surces with receivers By means f the dynamic establishment and maintenance f multicast distributin trees Uses either RPT r SPT distributin trees Explicit Jin mdel Surce sends Register messages twards the RP ruter DR ruters send Jin messages twards the RP t cnnect receivers Assumes n ne wants traffic unless explicitly requested 8

9 QS Issues IP multicast prvides n means t: Take int accunt the receivers' access capabilities Prvide sme guarantees abut the resurces' availability Gracefully handle cngestin ccurrences Reliability f multicast traffic frecasts is hard t achieve because f: The dynamics f multicast The behavir f receivers 9

10 Resurce Optimizatin Ntify multicast surces When they shuld start and stp transmitting Accrding t IGMP(v3)-based interest expressed by ptential receivers Make the subscriptin prcedure evlve Fr a better usage f the bandwidth resurces S as t enfrce a subscriptin plicy n a timely basis, fr example Investigate traffic engineering techniques T address path restratin issues T cmply with strict QS guarantees E.g. TV bradcasting services 10

11 DiffServ-Inferred Distributin Trees Keeps the receiver-initiated principle Adds signaling capability Based upn IGMP traffic T ntify leaf ruters abut access rate cnditins Marking is enfrced by aggregatin devices (e.g. BRAS) Infrmatin is prcessed by the IGMP Querier As per the crrespnding PHB cnfiguratin Mandates QS-based ruting T preserve the QS infrmatin during RPF checks Yields "clred" distributin trees Cre regin is hpefully shared A F D S G B E "EF" Receiver "AF" Receiver C 11

12 Multicast Traffic Cnditining Remains a lcal treatment Indicates a ruter hw t behave in case f cngestin N strict guarantee Lkup Table Traffic Measurer Multicast Flw Classifier Unicast Flw Classifier Marker Traffic Cnditiner 12

13 DiffServ-Inferred Tables When multicast traffic enters the DiffServ dmain: Prcessing dne by the access ruter Then enfrces the traffic cnditining plicy Multicast traffic vlume can be estimated as many unicast flws as receivers Grup Address PHB Weight EF 1 AF 1 3 AF 2 2 EF 1 AF 2 2 AF 1 1 AF

14 Investigating Traffic Engineering Cmpute and select paths t accmmdate: Netwrk-wide QS requirements Applicatin-specific cnstraints One-way transit delay, inter-packet delay variatin, packet lss rate, etc. Restratin capabilities Netwrk planning cnsideratins Prvisin resurces accrdingly Twards autmated cnfiguratin prcesses Make sure the TE plicy is nt CPU-intensive Switching perfrmances f the participating devices Vlume f slicitatins per unit f time 14

15 MPLS as the Natural Candidate Implicit and attractive traffic engineering capabilities IGP-inferred LSP path cmputatin TE extensins f RSVP with n scalability issues Fast recvery mechanisms fr bth link and nde prtectin Cmmercial and peratinal implementatins Mstly fr Fast Re-Rute purpses Claimed deplyments f DiffServ-aware MPLS TE 15

16 Basic Principles f Pint-t-Multipint Traffic-Engineered LSP Paths The IGP cnveys infrmatin abut ruters' capabilities P2MP LSP paths are established as per cst cnsideratins IGP Prtcl with TE Extensins P2MP LSP Request with QS Cnstraints Tplgy Database Tree Cmputatin Explicit Designatin f the Tree P2MP LSP Signaling via RSVP-TE 16

17 Lwest Cst Trees vs. Shrtest Path Trees Steiner tree (lw cst): 1. Cst = 5 2. Path cst = 4 Shrtest Path Tree 1. Cst = 7 2. Path cst = 3 17

18 Tree Cmputatin Optins "Rt" ruter-centric dynamic cmputatin Requires an adapted CSPF algrithm May be CPU-intensive and yield perfrmance issues Dynamic cmputatin perfrmed by an external entity Ntin f Path Cmputatin Element (PCE) Dwnlads the subsequent cnfiguratin infrmatin t the "rt" ruter Suggests a hpefully autmated prcedure May yield rbustness issues in case f frequent slicitatins 18

19 P2MP LSP Establishment RSVP-TE-based: "Surce" ruter sends RSVP_PATH message that includes: Sub-LSPs twards F and G A sends RSVP_PATH message with sub-lsp twards F B sends RSVP_PATH message with sub-lsp twards G Etc. Leaf ruters (F, G, D, E, ) send back RSVP_RESV messages t "surce" ruter (S) A and B send a single RSVP_RESV message twards S that cmpiles all the sub-lspspecific infrmatin A F S D G B E C 19

20 State Maintenance Technically, the number f RSVP states grws as the grup subscriptin dynamics Yields scalability and perfrmance issues Practically, RSVP states culd be decmpsed int "sub-states": Each sub-state crrespnds t a subset f branches and leaves Each sub-state can be dynamically refreshed independently The glbal state is updated as per the grafting prcess 20

21 One P2MP LSP per Service Yields as many tree structures as (S, G i ) pairs Dramatically increases the number f states t maintain Addresses finer resurce ptimizatin cncerns Well-suited fr applicatin-specific QS requirements E.g. VD service and a few TV channels t bradcast Prly adapted t massive deplyments E.g. several buquets with hundreds f TV channels Inevitably raises peratinal and scalability cncerns 21

22 One Single P2MP LSP per Surce Yields the maintenance f a single (*, *) Frwarding Equivalence Class (FEC) per surce Dramatically reduces the number f states t maintain Netwrk resurce ptimizatin is prly addressed Cmparable t RPT tree structures in IP multicast Well-suited fr massive deplyments E.g. several buquets with hundreds f TV channels Prly adapted t applicatin-specific QS requirements N means t enfrce traffic priritizatin within the tree structure 22

23 (S, G j ) Channel Aggregatin int a Given P2MP Tree Structure A FEC crrespnds t a set f (S, G j ) pairs Presumably an attractive tradeff, where: Several buquets f hundreds f TV channels need t be bradcast Service subscriptin plicy relies upn a thematic typlgy Mvie channels, dcumentary channels, etc. 23

24 Pending Issues RSVP-TE is nt suited fr high dynamics Cntext f frequent leaf additin r remval f the tree structure RSVP-TE raises scalability issues when the number f PE ruters is high RSVP-TE requires mre states than the LDP apprach 24

25 S, What's Next? "Triple-play" services are key drivers fr the: Design and enfrcement f QS plicies in access regins Never-ending ver-prvisining is nt an ptin Deplyment f multicast-inferred transmissin schemes TV bradcasting is becming mre than just anther hype DiffServ mechanisms remain an attractive ptin t deal with (prbable) cngestin Multicast-inferred MPLS TE capabilities are exciting, assuming: Dynamic cmputatin and cnfiguratin features An adapted multicast packet frwarding scheme T better address dynamics f subscriptin schemes 25

CCNA 3 Chapter 2 v5.0 Exam Answers 2015 (100%)

CCNA 3 Chapter 2 v5.0 Exam Answers 2015 (100%) 1. Which tw netwrk design features require Spanning Tree Prtcl (STP) t ensure crrect netwrk peratin? (Chse tw.) static default rutes implementing VLANs t