Winsock2 Generic QOS Mapping

Version 2.6

Presented by: Yoram Bernet, Jim Stewart, Raj Yavatkar, Dave Andersen, Charlie Tai
Microsoft Windows Networking Group

1 Overview

This document discusses the mapping of the existing Winsock2 QoS-related application programming interfaces (APIs) to underlying QoS-enabled service providers. Two underlying QoS service providers are under consideration. These are the RSVP service provider (RSVP SP) and the Traffic Control service provider (TCSP). This document addresses the RSVP SP.

The RSVP SP provides a resource reservation protocol which negotiates with a network to satisfy QoS requests from applications. The RSVP SP also configures kernel traffic control components in compliance with the QoS negotiated with the network.

The TCSP allows applications to configure kernel traffic control components directly, with no resource reservation protocol involved. The TCSP will be discussed in a separate document.

2 Generic QoS vs. Annexes

This document addresses the generic QoS interfaces to the RSVP SP. These are standard Winsock2 API calls, which carry QoS related parameters, in a general form. There are also specific API sets defined for the RSVP SP and for the TCSP. From here on, the standard Winsock2 QoS APIs are referred to as the generic QoS (GQoS) APIs, and the specific API sets as annexes.

It is expected that the majority of applications requiring QoS support will be modified to use GQoS. Designing applications to this interface has the benefit of enabling the application to invoke QoS from any QoS service provider transparently, whereas the annexes are specific to particular QoS service providers.

The annexes provide interfaces by which applications can exercise close control over specific features of a particular QoS service provider. The annexes also enable third-party applications. These applications that request QoS on behalf of another application that is not QoS-aware.

The QoS service providers support both the GQoS interfaces and the annex interfaces specific to the provider. However, any single application is expected to invoke the service provider’s functionality through one set of interfaces or the other.

3 General Strategy for Mapping GQoS to RSVP

In mapping GQoS to RSVP, this paper reviews the required RSVP functionality and parameters and then shows how Winsock2 GQoS calls can be used to invoke this functionality and provide the required parameters.

3.1 RSVP Functionality

In simple terms, relevant RSVP functionality on a host amounts to the exchange of PATH and RESV messages with the network.

An application intending to transmit traffic with a certain QoS must indicate so to RSVP. In turn, RSVP will respond by beginning the periodic transmission of PATH messages on the network. PATH messages describe the QoS parameters of the traffic to be sent (Tspec), the sender’s address (SenderTemplate) and the destination of the traffic (session).

An application wishing to receive traffic with a certain QoS must indicate so to RSVP. In turn, RSVP should respond by beginning the periodic transmission of RESV messages on the network. RESV messages describe the QoS parameters of the traffic to be received (flowspec), the source(s) from which QoS traffic is to be received (filterspec), and the destination of the traffic (session).

3.2 Using Winsock2 APIs to Invoke RSVP Functionality

The key to mapping Winsock2 calls to RSVP is to determine when to trigger the transmission of PATH and/or RESV messages by the RSVP SP, and when to stop their transmission. In general, the transmission of these messages should begin at the time that the RSVP SP has determined the application intends to invoke QoS in a specific direction (sending or receiving) and all information required for the generation of the messages is available.

3.2.1 QoS Related Calls

The following Winsock2 calls provide a mechanism by which applications can specify QoS parameters of sent and received traffic. These parameters are specified in the SendingFlowspec and ReceivingFlowspec structures (within the QoS structure) that may be included with these calls:

• WSAConnect
  
  
• WSAJoinLeaf
  
  
• The condition function callback (lpfnCondition) to WSAAccept
  
  
• WSAIoctl (SIO_SET_QOS, SIO_GET_QOS)

3.2.2 Implicit Invocation of QoS

The RSVP SP assumes that an application that includes a non-NULL pointer to a QoS structure with any of the previous calls is implicitly invoking QoS functionality. The QoS structure includes a SendingFlowspec and a ReceivingFlowspec. Within each flowspec there is a ServiceType field. QoS functionality will be invoked if the ServiceType field in the corresponding direction specifies a value other than SERVICETYPE_BESTEFFORT or SERVICETYPE_NOTRAFFIC. The specification of either of these values in one of the flowspecs will suppress QoS functionality in the corresponding direction.

Each of the QoS related calls specify a particular socket to which the call applies. Thus, QoS is invoked relative to a particular socket. A socket on which QoS has been invoked is said to be a QoS socket.

3.2.3 Information Required to Generate PATH and RESV Messages

The following information is required to begin the transmission of PATH messages:

The following information is required to begin the transmission of RESV messages:

3.2.4 Triggering the Transmission of PATH and RESV Messages

Upon being called through any of the QoS related calls listed above (with a SendingFlowspec and/or a ReceivingFlowspec), the RSVP SP can assume that the application is invoking QoS and obtains at least the QoS parameters describing the traffic to be sent and/or received. Depending on the state of the relevant QoS socket at the time the call is invoked, the RSVP SP may or may not have the additional parameters describing the source(s) and destination(s) of the QoS traffic.

In general, the address of the local host (the source address in the case that the application resides on the sending host, or the destination address in the case that the application resides on the receiving host) is available only after the socket has been bound by use of the Winsock2 bind call. Alternatively, the socket may be bound implicitly as a result of a call to WSAConnect or WSAJoinLeaf. See the subsequent section on binding.

In general, the address of the peer (the source address in the case that the application resides on the receiving host, or the destination address in the case that the application resides on the sending host) is available following one of the connection-oriented calls (WSAConnect, WSAJoinLeaf, and WSAAccept), but not necessarily following the WSAIoctl call.

Consequently, the RSVP SP typically begins sending PATH and/or RESV messages only after an application has called one of the connection-oriented calls, and the socket is unambiguously bound to a local address. However, there are cases in which the RSVP SP can begin sending PATH and/or RESV messages, even in the absence of one of the connection-oriented calls described. Subsequent sections discuss this sequence of events as it occurs in different cases, and the requirements imposed on applications.

3.3 Responses/Notifications From RSVP to Applications

RSVP will provide the following indications to applications using the GQoS interface:

• Information regarding the acceptance or rejection of the application’s QoS requests by the RSVP module or by the network. Note that rejection of a QoS request may indicate a transient failure, which will be corrected at a later time.
  
  
• Significant changes in the QoS provided by the network (as compared to a previously negotiated QoS).
  
  
• Status regarding the preparedness of a QoS peer to send or receive a particular QoS traffic flow.

These indications are mediated through status returned to Winsock2 calls, or through FD_QOS asynchronous event notifications.

4 General Concepts

Before delving into the detailed mapping of GQoS to RSVP, it is helpful to introduce some general concepts.

4.1.1 RSVP as a Service Provider

