Multicast Deployment and Standardization June 2008

© 2008 Cisco Systems, Inc. All rights reserved. 1

Multicast Deployment and StandardizationJune 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.

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

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


PIM

.


PIM

PIM-SM draft complete

PIM WG now working on PIM improvements–draft-farinacci-pim-port-00

• Dino Farinacci


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

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


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

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

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

draft-ietf-mboned-auto-multicast-08


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

Default MDT/PE Data MDT/PETotal MDT State/PE

Default MDT/RP or P

Data MDT/RP or P Total MDT State/P

PIM SSM PIM SSM

Default MDT: PIM SSM + Data MDT:

PIM SSM PIM SSM PIM SSM

Default MDT: PIM SSM + Data MDT:

PIM SSM(S,G) state 2000 4000 6000 2000 4000 6000(*,G) state 0 0 0 0 0 0total (S,G) and (*,G) state 2000 4000 6000 2000 4000 6000Default MDT PIM neighbours 1900 1900 NA NA NADefault MDT 100 100 NA NA NAInband MDT 3800 3800 NA NA NAOutband MDT 200 200 NA NA NA

PIM SM w/ SPT switchover PIM SSM

Default MDT: PIM SM w/ SPT

switchover + Data MDT: PIM SSM

PIM SM w/ SPT switchover PIM SSM

Default MDT: PIM SM w/ SPT


(S,G) state 2000 4000 6000 2000 4000 6000(*,G) state 100 0 100 100 0 100

2100 4000 6100 2100 4000 6100Default MDT PIM neighbours 1900 1900 NA NA NADefault MDT 100 100 NA NA NAInband MDT 3800 3800 NA NA NAOutband MDT 200 200 NA NA NA

PIM SM w/o SPT switchover PIM SSM

Default MDT: PIM SM w/o SPT


PIM SM w/o SPT switchover PIM SSM

Default MDT: PIM SM w/o SPT


(S,G) state 100 4000 4100 2000 4000 6000(*,G) state 100 0 100 100 0 100

200 4000 4200 2100 4000 6100Default MDT PIM neighbours 1900 1900 NA NA NADefault MDT 100 100 NA NA NAInband MDT 3800 3800 NA NA NAOutband MDT 200 200 NA NA NA

Input Parameters InputNumber of P interfaces 5Number of PE P-PIM interfaces 2Number of PE C-PIMinterfaces 1Number of PE 20Number of M-VPN 100Data MDT/VPN 2

Scenario1:default MDT: PIM SSM

data 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

PE PIM State

P PIM State


Auto Multicast Tunneling (AMT)

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

Nonmulticast

multicastcapable

AMT GatewayAMT Gateway

AMT RelayAMT Relay

AMT TunnelAMT Tunnel

Nonmulticast

HAGNAT


L3VPN

.


L3VPN

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

draft-rosen-l3vpn-mvpn-profiles-00


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


Receiver 4Receiver 4

B1

D

A

CECE

CECE

High bandwidth multicast source



C

CECE

CECE

MPLS VPNMPLS VPNCore Core

CECE


PEPEBPEPE

PEPE

EE

PEPEA

PEPED

C

Join highbandwidth source

Join highbandwidth source

CECE

DataDataMDTMDT

For High Bandwidth traffic only.

DefaultDefaultMDTMDTFor low

Bandwidth & control

traffic only.

B2

San Francisco

San Francisco

Los Angeles

Los Angeles

DallasDallas

New YorkNew York

MVPN domain model is not dependent on forwarding used.

MVPN GRE and MVPN MLDP use the same Domain model.

Default-MDT will be thereData-MDT will be therePIM signaling over Default-MDT

There is no difference except for core tree-building and encapsulation

Multicast Multicast VPNVPN

MVPN using PIM/GRE vs MVPN MLDP/MPLS


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


MPLS

.


LSM

LSM Protocols Distinct properties

MLDP

draft-ietf-mpls-ldp-p2mp-04

Dynamic Tree Building suitable for broad set of Multicast Applications

FRR as optional capability

Receiver driven dynamic tree building approach

P2MP RSVP-TE

RFC 4875

Deterministic bandwidth guarantees over entire tree

Head end defined trees

FRR inherent in tree set-up

Useful for Small but significant subset of Multicast Application: Broadcast TV where bandwidth restrictions exist.


Content Content SourceSource

Content Content ReceiverReceiver


PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLS Core

MP2MP LSP“Root”

VPNv4

Multicast LDP based Multicast VPN (Default-MDT)

VPNv4

VPNv4

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


PIM-V4 VRF Config:

ip vrf RED


