Transcript Before You Begin: Assign Information Classification

Multicast Deployment
and Standardization
June 2008
.
Mike McBride
© 2008 Cisco Systems, Inc. All rights reserved.
1
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.
© 2008 Cisco Systems, Inc. All rights reserved.
2
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
© 2008 Cisco Systems, Inc. All rights reserved.
3
PIM
.
© 2008 Cisco Systems, Inc. All rights reserved.
4
PIM
 PIM-SM draft complete
 PIM WG now working on PIM improvements
–draft-farinacci-pim-port-00
• Dino Farinacci
© 2008 Cisco Systems, Inc. All rights reserved.
5
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
© 2008 Cisco Systems, Inc. All rights reserved.
6
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
© 2008 Cisco Systems, Inc. All rights reserved.
7
New Hello Options
© 2008 Cisco Systems, Inc. All rights reserved.
8
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”
© 2008 Cisco Systems, Inc. All rights reserved.
9
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
© 2008 Cisco Systems, Inc. All rights reserved.
10
MBONED
.
© 2008 Cisco Systems, Inc. All rights reserved.
11
MBONED
 draft-ycai-mboned-mvpn-pim-deploy-02
 draft-ietf-mboned-auto-multicast-08
© 2008 Cisco Systems, Inc. All rights reserved.
12
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
© 2008 Cisco Systems, Inc. All rights reserved.
13
Multicast VPN Scalability Example
Input Pa ra meters
N umber of P interfa ces
N umber of PE P- PIM interfa ces
N umber of PE C- PIMinterfa ces
N umber of PE
N umber of M- VPN
Da ta MDT/ VPN
Scenario1:
default MDT: PIM SSM
data MDT: PIM SSM
Scenario2:
default MDT: PIM SM with
SPT switchover
data MDT: PIM SSM
Scenario3:
default MDT: PIM SM
without SPT switchover
data MDT: PIM SSM
Input
5
2
1
20
100
2
(S,G) state
(*,G) state
total (S,G) and (*,G) state
Default MDT PIM neighbours
Default MDT
Inband MDT
Outband MDT
(S,G) state
(*,G) state
Default MDT PIM neighbours
Default MDT
Inband MDT
Outband MDT
(S,G) state
(*,G) state
Default MDT PIM neighbours
Default MDT
Inband MDT
Outband MDT
© 2008 Cisco Systems, Inc. All rights reserved.
PE PIM
State
Default MDT/ PE
Data MDT/ PE
PIM SSM
2000
0
2000
1900
100
PIM SSM
4000
0
4000
3800
200
PIM SM w/ SPT
switchover
2000
100
2100
1900
100
PIM SSM
4000
0
4000
3800
200
PIM SM w/ o SPT
switchover
100
100
200
1900
100
PIM SSM
4000
0
4000
3800
200
Total MDT
State/ PE
Default MDT: PIM
SSM + Data MDT:
PIM SSM
6000
0
6000
1900
100
3800
200
Default MDT: PIM
SM w/ SPT
switchover + Data
MDT: PIM SSM
6000
100
6100
1900
100
3800
200
Default MDT: PIM
SM w/ o SPT
switchover + Data
MDT: PIM SSM
4100
100
4200
1900
100
3800
200
P PIM
State
Default MDT/ RP
or P
PIM SSM
2000
0
2000
NA
NA
NA
NA
PIM SM w/ SPT
switchover
2000
100
2100
NA
NA
NA
NA
PIM SM w/ o SPT
switchover
2000
100
2100
NA
NA
NA
NA
Data MDT/ RP or
P
Total MDT State/ P
Default MDT: PIM
SSM + Data MDT:
PIM SSM
PIM SSM
4000
6000
0
0
4000
6000
NA
NA
NA
NA
NA
NA
NA
NA
Default MDT: PIM
SM w/ SPT
switchover + Data
PIM SSM
MDT: PIM SSM
4000
6000
0
100
4000
6100
NA
NA
NA
NA
NA
NA
NA
NA
Default MDT: PIM
SM w/ o SPT
switchover + Data
PIM SSM
MDT: PIM SSM
4000
6000
0
100
4000
6100
NA
NA
NA
NA
NA
NA
NA
NA 14
Auto Multicast Tunneling (AMT)
AMT Relay
 Tunnel through non-multicast enabled network