RSVP functionality is implemented in a Winsock2 service provider. It may be implemented as part of a base service provider or as a layered service provider which is layered over a base service provider. In either case, it intercepts and acts upon Winsock API calls from an application to a transport service provider. Throughout this document, the RSVP service provider (RSVP SP) is recognized as being an integral part of a base transport service provider.

An application may use the GQoS interface to the RSVP SP to invoke QoS on its own behalf. Alternatively, third-party applications may invoke QoS on behalf of another application’s traffic flows, by using the RSVP annex interface. In this case, the third-party application will have to learn the addresses and ports used by the application for which it is invoking QoS. It is assumed that some out of band method is used for doing so, or that these are known a-priori.

4.1.2 Binding

In general, RSVP identifies packets associated with a particular traffic flow, by the source and destination IP addresses and ports included in the packets. Consequently, it is necessary for RSVP to learn the local and remote addresses and port numbers associated with each QoS socket. The local address and port associated with a socket are defined by either implicit or explicit binding of the socket. These are used by RSVP to compose the SenderTemplate on a sender, and the session on a receiver (for receiving sockets, the session indicated in RESV messages is determined by matching PATH state with local address and port parameters-see the section titled Sending RESV Messages Based on Matching PATH State).

Applications typically invoke the Winsock bind call to explicitly associate a local address and port with a socket. In general, an application may call bind without explicitly specifying an IP address or port or, in certain cases, may not call bind at all. When a socket is not explicitly bound by an application, the underlying transport service provider will automatically bind the socket to a specific port. The RSVP SP (and applications using RSVP), can readily determine the port bound, by issuing a getsockname call to the underlying transport service provider.

For Transmission Control Protocol (TCP) sockets, the local address to which the socket is bound can also be unambiguously determined using getsockname. However, in the case of UDP sockets, certain implementations of the transport service provider reserve the right to change the sending interface (and the address included in the source address field of sent packet headers), based on routing information. Because of this, calls to getsockname on UDP sockets are not guaranteed to return a bound address.

This presents a problem, primarily in the case of sending sockets, for which RSVP is required to compose a SenderTemplate object that matches the source address and interface on which the socket’s QoS data is transmitted. To address this problem, applications using the GQoS interfaces to the RSVP SP may use one of the approaches described later. Note that these approaches apply both in the case of unicast and multicast RSVP sessions. Also note that these are used for UDP sockets only. For TCP sockets, the RSVP SP can call getsockname to determine the local bound address.

4.1.2.1 Binding Using INADDR_ANY

The application may bind using INADDR_ANY. In this case, the RSVP SP will use the interface query Ioctl, WSAIoctl(SIO_LOCAL_INTERFACE_QUERY), to determine which source address to use when composing the SenderTemplate. To do so, the RSVP SP waits until the application calls WSAConnect or WSAJoinLeaf. At that time, the RSVP SP issues the interface query Ioctl, providing the peer address specified in the connection-oriented call. The RSVP SP composes the SenderTemplate based on the address returned in response, from the underlying transport service provider. The RSVP SP registers for routing change notifications through the FD_ROUTING_CHANGE event, or by calling WSAIoctl(SIO_LOCAL_INTERFACE_CHANGE). This ensures that it will be notified in the case of routing changes and is able to modify the SenderTemplate accordingly.

In this mode, the application remains unaware of the sending interface used and of routing changes. Calls to getsockname are not guaranteed to return a valid address. In addition, the address included in the source address field of transmitted packets, is subject to change as a result of routing changes. Although the RSVP SP will respond by correcting the SenderTemplate in transmitted PATH messages, the application will receive no indication of the change.

4.1.2.2 Binding a Specific Address Based on an Interface Query

For details regarding the usage of the interface query Ioctl and the associated change notification mechanisms, see the subsequent section in this document and/or the references in the Windows Sockets 2 Application Programming Interface (revision 2.2.1).

In this case, the application assumes full responsibility for binding to a specific address. The application may use the interface query Ioctl to determine the address to which it should bind, based on the destination address to which it will be sending. Once it has determined the correct address to bind, it issues a bind call, specifying the address. The RSVP SP will either monitor bind calls issued by the application, or issue getsockname calls to the underlying transport service provider, to determine the address to be used in the SenderTemplate.

For resilience in the unlikely event of a routing change, applications using this method on multihomed hosts, may register for routing change notifications through the FD_ROUTING_CHANGE event or by calling WSAIoctl(SIO_LOCAL_INTERFACE_CHANGE). Note that when an application binds explicitly, route changes will result in data being sent from a new interface, but will not cause a change in the source address used in datagram headers. Since the source address will not change, the SenderTemplate is not required to change. Therefore, strictly speaking, applications are not required to react to routing changes. There may be an intermittent disruption in RSVP service, however, due to the soft state maintained by RSVP, the network will eventually respond to the routing change, transparently.

By binding to specific addresses and tracking routing changes, the application can be fully aware of the sending interface used at any time.

4.1.2.3 No Bind by Application

An application does not have to bind a socket at all. This case is handled by the RSVP SP, as a variation on the case of a bind using INADDR_ANY. From the perspective of PATH message generation, the cases are identical. The RSVP SP issues the interface query ioctl (following one of the connection-oriented calls) and monitors routing changes to maintain the correct SenderTemplate. From the perspective of RESV message generation, unbound sockets provide no criteria by which the RSVP SP can search for matching PATH state. Consequently, no RESV messages will be sent on behalf of these sockets until they are bound, either explicitly by the application or implicitly by the transport provider, following one of the connection-oriented calls listed above.

Note that per standard Winsock protocol, applications calling WSAAccept must call bind first.

4.1.3 WSAIoctl(SIO_LOCAL_INTERFACE_QUERY) and Change Notifications

The interface query ioctl takes a unicast or multicast destination address as input. It returns the address of the interface which will be used by the transport provider, to send packets to the receiving peer.

The ioctl is guaranteed to return the correct interface for both unicast and multicast addresses. The interface returned in response to unicast queries is based on routing information. Routing information is not necessarily available for multicast addresses. Therefore, while the interface returned in response to multicast queries is the interface that will be used, this interface may have been chosen arbitrarily. Applications that require control over the choice of multicast interface used should explicitly set the multicast interface by calling setsockopt(IP_MULTICAST_IF).

Note that, on hosts acting as multicast gateways, an interface query on a multicast address may return a list of interfaces. QoS applications of the type described here are not expected to run directly on multicast gateways.

4.1.4 Port Number Negotiation

It is assumed that there is some application specific mechanism to allow peers to negotiate port numbers (or that they are implied by the application, such as in the case of FTP). Methods for negotiation of port numbers is beyond the scope of this document.

4.1.5 WSAIoctl (SIO_SET_QOS)

This call can be invoked by an application at any time to change or initialize the QoS parameters on a socket. The RSVP SP will respond differently depending on the state of the socket. The use of WSAIoctl(SIO_SET_QOS) will be discussed in subsequent sections.

