Platform SDK: Quality of Service |
RSVP establishes QOS-enabled connections through the use of PATH and RESV messages. A short explanation of each, and how they pertain to Windows 2000 QOS and the RSVP SP is merited. For a thorough explanation and discussion of RSVP PATH and RESV messages, consult IETF RFC 2205.
When a QOS-enabled connection is established and RSVP signaling is triggered (see Invoking RSVP), the sender and receiver(s) play specific roles in the establishment of an RSVP session:
The information contained in the PATH and RESV messages is derived from the FLOWSPEC structures associated with the SendingFlowspec and ReceivingFlowspec members of the QOS structure.
When a PATH message is received, the RSVP SP creates an RSVP session and associates a PATH state (based on the PATH message) with the RSVP session. The RSVP SP sends RESV messages once it determines that the PATH state exists for a session that matches a socket for which receiving QOS is indicated. In the absence of a received PATH message, the RSVP SP creates an RSVP session using QOS parameters (and thereby, QOS is invoked) on a receive socket. In this latter case, PATH state is not associated with the session until a matching PATH message is received.
The transmission of RESV messages, therefore, may be triggered by the following circumstances:
RSVP PATH messages derive their RSVP sender Tspec from the SendingFlowspec member of the QOS structure (the SendingFlowspec member of QOS is itself a FLOWSPEC structure).
The following table outlines the information required to begin transmission of RSVP PATH messages, and how the information is derived from the QOS structure or other information provided by the sender. The RSVP PATH parameters discussed serve the following purposes:
RSVP PATH parameter | Equivalent receiver–based parameters |
---|---|
SenderTspec | SendingFlowspec member of the QOS structure. |
SenderTemplate | Source IP address/port to which sending socket is bound. |
Session | Destination IP address/port and protocol identifier to which the socket is sending (sockaddr_in). |
Note that the RSVP session parameter includes specification of the protocol identifier can be UDP or TCP. The type of socket on which the QOS-enabled connection is being invoked determines the protocol identifier.
RSVP RESV messages derive their RSVP FLOWSPEC parameters from the ReceivingFlowspec member of the QOS structure (the ReceivingFlowspec member of QOS is itself a FLOWSPEC structure).
The following table outlines the information required to begin transmission of RSVP RESV messages, and how the information is derived from the QOS structure or other information provided by the receiver. The RSVP RESV parameters discussed serve the following purposes:
RSVP RESV parameter | Derived from the following Winsock parameter |
---|---|
flowspec | ReceivingFlowspec member of the QOS structure or the ProviderSpecific buffer. |
Filterspec (source(s) from which QOS traffic will be received). | Address(es) of peer(s) from which the socket is receiving. |
Session (destination of sent traffic). | Local IP address and port to which the receiving socket is bound (unicast), or multicast session address to which the socket has joined (multicast). |
The WF reservation style RESV messages do not have any filterspecs, so receivers need not supply the sender an IP address.