The Cable Guy - June 2003

  • Article

The Reliable Multicast Protocol Component of Windows Server 2003

TechNet's The Cable Guy

By The Cable Guy

In addition to unicast and broadcast support, Internet Protocol (IP) (version 4) also provides a mechanism to send and receive IP multicast traffic. IP multicast traffic is a one-to-many delivery process that is more efficient than unicast traffic (you do not have to send a separate packet to each receiver). And, unlike broadcast traffic, multicast traffic is forwarded across routers. For an introduction to IP multicast, see Overview of IP Multicast (February 2002 The Cable Guy column).

Typical multicast data streams are sent using the User Datagram Protocol (UDP). Transmission Control Protocol (TCP) is not used because it is designed for one-to-one unicast streams of data. Multicast data streams sent over UDP are inherently unreliable because UDP does not provide guaranteed delivery or retransmission of lost packets. Unless reliability is provided by the upper layer protocol, lost packets in UDP-based multicast data streams cannot be detected or recovered.

The charter of the Internet Engineering Task Force (IETF) Reliable Multicast Transport working group is to create a set of standards for the reliable transmission of multicast data streams from one or multiple senders to multiple receivers. There are many protocol standards that provide reliable multicast at the transport or application layers. Existing reliable multicast protocols fall into the following four categories:

  1. Negative acknowledgement (NACK)-only Receivers use NACK packets to request, from the sender, the retransmission of missing packets in the multicast data stream. NACK-only protocols do not require any additional support from routers in the network.
  2. Tree-based acknowledgement (ACK) Receivers use positive acknowledgments to indicate multicast data packets that are successfully received.
  3. Asynchronous Layered Coding (ALC) Senders provide forward error correction (FEC) with no messages from receivers or the routers of the network.
  4. Router assist Receivers use NACK packets. Routers in the network assist with retransmitting lost packets.

Pragmatic General Multicast (PGM) Overview

Pragmatic General Multicast (PGM) is a router assist type of reliable multicast protocol that is described in RFC 3208. PGM-enabled receivers use NACK packets to request the retransmission of missing packets. PGM-enabled routers in a network define a logical PGM topology and can facilitate the recovery of lost packets by sending them on behalf of the sender. The PGM topology is overlaid on top of the physical IP internetwork topology. PGM routers define a series of PGM hops between a sender and its receivers. Although defined in RFC 3208, PGM routers are not required. The PGM topology of a network can consist of the single logical hop between the sender and the receivers.

PGM does not provide all of the capabilities of TCP for multicast data streams. For example, PGM does not provide sender or receiver-side flow control, byte stream windowing, or congestion control. PGM provides basic reliability for PGM-enabled applications.

PGM is a transport layer multicast protocol that runs directly over IP using protocol number 113. It does not use TCP or UDP for its own messages or for multicast data transmission. PGM is the only reliable multicast protocol supported by the Windows Server 2003 family. The following figure shows the relationship between PGM and the other components in the TCP/IP architecture in Windows Server 2003.

cg060301

For more information about Windows network architecture, see Windows 2000 Network Architecture.

PGM Packets

The following types of PGM packets are defined in RFC 3208:

  • Source Path Messages (SPM)
  • Original data (ODATA)
  • Retransmitted data (RDATA)
  • Negative Acknowledgement (NAK)
  • NAK Confirmation (NCF)

The SPM, NCF, and RDATA packets contain the IP Router Alert option. The following figure shows the basic structure of PGM packets. The upper layer protocol data unit (PDU) is sent by the PGM-enabled application.

If your browser does not support inline frames, click here to view on a separate page.

Note  Because PGM does not provide data origin authentication or data integrity, it is only recommended for use on a private intranet.

Source Path Message (SPM) Packets

SPMs are periodically sent by the sender to provide PGM topology determination information to PGM routers in the network. An SPM includes a transmit window and the address of the previous hop PGM router. The transmit window is the range of data that is available for retransmission. The address of the previous hop PGM router is needed for requesting data retransmission.

Original Data (ODATA) and Retransmitted Data (RDATA) Packets

ODATA packets contain data in the multicast data stream as it was originally sent by the sender. Because PGM is providing reliable multicast delivery, the ODATA header has many fields that are similar to those in the TCP header, including the following:

  • Source Port

    A 16-bit field that is used to identify the sender process.

  • Destination Port

    A 16-bit field that is used to identify the receiver process.

  • Checksum

    A 16-bit field that is used to verify bit-level packet integrity for the ODATA header and the upper layer protocol data unit (PDU). Unlike the TCP or UDP checksums, the PGM checksum does not incorporate fields from the IP header in the checksum calculation.

  • Data Packet Sequence Number

    A 32-bit field that contains the packet's sequence number as assigned by the sender. The receiver uses the Data Packet Sequence Number field to detect missing packets in the multicast data stream.