4.1.6 Sending RESV Messages Based on Matching PATH State

When a PATH message is received, the RSVP SP creates an RSVP session and associates PATH state with it. The RSVP SP will also create a session (in the absence of PATH messages) when QoS is indicated on any receive socket. (However, in this case PATH state is not associated with the session until a corresponding PATH message is received.)

The RSVP SP will generally send RESV messages when it determines that PATH state exists for a session matching a socket for which receiving QoS is indicated. As a result, the transmission of RESV messages may be triggered either by the receipt of a PATH message (which matches the session associated with a preexisting socket), or by the creation of a socket (which matches the session associated with preexisting PATH state). The following rules are used to determine whether a match exists between sessions with associated PATH state and sockets for which receiving QoS is indicated.

4.1.6.1 TCP Sessions

In this case, matches are readily determined. TCP sockets, once they are connected, are associated with specific source and destination addresses and ports.

4.1.6.2 UDP Sessions

UDP sessions are subject to less stringent matching rules, since it is not always possible to determine unique addresses associated with a UDP socket. The rules are tabulated separately for unicast vs. multicast.

In the case of multicast sockets, the application is expected to create the socket using WSASocket, setting the appropriate flags to indicate that it is a multicast sender (or receiver). Otherwise, the RSVP SP may be unable to determine that the socket is multicast and may send undesired RESV messages based on the unicast matching rules described above.

4.1.7 QoS for Transmitted Data Contingent on RESV

The RSVP SP typically will not activate traffic control on behalf of a sending application’s flow unless there is RESV state for the flow (RESV messages are arriving). Until such time, sent traffic will be treated by the local network components and by the network at large, as best-effort traffic. Senders may register for notification that RESV state has been established, by using WSAEventSelect (FD_QOS).

In general, the default behavior of any QoS service provider, is to delay activation of traffic control until there is an indication from the network that there exists at least one listener. Applications may override this behavior by setting the SERVICE_IMMEDIATE_TRAFFIC_CONTROL bit in the ServiceType parameter of the SendingFlowspec. This will cause the QoS service provider to immediately invoke sending traffic control per the parameters in the SendingFlowspec.

4.1.8 GQoS and IP

Although RSVP and GQoS are supposed to be protocol independent, the reality is that they assume the IP protocol. Nonetheless, efforts were made to assure that the GQoS specification is as independent of a specific protocol as practically realizable.

4.1.9 Use of WSAJoinLeaf and sendto for Multicast Sessions

To invoke QoS service, applications are required to use the WSAJoinLeaf call both to send and receive multicast traffic. Alternate multicast semantics, such as simply calling sendto with a multicast address (for transmit) or using IP_ADD_MEMBERSHIP (for receive), will not invoke QoS service.

Applications are required to set the dwFlags parameter to JL_SENDER_ONLY, JL_RECEIVER_ONLY or JL_BOTH, to indicate the direction in which QoS service is requested.

Note that senders that have joined multicast sessions using WSAJoinLeaf are required to call sendto or WSASendTo with the correct multicast session address to send data to the multicast session (even though the multicast session address was already provided with the call to WSAJoinLeaf). The RSVP SP on a sender, generates the SenderTemplate based on the multicast session address specified in the call to WSAJoinLeaf. Therefore, if the sending application calls sendto or WSASendTo specifying a multicast session address other than the one specified with the WSAJoinLeaf, it will not receive QoS service for the data sent.

Also, note that the only case in which a QoS application should call sendto or WSASendTo, is the case of a multicast sender. For unicast UDP or TCP senders, the destination address must be specified using WSAConnect and it is sufficient for the application to call send or WSASend, rather than sendto or WSASendTo.

5 Detailed Mapping of GQoS to RSVP-Call Sequences

Applications must issue a sequence of QoS-related calls to invoke QoS functionality from the RSVP SP. The sequence may vary depending on the type of communication (such as UDP versus TCP and unicast versus multicast) and on the specific application. This section discusses these call sequences. For a list of sample call sequences, see Appendix A-Sample Call Sequences.

For the sake of simplicity, the following section covers sending applications separately from receiving applications. Applications are classified as sending or receiving, based on their QoS requirements. Most applications do not exclusively send or receive, however-many applications may be interested in QoS service only for traffic sent or only for traffic received. This is the case for playback applications, such as video and audio servers, in which the server sends QoS traffic and the receiver receives QoS traffic. For other types of applications, such as conferencing, the application may be interested in QoS service for both traffic sent and traffic received. In this case, the sequences described below can be combined.

5.1 Sending Applications

Sending applications must provide the RSVP SP with the following information to invoke RSVP processing:

• Peer (destination) address, for the composition of RSVP session objects.
  
  
• Local (source) address, for the composition of the RSVP SenderTemplate objects.
  
  
• QoS parameters, in a SendingFlowspec, for the generation of Tspec objects.

Once this information is available to the RSVP SP, it begins to transmit RSVP PATH messages on behalf of the application.

The following table summarizes how the RSVP SP obtains the information for session and SenderTemplate for various cases of sending applications.

The RSVP SP obtains QoS parameters from a SendingFlowspec which is included either in the application’s call to WSAConnect or WSAJoinLeaf, or provided separately in a call to WSAIoctl(SIO_SET_QOS).

5.1.1 Unicast UDP Senders

Unicast UDP senders will typically call WSAConnect to invoke RSVP functionality. This call provides the peer address to the RSVP SP and may also provide QoS parameters. The RSVP SP uses the address passed to directly generate the session object included in PATH messages. For sockets that have been bound using INADDR_ANY, the RSVP SP uses the peer address to determine the local address to be used in the SenderTemplate object. It does so by issuing an interface query to the underlying transport service provider. This returns the address of the local interface, which should be used to reach the peer specified.

Typically, the call to WSAConnect will include sending QoS parameters. However, the sending application may use the WSAIoctl(SIO_SET_QOS) to provide the sending QoS parameters to the RSVP SP before or after the call to WSAConnect. In all cases, RSVP processing will begin at the earliest time the RSVP SP knows the peer address (from which it may also determine the local bound address) and the sending QoS parameters.

5.1.2 Multicast UDP Senders

The previous discussion on unicast UDP senders applies to multicast UDP senders as well. The only difference between the two cases is that multicast UDP senders use the WSAJoinLeaf call, instead of the WSAConnect call used in the unicast case. The WSAJoinLeaf call provides the destination multicast session address and may also be used to provide QoS parameters. If QoS parameters are not provided with the call to WSAJoinLeaf, they must be provided separately, with a call to WSAIoctl(SIO_SET_QOS). The multicast session address is used to compose the RSVP session object to be included in RSVP PATH messages.

