Ip multicast Peering


Download 152.5 Kb.
Sana15.03.2020
Hajmi152.5 Kb.
#90268

IP Multicast Peering

  • Karl Jeacle
  • kj@eircom.net

Overview

  • Overview of multicast peering points
    • What, where, who, how?
  • Equipment & associated costs
  • Protocol interaction (PIM/MSDP/MBGP)
  • Multicast peering policies
  • Operational best common practice

What is a peering point?

  • Peering definition
    • “Peering is the arrangement of traffic exchange between Internet Service Providers, at public exchange points, with zero sum financial settlement”
    • Note:

European exchanges

  • DECIX – Frankfurt, Germany
  • INXS – Munich, Germany
  • AMSIX – Amsterdam, Netherlands
  • NDIX – Enschede, Netherlands
  • NETNOD – Stockholm, Sweden
  • LINX – London, UK
  • LoNAP – London, UK
  • MaNAP – Manchester, UK
  • XchangePoint - London, UK
  • VIX – Vienna, Austria
  • BNIX – Brussels, Belgium
  • SFINX – Paris, France
  • GIGAPIX – Lisbon, Portugal
  • CATNIX – Barcelona, Spain
  • SIX – Bratislava, Slovakia
  • CIXP – Geneva, Switzerland

Future exchange trials

  • Most exchanges planning trials in 2003
  • INEX – Dublin, Ireland
  • MIXITA – Milan, Italy
  • NIX – Oslo, Norway
  • SWISSIX - Zurich, Switzerland

Who can join?

  • Varies across exchange points
    • Network criteria must be met
    • Typically ISPs only
    • Sometimes content providers
    • Rarely end-users
    • Depends on MoU and T&C

Exchange equipment

  • Desire to isolate multicast traffic from existing “production” unicast traffic
    • Separate switch used
      • Dedicated connection to multicast switch port
      • LINX – Extreme Summit 48
    • Separate VLAN on same switch
      • Dedicated connection to port in multicast VLAN
      • AMSIX – Foundry BigIron 8000 & 15000

Exchange equipment

  • Some exchanges do not require an additional network connection
    • e.g. FICIX, NETNOD, SIX
    • OK if point-to-point (e.g. ATM)
    • Concern if shared access (e.g. Ethernet)
      • Multicast traffic looks like broadcast traffic
      • Switch will send data out on all ports
      • Bearable if multicast only, unacceptable if unicast
  • PIM Snooping or equivalent required

PIM Snooping

  • Hosts connected to a switch
    • IGMP snooping prevents unwanted traffic
  • Routers connected to a switch
    • PIM used instead of IGMP
    • Switches do not “see” PIM messages
    • Traffic will be flooded on all ports
  • Solution:
    • Enable “PIM snooping” on switches so they can restrict multicast traffic flows to interested parties

RGMP

  • Cisco provide RGMP
    • RouterPort Group Management Protocol
    • Proprietary, but submitted as IETF draft
    • Message format resembles IGMP to allow easier upgrade of existing switches
    • Unlike PIM Snooping, all devices (i.e. switch and routers) must run RGMP

Member costs

  • Present for unicast peering already
    • New router is unnecessary
    • Extra port on existing router sufficient
    • Additional rental for multicast port
    • Software upgrades may be required
  • Main cost
    • Staff competence development
    • Depends on commitment to multicast

Steps involved

  • Peering agreements
    • Are multicast & unicast peers equivalent?
    • Is a (new) peering agreement necessary?
  • Session configuration
    • MBGP / MSDP / PIM-SM
  • RIPE database
    • No specific multicast route entries

Protocols required

  • Protocols required for multicast peering
    • MBGP
      • Exchange unicast routes to multicast sources
    • MSDP
      • Exchange “Source Active” messages (SAs)
    • PIM-SM
      • Allows branches of multicast distribution tree to be built between peers across the exchange

MBGP

  • Multiprotocol Border Gateway Protocol
    • Not “Multicast BGP”
      • Multiprotocol extensions allow IPv6 & MPLS VPNs
    • MBGP exchanges unicast prefixes of multicast hosts, it does not exchange group addresses!
  • MBGP multicast rationale
    • Incongruent routing between unicast & multicast
    • Force multicast traffic to take alternative path

Incongruent routes

MBGP Policies

  • Peering policy
    • Unicast peering has AS path & prefix filters
    • Re-use depending on administrative policy
    • Can re-announce other peers’ prefixes… …a sort of pseudo-transit for multicast
    • Always agree first with peers concerned!

MSDP

  • Multicast Source Discovery Protocol
    • Connects PIM-SM domains
    • Allows multicast sources for a group to be known across different domains
    • Peers exchange multicast “Source Active” messages (MSDP SAs)
    • SAs carried to PIM Rendezvous Points

PIM-SM

  • PIM Sparse Mode
    • Allow PIM neighbours to be established
    • Branches of multicast distribution tree are built between peers across the exchange
    • Enable on exchange-facing interface
      • Ideally run natively back to core of network
      • Or tunnel back to multicast-enabled network

Best Common Practice

  • Keep local traffic local!
  • Filter traffic & SAs with ACLs
    • Private source addresses
    • Private group destination addresses
    • SSM 232/8 space
    • PIM BSR and/or Auto-RP
    • Misc services (e.g. discovery protocols)

How active?

  • # Participants
    • Usually numerous interested members…
    • but typically just 10-20% get up & running
  • Traffic
    • Small percentage of unicast (~ 1%)
      • Efficiency – it’s multicast! 
      • Lack of content 

Evangelism!

  • If you are an ISP
  • If you are an ISP customer
    • Ask your provider for multicast service
    • Ask them for details on peering presence

More information

  • Exchange points
    • http://www.ep.net/
    • http://www.euro-ix.net/ispportal/ixpmatrix.htm
  • BCP ACLs
    • ftp://ftpeng.cisco.com/ipmulticast/config-notes/msdp-sa-filter.txt
  • Sample config
    • http://multicast.eircom.net/

Thank you! ——— Questions?



Download 152.5 Kb.

Do'stlaringiz bilan baham:




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2022
ma'muriyatiga murojaat qiling