PIM-V4 VRF Config:

ip vrf RED


PIM-V4 VRF Config:

ip vrf RED


PIM-V4 VRF Config:

ip vrf RED


• All PE’s configured for same VRF derive FEC from configured All PE’s configured for same VRF derive FEC from configured default-mdt group.default-mdt group.

• Downstream path is setup like a normal P2MP LSP.Downstream path is setup like a normal P2MP LSP.

• Upstream path is setup like a P2P LSP to the upstream router.Upstream path is setup like a P2P LSP to the upstream router.

MP2MP Tree Setup Summary

M-LDP Label Advertisement:FEC= FEC-MDT RPFv=P-4

Label =(30)

Label =(31) Upstrm

M-LDP Label Advertisement:FEC= FEC-MDT RPFv=P-4

Label =(30)

Label =(31) Upstrm

M-LDP Label Advertisement:FEC= FEC-MDT

RPFv=P-4Label=(20)

(21) Upstrm


RPFv=P-4Label=(20)

(21) Upstrm


RPFv=P-4Label=(20)

(21) Upstrm


RPFv=P-4Label=(20)

(21) Upstrm





PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLS Core

VPNv4

VPNv4

VPNv4


IPv4 IPv4 L100VPNv4Label

“Push”

IPv4 L20VPNv4Label

IPv4 L30VPNv4Label

“Swap”

“Pop” Outer Label

IPv4 VPNv4Label

IPv4 VPNv4Label





PE-1

PE-2

PE-3

P-4CE-1

CE-2

CE-3

MPLS Core

VPNv4

VPNv4

VPNv4


IPv4

IPv4

“Pop” Inner Label


P2MP RSVP-TE – Signaling Details

SourceSource

ReceiverReceiver

Layer 2Switch

Layer 2Switch

PE

PE

Service EdgeDistribution/

AccessCore

CE

CE

PE

Source Receiver

R1 R2

R4 R6

PR3

R5

CE

R7

ReceiverReceiver

Layer 2Switch

PATH Message : ERO -> R2-R3-R4 PATH Message : ERO -> R2-R3-R5

Headend sends one PATH message per destination

PE


P2MP RSVP-TE – Signaling Details

SourceSource

ReceiverReceiver

Layer 2Switch

Layer 2Switch

PE

PE


AccessCore

CE

CE

PE

Source Receiver

R1 R2

R4 R6

PR3

R5

CE

R7

ReceiverReceiver

Layer 2Switch

Label Merge

RESV Messages are sent by Tailend routers; Communicates labels & reserves BW on each link

PE

RESV Msg Initiated by R4

RESV Msg Initiated by R5

44

55

33

33

55 Label Advertisement carries in the RESV Message


P2MP RSVP-TE – Forwarding

SourceSource

ReceiverReceiver

Layer 2Switch

Layer 2Switch

PE

PE


AccessCore

CE

CE

PE

Source Receiver

R1 R2

R4 R6

PR3

R5

CE

R7

ReceiverReceiverLayer 2Switch

PE

No PHP ! Need label on tailend PE to identify tree

Multicast Packet Labeled Packet

PIM-SSM,

SSM,PIM-SM,

44

55

33


MSEC

.


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

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

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

Security Requirements


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

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

Key Management Protocols


MOBOPTS

.


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

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 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

One Multicast Packet InLWAPP

Encapsulated Packets

Multiple Copies of the Same Multicast PacketEncapsulated with LWAPP

Unicast Packets out to Each AP

Unicast Mechanism


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

One Multicast Packet InLWAPP

Multicast Group

One LWAPP Encapsulated Multicast Packet Out

Network ReplicatesPacket as Needed


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 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

MESH NETWORK


ANCP

.


ANCP in Cisco’s Reference Model

CPE Access Node(DSLAM)

IP-Edge(NAS)

VoD Pump

IPTV Source

AFNASS

ANCP

RACS

• 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

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)

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)


CP1

CP2

CPn

DB

Radius

Want channel CNN Channel CNN

RequestFor subscriber IP A

Subs Aallowed to

watch CNN ?

1

2

5Push

Multicast (S,G),aaa.bbb.ccc.ddd

on port X VLAN Y

6

PIM (S,G) Join

7Multicast Join - OK

4 Content response OK to IP A. Info: S,G

C4500

Gateway

IP Content Delivery

3

ANCP Use Case Example:Application triggered mcast.

EntitlementServer


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


Date post:	15-Jan-2016
Category:	Documents
Upload:	sue
View:	36 times
Download:	0 times

Multicast Deployment and Standardization June 2008

Documents