Note that in the case that a sending multicast UDP socket is bound using INADDR_ANY, the RSVP SP will use the multicast session address to perform an interface query, just as it would in the unicast case. The RSVP SP will use the interface address returned from the interface query to compose the RSVP SenderTemplate to be included in PATH messages.

5.1.3 Unicast TCP Senders

For TCP sessions, the active peer issues a WSAConnect and the passive peer issues a WSAAccept. Typically, the passive peer is the sender, and the active peer is the receiver, although this is not necessarily the case. In this section, the passive peer is assumed also to be the sender. For the case in which the active peer is the sender, the subsequent section on unicast receivers can be applied.

As the passive peer, the sending application calls WSAAccept. This call returns the connecting peer’s address but does not carry QoS parameters. Instead, the application defines a callback function (ConditionFunc) which is called by the transport service provider when the active peer initiates a connection. ConditionFunc tells QoS parameters to be passed to the application or for the application to pass QoS parameters back to the service provider.

Therefore, passive TCP peers may provide QoS parameters to the RSVP SP with the completion of the ConditionFunc or, alternatively, using WSAIoctl(SIO_SET_QOS). The application may call WSAIoctl(SIO_SET_QOS) to associate QoS parameters with a socket, at any time following the creation of the socket (The RSVP SP will call the ConditionFunc with no ProviderSpecific buffer. Therefore, if the passive TCP application wishes to convey ProviderSpecific QoS parameters, it must call WSAIoctl(SIO_SET_QOS) to do so.). RSVP sender processing will begin at the earliest time at which the RSVP SP knows the peer address, the address to which the socket is bound locally and the QoS parameters.

To provide QoS parameters through the ConditionFunc, the application is required to complete the ConditionFunc with status CF_ACCEPT. In addition, if the application has previously associated QoS parameters with the socket by calling WSAIoctl(SIO_SET_QOS), then completion of the ConditionFunc may cause modification of the QoS parameters unless the ServiceType parameters in the corresponding flowspecs are set to SERVICETYPE_NOCHANGE.

The RSVP SP can readily determine the connected peer’s address by monitoring the application’s call to WSAConnect or by calling getpeername after the socket is connected.

Recall that, for TCP sockets, the RSVP SP can unambiguously determine the local address bound to the socket, by calling getsockname at any time following the establishment of the connection. This address is used to compose the SenderTemplate for inclusion in RSVP PATH messages. As a result, no interface query is required in the case of TCP connections, even if the application binds using INADDR_ANY.

5.2 Receiving Applications

Receiving applications must provide the RSVP SP with at least, the QoS parameters, in a ReceivingFlowspec to invoke RSVP processing. The application includes the ReceivingFlowspec in a call to WSAConnect or WSAJoinLeaf, or separately, in a call to WSAIoctl(SIO_SET_QOS).

The RSVP SP must compose a session object, and in certain cases, a filterspec (defining the senders from which QoS traffic is to be received) for inclusion in RESV messages. Generally, these are obtained from all matching PATH states. However, to limit the PATH state matched, receiving applications may provide the following addresses to the RSVP SP:

• Peer (source) address, to compose the RSVP filterspec, thereby limiting the RSVP senders for which RESV messages are sent.
  
  
• Local (destination) address, to limit the RSVP sessions for which RESV messages are sent.

See the previous section titled Sending RESV Messages Based on Matching PATH State, for further details.

Once sufficient information is available to the RSVP SP, it begins to transmit RSVP RESV messages on behalf of the application.

5.2.1 Unicast UDP Receivers

UDP-receiving applications may use either the WSAConnect call or the WSAIoctl(SIO_SET_QOS) call to provide QoS parameters to the RSVP SP, indicating they are interested in receiving QoS traffic. The WSAConnect call can be used to provide a peer address, in so selecting a specific sender.

If the application calls WSAIoctl(SIO_SET_QOS) to indicate receiving QoS parameters, the RSVP SP will begin transmitting RESV messages for any matching PATH state (see the previous section titled Sending RESV Messages Based on Matching PATH State). Since the WSAIoctl(SIO_SET_QOS) call does not associate a peer address with the socket (except in the case that the ProviderSpecific structure is used to specify a particular sender-use of the ProviderSpecific structure is addressed later in the document), the socket will match PATH state regardless of sender. The RSVP SP will transmit Wildcard Filter (WF)-style RESV messages.

The WSAConnect call should be used if the application is interested in receiving traffic from a single sender only (WSAConnect will cause traffic received from senders other than the one specified to be discarded-to receive traffic from multiple senders, using WSAConnect, requires that a separate socket be created for each sender). In this case, the RSVP SP will send RESV messages only when PATH state exists for the sender specified. It will use the peer address included to compose FF-style RESV messages, selecting the specified sender.

Receiving applications may call both WSAIoctl(SIO_SET_QOS) and WSAConnect, and may do so in any order. The RSVP SP will send RESV messages at the earliest indication of QoS parameters and the existence of matching PATH state. If WSAIoctl(SIO_SET_QOS) is called prior to WSAConnect, the RSVP SP will send WF-style RESV messages (provided there is matching PATH state) initially and will send FF-style RESV messages as soon as a peer is specified by WSAConnect (provided that matching PATH state exists for the particular sender specified).

Note that calling WSAIoctl(SIO_SET_QOS) after WSAConnect does not negate the selection of a specific sender. Thus, although WSAIoctl(SIO_SET_QOS) may be called after WSAConnect to alter the QoS parameters indicated in the RESV messages (or to terminate the transmission of RESV messages-by specifying BestEffort service), it will not cause the RSVP SP to send WF-style RESV messages.

Calling WSAConnect may actually cause the RSVP SP to cease sending RESV messages triggered by a previous call to WSAIoctl(SIO_SET_QOS), since PATH state may have existed for some senders, but not for the particular sender specified.

5.2.2 Multicast UDP Receivers

Multicast receiving applications are expected to create UDP sockets using WASocket and to indicate in the accompanying flags that they are multicast receivers. Such applications are required to call WSAJoinLeaf to indicate the multicast session they are interested in joining. QoS parameters may be indicated either with the call to WSAJoinLeaf or separately, using WSAIoctl(SIO_SET_QOS).

Unlike the unicast case, the RSVP SP will not send RESV messages for multicast sessions until a multicast session address is unambiguously specified in a call to WSAJoinLeaf. The RSVP SP makes no use of the parameters with which the multicast socket is bound. Also, since no peer is specified, the RSVP SP makes no assumptions about specific senders. Consequently, RESV messages sent on behalf of multicast receivers, are by default the WF style (applications may use the ProviderSpecific fields of the QoS structure to specify particular senders, thereby causing the RSVP SP to send FF or SE-style RESV messages).

Receiving applications may call both WSAIoctl(SIO_SET_QOS) and WSAJoinLeaf, and may do so in any order. The RSVP SP will send RESV messages at the earliest indication of QoS parameters and the existence of matching PATH state. However, note that in the multicast case, matching PATH state will only be found if a multicast socket has been created with a matching multicast session address.

