Your SlideShare is downloading. ×
0
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Towards Multicast Traffic Towards Multicast Traffic ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Towards Multicast Traffic Towards Multicast Traffic ...

303

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
303
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. International Telecommunication Union ITU-T Towards Multicast Traffic Engineering? Christian JACQUENET christian.jacquenet@orange-ft.com ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006
  • 2. Outline ITU-T o Context and motivation o IP multicast reminder o Approaches to multicast-inferred traffic engineering • DiffServ and MPLS-TE capabilities • Design considerations o Conclusion ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 2
  • 3. Some Actors of Multimedia Services ITU-T Content Network operator Provider o Network resources o Contents o Internet access o Possible pay-per-view scheme o Availability ISP Customer o Internet access o Provided with a (guaranteed) level of quality ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 3
  • 4. Sample Figures ITU-T o Around 200 Gbytes of traffic per VOD server per week o MPEG2-encoded TV traffic at ~4 Mbit/s per channel • Access any TV channel in less than 2s • Packet loss rate should not exceed 10-7 • A three 9’s+ (99,97%) availability o MPEG4-encoded HD TV is underway ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 4
  • 5. Why Consider IP Multicast? ITU-T o Resource optimization • Moving from n x P2P communications to 1 x P2MP communication —Data replication is performed as closely to the receivers as possible o Dynamics • Finer management of zapping behaviors —Tradeoff between IGP performance and state maintenance ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 5
  • 6. Application Spectrum ITU-T o Tree-based multicast network design is somewhat application-dependent 1-to-n Group Communication p-to-n Group Communication SSM PIM-SM Bi-Dir PIM ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 6
  • 7. Multicast Tree Taxonomy ITU-T o Rendezvous Point Trees (RPT), a.k.a. “shared trees” • A router of the multicast network is the root of the tree • Preferred design in case of numerous sources — Optimizes state maintenance in participating routers o Shortest Path Trees (SPT), a.k.a. “source trees” • The source is the root of the tree • Preferred design for path optimization purposes — Assumes a few sources ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 7
  • 8. PIM-SM Basics ITU-T o Requires a Rendezvous Point router to connect sources with receivers • By means of the dynamic establishment and maintenance of multicast distribution trees • Uses either RPT or SPT distribution trees o Explicit Join model • Source sends Register messages towards the RP router • DR routers send Join messages towards the RP to connect receivers • Assumes no one wants traffic unless explicitly requested ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 8
  • 9. QoS Issues ITU-T o IP multicast provides no means to: • Take into account the receivers' access capabilities • Provide some guarantees about the resources' availability • Gracefully handle congestion occurrences o Reliability of multicast traffic forecasts is hard to achieve because of: • The dynamics of multicast • The behavior of receivers ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 9
  • 10. Resource Optimization ITU-T o Notify multicast sources • When they should start and stop transmitting —According to IGMP(v3)-based interest expressed by potential receivers • Make the subscription procedure evolve —For a better usage of the bandwidth resources —So as to enforce a subscription policy on a timely basis, for example o Investigate traffic engineering techniques • To address path restoration issues • To comply with strict QoS guarantees —E.g. TV broadcasting services ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 10
  • 11. DiffServ-Inferred Distribution Trees ITU-T o Keeps the receiver-initiated principle • Adds signaling capability — Based upon IGMP traffic — To notify leaf routers about access rate conditions S • Marking is enforced by aggregation A B C devices (e.g. BRAS) — Information is processed by the IGMP Querier D E o As per the corresponding PHB configuration o Mandates QoS-based routing F G • To preserve the QoS information during RPF checks o Yields "colored" distribution trees "EF" Receiver "AF" Receiver • Core region is hopefully shared ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 11
  • 12. Multicast Traffic Conditioning ITU-T o Remains a local treatment • Indicates a router how to behave in case of congestion o No strict guarantee Lookup Table Traffic Measurer Multicast Flow Classifier Traffic Marker Conditioner Unicast Flow Classifier ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 12
  • 13. DiffServ-Inferred Tables ITU-T o When multicast traffic Group Address PHB Weight enters the DiffServ 233.12.144.2 EF 1 domain: AF1 3 AF2 2 • Processing done by the 233.12.144.4 EF 1 access router AF2 2 • Then enforces the traffic 233.12.144.25 AF1 1 conditioning policy AF2 2 —Multicast traffic volume can be estimated as many unicast flows as receivers ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 13
  • 14. Investigating Traffic Engineering ITU-T o Compute and select paths to accommodate: • Network-wide QoS requirements • Application-specific constraints — One-way transit delay, inter-packet delay variation, packet loss rate, etc. — Restoration capabilities • Network planning considerations o Provision resources accordingly • Towards automated configuration processes o Make sure the TE policy is not CPU-intensive • Switching performances of the participating devices • Volume of solicitations per unit of time ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 14
  • 15. MPLS as the Natural Candidate ITU-T o Implicit and attractive traffic engineering capabilities • IGP-inferred LSP path computation • TE extensions of RSVP with no scalability issues • Fast recovery mechanisms for both link and node protection o Commercial and operational implementations • Mostly for Fast Re-Route purposes • Claimed deployments of DiffServ-aware MPLS TE ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 15
  • 16. Basic Principles of Point-to-Multipoint Traffic-Engineered LSP Paths ITU-T o The IGP conveys information about routers' capabilities o P2MP LSP paths are established as per cost considerations IGP Protocol with TE Extensions P2MP LSP Request with QoS Constraints Topology Database Tree Computation Explicit Designation of the Tree P2MP LSP Signaling via RSVP-TE ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 16
  • 17. Lowest Cost Trees vs. Shortest Path Trees ITU-T Steiner tree (low cost): Shortest Path Tree 1. Cost = 5 1. Cost = 7 2. Path cost = 4 2. Path cost = 3 ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 17
  • 18. Tree Computation Options ITU-T o "Root" router-centric dynamic computation • Requires an adapted CSPF algorithm • May be CPU-intensive and yield performance issues o Dynamic computation performed by an external entity • Notion of Path Computation Element (PCE) —Downloads the subsequent configuration information to the "root" router —Suggests a hopefully automated procedure • May yield robustness issues in case of frequent solicitations ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 18
  • 19. P2MP LSP Establishment ITU-T o RSVP-TE-based: • "Source" router sends RSVP_PATH message that includes: — Sub-LSPs towards F and G • A sends RSVP_PATH message with sub-LSP S towards F • B sends RSVP_PATH message with sub-LSP A B C towards G • Etc. D E o Leaf routers (F, G, D, E,…) send back RSVP_RESV messages to "source" router (S) F G • A and B send a single RSVP_RESV message towards S that compiles all the sub-LSP- specific information ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 19
  • 20. State Maintenance ITU-T o Technically, the number of RSVP states grows as the group subscription dynamics • Yields scalability and performance issues o Practically, RSVP states could be de- composed into "sub-states": • Each sub-state corresponds to a subset of branches and leaves • Each sub-state can be dynamically refreshed independently • The global state is updated as per the grafting process ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 20
  • 21. One P2MP LSP per Service ITU-T o Yields as many tree structures as (S, Gi) pairs • Dramatically increases the number of states to maintain • Addresses finer resource optimization concerns o Well-suited for application-specific QoS requirements • E.g. VoD service and a few TV channels to broadcast o Poorly adapted to massive deployments • E.g. several bouquets with hundreds of TV channels • Inevitably raises operational and scalability concerns ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 21
  • 22. One Single P2MP LSP per Source ITU-T o Yields the maintenance of a single (*, *) Forwarding Equivalence Class (FEC) per source • Dramatically reduces the number of states to maintain • Network resource optimization is poorly addressed o Comparable to RPT tree structures in IP multicast o Well-suited for massive deployments • E.g. several bouquets with hundreds of TV channels o Poorly adapted to application-specific QoS requirements • No means to enforce traffic prioritization within the tree structure ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 22
  • 23. (S, Gj) Channel Aggregation into a Given P2MP Tree Structure ITU-T o A FEC corresponds to a set of (S, Gj) pairs o Presumably an attractive tradeoff, where: • Several bouquets of hundreds of TV channels need to be broadcast • Service subscription policy relies upon a thematic typology —Movie channels, documentary channels, etc. ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 23
  • 24. Pending Issues ITU-T o RSVP-TE is not suited for high dynamics • Context of frequent leaf addition or removal of the tree structure o RSVP-TE raises scalability issues when the number of PE routers is high o RSVP-TE requires more states than the LDP approach ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 24
  • 25. So, What's Next? ITU-T o "Triple-play" services are key drivers for the: • Design and enforcement of QoS policies in access regions — Never-ending over-provisioning is not an option • Deployment of multicast-inferred transmission schemes — TV broadcasting is becoming more than just another hype o DiffServ mechanisms remain an attractive option to deal with (probable) congestion o Multicast-inferred MPLS TE capabilities are exciting, assuming: • Dynamic computation and configuration features • An adapted multicast packet forwarding scheme — To better address dynamics of subscription schemes ITU-T IPTV Global Technical Workshop Seoul, Korea, 12-13 October 2006 25

×