2.3. Fenstergröße für überlappende Anfragen
2.3. Fenstergröße für überlappende Anfragen
Die SET_WINDOW_SIZE-Benachrichtigung besagt, dass der sendende Endpunkt in der Lage ist, Zustand für mehrere laufende Austausche zu behalten, was dem Empfänger erlaubt, mehrere Anfragen zu senden, bevor er eine Antwort auf die erste erhält. Die mit einer SET_WINDOW_SIZE- Benachrichtigung verbundenen Daten MÜSSEN eine Länge von 4 Oktetten haben und die Big-Endian-Darstellung der Anzahl der Nachrichten enthalten, die der Sender zu behalten verspricht. Die Fenstergröße ist immer eins, bis die anfänglichen Austausche abgeschlossen sind.
Ein IKE-Endpunkt MUSS auf eine Antwort zu jeder seiner Nachrichten warten, bevor er eine nachfolgende Nachricht sendet, es sei denn, er hat eine Notify-Nachricht SET_WINDOW_SIZE von seinem Peer erhalten, die ihn darüber informiert, dass der Peer bereit ist, Zustand für mehrere laufende Nachrichten zu halten, um einen höheren Durchsatz zu ermöglichen.
Nachdem eine IKE SA etabliert ist, kann ein IKE-Endpunkt, um den IKE- Durchsatz zu maximieren, mehrere Anfragen senden, bevor er eine Antwort auf eine davon erhält, bis zum durch die SET_WINDOW_SIZE des Peers gesetzten Limit. Diese Anfragen können sich im Netzwerk überkreuzen. Ein IKE-Endpunkt MUSS bereit sein, eine Anfrage zu akzeptieren und zu verarbeiten, während er bereits eine in Bearbeitung hat, um einen Stillstand in dieser Situation zu vermeiden. Ein IKE-Endpunkt kann auch mehrere Anfragen akzeptieren und verarbeiten, während er bereits eine in Bearbeitung hat.
Ein IKE-Endpunkt DARF das vom Peer deklarierte Fenster für übertragene IKE-Anfragen nicht überschreiten. Mit anderen Worten, wenn der Responder eine Fenstergröße von N deklariert hat, dann muss der Initiator, wenn er eine Anfrage X stellen muss, darauf warten, die Antworten auf alle Anfragen bis einschließlich der Anfrage X-N erhalten zu haben. Ein IKE-Endpunkt MUSS eine Kopie von (oder in der Lage sein, exakt zu regenerieren) jeder gesendeten Anfrage behalten, bis er die entsprechende Antwort erhält. Ein IKE-Endpunkt MUSS eine Kopie von (oder in der Lage sein, exakt zu regenerieren) der Anzahl vorheriger Antworten gleich seiner deklarierten Fenstergröße behalten, für den Fall, dass seine Antwort verloren geht und der Initiator ihre Retransmission anfordert, indem er die Anfrage retransmittiert.
Ein IKE-Endpunkt, der eine Fenstergröße größer als eins unterstützt, sollte in der Lage sein, eingehende Anfragen außerhalb der Reihenfolge zu verarbeiten, um die Leistung bei Netzwerkausfällen oder Paketumordnung zu maximieren.
Die Fenstergröße ist normalerweise eine (möglicherweise konfigurierbare) Eigenschaft einer bestimmten Implementierung und nicht mit Congestion Control verknüpft (im Gegensatz zur Fenstergröße in TCP beispielsweise). Insbesondere ist nicht definiert, was der Responder tun soll, wenn er eine SET_WINDOW_SIZE-Benachrichtigung mit einem kleineren Wert als dem aktuell gültigen empfängt. Somit gibt es derzeit keine Möglichkeit, die Fenstergröße einer bestehenden IKE SA zu verringern; man kann sie nur erhöhen. Beim Neu-Schlüsseln einer IKE SA startet die neue IKE SA mit einer Fenstergröße von 1, bis sie explizit durch Senden einer neuen SET_WINDOW_SIZE-Benachrichtigung erhöht wird.
Die INVALID_MESSAGE_ID-Benachrichtigung wird gesendet, wenn eine außerhalb des unterstützten Fensters liegende IKE Message ID empfangen wird. Diese Notify-Nachricht DARF NICHT in einer Antwort gesendet werden; die ungültige Anfrage DARF NICHT bestätigt werden. Stattdessen informieren Sie die andere Partei, indem Sie einen INFORMATIONAL- Austausch initiieren, dessen Benachrichtigungsdaten die ungültige vier-Oktett-Message-ID enthalten. Das Senden dieser Benachrichtigung ist OPTIONAL, und Benachrichtigungen dieses Typs MÜSSEN in ihrem Durchsatz begrenzt werden.