Multicast deployment and standardization june 2008
This presentation is the property of its rightful owner.
Sponsored Links
1 / 49

Multicast Deployment and Standardization June 2008 PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Multicast deployment and standardization june 2008

Multicast Deployment and StandardizationJune 2008

.

Mike McBride


Multicast deployment and standardization june 2008

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.


Multicast in the ietf

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


Multicast deployment and standardization june 2008

PIM

.


Multicast deployment and standardization june 2008

PIM

  • PIM-SM draft complete

  • PIM WG now working on PIM improvements

    • draft-farinacci-pim-port-00

      • Dino Farinacci


Pim port problem statement

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


Solution statement

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


New hello options

New Hello Options


Connection establishment

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”


Receiving jps in transport mode

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


Mboned

MBONED

.


Mboned1

MBONED

  • draft-ycai-mboned-mvpn-pim-deploy-02

  • draft-ietf-mboned-auto-multicast-08


Draft ycai mboned mvpn pim deploy 02

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


Multicast vpn scalability example

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


Auto multicast tunneling amt

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


L3vpn

L3VPN

.


L3vpn1

L3VPN

  • draft-ietf-l3vpn-2547bis-mcast-06

  • draft-rosen-l3vpn-mvpn-profiles-00


Cisco mvpn strategy

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


Multicast deployment and standardization june 2008

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


Mvpn next generation

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


Multicast deployment and standardization june 2008

MPLS

.


Multicast deployment and standardization june 2008

LSM


Multicast ldp based multicast vpn default mdt

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


Multicast ldp based multicast vpn default mdt1

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


Multicast ldp based multicast vpn default mdt2

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


P2mp rsvp te signaling details

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


P2mp rsvp te signaling details1

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


P2mp rsvp te forwarding

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


Multicast deployment and standardization june 2008

MSEC

.


Gdoi update draft

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.


Secure groups

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


Deliver keys to all group members

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


Group hug vs key server methods

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


Key server method

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


Mobopts

MOBOPTS

.


Mobile multicast

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


Background terminology

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)


Mobile multicast1

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


Multicast delivery method

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


Multicast delivery method1

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


Mobile access router overview

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


Mar vehicle network example

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


Multicast deployment and standardization june 2008

ANCP

.


Ancp in cisco s reference model

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


Ancp status

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


Ancp status multicast use case

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)


Ancp use case example application triggered mcast

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


Multicast in other sdos

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


  • Login