Explicit Multicast (Xcast) MD06 Yuji Imai Fujitsu SGM Rick Boivie IBM CLM Dirk Ooms Alcatel

1
Explicit Multicast (Xcast)MD06 Yuji Imai
FujitsuSGM Rick Boivie IBMCLM Dirk Ooms
Alcatel
2
Multicast applications

• Broadcast-like (one-to-many)
• Multicast of IETF meetings
• Distribution of broadcast TV channels

• Narrowcast-like (few-to-few)
• IP Telephony with conferencing
• Video conferencing
• Real-time collaborative applications
• Multiparty networked games
• Other applications with millions of concurrent
  groups

• Todays multicast schemes support the first case,
  but there may be a better solution for the second
  case
• 'It is believed that a "one size fits all"
  protocol will be unable to meet the requirements
  of all applications'
• - as the Reliable Multicast Transport Group
  said on their web page

3
Cost of Multicast (1)

• Cost of Host Group Model
• multicast addresses must be globally unique gt
  multicast address allocation servers required
  MAAS (multicast address allocation servers),
  MADCAP (client-server), AAP (intradomain), MASC
  (interdomain)
• Cost of Multicast Routing Protocols
• connection state state per group or source-group
  in every node of the tree
• signaling to create this connection state
• source discovery mechanism
• network wide announcement of core node (PIM-SM,
  CBT)
• floodprune nature (DVMRP, PIM-DM)

4
Cost of Multicast (2)
Cost of current multicast per member
OK
costly
Number of members
alternative xcast
5
Cost of Multicast (3)

• New multicast protocols (Simple Multicast,
  Express, PIM Source Only) avoid some of the costs
  (e.g. address allocation), but they still need
  state and signaling per flow.
• Our point is that just as
• Core routers dont keep track of individual TCP
  flows today
• Diffserv suggests that core routers shouldnt
  have to keep track of large numbers of individual
  QOS flows tomorrow
• Its our belief that core routers shouldnt have
  to keep track of large numbers of individual
  multicast flows either.

6
Explicit Multicast (xcast) basics

• "Multiple Destination Option on IPv6",
  draft-imai-mdo6-01.txt
• "Small Group Multicast", draft-boivie-sgm-00.txt
• "Connectionless Multicast", draft-ooms-cl-multicas
  t-01.txt
• "Distributed Core Multicast", draft-blazevic-dcm-m
  obility-00.txt

• explicit list of destinations
• forwarding uses unicast route table
• complementary to current multicast model
• current multicast scales with number of receivers
• xcast scales with the number of sessions
• xcast can lessen the load on current multicast

7
Xcast Advantages

• No multicast address allocation
• No multicast routing protocol needed (intra- nor
  interdomain)
• No state in routers
• No need for a core node (RP)
• Optimal route is taken (even when paths are not
  symmetrical)
• triangular routing avoided
• maximizes network efficiency
• Automatic and immediate reaction to unicast
  reroutes
• Simple (only data plane changes)
• Lends itself to Reliable Transport
• Destination aware simple security and accounting
• Simple transition schemes

8
Xcast Basic Mode Disadvantages

• Overhead in packet header
• More header processing
• n routing look-ups
• on the fly header changes
• Doesnt support large groups
• gtcomplementary to current multicast

9
Xcast Flexibility
gt xcast can adapt to specific network
constraints (access, backbone, LAN, )
10
Why not n times unicast?

• Conferencing for residential users
• access asymmetric
• gt upstream bandwidth is limited
• gt point-to-multipoint mechanism required
• gt xcast is cheap multicast solution
• Examples xDSL, GPRS, cable modem, etc...

Access e.g. xDSL
Sender 1
Access router
Sender 2
2 Mb/s
200 Kb/s
11
Earnest urgent need from a real user

• An anonymous PC-game vendor shipped a multiplayer
  game using unicast UDP to share player status
  information.
• They considered using multicast but had concerns
  about the number of concurrent
• groups that could be supported in the existing
  multicast schemes.
• Currently they have 3000 groups but this number
  is growing every day. And the reflector is
  becoming a bottleneck.

