Multicast im Überblick: Denkbare Kommunikationsarten: one-to-one one-to-many many-to-many ? many-to-one ? ---- Das Broadcast Dilemma. ---- Wie löst man daß? Eigentlich eine Triviale Idee: * eigener Adressbereich * RFC 1112 "Host Extensions for IP Multicasting", August 1989. * RFC 1458 "Requirements for Multicast Protocols", May 1993. * UDP, Reliable Multicast * Erstmals 1993 in BSD 4.4 implementiert ---- "Class D" / Multicast Addressbereich Bit --> 0 31 Address Range: +-+----------------------------+ |0| Class A Address | 0.0.0.0 - 127.255.255.255 +-+----------------------------+ +-+-+--------------------------+ |1 0| Class B Address | 128.0.0.0 - 191.255.255.255 +-+-+--------------------------+ +-+-+-+------------------------+ |1 1 0| Class C Address | 192.0.0.0 - 223.255.255.255 +-+-+-+------------------------+ +-+-+-+-+----------------------+ |1 1 1 0| MULTICAST Address | 224.0.0.0 - 239.255.255.255 +-+-+-+-+----------------------+ +-+-+-+-+-+--------------------+ |1 1 1 1 0| Reserved | 240.0.0.0 - 247.255.255.255 +-+-+-+-+-+--------------------+ ---- Problem: WAN Routing ... Bisher nicht endgültig gelößt. ---- Problem: Scoping Ansatz 1: Auf IP-Ebene Well known groups: * 224.0.0.1 all-hosts * 224.0.0.2 all-routers * 224.0.0.4 all DVMRP routers * 224.0.0.5 all OSPF routers * 224.0.0.13 all PIM routers * 224.0.0/24local purposes 239/8 "administrative scoping" -> "Administratively Scoped IP Multicast". RfC 2365 239.255.0.0/16 local-scope 239.192/14 organizational scoping (MZAP, the Multicast-Scope Zone Announcement Protocol, RFC 2776) -> Bisher eigentlich nur UU.net -> wird i.d.R. gefiltert GLOP -> RfC 2770 -> GLOP bist keine Abkürzung -> 233/8 ~ AS - Nummer +0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |------233------|----------16 bits AS-----------|--local bits---| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ansatz 2: TTL scoping TTL. TTL Scope ---------------------------------------------------------------------- 0 Restricted to the same host. Won't be output by any interface. 1 Restricted to the same subnet. Won't be forwarded by a router. <32 Restricted to the same site, organization or department. <64 Restricted to the same region. <128 Restricted to the same continent. <255 Unrestricted in scope. Global. --- Senden: Eigentlich Ganz einfach Aber: - TTL setzen - Gruppe herausfinden - Gruppe joinen Beispielprogramm: int main(void) {   const int TTL=64;   char buffer[BUFFSIZE];   const int v_off=0, v_on=1;   struct sockaddr_in to;   struct ip_mreq multiaddr;   int m;   int sock = socket(AF_INET, SOCK_DGRAM, 0);   // Join a multicast group 224.1.1.1 on all interfaces   multiaddr.imr_multiaddr.s_addr = htonl(0xe0010104); // 224.1.1.1   multiaddr.imr_interface.s_addr = htonl(INADDR_ANY);   setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP,                  &multiaddr, sizeof(multiaddr));   setsockopt(sock, IPPROTO_IP, IP_MULTICAST_TTL,                  &TTL, sizeof(TTL));   // setup the destination address of 224.1.1.1 and UDP port 2007   to.sin_family = AF_INET;   to.sin_addr.s_addr = htonl(0xe0010104);   to.sin_port = htons(2007);   // write some data   for(m=0;m<1000000;m++)   {     sendto(sock,buffer,BUFFSIZE, 0,            (const struct sockaddr*)&to,sizeof(to));   }   // tell router we are no longer interested in this group   close(sock); } ---- Empfangen: Fast Einfach. - eigentlich nur Gruppe joinen. -> macht der Kernel mit IGMP -> Exkurs: Broadcast/LAN/Ethernet -> vom Standpunkt der Anwendung ist Einfach, aber UDP ---- Im LAN: IGMP RfC 2236 MAC: 48 bits multicast prefix: 01:00:5E in hexadecimal, and the next bit must be zero. -> 23 bits -> 28 independent bits in a Class D address -> 5 bits are "lost" ---- Problem: Routing -> Sparse Mode vs Dense Mode DVMRP (Distance Vector Multicast Routing Protocol) MOSPF (Multicast Extensions to OSPF -Open Shortest Path First-), RfC 1583, 1584 PIM-DM (Protocol-Independent Multicast Dense Mode) PIM-SM (Protocol Independent Multicast Sparse Mode), RfC 2117 CBT (Core Based Trees) RfC 2201 ---- Reliable Multicast * NACK based * ACK based http://www.tascnets.com/mist/doc/mcpCompare.html http://research.ivv.nasa.gov/RMP/links.html http://hill.lut.ac.uk/DS-Archive/MTP.html ---- What IETF working groups deal with multicast ? * Audio Video Transportor AVT, deals with streaming audio, video and multimedia using the Real Time Protocol (RTP). * Reliable Multicast Transportor RMT, deals with reliable transport proposals. * MALLOC deals with one means of actively managing the multicast address space. * BGMP deals with the Border Gateway Multicast Protocol, the supposed long term solution for multicast inter-domain routing. The MSDPgroup deals with MSDP, the current solution for inter-domain multicast routing. * MBONED deals with issues of MBone deployment, and tends to have the most discussion about operational multicast issues. * IDMR deals with Inter-Domain Multicast Routing, with IGMP, and also with DVMRP. * Other multicast routing issues are dealt with by the PIMand MOSPFgroups. * There is an IRTF Working Group on Secure Multicast. * SSM working group deals with Source Specific Multicasting, the latest proposal for removing complexity from PIM-SM and thereby making multicast more practical. ---- MBone Statistik http://www.caida.org/tools/measurement/mantra/ MBONE Router on FreeBSD http://www.cs.ndsu.nodak.edu/~tinguely/mbone-freebsd/mrouted.html Linux-Mrouted-MiniHOWTO http://www.jukie.net/~bart/multicast/Linux-Mrouted-MiniHOWTO.html Multicast over TCP/IP HOWTO http://linuxdoc.org/HOWTO/Multicast-HOWTO.html evtl. route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 ---- Protokolle: * RTP Real Time Protocol * RTCP Real Time Control Protocol -> RfC 1889f Real Time Transport Protocol 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * V indicates the version of RTP used * P indicates the padding, a byte not used at bottom packet to reach the parity packet dimension * X is the presence of the header extension * CC field is the number of CSRC identifiers following the fixed header. CSRC field are used, for example, in conference case * M is a marker bit * PT payload type Multicast in der Praxis: MP3-over-RTP * lame * rtptools * quicktime * freeamp http://www.freeamp.org/ http://www.live.com/multikit/winamp-plugin.html http://www.live.com/multikit/playRTPMPEG.html http://www.live.com/ http://obs.freeamp.org/