Multicast, CPE and TR-101

1,546 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,546
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
52
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Multicast, CPE and TR-101

  1. 1. Multicast, CPE and TR-101 David Thorne 15 June 2007
  2. 2. Contents <ul><li>What has the Residential Gateway (RG) got to do with Multicast ? </li></ul><ul><li>Basic Connectivity Requirements </li></ul><ul><li>The BT approach </li></ul><ul><li>Alignment with TR-101 </li></ul>
  3. 3. What has the RG got to do with Multicast ? <ul><li>3 Issues </li></ul><ul><li>The VC architecture </li></ul><ul><li>IGMP and PPP </li></ul><ul><li>LANside IGMP snooping </li></ul>
  4. 4. Basic Connectivity RG AN BRAS PPP Internet Multicast IGMP
  5. 5. Basic Connectivity Requirements <ul><li>The AN will be a multicast replication point </li></ul><ul><li>Downstream multicast cannot be injected into the PPP session </li></ul><ul><li>IGMP requests need to be passed on to the BRAS even if the traffic can be sourced from the AN </li></ul><ul><ul><li>may need to be used for reprofiling purposes </li></ul></ul><ul><li>The RG will have both routed and switched ports </li></ul>
  6. 6. VC Options <ul><li>Downstream </li></ul><ul><li>Can’t have the mcast traffic in the PPP session </li></ul><ul><li>Have to be able to separate the multicast and Internet traffic </li></ul><ul><li>Can do this by means of IPOE and PPPOE </li></ul><ul><li>Can prioritise the injected multcast traffic </li></ul><ul><li>Upstream </li></ul><ul><li>Need to be able to snoop the IGMP at the AN </li></ul><ul><li>Some ANs can’t do this within PPP </li></ul><ul><li>Can do IGMP forking and send the IGMP in both the IPOE and PPPOE sessions </li></ul><ul><li>Do not need to separate by way of VC </li></ul><ul><li>Conclusion </li></ul><ul><li>Can do everything in the existing VC </li></ul><ul><ul><li>don’t need to change the access configuration </li></ul></ul><ul><ul><li>VCs are disappearing beyond the AN </li></ul></ul>
  7. 7. LANside requirements <ul><li>RG has both routed and switched ports </li></ul><ul><li>Want to be able to suppress multicast replication on L2 ports </li></ul><ul><li>There is an issue with multicast over wireless </li></ul><ul><li>This is nothing to do with the overall architecture </li></ul>
  8. 8. TR101 and multicast <ul><li>TR101 is primarily about migrating to Ethernet aggregation and backhaul, to a single BRAS </li></ul><ul><li>There is explicit recognition of multicast and a second, multicast BNG </li></ul><ul><ul><li>considerable part of the complexity of TR101 </li></ul></ul><ul><ul><li>even making it as simple as possible </li></ul></ul><ul><li>Some of the connectivity requirements flow from this </li></ul>
  9. 9. TR-101 Multicast Reference Model
  10. 10. TR-101 Multicast Overview <ul><li>Efficient L2 replication in the Ethernet aggregation network through the use of N:1 VLANs </li></ul><ul><li>Separate multicast-VC not required on the access loop </li></ul><ul><li>Support for IGMP V2 and V3 </li></ul><ul><li>Support for ASM and SSM models </li></ul><ul><li>Support for multiple content injection points in the network </li></ul><ul><li>Support for multiple multicast VLANs in the access network </li></ul><ul><li>IP (and IGMP) packets are directly encapsulated in Ethernet frames </li></ul><ul><li>IGMP hosts are connected to Access Node ports that are members of the multipoint VLAN that will carry (receive) the multicast frames </li></ul><ul><li>IGMP packets are transmitted in that same VLAN from which the multicast packet will be received </li></ul><ul><li>User ports can be members of multiple VLANs. </li></ul><ul><li>Note that this Technical Report does not consider optimizing multicast delivery over PPPoA and IPoA sessions in the Access Node (U interface) and therefore those scenarios are not considered. </li></ul>
  11. 11. TR-101 RG Requirements <ul><li>R-191 The RG MUST support an IGMP Proxy-Routing function. </li></ul><ul><li>R-192 The RG MUST support IGMP version 3 as per RFC 3376. </li></ul><ul><li>R-193 The RG MUST support IGMP forwarding with local NAT and firewall features including </li></ul><ul><li>establishing any pin-holes in the firewall for the multicast streams received (after join) </li></ul><ul><li>R-194 When the RG is configured with multiple WAN-facing IP interfaces (e.g. PPP or IPoE), the </li></ul><ul><li>IGMP Proxy-Routing function MUST be able to multicast upstream IGMP messages to all or </li></ul><ul><li>a configured subset of those WAN interfaces. </li></ul><ul><li>R-195 The RG MUST be configurable as to which interfaces IGMP messages should be forwarded </li></ul><ul><li>to in the upstream direction. The default behavior MUST be to forward messages to all </li></ul><ul><li>provisioned interfaces. </li></ul><ul><li>R-196 When the RG receives an IGMP membership query on a given WAN-facing IP interface, the </li></ul><ul><li>IGMP Proxy-Routing function MUST only send a corresponding membership report on this </li></ul><ul><li>specific interface. </li></ul><ul><li>R-197 The RG SHOULD be able to classify IGMP requests according to source IP/MAC address or </li></ul><ul><li>incoming LAN physical port on the RG to distinguish between multicast services (e.g. IPTV </li></ul><ul><li>and some other Best Effort (BE) Internet IGMP application). </li></ul><ul><li>R-198 The RG MUST have a way of suppressing the flooding of multicast on selected ports, either </li></ul><ul><li>through dedicated ports connecting to IGMP hosts or IGMP Proxy-Routing. </li></ul><ul><li>R-199 The RG SHOULD be able to configure which ports are allowed to have IGMP hosts. </li></ul><ul><li>R-200 The RG MUST support IGMP immediate leave with explicit host tracking. </li></ul><ul><li>R-201 The RG MUST NOT forward UPNP multicast messages to its WAN interface. </li></ul>
  12. 12. TR-101 RG Key requirements <ul><li>IGMP version 3 </li></ul><ul><li>IGMP forwarding with local NAT and firewall features including </li></ul><ul><li>establishing any pin-holes in the firewall for the multicast streams received </li></ul><ul><li>When the RG is configured with multiple WAN-facing IP interfaces (e.g. PPP or IPoE), the IGMP Proxy-Routing function MUST be able to multicast upstream IGMP messages to all or a configured subset of those WAN interfaces. </li></ul><ul><ul><li>IGMP forking </li></ul></ul><ul><li>The RG MUST be configurable as to which interfaces IGMP messages should be forwarded to in the upstream direction </li></ul><ul><li>SHOULD be able to classify IGMP requests according to source IP/MAC address or incoming LAN physical port on the RG to distinguish between multicast services (e.g. IPTV and some other Best Effort (BE) Internet IGMP application). </li></ul><ul><li>MUST have a way of suppressing the flooding of multicast on selected ports, either through dedicated ports connecting to IGMP hosts or IGMP Proxy-Routing. </li></ul><ul><li>MUST NOT forward UPNP multicast messages to its WAN interface. </li></ul>
  13. 13. Conclusion <ul><li>Multicast is not simple </li></ul><ul><li>Proposed BT solution is as simple as we could make it </li></ul><ul><li>Takes into account capabilities and limitations of existing RGs and ANs </li></ul><ul><li>Fully aligned with TR101 </li></ul>

×