1 / 49

Multicast Deployment and Standardization June 2008

Multicast Deployment and Standardization June 2008. Mike McBride. IETF. Goal is to make the Internet work better International community of network designers, operators, vendors, and researchers Create docs which include protocol standards, best current practices, and informational documents.

sue
Télécharger la présentation

Multicast Deployment and Standardization June 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multicast Deployment and StandardizationJune 2008 . Mike McBride

  2. IETF • Goal is to make the Internet work better • International community of network designers, operators, vendors, and researchers • Create docs which include protocol standards, best current practices, and informational documents. • The actual work is done in working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). • The working groups are grouped into areas, and managed by Area Directors. The ADs are members of the Internet Engineering Steering Group (IESG). • Rough consensus based decision making.

  3. Multicast in the IETF • PIM WG • Reliability • PIM over TCP (draft-farinacci-pim-port-00) • MBONED WG • MVPN Deployment (draft-ycai-mboned-mvpn-pim-deploy-02) • AMT (draft-ietf-mboned-auto-multicast-08) • L3VPN WG • MVPN (draft-ietf-l3vpn-2547bis-mcast-06) • previously: draft-rosen-vpn-mcast-08 • BGP vs PIM (draft-rosen-l3vpn-mvpn-profiles-00) • MPLS WG • LSM • MLDP / P2MP RSVP-TE • MSEC, SOFTWIRES, FECFrame, ANCP, L2VPN, RMT, BMWG

  4. PIM .

  5. PIM • PIM-SM draft complete • PIM WG now working on PIM improvements • draft-farinacci-pim-port-00 • Dino Farinacci

  6. PIM Port Problem Statement • Periodic sending of JP messages • Could take more CPU than desirable • Could use more bandwidth than desirable • More profound when there is a PIM instance per VPN • Other periodic messages not as critical • Hello messages can be backed off

  7. Solution Statement • Make simple and isolated changes to PIMv2 • No need to rev the protocol version • Make optional on a per logical or physical interface basis • Use existing transport layers • So we don’t have to reinvent congestion control, in order delivery, and retransmission logic • TCP and SCTP • Only for JP messages • Avoid the complexities of mix-mode LANs

  8. New Hello Options

  9. Connection Establishment • Use address from PIM Hello for transport connection addresses • Use address comparison for call collision • O(n2) connections not necessary • Reliability is between you and your RPF neighbor • Even over LANs or NBMA configured MDTs • Sending JPs over TCP/SCTP is called • “transport-mode” • When connection not established • Use “datagram-mode”

  10. Receiving JPs in Transport-Mode • Don’t need to maintain oif-timers • State is not refreshed but now incremental • So Join adds to oif-list and Prune removes • When transitioning between transport-mode and datagram-mode • Use oif-timers • Send full set of JPs since transmitter doesn’t know what was received

  11. MBONED .

  12. MBONED • draft-ycai-mboned-mvpn-pim-deploy-02 • draft-ietf-mboned-auto-multicast-08

  13. draft-ycai-mboned-mvpn-pim-deploy-02 • Purpose: “Create ‘practice and experience’ documents that capture the experience of those who have deployed and are deploying various multicast technologies.” In this case, pim based mvpn. • 02 revisions: • Removed historical mentioning of draft-rosen • Added Alcatel-Lucent TimOS mvpn implementation • Added scaling numbers from Wim • Suggestions: • Need info on resiliency being deployed in mvpn. • Intended status? • informational

  14. Multicast VPN Scalability Example PE PIM State P PIM State Scenario1:default MDT: PIM SSMdata MDT: PIM SSM Scenario2:default MDT: PIM SM with SPT switchoverdata MDT: PIM SSM Scenario3:default MDT: PIM SM without SPT switchoverdata MDT: PIM SSM

  15. Auto Multicast Tunneling (AMT) AMT Relay AMT Gateway • Tunnel through non-multicast enabled network segment • Draft in IETF ; Primarily for SSM • GRE or UDP encap • Relay uses well known ‘anycast’ address • Difference to IPsec, L2TPv3, MobileIP, … • Simple and targeted to problem • Consideration for NAT (UDP) • Ease implemented in applications (PC/STB) (UDP) • Variety of target deployment cases • Relay in HAG – provide native multicast in home • Gateway in core-SP – non-multicast Access-SP • Access-SP to Home - non-multicast DSL • In-Home only – eg: multicast WLAN issues AMT Tunnel multicast capable Non multicast Non multicast HAG NAT

  16. L3VPN .

  17. L3VPN • draft-ietf-l3vpn-2547bis-mcast-06 • draft-rosen-l3vpn-mvpn-profiles-00

  18. Cisco MVPN Strategy • Customers require multiple forwarding options for transit services. • Build upon successful PIM based MVPN model. • Scalable modular architecture for multicast transport services • MVPN PIM+GRE is first deployable option. • Still a perfectly valid choice! • Continues to be improved based on customer demand • MVPN LSM is additional option • mLDP • P2MP RSVP-TE • Same operations model for IP or MPLS for ease of transition between options. May use multiple options in parallel (depending on service) • Focus on (necessary) migration options

  19. Join high bandwidth source Join high bandwidth source A A Receiver 1 B New York PE PE C C PE E Default MDT For low Bandwidth & control traffic only. Data MDT Dallas PE For High Bandwidth traffic only. Los Angeles PE D D Receiver 3 High bandwidth multicast source MVPN using PIM/GRE vs MVPN MLDP/MPLS MVPN domain model is not dependent on forwarding used. MVPN GRE and MVPN MLDP use the same Domain model. Default-MDT will be there Data-MDT will be there PIM signaling over Default-MDT There is no difference except for core tree-building and encapsulation Receiver 4 CE CE CE CE B2 B1 San Francisco MPLS VPN Core Multicast VPN CE CE Receiver 2

  20. MVPN Next Generation • MPLS has a rich set of options for supporting multipoint services • Richness derives from broad set of service demands • No one-size-fits-all answer • MVPN solution space is a little confusing, but need not be overwhelming • Build P-trees with PIM, RSVP-TE or MLDP • Autodiscover MVPN members with PIM or BGP • Exchange C-mroutes with PIM or BGP • Choosing among solutions is not simple • Requires understanding of customer needs, topology, behavior • Greater clarity may come with more deployment experience • Considerable deployment experience today with PIM based mvpn approach

  21. MPLS .

  22. LSM

  23. PIM-V4 VRF Config: ip vrf RED mdt default 239.1.1.1 mp2mp 4.4.4.4 M-LDP Label Advertisement:FEC= FEC-MDT RPFv=P-4Label=(20) (21) Upstrm M-LDP Label Advertisement:FEC= FEC-MDT RPFv=P-4Label=(20) (21) Upstrm M-LDP Label Advertisement:FEC= FEC-MDT RPFv=P-4 Label =(30) Label =(31) Upstrm PIM-V4 VRF Config: ip vrf RED mdt default 239.1.1.1 mp2mp 4.4.4.4 PIM-V4 VRF Config: ip vrf RED mdt default 239.1.1.1 mp2mp 4.4.4.4 Multicast LDP based Multicast VPN (Default-MDT) MP2MP Tree Setup Summary • All PE’s configured for same VRF derive FEC from configured default-mdt group. • Downstream path is setup like a normal P2MP LSP. • Upstream path is setup like a P2P LSP to the upstream router. VPNv4 CE-2 Content Receiver PE-2 VPNv4 P-4 PE-1 CE-1 MPLS Core MP2MP LSP “Root” Content Source PE-3 VPNv4 CE-3 Content Receiver

  24. IPv4 IPv4 VPNv4 Label VPNv4 Label IPv4 IPv4 IPv4 IPv4 VPNv4 Label VPNv4 Label VPNv4 Label L30 L20 L100 “Pop” Outer Label “Push” “Swap” Multicast LDP based Multicast VPN (Default-MDT) VPNv4 CE-2 Content Receiver PE-2 VPNv4 P-4 PE-1 CE-1 MPLS Core Content Source PE-3 VPNv4 CE-3 Content Receiver

  25. IPv4 “Pop” Inner Label IPv4 Multicast LDP based Multicast VPN (Default-MDT) VPNv4 CE-2 Content Receiver PE-2 VPNv4 P-4 PE-1 CE-1 MPLS Core Content Source PE-3 VPNv4 CE-3 Content Receiver

  26. PATH Message : ERO -> R2-R3-R4 PATH Message : ERO -> R2-R3-R5 P2MP RSVP-TE – Signaling Details Distribution/ Access Service Edge Source Core Receiver Layer 2 Switch R4 R6 PE CE Layer 2 Switch Receiver PE R1 R2 R3 CE PE P Layer 2 Switch Source R5 R7 CE PE Receiver Headend sends one PATH message per destination

  27. P2MP RSVP-TE – Signaling Details Distribution/ Access Service Edge Source Core Receiver Label Merge Layer 2 Switch R4 R6 44 PE CE 33 Layer 2 Switch Receiver PE R1 R2 R3 CE PE P PE Layer 2 Switch 33 Source R5 R7 55 CE Receiver RESV Messages are sent by Tailend routers; Communicates labels & reserves BW on each link RESV Msg Initiated by R4 55 Label Advertisement carries in the RESV Message RESV Msg Initiated by R5

  28. P2MP RSVP-TE – Forwarding Distribution/ Access Service Edge Source Core Receiver 44 R4 R6 33 PE CE Layer 2 Switch Layer 2 Switch Receiver PE R1 R2 SSM, PIM-SM, R3 CE PE P PE Source R5 R7 PIM-SSM, CE 55 Layer 2 Switch Receiver No PHP ! Need label on tailend PE to identify tree Multicast Packet Labeled Packet

  29. MSEC .

  30. GDOI Update Draft • RFC3547 • One clarification is to extend the capability of GDOI to support AH as well as ESP. This will allow us to describe how to protect PIM with AH.

  31. Secure Groups What is needed to secure group traffic? • Policy Distribution • Distribution of the knowledge that group traffic is protected, and what is needed to participate in the group • Protect the data in transit • Only group members should be able to participate in the group • Non-group members should not be able to spoof or disrupt group communication • Deliver keys to all group members

  32. Deliver keys to all group members Security Requirements • Authentication • Group members & key servers confirm each others identity. • Authorization • Key server only accepts requests from authorized group members • Group members validate that they are getting keys from an authorized key server

  33. Group Hug vs. Key server Methods • Group Hug method • When a new group member joins, all group members participate in creating a new set of group keys, usually using some variety of Group Diffie-Hellman • Efficiently used by small groups • Key Server method • A key server unilaterally chooses the keys • Group members join by registering with the key server • The key server replaces keys when a group member leaves • Can scale to very large groups by using multiple collaborating key servers

  34. Key Server Method Key Management Protocols • GSAKMP/GSAKMP light • Protocol definitions along with strong policy component. • IETF MSEC Internet Drafts • Group Domain of Interpretation (GDOI) • Re-uses IKE protocols and definitions

  35. MOBOPTS .

  36. Mobile Multicast • Increasing activity in this area • Mobile hosts • Mobile network nodes • Focus area of enterprise video project • New IETF area of discussion • multimob held during mobopts in Vancouver • No multimob mtg in Philly, only informal gathering to discuss solutions

  37. Background - Terminology • Portability (nomadic) • Node or network disconnects, moves to new location, and easily reconnects (e.g., Mobile worker, VPN, building to building) • Mobility • Node or network remains connected while in motion, using pre-defined network infrastructure (e.g., Mobile IP, NEMO). • L2 (cellular, 802.11x, 802.16x) Roaming, Handover • L3 (IP Mobility) Roaming • Remote Access • Wireless (WiFi, WiMAX) • Ad Hoc • Nodes or networks interconnect opportunistically, no pre-defined infrastructure, no dependence on any particular node (MANET)

  38. Mobile Multicast Problem statement drafts: • draft-deng-multimob-ps-mobilemulticast-00 • draft-liu-multimob-igmp-mld-mobility-req-00 • draft-irtf-mobopts-mmcastv6-ps-02 • draft-zhang-multimob-memcast-ps-01 Agent-based solution drafts: • draft-yang-multimob-mip6-mc-tunnel-opt-00 • draft-von-hugo-multimob-agents-01 Protocol-based solution drafts: • draft-asaeda-multimob-igmp-mld-mobility-extensions-00 • draft-schmidt-waehlisch-mhmipv6-04 • draft-xia-multimob-hybrid-00

  39. Multicast Delivery Method Unicast Mechanism One Multicast Packet In LWAPP Encapsulated Packets Multiple Copies of the Same Multicast Packet Encapsulated with LWAPP Unicast Packets out to Each AP

  40. Multicast Delivery Method • Improved multicast performance over wireless networks • Multicast packet replication occurs only at points in the network where it is required, saving wired network bandwidth Network Replicates Packet as Needed One LWAPP Encapsulated Multicast Packet Out LWAPP Multicast Group One Multicast Packet In

  41. Mobile Access Router Overview • Ideal for use in vehicles in public safety, homeland security, and transportation applications • Compact size, rugged enclosure • Seamless mobility and interoperability across multiple wireless networks, including satellite, cellular, and 802.11

  42. MAR Vehicle Network Example MESH NETWORK • MAR allows client devices in and around the vehicle to stay connected while the vehicle is roaming. • MAR WMIC in access point mode provides WLAN hotspot for wireless clients around vehicle. • Ethernet interfaces connect in-vehicle wired clients, laptop, camera, or other sensors. • Another WMIC configured as a Universal Workgroup Bridge for connectivity to a Mesh AP. • Serial interfaces provide connectivity to wireless WAN modems, CDMA or GPRS. Used as backup when mesh network is not available

  43. ANCP .

  44. ANCP in Cisco’s Reference Model AF RACS NASS IPTV Source IP-Edge (NAS) CPE Access Node(DSLAM) VoD Pump ANCP • ANCP= Access Node Control Protocol • Between AN and NAS • Intended primarily for L2 Access architectures with L3 subscriber aware node in the aggregation • Aims to leverage BNG Subscriber awareness (ISG) for control and management • Works towards a black box principle; L2 access-node and L3 edge seen as working in unison, although functionality is distributed between the two

  45. ANCP Status • An ANCP Requirements document: • "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", • draft-ietf-ancp-framework-05 (Feb 08) • An ANCP Protocol document • "Protocol for Access Node Control Mechanism in Broadband Networks", • draft-ietf-ancp-protocol-02 (Nov 07) • An ANCP Security Threat document • draft-ietf-ancp-security-threat-03 • Two ANCP MIB documents • draft-ietf-ancp-mib-an-01 • draft-decnodder-ancp-mib-nas-00

  46. ANCP Status (Multicast Use Case) • Multicast use cases have been driven by Cisco & TI. • ancp-framework now incorporates the models driven by Cisco/TI: • White-List/Black-List (ie AN can do Conditional Access when CAC not needed) • Grey-List (AN queries NAS, CAC & Conditional Access done by NAS for both multicast & unicast) • Grey-List with Flow-Groups (NAS provides “admit decision” for a group of Multicast flows, so AN can handle zapping within group)

  47. C4500 ANCP Use Case Example:Application triggered mcast. Radius DB Entitlement Server 2 Want channel CNN Channel CNN RequestFor subscriber IP A 1 CP1 Content response OK to IP A. Info: S,G 4 PIM (S,G) Join 6 IP Content Delivery 3 Push Multicast (S,G), aaa.bbb.ccc.ddd on port X VLAN Y 5 Subs A allowed to watch CNN ? CP2 Multicast Join - OK 7 Gateway CPn

  48. Multicast in other SDOs • ITU-T • Multicast CAC • Cablelabs • DOCSIS 3.0/Wideband DOCSIS • TISPAN • Multicast Admission Control • WiMAX Forum • Multicast-broadcast to deliver content to WiMAX users • 3GPP/3GPP2 • IMS using multicast bearers • DSL Forum • Multicast Architecture Options

More Related