• Save
IPv4 Multicast Application Development
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

IPv4 Multicast Application Development

on

  • 7,397 views

Multicast Intro and API Overview

Multicast Intro and API Overview

Statistics

Views

Total Views
7,397
Views on SlideShare
7,391
Embed Views
6

Actions

Likes
3
Downloads
0
Comments
0

3 Embeds 6

http://www.slideshare.net 4
http://www.techgig.com 1
http://115.112.206.131 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

IPv4 Multicast Application Development Presentation Transcript

  • 1. IP Multicast Application Development BOF Bob Quinn Stardust Technologies, Inc. February 8, 1998
  • 2. Agenda
    • What are the Challenges?
    • What Applications are possible?
    • What is Multicast ?
    • What are their Requirements ?
    • What APIs are available?
    • What are the Solutions?
  • 3. IP Multicast is...
    • A protocol mechanism:
      • that enables the Network to send a single data stream to multiple recipients
    • An address range:
      • that comprises the Class D IP addresses (224.0.0.0 through 239.255.255.255)
    • An infrastructure:
      • that support the protocols, manage state and traffic and addresses
  • 4. IP Multicast in Action Multicast Sender Multicast Routers Data Replicated Multicast Receivers Entities: Actions: Single Data Send Data Propagated to Receivers Data Pruned where no Receivers
  • 5. Multicast Application Categories
    • One-to-Many
      • Uni-directional traffic
      • Only a single Sender and Multiple Receivers
    • Many-to-Many
      • Bi-directional traffic
      • Each Sender may also be a Receiver
  • 6. Multicast Application Sketches
    • Any application with a UDP (or raw) socket can Send to a multicast address
      • By default, however, the TTL is set to 1
      • TTL requires modification to traverse router(s)
    • To receive multicast traffic, UDP socket must join a group
      • Joining a group initiates IGMP traffic
    • All multicast traffic “loops-back” by default
  • 7. Original Multicast API
    • Described in the readme for the original 4.3 BSD UNIX Multicast implementation by Steve Deering (author of RFC 1112)
      • See http://www.kohala.com/~rstevens/mcast.api.txt
      • Beware that socket option values differ in current implementations
    • APIs use setsockopt() Sockets function and mirror the simplicity of Internet Group Management Protocol (IGMP)
  • 8. Join Multicast Group
    • This is (arguably) the most significant API
      • To receive multicast traffic use setsockopt() optname = IP_ADD_MEMBERSHIP
      • Initiates IGMP “Host Membership Report”
    Int setsockopt( SOCKET s, int level, int optname, const char FAR*optval, int optlen); /* The structure used to add and drop multicast addresses */ typedef struct ip_mreq { struct in_addr imr_multiaddr; /* multicast group to join */ struct in_addr imr_interface; /* interface to join on */ }IP_MREQ;
  • 9. IGMP v1 in Action
    • When a Multicast receiver joins a group IGMP Host Membership Report generated
      • IGMP Packet Format (as defined by RFC 1112)
    Muliicast Receiver joins group Multicast Router stores multicast address Router protocol shares group membership info with other routers. IGMP Host Membership Report (type = 2) sent to group address when application joins group 0 32 8 16 24 version type <unused> checksum Multicast Group Address
  • 10. IGMP v1 in Action
    • Router and hosts transparently maintain the group membership
    Muliicast Receiver joins group Multicast Router stores multicast address After random timer expires and no other responses seen,group member responds with another Host Membership Report After timeout, Router checks for current members by sending Host Membership Query (type=1) to “All Hosts” group (224.0.0.1)
  • 11. Other Sockets Multicast APIs
    • These other multicast APIs are also significant (some more than others):
      • IP_MULTICAST_IF : Join a multicast group on a specific interface
      • IP_MULTICAST_TTL : Assign IP Time-to-Live value
      • IP_MULTICAST_LOOP : Disable multicast loopback (on by default)
      • IP_DROP_MEMBERSHIP : Leave a multicast group
  • 12. Multicast API Subtleties
    • It should be possible to have either:
      • same socket join multiple multicast groups
      • multiple sockets join same group on different port numbers
      • multiple sockets join same group on same port
    • However, implementations differ:
      • Bottom Line: To be safe, don’t share resources
  • 13. Sample Multicast Applications
    • Sender and Receiver application pair:
      • Sender (server) multicasts non-descript data
      • Receiver (client) receives it
    • All standard multicast APIs illustrated
      • compatible with BSD Sockets and WinSock
    • Two applications could be combined:
      • using sharable data (other than the current time) could create a many-to-many application
  • 14. Get a UDP socket
    • Necessary in both sender and receiver
      • This sample is WinSock-compatible, so uses WSAGetLastError() in place of errno
    /* Get a datagram socket */ hSocket = socket(AF_INET, SOCK_DGRAM, 0); if (hSocket == INVALID_SOCKET) { printf (&quot;socket() failed, Err: %d &quot;, WSAGetLastError()); return(-1); }
  • 15. Name the socket
    • Calling bind() is only necessary in receiver
      • BSD Sockets doesn’t require this, but Microsoft WinSock implementations do
    /* Name the socket (assign port number to receive on) */ stLclAddr.sin_family = AF_INET; stLclAddr.sin_addr.s_addr = htonl(INADDR_ANY); stLclAddr.sin_port = htons(nPort); nRet = bind(hSocket, (struct sockaddr*) &stLclAddr, sizeof(stLclAddr)); if (nRet == SOCKET_ERROR) { printf (&quot;bind() port: %d failed, Err: %d &quot;, nPort, WSAGetLastError()); }
  • 16. Join the Multicast Group
    • This is only necessary in a receiver
      • As mentioned earlier, this initiates IGMP traffic that tells the local router about membership
    /* Join the multicast group so we can receive from it */ stMreq.imr_multiaddr.s_addr = inet_addr(achMCAddr); stMreq.imr_interface.s_addr = INADDR_ANY; nRet = setsockopt(hSocket, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char *)&stMreq, sizeof(stMreq)); if (nRet == SOCKET_ERROR) { printf(&quot;IP_ADD_MEMBERSHIP address %s failed, Err: %d &quot;, achMCAddr, WSAGetLastError()); }
  • 17. Receive Multicast Data
    • This sample blocks on recvfrom() waiting for data to arrive, then processes it
    for (;;) { int addr_size = sizeof(struct sockaddr_in); nRet = recvfrom(hSocket, achInBuf, BUFSIZE, 0, (struct sockaddr*)&stSrcAddr, &addr_size); if (nRet < 0) { printf (&quot;recvfrom() failed, Error: %d &quot;, WSAGetLastError()); break; } << process data received >> } /* end for(;;) */
  • 18. Leave the Multicast Group
    • When complete, receiver leaves the group
      • With IGMP v1 this is a noop, but with IGMP v2 it actually sends a Leave Group message
    /* Leave the multicast group */ stMreq.imr_multiaddr.s_addr = inet_addr(achMCAddr); stMreq.imr_interface.s_addr = INADDR_ANY; nRet = setsockopt(hSocket, IPPROTO_IP, IP_DROP_MEMBERSHIP, (char *)&stMreq, sizeof(stMreq)); if (nRet == SOCKET_ERROR) { printf (&quot;IP_DROP_MEMBERSHIP address %s failed, Err: %d &quot;, achMCAddr, WSAGetLastError()); } /* Close the socket */ closesocket(hSocket);
  • 19. In the Sender...
    • Set the TTL -- the scope of the multicast
        • 0: restricted to the same host
        • 1: restricted to the same subnet (default value)
        • 32: restricted to the same site
        • 64: restricted to the same region
        • 128: restricted to the same continent
        • 255: unrestricted
    /* Set IP TTL to traverse up to multiple routers */ nRet = setsockopt(hSocket, IPPROTO_IP, IP_MULTICAST_TTL, (char *)&lTTL, sizeof(lTTL)); if (nRet == SOCKET_ERROR) { printf (&quot;setsockopt() IP_MULTICAST_TTL failed, Err: %d &quot;, WSAGetLastError()); }
  • 20. Disable Loopback
    • Sender may want to disable loopback only if it is also a receiver (member of group)
      • Moot point on Microsoft stacks, none of which support this option
    /* Disable loopback */ fFlag = FALSE; nRet = setsockopt(hSocket, IPPROTO_IP, IP_MULTICAST_LOOP, (char *)&fFlag, sizeof(fFlag)); if (nRet == SOCKET_ERROR) { printf (&quot;setsockopt() IP_MULTICAST_LOOP failed, Err: %d &quot;, WSAGetLastError()); }
  • 21. Send to Multicast Address
    • Send on UDP socket won’t fail
      • generally true, but especially with multicast
    /* send to destination multicast address */ stDstAddr.sin_family = AF_INET; stDstAddr.sin_addr.s_addr = inet_addr(achMCAddr); stDstAddr.sin_port = htons(nPort); nRet = sendto(hSocket, (char *)&achBuf, sizeof(achBuf), 0, (struct sockaddr*)&stDstAddr, sizeof(stDstAddr)); if (nRet < 0) { printf (&quot;sendto() failed, Error: %d &quot;, WSAGetLastError()); }
  • 22. IGMP v2
    • Features: <IGMPv2: ftp://ds.internic.net/rfc/rfc2236.txt>
      • Leave Group message mapped to IP_DROP_MEMBERSHIP API
        • Particularly important on dialups to kill traffic
      • Compatible with IGMP v1
        • Version and Type Fields combined
      • Variable Response Delays in Queries
        • Router Alert option set in all msgs
    • Now widely implemented
      • e.g. Microsoft TCP/IP (but watch for bug)
  • 23. IGMP V2
    • Message Types:
      • 0x11 - Membership Query
      • 0x16 - Version 2 Membership Report
      • 0x17 - Leave Group
      • 0x12 - Version 1 Membership Report (for backward compatibility)
    0 32 8 16 24 type Max respns time checksum Multicast Group Address IP Router Alert option (RFC 2113) enabled in all messages
  • 24. Other APIs
    • Apple Open Transport APIs
      • Modeled after standard BSD Sockets APIs
    • Windows Sockets version 2
      • WinSock supports standard BSD APIs
      • WinSock 2 also has “protocol-independent” multipoint APIs that support IP multicast as well as stricture multipoint protocols (e.g. ATM)
      • For samples see http://www.ipmulticast.com/cgi-bin/ipmulticast/wpform.pl
  • 25. Multicast Application Similarities & Differences
    • Many varied multicast applications possible
    • All use the same basic APIs
    • Most differ in their service requirements:
      • The basic IP multicast implementation and APIs enable simple datagram applications
      • Many applications require various reliability services and feedback mechanisms, which standard UDP and IP multicast do not themselves provide
  • 26. Range of Application Requirements
    • Delay and Loss Tolerance are key factors
    Delay In tolerant Delay Tolerant Loss Tolerant Loss In tolerant Audio/Video Conferencing Distributed Interactive Simulations Audio/Video Streaming File Distribution Non-Essential Data: - Headline News, - Sports Scores - Weather Updates - Session Directories Stock Info & Online Auction Whiteboard Sharing Resource Discovery
  • 27. QoS not tied to Multicast
    • Quality of Service (QoS) parameters
      • Delay between sending and receiving
      • Delay Variability (jitter)
      • Bandwidth usage
    • These are not strictly Multicast related
      • Differentiated Services and Resource Reservation are separate issues with their own protocols, algorithms, architectures and APIs (e.g. RSVP, 802.1p, CBQ, IP TOS, etc.)
  • 28. Reliability Requirements
    • Data Recovery or Loss Avoidance are key reliability requirements for many multicast applications
    • Data Ordering (without duplicates) is another
    • One might immediately think of using TCP’s reliable data delivery mechanisms, since TCP provides exactly these services
  • 29. Can Reliable Multicast Protocols use TCP model?
    • TCP is “sender-based”: Receivers return acknowledgements (with flow window)
      • Model results in ACK implosion with multicast
    Multicast sender sends a single message Multicast receivers simultaneously respond with a storm of ACKs
  • 30. Multicast protocols are Receiver-Based
    • The implosion problem can be reduced by using Negative Acks (NAKS)
      • but NAK implosion potential still exists ...
    Multicast sender sends a single message Multicast receivers respond with NAKs (only) when they detect missing data
  • 31. Shared Recovery
    • When loss detected, use timer and leverage multicast’s advantage of shared traffic:
      • Start random timer
      • Watch for NAKs sent by others
      • Watch for retransmissions
    • This is analogous to how IGMP hosts respond to Host Membership Requests, and congestion avoidance measures in TCP
  • 32. Local Recovery
    • Allow Local Agents to receive NAKs and send retransmissions on behalf of sender
      • Who should the agents be?
        • Need to detect and locate agents close to the “crying babies”
      • Need to handle Agent disconnects
        • Requires detection of disconnect
        • Requires designation of new agent
    • Effective, but not a simple solution
  • 33. Local Recovery in Action Multicast Sender Multicast Routers 3) Data Retransmitted by Recovery Designates Multicast Receivers Entities: Actions: 1) NAK Sent by Receivers after missing data detected 2) NAK detected by Recovery Designates Local Recovery Designates
  • 34. Send Redundant Data
    • Trade-off: More bandwidth = More reliable
    • Example Strategies:
      • FEC: Forward Error Correction
        • Can reduce overhead by sending FEC only in retransmissions
        • FEC striped across multiple address streams, can potentially send at a faster data rate
        • FEC only thing that works when no “back-channel” (e.g. one-way satellite, IPoVBI, pagers, etc.)
      • “ Round-Robin” retransmissions
  • 35. FEC techniques Data 7 Data 5 Data 3 Data 1 Data 2 ta 4 6 D Dat Data 8 “ Striped” Data Data 7 Parity4 Data with Parity Data 6 Parity3 Data 5 Parity2 Data 4 Parity1 These representations are simplified versions of the real thing and there are many different algorithms, but these give some FEC techniques. Notice that data is spread over time, to avoid fate sharing (due to burst errors). time time
  • 36. Rate Adaptive
    • Reduce data rate when loss increased
      • When NAKs increase, slow sender down
    • A few rotten apples...
      • All receivers limited by worst case
      • A lower data rate means lower quality
    • Limited usefulness to apps that:
      • Are tolerant of loss, or of delay
      • Have multiple choices between codecs
  • 37. Send Layered Data
    • Multiple encodings combined
      • The more data received, the better the quality
      • Analogous to receiving a monophonic signal from FM stereo radio when the signal is weak
    • One signal fits all
      • Scales very nicely on heterogeneous net
    • Limited applicability
      • Not useful for loss intolerant apps!
  • 38. Reliable Multicast Transports - A Summary
    • Development of a reliable multicast transport protocol is a hot research topic
      • See http://research.ivv.nasa.gov/RMP/links.html
      • See http://www.isi.edu/people/katia/transport-related.ps.gz
    • Some commercial implementations:
      • GlobalCast and StarBurst Communications
    • Consensus is there’s no universal solution:
      • Protocols will be application-specific
      • Utilize various techniques as appropriate
  • 39. Other Issues with Multicast
    • Lack of multicast-capable infrastructure
    • No standard for dynamic address allocation
    • No mechanism to find multicast routers
    • Unable to limit senders
    • Unable to authenticate senders or receivers
    • No standard for authentication or key exchange
    • No standard for firewall traversal
    • Scoping with TTL insufficient
    • Managing many-to-many is difficult (scaling problem)
    • Transmission on heterogeneous nets is problematic
    • Tools for Debugging
  • 40. Solutions in the works
    • More Multicast-capable routers
    • IGMP version 3
    • Domain-Wide Multicast Reports
    • MDHCP and infrastructure (MASC, et al)
    • Reliable Multicast Implementations (IRTF)
    • Firewall traversal standards (see AFT WG)
    • Administratively Scoped Multicast
    • Multicast Router Advertisements
  • 41. More Multicast Infrastructure
    • Most Dial-up Servers now shipping have “IGMP Proxy” support
    • Education of ISPs and Corporate Network Managers is underway
      • FUD due to misconceptions & inexperience
    • Content will be the Killer Application!
      • Infrastructure becoming less of a problem
      • Demand will increase support from ISPs
      • IPMI is making headway!
  • 42. IGMP v3
    • Significant update will bring new services:
      • Source Filtering (squelch senders)
    • Still early in specification development, but so far IGMP v3 is significantly more complex than its predecessors
      • See IGMP v3: draft-ietf-idmr-igmp-v3-00.txt
    • Sample API:
    int IPMulticastListen(socket, interface, // interface as in m_req multicast-address, // group address as in m_req filter-mode, // INCLUDE or EXCLUDE source-list); // list (<64) of source addresses
  • 43. Domain-Wide Group Membership Reports
    • A routing (infrastructure) protocol that may back-end IGMP, to inform inter-domain routers of group memberships in domains
      • See DWR: draft-ietf-idmr-membership-reports-00.txt
  • 44. Multicast Address Management Protocols
    • Allocate multicast addresses, and manage their domains
      • MDHCP : Multicast Dynamic Host Configuration Protocol responds to host requests
      • AAP : Address Allocation Protocol
      • MASC: Multicast Address Set Claim Protocol
    • Also includes APIs, which will be available in NT Beta 2
  • 45. Multicast Address Management Architecture MDHCP router MASC router Multicast Address Domain MASC to other Domains Client Client Server listening on well-known multicast address MDHCP Unicast MDHCP Multicast AAP or other protocols provide address ranges See http://north.east.isi.edu/malloc/ for more information
  • 46. MDHCP APIs
    • Enumerate the Scopes
      • Scope list entries include Scope ID value, Server Address and a description
    int MDhcpEnumerateScopes( IN OUT SCOPE *ScopeList, IN OUT int *ScopeListLen, OUT int *ScopeCount); typedef struct scope { int ScopeId, IP_ADDR ServerIpAddress; STRING ScopeDescription; } SCOPE;
  • 47. MDHCP APIs
    • Request an Address (or more than one)
      • Each address has a “Lease” time and a Scope (each of which may be requested).
    int MDhcpRequestAddress( IN OUT REQUEST_ID *RequestUID, IN SCOPE *Scope, IN LEASE_INFO *AddrRequest, IN OUT LEASE_INFO *AddrResponse); typedef struct lease_info { TIME StartTime, TIME EndTime, int TTL; int AddrCount; IP_ADDR Address[1]; } LEASE_INFO;
  • 48. MDHCP APIs
    • Renew & Release Addresses
      • Prototypes for these APIs very similar to the Address Request function call
    int MDhcpRenewAddress( IN OUT REQUEST_ID *RequestUID, IN SCOPE *Scope, IN LEASE_INFO *RenewRequest, IN OUT LEASE_INFO *RenewResponse); int MDhcpReleaseAddress( IN OUT REQUEST_ID *RequestUID, IN SCOPE *Scope, IN int *ReleaseRequest);
  • 49. Conclusions
    • Simple Multicast applications are easy
      • There are some holes, but most of what’s needed is available
    • Complexity increases dramatically when service requirements increase, and there are some significant standards still missing
    • Development of solutions is underway!
      • Reliable Multicast, Address Mgmt, Security, etc.
  • 50. References
    • Writing IP Multicast-enabled Applications, an IPMI White Paper: http://www.ipmulticast.com/cgi-bin/ipmulticast/wpform.pl
    • Quinn, B., Internet Multicasting, Dr. Dobbs Journal, Oct ‘97 http://www.ddj.com/ddj/1997/1997_10/quin.htm
    • Obraczka, K., Multicast Transport Protocols: A Survey and Taxonomy , IEEE Communications Magazine, Jan ‘98 (Vol. 36 No. 1)
    • Windows Sockets Network Programming, http://www.sockets.com/ch16.htm
    • Multicast Address Allocation: http://north.east.isi.edu/malloc
    • ftp://ftp.ietf.org/internet-drafts/draft-bradner-multicast-problem-00.txt
    • Multicast Debugging Handbook: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-mdh-00.txt
    • IGMPv1: ftp://ds.internic.net/rfc/rfc1112.txt
    • IGMPv2: ftp://ds.internic.net/rfc/rfc2236.txt
    • IGMPv3: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-00.txt
    • WinSock 2 API: ftp://ftp.microsoft.com/bussys/winsock/winsock2/