FLOWSPEC-Struktur (qos.h)
Die FLOWSPEC-Struktur stellt Qualitätsparameter für den RSVP SP bereit. Dadurch können QOS-fähige Anwendungen QOS-Einstellungen für einen bestimmten Flow aufrufen, ändern oder entfernen. Einige Member von FLOWSPEC können auf Standardwerte festgelegt werden. Weitere Informationen finden Sie unter Hinweise.
Syntax
typedef struct _flowspec {
ULONG TokenRate;
ULONG TokenBucketSize;
ULONG PeakBandwidth;
ULONG Latency;
ULONG DelayVariation;
SERVICETYPE ServiceType;
ULONG MaxSduSize;
ULONG MinimumPolicedSize;
} FLOWSPEC, *PFLOWSPEC, *LPFLOWSPEC;
Member
TokenRate
Gibt die zulässige Rate an, mit der Daten über die Lebensdauer des Flusses übertragen werden können. Das TokenRate-Element ähnelt anderen Tokenbucketsmodellen, die in WAN-Technologien wie Frame Relay zu sehen sind, bei denen das Token analog zu einem Guthaben ist. Wenn solche Token nicht sofort verwendet werden, können sie die Datenübertragung bis zu einem bestimmten periodischen Grenzwert ermöglichen (PeakBandwidth, im Fall der Dienstqualität von Windows 2000). Die Anrechnung von Guthaben ist jedoch auf einen bestimmten Betrag (TokenBucketSize) beschränkt. Durch das Einschränken der Gesamtguthaben (Token) werden Situationen vermieden, in denen beispielsweise Flows, die für einige Zeit inaktiv sind, die verfügbare Bandbreite mit ihrer großen Menge an aufgelaufenen Token überfluten. Da Flows im Laufe der Zeit Übertragungsgutschriften (mit ihrem TokenRate-Wert ) nur bis zum Maximum ihres TokenBucketSize-Werts ansammeln können, und da sie in Burstübertragungen auf ihre PeakBandwidth beschränkt sind, werden die Datenverkehrssteuerung und die Ressourcenintegrität des Netzwerkgeräts beibehalten. Die Steuerung des Datenverkehrs wird beibehalten, da Flows nicht zu viele Daten gleichzeitig senden können, und die Ressourcenintegrität von Netzwerkgeräten wird beibehalten, da solche Geräte von Bursts mit hohem Datenverkehr verschont bleiben.
Mit diesem Modell können Anwendungen Daten nur übertragen, wenn genügend Guthaben verfügbar ist. Wenn keine ausreichenden Gutschriften verfügbar sind, muss die Anwendung den Datenverkehr entweder warten oder verwerfen (basierend auf dem Wert von QOS_SD_MODE). Daher ist es wichtig, dass Anwendungen ihre TokenRate-Anforderungen auf vernünftige Erwartungen an die Übertragungsanforderungen stützen. In Videoanwendungen wird TokenRate z. B. in der Regel auf die durchschnittliche Bitrate von Peak zu Peak festgelegt.
Wenn TokenRate nur für den Empfänger auf QOS_NOT_SPECIFIED festgelegt ist, wird die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) für TokenRate verwendet, und grenzwerte für die Übertragungsrate (das Tokenbucketmodell) werden nicht wirksam. Daher wird TokenRate in Bytes pro Sekunde ausgedrückt.
Der TokenRate-Member kann nicht auf 0 festgelegt werden. Es kann auch nicht als Standard (d. h. auf QOS_NOT_SPECIFIED festgelegt) in einem sendenden FLOWSPEC festgelegt werden.
TokenBucketSize
Die maximale Anzahl von Guthaben, die eine bestimmte Richtung eines Flusses erhalten kann, unabhängig von der Zeit, in Byte. In Videoanwendungen ist TokenBucketSize wahrscheinlich die größte durchschnittliche Framegröße. In Anwendungen mit konstanter Rate sollte TokenBucketSize so festgelegt werden, dass kleine Variationen möglich sind.
PeakBandwidth
Die Obergrenze für die zeitbasierte Übertragungsberechtigung für einen bestimmten Flow in Bytes pro Sekunde. Das PeakBandwidth-Element schränkt Datenflüsse ein, die möglicherweise eine erhebliche Menge an Übertragungsguthaben oder Token aus der Überlastung von Netzwerkressourcen mit einmaligen oder zyklischen Daten bursts erhalten haben, indem eine Datenübertragungsgrenze pro Sekunde erzwungen wird. Einige Zwischensysteme können diese Informationen nutzen, was zu einer effizienteren Ressourcenzuordnung führt.
Latency
Maximal zulässige Verzögerung zwischen der Übertragung eines Bits durch den Absender und dem Empfang durch einen oder mehrere beabsichtigte Empfänger in Mikrosekunden. Die genaue Interpretation dieser Zahl hängt von der in der QOS-Anforderung angegebenen Garantiestufe ab.
DelayVariation
Unterschied zwischen der maximalen und der minimalen möglichen Verzögerung eines Pakets in Mikrosekunden. Anwendungen verwenden DelayVariation , um den puffernden Speicherplatz zu bestimmen, der am empfangenden Ende des Flows benötigt wird. Diese Pufferspeicherplatzinformationen können verwendet werden, um das ursprüngliche Datenübertragungsmuster wiederherzustellen.
ServiceType
Gibt die Dienstebene an, die für den Flow ausgehandelt werden soll. Das ServiceType-Element kann einer der folgenden definierten Diensttypen sein.
| Wert | Bedeutung |
|---|---|
|
Gibt an, dass kein Datenverkehr in die angegebene Richtung übertragen wird. Auf duplexfähigen Medien signalisiert dieser Wert der zugrunde liegenden Software, nur unidirektionale Verbindungen einzurichten. Dieser Diensttyp ist für die TC-API ungültig. |
|
Führt dazu, dass keine Aktion vom RSVP SP ausgeführt wird. Die Verkehrssteuerung erstellt jedoch einen BESTEFFORT-Fluss, und der Datenverkehr im Flow wird ähnlich wie anderer BESTEFFORT-Datenverkehr von der Verkehrssteuerung verarbeitet. |
|
Stellt ein End-to-End-QOS bereit, das die Übertragungsqualität, die vom Dienst mit optimalem Aufwand bereitgestellt wird, genau annähert, wie unter entladenen Bedingungen von den zugeordneten Netzwerkkomponenten entlang des Datenpfads erwartet.
Anwendungen, die SERVICETYPE_CONTROLLEDLOAD verwenden, können daher Folgendes annehmen:
|
|
Garantiert, dass Datagramme innerhalb der garantierten Lieferzeit eintreffen und aufgrund von Warteschlangenüberläufen nicht verworfen werden, sofern der Datenverkehr des Flows innerhalb der angegebenen Verkehrsparameter bleibt. Dieser Dienst ist für Anwendungen vorgesehen, die eine feste Garantie dafür benötigen, dass ein Datagramm spätestens zu einem bestimmten Zeitpunkt nach der Übertragung durch seine Quelle eintrifft. |
|
Gibt an, dass die Anwendung eine bessere Als BESTEFFORT-Übertragung erfordert, ihre Übertragungsanforderungen jedoch nicht quantifizieren kann. Anwendungen, die SERVICETYPE_QUALITATIVE verwenden, können ein Anwendungsbezeichnerrichtlinienobjekt bereitstellen. Das Anwendungsidentifikationsrichtlinienobjekt ermöglicht es Richtlinienservern im Netzwerk, die Anwendung zu identifizieren und der Anforderung entsprechend eine geeignete Dienstqualität zuzuweisen. Weitere Informationen zur Anwendungsidentifikation finden Sie im IETF Internet Draft draft-ietf-rap-rsvp-appid-00.txt oder im Microsoft-Whitepaper zur Anwendungsidentifikation. Die Datenverkehrssteuerung behandelt Flows dieses Typs mit der gleichen Priorität wie BESTEFFORT-Datenverkehr auf dem lokalen Computer. Anwendungsprogrammierer können jedoch eine höhere Priorität für solche Flows erhalten, indem sie die Layer 2-Einstellungen für den zugeordneten Flow mithilfe des QOS_TRAFFIC_CLASS QOS-Objekts ändern. |
|
Wird verwendet, um Netzwerkänderungen zu benachrichtigen. |
|
Wird nur für die Übertragung von Steuerungspaketen (z. B. RSVP-Signalmeldungen) verwendet. Dieser ServiceType hat die höchste Priorität. |
|
Gibt an, dass alle Diensttypen für einen Flow unterstützt werden. Kann nur auf Absenderseite verwendet werden. |
|
Gibt an, dass die Dienstqualität bei der Übertragung mit diesem ServiceType-Wert nicht geändert wird. SERVICETYPE_NOCHANGE kann verwendet werden, wenn eine Änderung der Dienstqualität nur für eine Richtung oder nur innerhalb der ProviderSpec-Parameter einer QOS-Spezifikation und nicht in der SendingFlowspec oder ReceiveingFlowspec angefordert wird. |
|
Wird verwendet, um nicht konformen Datenverkehr anzugeben. |
|
Gibt an, dass die Datenverkehrssteuerung nicht in der angegebenen Richtung aufgerufen werden soll. |
|
Unterdrückt RSVP-Signalisierung in der angegebenen Richtung. |
In der folgenden Liste wird die relative Priorität der ServiceType-Einstellungen angegeben:
SERVICETYPE_NETWORK_CONTROL
SERVICETYPE_GUARANTEED
SERVICETYPE_CONTROLLED_LOAD
SERVICETYPE_BESTEFFORT
SERVICETYPE_QUALITATIVE
Nicht konformer Datenverkehr
Ein einfaches Beispiel: Wenn ein bestimmtes Netzwerkgerät ressourcengebunden wäre und sich zwischen der Übertragung eines Pakets aus einer der oben genannten ServiceType-Einstellungen entscheiden müsste, würde es zuerst ein Paket mit SERVICETYPE_NETWORKCONTROL senden, und wenn keine Pakete dieses ServiceType-Typs vorhanden wären, die eine Übertragung erfordern, würde es ein ServiceType-Paket SERVICETYPE_GUARANTEED usw. senden.
MaxSduSize
Gibt die maximal zulässige oder im Datenverkehrsfluss verwendete Paketgröße in Bytes an.
MinimumPolicedSize
Gibt die Mindestpaketgröße an, für die die angeforderte Dienstqualität in Bytes bereitgestellt wird. Pakete, die kleiner als diese Größe sind, werden von der Datenverkehrssteuerung als MinimumPolicedSize behandelt. Wenn Sie die FLOWSPEC-Struktur in Verbindung mit RSVP verwenden, darf der Wert von MinimumPolicedSize nicht null sein. Wenn Sie jedoch die FLOWSPEC-Struktur speziell mit der TC-API verwenden, können Sie MinimumPolicedSize auf Null festlegen.
Hinweise
Viele Member der FLOWSPEC-Struktur können auf Standardwerte festgelegt werden, indem das Element auf QOS_NOT_SPECIFIED festgelegt wird. Beachten Sie, dass die Member, die auf Standardwerte festgelegt werden können, je nachdem, ob es sich bei FLOWSPEC um eine empfangende FLOWSPEC oder eine sendende FLOWSPEC handelt.
Es gibt eine Reihe von Überlegungen, die Sie berücksichtigen sollten, wenn Sie FLOWSPEC mit Verkehrssteuerung verwenden:
- TokenRate kann für SERVICETYPE_NETWORKCONTROL, SERVICETYPE_QUALITATIVE und SERVICETYPE_BESTEFFORT QOS_NOT_SPECIFIED werden. TokenRate muss für alle anderen ServiceType-Werte gültig sein.
- Wenn PeakBandwidth angegeben ist, muss es größer oder gleich TokenRate sein.
- Für einen Controlled Load Service-Empfänger werden die Standardwerte von der TSPEC des Absenders abgeleitet.
- Für einen Garantierten Dienstempfänger müssen ServiceType und TokenRate angegeben werden.
Wenn der Wert von ServiceType auf SERVICETYPE_GUARANTEED festgelegt ist, gilt auch Folgendes:
- Der RATE-Wert in RSPEC wird auf den Wert von TokenRate festgelegt.
- Der DELAYSLACKTERM-Wert in RSPEC ist auf DelayVariation festgelegt, der auf Null festgelegt wird, wenn DelayVariation auf QOS_NOT_SPECIFIED festgelegt ist.
- Für Empfänger, die SERVICETYPE_GUARANTEED anfordern, muss die empfangende TokenRate angegeben werden. Dies steht im Gegensatz zu einem SERVICETYPE_CONTROLLEDLOAD-Empfänger, für den TokenRate auf QOS_NOT_SPECIFIED festgelegt werden kann.
Datenverkehrssteuerung: Die folgenden ServiceTypessind ungültig, wenn sie speziell mit Traffic Control arbeiten. Wenn Sie nicht sicher sind, ob Sie direkt mit Traffic Control arbeiten (und sich dabei Gedanken darüber machen müssen, ob die folgenden ServiceTypesin Ihrer Situation anwendbar sind), sind Sie wahrscheinlich nicht:
- SERVICE_NO_TRAFFIC_CONTROL
- SERVICE_NO_QOS_SIGNALING
- SERVICETYPE_GENERAL_INFORMATION
- SERVICETYPE_NETWORK_UNAVAILABLE
- SERVICETYPE_NOCHANGE
- SERVICETYPE_NOTRAFFIC
Anforderungen
| Anforderung | Wert |
|---|---|
| Unterstützte Mindestversion (Client) | Windows 2000 Professional [nur Desktop-Apps] |
| Unterstützte Mindestversion (Server) | Windows 2000 Server [nur Desktop-Apps] |
| Kopfzeile | qos.h |
Weitere Informationen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für