If current multicast schemes are used, the number
of multicast groups in the route table will soon
surpass the number of unicast entries in the
route tables of backbone routers.
12
Partnership
ISP
IT vendor
IRI (JPIX)
ITJIT
IBM
Fujitsu
Research Partners iCAIR/Internet2 W
IDE IIJ Lab SONY CSL EPFL
Alcatel
Communication Equipment vendor
13
Xcast Partners

• iCAIR/Internet2
• WIDE Japanese research consortium
• IIJ Lab research subsidiary of www.iij.ad.jp
  (active in IPv6 community).
• SONY CSL is a SONY Center of Excellence.
• IRI (Internet Research Institute) one of the
  most successful Internet ventures in Japan
  (operates JPIX, Japans largest Internet
  Exchange).
• ITJITsubsidiary company of Nihon Telecom Co.
  (Long Distance Carrier in Japan), serving mainly
  domestic Internet connections.
• Swiss Federal Institute of Technology / Ecole
  Polytechnique Federale de Lausanne (EPFL)

14
MDO6 Prototype
Router3
MDO6
MDO6
PEN4
PEN1
Router2
Router1
MDO6
PEN3
PEN2

• Based on FreeBSD 2.2.8 KAME
• KAME is a IPv6 stack developed by the WIDE
  project
• vic for IPv6 has been ported to MDO6

15
SGM Prototype

• Host piece
• runs on AIX or Windows
• SGM library that
• implements the SGM layer/SGM API
• uses UDP and raw sockets to receivesend SGM
  packets
• a simple application
• Router stub
• an app that runs on AIX (or Windows)
• rolling out on RS/6000s used in the Internet2 DSI
  project

16
CLM Prototype
clm-vic
bottleneck
FreeBSD PC
17
To Dos

• Develop Single Standard
• Work through some unresolved issues
• performance (several ideas exist to enhance
  forwarding)
• gradual deployment (several schemes exist)
• use of bitmap
• header format (L3 or L3.5)
• etc

18
Summary

• Multicast scheme that scales with number of
  sessions
• Complementary to current multicast model
• Simple
• Several groups are working on similar approaches
• "Connectionless Multicast", draft-ooms-cl-multicas
  t-01.txt
• "Small Group Multicast", draft-boivie-sgm-00.txt
• "Multiple Destination option on IPv6",
  draft-imai-mdo6-01.txt
• "Distributed Core Multicast", draft-blazevic-dcm-m
  obility-00.txt

19
Next steps

• We submitted a proposal for a WG charter
  (http//www.alcatel.com/xcast)
• Presented xcast at MADDOGS meeting
• maybe in Internet Area
• main questions were on UDP checksum and IPsec gt
  couple of scenarios possible
• Meeting with Area Directors of Routing and
  Internet areas

20
Proposed Charter

• The Explicit Multicast (xcast) Working Group is
  chartered to define, develop, specify and promote
• principles and mechanisms that allow multi-point
  to multi-point communication that scales with the
• number of sessions.
• The basic idea of xcast is to use an explicit
  list of destinations instead of one logical
  multicast address.
• This approach should be complementary to the
  current multicast schemes. While today's
  multicast
• schemes are scaleable in the sense that they can
  support very large multicast groups, these
  schemes
• are pretty expensive when a network needs to
  support a very large number of distinct multicast
  groups.
• Explicit Multicast complements the existing
  multicast schemes in that it can efficiently
  support very
• large numbers of distinct (small) multicast
  groups and thus can play an important role in
  making
• multicast practical for applications such as IP
  telephony, various conferencing collaborative
• applications, multiparty networked games, etc
• The WG will try to reuse existing control plane
  mechanisms and thus the primary focus of the WG
  will be on data plane mechanisms. Initially an
  end-to-end solution will be developed. Approaches
  for both IPv4 and IPv6 will be defined. The WG
  will specify the necessary protocols or protocol
  extensions.

21
Goals Milestones

• July 2000 Hold first Working Group meeting,
  explain the "charter" and discuss the "Framework
  Document".
• Sept 2000 Submit "Framework Document" to IESG
  (Informational RFC)
• Feb 2001 Submit "Architecture Document" to IESG
  (Informational RFC)
• May 2001 Submit "Protocol Specification for IPv4"
  to IESG (Standards Track)
• May 2001 Submit "Protocol Specification for IPv6"
  to IESG (Standards Track)
• May 2001 Submit "MIB" to IESG (if needed)