The RSVP SP does not preclude a receiving application from joining multiple multicast groups on a single socket. In this case, the RSVP SP will send RESV messages for all groups for which there is a matching PATH state. Unless WSAIoctl(SIO_SET_QOS) is called, QoS parameters will be obtained separately from the ReceivingFlowspecs included with the WSAJoinLeaf calls for each multicast group. If WSAIoctl(SIO_SET_QOS) is called, the QoS parameters included will be applied to all multicast groups joined.

5.2.3 Unicast TCP Receivers

Typically, the TCP receiver is the active peer in a TCP connection. As such, receiving TCP applications are expected to use WSAConnect to initiate a connection to the sender. Rules for invoking RSVP processing from the RSVP SP are similar to those which apply in the unicast UDP sender case. Specifically, the receiving application must use WSAConnect to specify the peer sender’s address. The RSVP SP uses this address directly to compose the filterspec for Fixed Filter (FF)-style RESV messages.

Typically, the call to WSAConnect will include receiving QoS parameters. However, the receiving application may use the WSAIoctl(SIO_SET_QOS) to provide the receiving QoS parameters to the RSVP SP before or after the call to WSAConnect. In all cases, the RSVP SP will begin RSVP processing at the earliest time it knows the receiving QoS parameters and there is a matching PATH state. In the case of TCP receivers, PATH state will match only if the session address and the SenderTemplate match the bound address and the peer address associated with the socket.

In case the receiving socket is bound using INADDR_ANY, the bound address cannot be determined until WSAConnect is called. If the receiving socket is bound with a specific address, the bound address can be determined earlier. However, if the peer address remains unknown and it is impossible to match PATH state, the transmission of RESV messages will still be delayed. Following connection establishment, the RSVP SP calls getpeername to determine the peer address. At that time sufficient information is available to generate RESV messages.

5.3 Use of WSAIoctl(SIO_SET_QOS)

The previous paragraphs covered the use of WSAIoctl(SIO_SET_QOS) in conjunction with the various QoS connection-oriented calls. Typically, connection-oriented calls will be used both to indicate the QoS parameters and address parameters to the RSVP SP so the call to WSAIoctl(SIO_SET_QOS) is not required.

One exception is a UDP receiving application, which receives from multiple senders. In this case, the application must use WSAIoctl(SIO_SET_QOS) to specify QoS parameters without calling WSAConnect (which will limit the socket to receive traffic from a single sender).

In other cases, applications may use WSAIoctl(SIO_SET_QOS) to specify QoS parameters, even if one of the connection-oriented calls is also used. An application can then modify QoS parameters at any time after they were originally indicated in one of the connection-oriented calls. It also allows the application to separate the specification of the QoS parameters from the determination of local and peer addresses implicit in the connection-oriented call.

5.4 Terminating QoS Service

The previous paragraphs discuss the method that applications invoke RSVP processing. Several events may cause the termination of RSVP processing associated with a socket. Specific examples include:

• Closing a socket by calling closesocket.
  
  
• Shutting down a socket by calling shutdown (note that shutting down a socket for reception or transmission only will not terminate QoS processing for transmission or reception, respectively).
  
  
• Calling WSAConnect with a NULL peer address.
  
  
• Calling WSAIoctl (SIO_SET_QOS) with SERVICETYPE_ NOTRAFFIC or SERVICETYPE_BESTEFFORT.

Note that in the first two cases, all RSVP processing on the socket will be terminated. However, in the third case, it is possible to terminate sending only or receiving only RSVP processing by selectively specifying SERVICETYPE_NOTRAFFIC or SERVICETYPE_BESTEFORT in SendingFlowspec or ReceivingFlowspec, respectively.

In general, any event that closes a socket, will also terminate RSVP processing on the socket.

6 Detailed Mapping of GQoS to RSVP- QoS Parameters

This section covers the mapping of QoS parameters from GQoS to RSVP.

Winsock2 QoS calls include two flowspec structures, SendingFlowspec and ReceivingFlowspec. SendingFlowspec is used to invoke RSVP-sender processing and ReceivingFlowspec is used to invoke receiver processing. RSVP-sender processing requires the inclusion of a Tspec with PATH messages. The Tspec describes the traffic flow offered by the sender and is readily derived from SendingFlowspec. RSVP-receiver processing varies depending on the service type requested. Receiver processing for controlled load service requires inclusion of a Tspec with RESV messages. Receiver processing for guaranteed load service requires inclusion of a Tspec and an Rspec. The Rspec defines the QoS desired by the receiver.

The following table shows the general mapping of parameters from the Winsock2 QoS flowspecs to RSVP Tspecs and Rspecs.

By specifying the value ‘-1’ as a flowspec parameter, applications can indicate that a default parameter will be inferred by the RSVP SP. Additionally, applications may specify SERVICETYPE_NOCHANGE in one or both flowspecs, to indicate that the QoS parameters in the corresponding direction(s) should remain unchanged. This is especially useful, for example, so an application can change sending parameters without affecting receiving parameters (or vice versa).

6.1 Tspec

6.1.1 SenderTspec

On senders, RSVP uses the mapping tabulated above, to derive a SenderTspec from the SendingFlowspec, for inclusion in PATH messages (with the possible exceptions noted below).

If the sending application does not specify the parameter MaxSduSize, the RSVP SP will use a default value of 1514 bytes.

If the application does not specify the parameter MinimumPolicedSize, the RSVP SP will use a default value of 128 bytes.

6.1.2 ReceiverTspec

6.1.2.1 Controlled Load Service

On receivers, for ControlledLoadService, the application may specify only the ServiceType parameter in the ReceivingFlowspec. In this case, the RSVP SP copies the SenderTspec from matching PATH messages (see the section titled Sending RESV Messages Based on Matching PATH State), to the ReceiverTspec sent with the RESV messages (with the possible exceptions noted below). Alternatively, the receiving application may specify, in the ReceivingFlowspec, any of the Tspec parameters tabulated above. This will cause the RSVP SP to use the specified parameters in the ReceiverTspec sent with the RESV messages (instead of the corresponding parameter from received PATH messages). Parameters not specified by the application should be set to ‘-1’ in the ReceivingFlowspec and will be copied from the matching PATH messages.

6.1.2.2 Guaranteed Service

On receivers, for GuaranteedService, the RSVP SP will copy the SenderTspec from matching PATH messages to the ReceiverTspec sent with the RESV messages (with the possible exceptions noted below). The application cannot override Tspec parameters in this case.

6.1.2.3 Exceptions

In the case of Wildcard Filter reservation styles, multiple PATH messages may be received (corresponding to the same session) but with different SenderTspecs (representing different senders). In this case, the RSVP SP will copy the greater (as determined by the RSVP least upper bound calculation) of the SenderTspecs, to the ReceiverTspec included with RESV messages.