RDATA packets are used for retransmitted multicast data. RDATA packets use the same header and fields as ODATA packets. A Type field in the ODATA and RDATA headers differentiates an ODATA from an RDATA packet. RDATA packets are sent from either the sender or a Designated Local Repairer (DLR). A DLR can retransmit packets in the multicast data stream on behalf of the sender.

Negative Acknowledgement (NAK) and NAK Confirmation (NCF) Packets

A receiver sends a NAK packet to its nearest-hop PGM router to request a missing packet, as identified by its Data Packet Sequence Number. The PGM router confirms receipt of the NAK by sending an NCF to the sender of the NAK. The PGM router then sends the NAK packet to its next nearest PGM router. That PGM router responds with an NCF packet. This NAK and NCF packet exchange continues PGM hop-by-PGM hop, upstream to either the sender or a DLR.

The key fields in the NAK and NCF headers are the following:

  • Requested Sequence Number For a NAK packet, this is the sequence number of the data packet that needs to be retransmitted. For an NCF packet, this is the sequence number of a NAK being confirmed.
  • Source Network Layer Address The unicast IP address of the original sender of the missing data.

Adding and Using the Reliable Multicast Protocol

To use PGM on computers running a member of the Windows Server 2003 family, you must add the Reliable Multicast Protocol component and create PGM-enabled applications.

Adding the Reliable Multicast Protocol

To add the Reliable Multicast Protocol to a connection, complete the following steps:

  1. Click Start, click Control Panel, and then double-click Network Connections.
  2. In Network Connections, right-click the connection, and then click Properties.
  3. In the properties dialog box for the connection, click Install.
  4. In Select Network Component Type, double-click Protocol.
  5. In the Network Protocol list, click Reliable Multicast Protocol, and then click OK.
  6. To save changes to the connection properties, click Close.

The Reliable Multicast Protocol component appears in the list of items being used by the connection, but has no configurable properties. The driver for the Reliable Multicast Protocol is Rmcast.sys and is located in the systemroot\System32\Drivers folder.

Writing PGM-enabled applications

To use PGM, an application must use Windows Sockets and the PGM socket options. A sender application uses Windows Sockets to create a PGM socket, bind the socket to any address, and then connect to the multicast group address. A receiver application uses Windows Sockets to create a PGM socket, bind the socket to the multicast group address, post a listen on the new socket, and then use the accept() function to obtain a socket handle for the PGM session. For more information about using Windows Sockets to create sender and receiver PGM-enabled applications, see Reliable Multicast Programming (PGM).

Microsoft products that use PGM include Message Queuing (also known as MSMQ) and Automated Deployment Services (ADS).

Note   Applications must run under an account that has administrator privileges to be a PGM sender and to receive more than two streams of the same multicast session.

How PGM and the Reliable Multicast Protocol Works

A receiver uses the following process:

  1. The multicast application opens a listen socket with the appropriate reliable multicast socket options.
  2. The receiver sends an Internet Group Management Protocol (IGMP) Membership Report message to inform the local routers of the receiver's membership in the multicast group.

A sender uses the following process:

  1. The multicast application opens a send socket with the appropriate reliable multicast socket options.
  2. The multicast application begins to send data. ODATA packets are sent beginning with a sequence number of 0, and are incremented by 1 for subsequent ODATA packets.
  3. The ODATA packets are forwarded throughout the IPv4 internetwork by the multicast-enabled routers to the subnets that contain group members.

A receiver uses the following process to request a missing packet in the multicast data stream:

  1. If a missing packet is detected, a multicast group member sends a unicast NAK packet to the nearest PGM router.
  2. The PGM router responds with an NCF packet to confirm receipt of the NAK.
  3. The router sends an NCF to the client to confirm that it received the NAK. This process is repeated hop-by-hop up to the data sender or DLR.
  4. The sender or DLR sends an RDATA packet to replace the missing data in the originally lost ODATA packet.

If there are no PGM-enabled routers in the network, the NAK is sent to the sender or DLR.

To maintain an awareness of the PGM logical topology, the sender sends periodic SPM packets that contain their own sequence number. The SPM sequence number is incremented by 1 and used to detect the loss of SPM packets. The SPM also contains the leading and trailing edge sequence numbers that correspond to the data stream. The leading edge sequence number specifies to the receiving client the data packets that should have been received. The trailing edge is the oldest packet that can be requested for retransmission.

For More Information

For more information about IP multicast and reliable multicast, consult the following resources:

For a list of all The Cable Guy articles, click here.