segment
AMT Gateway
AMT Tunnel
–Draft in IETF ; Primarily for SSM
–GRE or UDP encap
–Relay uses well known ‘anycast’ address
multicast
capable
 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
© 2008 Cisco Systems, Inc. All rights reserved.
NAT
Non
Non
multicast
multicast
HAG
15
L3VPN
.
© 2008 Cisco Systems, Inc. All rights reserved.
16
L3VPN
 draft-ietf-l3vpn-2547bis-mcast-06
 draft-rosen-l3vpn-mvpn-profiles-00
© 2008 Cisco Systems, Inc. All rights reserved.
17
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
© 2008 Cisco Systems, Inc. All rights reserved.
18
MVPN using PIM/GRE vs MVPN MLDP/MPLS
Receiver 4
Join high
bandwidth source
MVPN domain model is not
dependent on forwarding used.
CE
A
CE
CE
Receiver 1
B1
PE
A
San
Francisco
PE
PE
MPLS VPN
Core
B
Default
MDT
E
Data
MDT
PE
For High
Bandwidth
traffic only.
D
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
Multicast
VPN
For low
Bandwidth &
control
traffic only.
Los
Angeles
CE
New York
B2
There is no difference except
for core tree-building and
encapsulation
C
CE
PE
D
C
Receiver 3
High bandwidth
multicast source
Dallas
CE
Join high
bandwidth source
© 2008 Cisco Systems, Inc. All rights reserved.
Receiver 2
19
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
© 2008 Cisco Systems, Inc. All rights reserved.
20
MPLS
.
© 2008 Cisco Systems, Inc. All rights reserved.
21
LSM
LSM Protocols
Distinct properties
MLDP
Dynamic Tree Building suitable for broad set of Multicast
Applications
draft-ietf-mpls-ldp-p2mp-04
FRR as optional capability
Receiver driven dynamic tree building approach
P2MP RSVP-TE
Deterministic bandwidth guarantees over entire tree
RFC 4875
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.
© 2008 Cisco Systems, Inc. All rights reserved.
22
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.
PIM-V4 VRF Config:
ip vrf RED
mdt default 239.1.1.1 mp2mp 4.4.4.4
• Upstream path is setup like a P2P LSP to the upstream router.
M-LDP Label
Advertisement:
FEC= FEC-MDT
RPFv=P-4
Label=(20)
(21) Upstrm
VPNv4
CE-1
PE-1
M-LDP Label
Advertisement:
FEC= FEC-MDT
RPFv=P-4
Label=(20)
(21) Upstrm
VPNv4
CE-2
Content
Receiver
PE-2
P-4
MPLS Core
M-LDP Label
Advertisement:
FEC= FEC-MDT
RPFv=P-4
MP2MP LSP
Label =(30)
“Root”
Label =(31) Upstrm
Content
Source
PIM-V4 VRF Config:
ip vrf RED
mdt default 239.1.1.1 mp2mp 4.4.4.4
© 2008 Cisco Systems, Inc. All rights reserved.
PE-3
PIM-V4 VRF Config:
ip vrf RED
mdt default 239.1.1.1 mp2mp 4.4.4.4
VPNv4
CE-3
Content
Receiver
23
Multicast LDP based Multicast VPN (Default-MDT)
IPv4 VPNv4 L20
Label
IPv4
CE-2
Content
IPv4 VPNv4 Receiver
Label
IPv4 VPNv4 L100
Label
PE-2
VPNv4
CE-1
VPNv4
PE-1
P-4
“Pop”
Outer Label
MPLS Core
Content
Source
“Push”
IPv4 VPNv4 L30
Label
PE-3
IPv4 VPNv4
Label
VPNv4
“Swap”
© 2008 Cisco Systems, Inc. All rights reserved.
CE-3
Content
Receiver
24
Multicast LDP based Multicast VPN (Default-MDT)
VPNv4
Content
Receiver
PE-2
VPNv4
CE-1
CE-2
IPv4
PE-1
“Pop”
Inner Label
P-4
MPLS Core
Content
Source
PE-3
IPv4
VPNv4
CE-3
© 2008 Cisco Systems, Inc. All rights reserved.
Content
Receiver
25
P2MP RSVP-TE – Signaling Details
Source
Service Edge
Distribution/
Access
Core
Receiver
Layer 2
Switch
Layer 2
Switch
R4
R6
PE
CE
Receiver
R1
CE
PE
R2
PE
R3
Layer 2
Switch
P
Source
R5
R7
PE
CE
Receiver
Headend sends one PATH message per destination
PATH Message : ERO -> R2-R3-R4
PATH Message : ERO -> R2-R3-R5
© 2008 Cisco Systems, Inc. All rights reserved.
26
P2MP RSVP-TE – Signaling Details
Source
Service Edge
Distribution/
Access
Core
Label Merge
44
33
Layer 2
Switch
Receiver
Layer 2
Switch
R4
R6
PE
CE
Receiver
R1
CE
PE
R2
PE
R3
33
Source
Layer 2
Switch
P
PE
55
R5
R7
CE
Receiver
RESV Messages are sent by Tailend routers;
Communicates labels & reserves BW on each link
RESV Msg Initiated by R4
RESV Msg Initiated by R5
© 2008 Cisco Systems, Inc. All rights reserved.
55
Label Advertisement carries in the RESV Message
27
P2MP RSVP-TE – Forwarding
Source
Service Edge
Distribution/
Access
Core
Receiver
44
33
Layer 2
Switch
R1
CE
PE
R2
PE
R4
R6
PE
CE
Layer 2
Switch
SSM,
PIM-SM,
R3
Receiver
P
PE
Source
PIM-SSM,
R5
55
R7
CE
Layer 2
Switch
Receiver
No PHP ! Need label on tailend PE to identify tree
Multicast Packet
Labeled Packet
© 2008 Cisco Systems, Inc. All rights reserved.
28
MSEC
.
© 2008 Cisco Systems, Inc. All rights reserved.
29
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.
© 2008 Cisco Systems, Inc. All rights reserved.
30
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
© 2008 Cisco Systems, Inc. All rights reserved.
31
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
© 2008 Cisco Systems, Inc. All rights reserved.
32
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
© 2008 Cisco Systems, Inc. All rights reserved.
33
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
© 2008 Cisco Systems, Inc. All rights reserved.
34
MOBOPTS
.
© 2008 Cisco Systems, Inc. All rights reserved.
35
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
© 2008 Cisco Systems, Inc. All rights reserved.
36
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)
© 2008 Cisco Systems, Inc. All rights reserved.
37
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
© 2008 Cisco Systems, Inc. All rights reserved.
38
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
© 2008 Cisco Systems, Inc. All rights reserved.
39
Multicast Delivery Method
Network Replicates
Packet as Needed
One LWAPP Encapsulated
Multicast Packet Out
One Multicast Packet In
LWAPP
Multicast Group
 Improved multicast performance over wireless networks
 Multicast packet replication occurs only at points in the network