The RSVP SP will populate the MaximumPacketSize in the ReceiverTspec with the PATH_MTU value from the Adspec in the corresponding inbound PATH message. If there are multiple PATH messages, the lowest PATH_MTU value from all corresponding Adspecs will be used.

6.2 Rspec

The Rspec is included by the RSVP SP in RESV messages sent on behalf of a receiving application, only when GuaranteedService is specified by the receiving application. The application is expected to specify two of the three parameters; TokenRate, DelayVariation, and Latency, as shown in the following table:

If the application does not specify two of the three parameters (all parameters are set to ‘-1’), then the RSVP SP will infer appropriate default values based on corresponding received PATH messages.

6.3 Service Types

The following values may be specified in the ServiceType parameter of the SendingFlowspec and the ReceivingFlowspec:

7 Reservation Styles

Three reservation styles are recognized by RSVP. These are Fixed Filter (FF), Shared Explicit (SE), and Wildcard Filter (WF). Not all reservation styles can be accommodated using the GQoS interface (unless the ProviderSpecific structure is also used). The RSVP SP will infer the reservation style desired by a receiving application per the following rules.

For details on invocation of alternate reservation styles, see the section titled Use of the Provider Specific Structure.

7.1 Fixed Filter-Unicast

Receiving applications requesting QoS for a unicast session will be assumed to require the FF reservation style. TCP receivers are always assumed to be unicast receivers.

Note that UDP unicast receivers will be handled using FF-style reservations, only if they call WSAConnect. UDP unicast receivers which do not call WSAConnect will be handled using WF-style reservations.

7.2 Wildcard Filter-Multicast

Receiving applications requesting QoS for a multicast address and UDP applications that do not call WSAConnect will be assumed to require the W-style reservation. This is necessary because there is no means for the receiving application to specify selected senders for the multicast session. If an SE- or FF-style reservation is required, either the ProviderSpecific structure must be used to supply the required flowdescriptors, or the RSVP annex must be used.

7.3 Shared Explicit

Shared Explicit (SE) reservations require the specification of multiple flowdescriptors. The standard structures included with the Winsock2 GQoS interface do not provide for this. Therefore, in general, the SE reservation style will require use of the ProviderSpecific structure or the RSVP Annex.

8 Use of ProviderSpecific Structure

The GQoS interfaces support the QoS requirements of a majority of applications without using the ProviderSpecific buffer. In certain cases, the application will be required to provide information which cannot be provided through the standard GQoS parameters. In these cases, the application will provide additional parameters in the ProviderSpecific buffer which is a member of the QoS structure. The following paragraphs describe the use of the ProviderSpecific structure.

The ProviderSpecific buffer is of type WSABUF. This structure includes a length field and a pointer to a buffer. The buffer may include a number of objects. Each object includes a type field (which identifies the object), followed by a length field (which contains the length of the object, excluding the header), followed by the object data itself.

8.1 The RSVP_RESERVE_INFO Object

This object may be used by applications to override the default reservation styles. It includes a Style parameter that specifies the reservation style to be used, and allows for the specification of a list of flowdescriptors. For detailed structure formats, refer to the “ws2rsvp.h” header file.

The following reservation styles may be specified:

• RSVP_WILDCARD_SYLE: Used to request RSVP to make reservations using the WF style. Note that this is the default for multicast receivers and unconnected UDP unicast receivers, while FF is the default for connected unicast receivers. This command type can be used to override the default FF style for connected unicast receivers.
  
  
• RSVP_FIXED_FILTER_STYLE: This style object may be used to override the default WF style for multicast receivers or unconnected UDP unicast receivers. It may also be used to generate multiple FF-style reservations where only a single FF-style reservation would have been generated by default (connected unicast receivers).
  
  
• RSVP_SHARED_EXPLICIT_STYLE: Used to request RSVP to make reservations for a number of explicitly specified sources (filterpsecs).

The flowdescriptor list is specified using the RSVP_FLOWDESCRIPTOR structure, which is a member of the RSVP_RESERVE_INFO object.

8.2 Alternate Reservation Styles

The following reservation styles are provided by default:

• Unicast-a single FF-style reservation.
  
  
• Multicast-a WF-style reservation.

In the absence of an RSVP_RESERVE_INFO object in the ProviderSpecific structure, these reservation styles will be provided. To override the default reservation styles, the RSPV_RESERVE_INFO object is used to specify a reservation style, and one or more RSVP_FLOWDESCRIPTOR structures follow, as described below.

8.2.1 Single FixedFilter Reservations

This is the default reservation style invoked for connected unicast receivers. To invoke this reservation style for multicast receivers, it is necessary to override the default WF-style reservation by specifying the FF-style object, followed by a single RSVP_FLOWDESCRIPTOR.

8.2.2 Multiple FixedFilter Reservations in a Single Reservation

This style allows a receiver to reserve mutually exclusive flows from multiple, explicitly identified sources. It is invoked by specifying the FF style followed by a list of multiple RSVP_FLOWDESCRIPTORs. Note that this style cannot be applied to TCP receivers since they are assumed to be connected to a single peer sender. Also, this style cannot be applied to UDP receivers that have been connected (by calling WSAConnect), since the transport will discard data from all senders other than the one specified in the call to WSAConnect.

8.2.3 Shared Explicit Reservations

This style allows a receiver to specify multiple sources. The flow resources requested will be shared between all sources. It is invoked by specifying the corresponding style, followed by a single RSVP_FLOWDESCRIPTOR, which includes multiple RSVP_FILTERSPECs. As is the case with multiple FF-style reservations, this style cannot be applied to TCP receivers or to connected UDP receivers.

8.2.4 WF Reservations

This is the default reservation style for multicast receivers and unconnected UDP receivers. To invoke this reservation style for TCP unicast receivers or for connected UDP unicast receivers, it is necessary to override the default FF reservation style by specifying the WF style, followed by a single RSVP_FLOWDESCRIPTOR.

8.3 The Priority Object

The optional priority object contains two parameters. One indicates the transmission priority of a requested flow, the other represents the receive priority of the requested flow. It should be used to supplement the standard flowspec. Note that the transmit priority object will be used by the kernel to determine relative priorities for multiple flows of the same Intserv service type. Priorities between Intserv service types are defined by the Intserv service type definitions.

8.3.1 Packet Sequencing

The transmit priority object will be interpreted by packet sequencing components in the network stack (typically in the kernel), and will determine which flow’s packets get access to the wire under congested conditions. The typical packet sequencer will group flows according to the value specified in the priority object. Under congested conditions, a packet sequencer will send packets from each flow, in the highest priority group for which packets are pending. Flows within the group will be serviced in a round-robin fashion.

Note that flow priority is machinewide, not within an application. Thus, flows from two different applications, given the same priority, will be serviced as part of the same priority group.

8.3.2 Avoiding Starvation

Although this priority mechanism has the potential to starve low priority flows, this is unlikely to happen in a correctly configured system. Traffic control components will limit the admission of high-priority flows so sustained capacity of the media is not exceeded. In this case, priority will determine the latencies perceived by packets on particular flows, under transient congestion conditions, while maintaining the sustained rates specified in the token bucket parameters of the flowspec.

8.3.3 Usage

The priority object can be used to specify a range of priorities between 0 and 7 (with 0 being the lowest priority and 7 being the highest). This value will be used by the kernel, together with the service type specified in the flowspec, to control the prioritization in the kernel. The absence of a priority object with a flowspec will be interpreted as default priority (equivalent to a priority object of three).

The kernel is not required to implement multiple priority levels for each Intserv service class. Applications should specify relative priority by use of the Intserv service class whenever possible. Where it is absolutely necessary to specify prioritization within an Intserv service class, applications should restrict the priority levels to the minimum possible. For example, use 7 to specify higher than default for the class, and 0 to specify lower than default for the class.

Consider a video-conferencing or whiteboard application. Such an application should specify service as follows:

8.3.4 Relation to Socket Group Priority

The socket group priority mechanism has been eliminated. It was intended to specify relative priorities of sockets within a group without defining the interpretation of priorities across groups. The priority object defined here, specifies the relative priority across all flows on the host.

8.3.5 Relation to 802.1p

The priority object is unrelated to 802.1p traffic classes, which are indicated in tags attached to transmitted packets. The kernel traffic control components will determine the 802.1p traffic classes based on standardized Intserv flowspec to 802.1p traffic class mappings.

9 Status Indications from the RSVP SP to Applications

Applications are expected to register interest in FD_QOS (WSAEventSelect or WSAAsyncSelect) to receive asynchronous notifications of status events from the RSVP SP. When a significant QoS event occurs on the specified socket, the RSVP SP posts a message or signals the event, as appropriate. In either case, one of the error codes below will be included. Alternatively, these error codes may be retrieved by calling WSAEnumNetworkEvents. These error codes may be found in the “winsock2.h” header file.

• WSA_QOS_RECEIVERS-at least one RESV has arrived.
  
  
• WSA_QOS_SENDERS-at least one PATH has arrived.
  
  
• WSA_QOS_NO_SENDERS-there are no senders.
  
  
• WSA_QOS_NO_RECEIVERS-there are no receivers.
  
  
• WSA_QOS_REQUEST_CONFIRMED-reserve has been confirmed.
  
  
• WSA_QOS_ADMISSION_FAILURE-error due to lack of resources.
  
  
• WSA_QOS_POLICY_FAILURE-rejected for administrative reasons.
  
  
• WSA_QOS_BAD_STYLE-unknown or conflicting style.
  
  
• WSA_QOS_BAD_OBJECT-problem with some part of the flowspec.
  
  
• WSA_QOS_TRAFFIC_CTRL_ERROR-problem with some part of the filterspec.
  
  
• WSA_QOS_GENERIC_ERROR - general error.

When the FD_QOS event is signaled, the application should issue a WSAIoctl (SIO_GET_QOS) to retrieve a QoS structure. The returned QoS structure will indicate the current QoS parameters. The application should inspect these parameters to determine the extent of the QoS change.

Regardless of the status code indicated, the application must issue the WSAIoctl (SIO_GET_QOS) to reenable the FD_QOS event.

9.1 Use of the ProviderSpecific Structure for Status Indications

The status indication mechanisms described so far provide for the indication of a single status code, and the notification of a change in specific QoS parameters. Additional information can be indicated from the RSVP SP to applications, by use of the ProviderSpecific member of the QoS structure which is indicated in response to WSAIoctl (SIO_GET_QOS).

When the ProviderSpecific structure included is at least as the size of the QOS_STATUS structure then the following additional information will be returned. The first value in the structure is the same as the status value returned in response to WSAEnumNetworkEvents. Additional parameters provide the specific RSVP error code and error value from the standard RSVP ErrorSpec object, if available.

10 WSAGetQoSByName

Applications call WSAGetQoSByName to retrieve a list of available QoS templates and to populate flowspec structures with a named template. This facility is particularly useful to applications which are aware of the codec which they are using, since these tend to have well-defined flowspec parameters.

General usage of the WSAGetQoSByName call is as follows:

1. Applications call WSAGetQoSByName with a NULL lpQoSName parameter and a pointer to a WSABUF structure in the lpQoS parameter.
   
   
2. Winsock returns a list of QoS template names.
   
   
3. The application selects a template name based on the type of QoS flow it will be generating. It passes the selected template name to Winsock, in the lpQoSName parameter. It passes a pointer to the flowspec structure to be used in the lpQoS parameter.
   
   
4. Winsock fills in the flowspec structure with the parameters from the selected template.

11 QoS For Socket Groups

The socket group mechanism for specifying QoS priority has been eliminated. Instead, priorities are specified by the ServiceType parameter of the flowspec structure. Applications may use the QOS_PRIORITY object in the ProviderSpecific buffer that accompanies flowspecs, to specify some degree of prioritization within the service class specified by ServiceType.

12 Protocol Chaining

QoS-aware applications are expected to call WSAEnumProtocols to get a list of WSAPROTOCOL_INFO structures, which describe the various protocols (chains) available as service providers. The application should inspect the XP1_QOS_SUPPORTED flag in the dwServiceFlags1 field of each structure to determine whether QoS is supported by the protocol (chain). It may then scan additional fields of the WSAPROTOCOL_INFO, in particular the szProtocol text field, to select a specific QoS provider. The RSVP SP will register the following chains:

These chain configurations are available both to applications using the GQoS interface and to those using the RSVP-specific annex interface.

Specific implementations of RSVP SPs may support additional underlying transport protocols. These will be indicated by the registration of corresponding protocol chains.

13 Appendix A-Sample Call Sequences

In the following paragraphs there are examples of legitimate call sequences that may be invoked by QoS-aware applications. Each sequence is shown to begin with a call to bind. Strictly speaking, this call is not required, except in the case of the passive TCP application calling WSAAccept, as long as the application calls one of the connection-oriented calls (WSAConnect or WSAJoinLeaf). The transport provider will bind on its behalf at that time.

13.1 UDP Unicast Sender, Bound Using INADDR_ANY

In this example, the sending application binds using INADDR_ANY. As a result, the RSVP SP calls WSAIoctl(SIO_LOCAL_INTERFACE_QUERY) as soon as the peer address is available from the application’s call to WSAConnect.

13.2 UDP Unicast Sender Bound to a Specific Address