where it is required, saving wired network bandwidth
© 2008 Cisco Systems, Inc. All rights reserved.
40
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
© 2008 Cisco Systems, Inc. All rights reserved.
41
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
© 2008 Cisco Systems, Inc. All rights reserved.
42
ANCP
.
© 2008 Cisco Systems, Inc. All rights reserved.
43
ANCP in Cisco’s Reference Model
AF
NASS
CPE
Access Node
(DSLAM)
IP-Edge
(NAS)
RACS
IPTV Source
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
© 2008 Cisco Systems, Inc. All rights reserved.
44
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
© 2008 Cisco Systems, Inc. All rights reserved.
45
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)
© 2008 Cisco Systems, Inc. All rights reserved.
46
ANCP Use Case Example:
Application triggered mcast.
Radius
Want channel
CNN
1
DB
2
Channel CNN
RequestFor
subscriber IP A
4
PIM (S,G) Join
6
C4500
Push
5 Multicast (S,G),
aaa.bbb.ccc.ddd
on port X VLAN Y
Entitlement
Server
CP1
Content
response OK to
IP A. Info: S,G
3
Subs A
allowed to
watch CNN ?
IP Content
Delivery
CP2
Multicast Join - OK
7
Gateway
CPn
© 2008 Cisco Systems, Inc. All rights reserved.
47
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
© 2008 Cisco Systems, Inc. All rights reserved.
48
© 2008 Cisco Systems, Inc. All rights reserved.
49