In this example, the application binds using a specific address. The RSVP SP is not required to call WSAIoctl(SIO_LOCAL_INTERFACE_QUERY), and it will not be responsible for directly handling routing changes. The application must handle routing changes if it wishes to maintain QoS following a routing change. It does so by closing the existing socket and creating a new one, bound to the new address.

13.3 UDP Unicast Sender, QoS Parameters Modified

In this example, a QoS session is initiated according to the QoS parameters supplied by the sender (with the WSAConnect call). The application later modifies the sending QoS by calling WSAIoctl(SIO_SET_QOS) with modified QoS parameters.

13.4 UDP Multicast Sender, QoS Parameters in WSAIoctl

In the following example, a sending UDP application binds a socket using INADDR_ANY . Later it calls WSAJoinLeaf, indicating the destination session address. However, since no QoS parameters are included with the call to WSAJoinLeaf, it does not begin RSVP processing. The application supplies QoS parameters later, with a call to WSAIoctl. At that time, the RSVP SP performs an interface query on the multicast session address to determine which address to use in the SenderTemplate. The RSVP SP is then able to begin sending PATH messages.

13.5 TCP Unicast Sender, QoS Parameters Included With ConditionFunc

In the following example, a unicast TCP sender accepts a connection from a receiving peer. The sender is the passive peer, indicating its preparedness to receive a connection, using WSAAccept. In this example, the ConditionFunc is used by the application to provide QoS parameters to the RSVP SP. The RSVP SP learns of the application’s intent to invoke QoS at this time. Since this is a TCP socket, the RSVP SP can call getsockname to unambiguously obtain the address of the sending interface. This address is used to compose the SenderTemplate and to begin sending PATH messages. The RSVP SP calls getpeername following connection establishment to obtain the remote peer’s address. This address is used to generate the RSVP session address.

13.6 TCP Unicast Sender, WSAAccept Followed by WSAIoctl

In the following example, a unicast TCP sender accepts a connection from a receiving peer. The sender is the passive peer, indicating its preparedness to receive a connection, using WSAAccept. In this example, the ConditionFunc is not used to provide QoS parameters. Instead, the application follows the acceptance of the connection, with a call to WSAIoctl(SIO_SET_QOS). The RSVP SP learns of the application’s intent to invoke QoS at this time. Since this is a TCP socket, the RSVP SP can call getsockname to unambiguously obtain the address of the sending interface. This address is used to compose the SenderTemplate and to begin sending PATH messages. The RSVP SP calls getpeername following connection establishment, to obtain the remote peer’s address. This address is used to generate the RSVP session address.

13.7 TCP Unicast Sender, WSAIoctl Precedes WSAAccept

This example is similar to the previous example, except that the sending application indicates its interest in sending QoS traffic by calling WSAIoctl(SIO_SET_QOS) prior to connection establishment. In this case, the RSVP SP has all the information required to begin transmitting PATH messages upon completion of WSAAccept, which includes the receiving peer’s address. As in the previous example, the RSVP SP generates the SenderTemplate based on the address returned from getsockname and generates the session based on the address returned from getpeername.

13.8 TCP Unicast Sender, Active Sender

In this example, the TCP sender is the active TCP peer. Consequently, the sender calls WSAConnect. This is similar to the UDP sender case, with the exception that the local address and the peer address can be unambiguously determined by calling getsockname and getpeername following connection establishment.

13.9 UDP Receiver, Bound to INADDR_ANY, Followed by WSAConnect

In this example, a receiving application binds using INADDR_ANY. As a result, the RSVP SP will match any PATH messages for which the session port matches the bound socket’s port, and for which the SenderTemplate matches the peer address specified in the connect, regardless of the session address.

If PATH messages were received prior to the WSAConnect, and if they are determined to match, the RSVP SP will begin to send RESV messages immediately following the WSAConnect. This is depicted in the following sequence.

Also in this example, the receiving application issues a WSAConnect. As a result, traffic originating from peers other than the one specified will be discarded by the transport provider.

UDP Receiver, Bound to Specific Address, Followed by WSAIoctl

In this example, the receiving application binds using a specific address. As a result, the RSVP SP will be more discriminating in searching for matching PATH state. It will match only PATH messages for which both the session address and port match the bound socket’s address and port. However, since no sender was specified (no WSAConnect), SenderTemplate will not be considered when searching for matching PATH state.

13.10 UDP Receiver, WSAIoctl Followed by WSAConnect

In the following example, the receiving application calls WSAIoctl(SIO_SET_QOS) to associate QoS parameters with the socket. PATH state is matched at this time, initiating the transmission of WF-style RESV messages. Subsequently, the application calls WSAConnect, specifying a peer sender and causing the RSVP SP to send FF-style RESV messages, selectively, for the specified sender.

13.11 Multicast UDP Receiver, WSAIoctl Followed by WSAJoinLeaf

In the following example, a UDP-receiving application calls WSAIoctl(SIO_SET_QOS) to associate QoS parameters with a multicast socket. Since the socket is multicast and has not yet been joined to a multicast group, no RESV messages will be sent on its behalf. Subsequently, the application calls WSAJoinLeaf to join a multicast group. At this time, PATH state for the multicast group is matched, and the RSVP SP begins sending RESV messages.

13.12 Multicast UDP Receiver, QoS Parameters in WSAJoinLeaf

In this example, QoS parameters are provided at the time the multicast group is joined.

13.13 Unicast TCP Receiver, Active Receiver

This example illustrates the typical case of active receiver. Recall that, for TCP receivers, PATH state will not be matched until the specific sending peer’s address is known. The RSVP SP determines the sending peer’s address by calling getpeername following connection establishment.

13.14 Unicast TCP Receiver, Passive Receiver

This example illustrates the atypical case of a passive receiver. As a passive receiver, the application calls WSAAccept to indicate readiness to accept a connection. In this case, the RSVP SP obtains the peer address by calling getpeername following connection establishment. The peer address returned is used to find matching PATH state for a specific sending peer.

Note that, in this example, the application does not indicate its interest in receiving QoS traffic using the ConditionFunc. Instead, it does so by providing a ReceivingFlowspec with a call to WSAIoctl(SIO_SET_QOS). In this case, the application calls WSAIoctl(SIO_SET_QOS) after the connection is established, delaying the transmission of RESV messages until that time. Alternatively, it may call WSAIoctl(SIO_SET_QOS) before a connection is established.

14 Bibliography

• Windows Sockets 2 Protocol-Specific Annex, rev. 2.0.2, January22, 1996
  
  
• Windows Sockets 2 Application Programming Interface, rev. 2.2.0, May, 1996
  
  
• Windows Sockets 2 Service Provider Interface, rev. 2.2.0, May, 1996
  
  
• IETF Draft of RSVP Protocol, version 14, November 5, 1996
  
  
• The Use of RSVP With Integrated Services (from the INTSERV WG of the IETF)

© 1997 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.

Microsoft and Windows are registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may by the trademarks of their respective owners.