2.3. Dimensione della finestra per le richieste sovrapposte
2.3. Dimensione della finestra per le richieste sovrapposte
La notifica SET_WINDOW_SIZE asserisce che l'endpoint mittente è in grado di mantenere lo stato per più scambi in sospeso, permettendo al destinatario di inviare più richieste prima di ottenere una risposta alla prima. I dati associati a una notifica SET_WINDOW_SIZE DEVONO essere lunghi 4 ottetti e contenere la rappresentazione big endian del numero di messaggi che il mittente promette di mantenere. La dimensione della finestra è sempre uno fino al completamento degli scambi iniziali.
Un endpoint IKE DEVE attendere una risposta a ciascuno dei suoi messaggi prima di inviare un messaggio successivo, a meno che non abbia ricevuto un messaggio Notify SET_WINDOW_SIZE dal proprio peer che lo informa che il peer è pronto a mantenere lo stato per più messaggi in sospeso al fine di consentire una maggiore produttività.
Dopo che un'IKE SA è stata creata, per massimizzare la produttività di IKE, un endpoint IKE PUÒ emettere più richieste prima di ottenere una risposta a qualsiasi di esse, fino al limite impostato dal SET_WINDOW_SIZE del proprio peer. Queste richieste possono incrociarsi sulla rete. Un endpoint IKE DEVE essere pronto ad accettare ed elaborare una richiesta mentre
ha una richiesta in sospeso per evitare un deadlock in questa situazione. Un endpoint IKE può anche accettare ed elaborare più richieste mentre ha una richiesta in sospeso.
Un endpoint IKE NON DEVE superare la dimensione della finestra dichiarata dal peer per le richieste IKE trasmesse. In altre parole, se il risponditore ha dichiarato che la sua dimensione della finestra è N, allora quando l'iniziatore deve effettuare una richiesta X, DEVE attendere fino a quando non ha ricevuto risposte a tutte le richieste fino alla richiesta X-N. Un endpoint IKE DEVE mantenere una copia (o essere in grado di rigenerare esattamente) di ogni richiesta che ha inviato finché non riceve la risposta corrispondente. Un endpoint IKE DEVE mantenere una copia (o essere in grado di rigenerare esattamente) di un numero di risposte precedenti pari alla sua dimensione della finestra dichiarata nel caso in cui la sua risposta sia andata persa e l'iniziatore richieda la sua ritrasmissione ritrasmettendo la richiesta.
Un endpoint IKE che supporta una dimensione della finestra maggiore di uno dovrebbe essere in grado di elaborare le richieste in arrivo fuori ordine per massimizzare le prestazioni in caso di guasti di rete o riordinamento dei pacchetti.
La dimensione della finestra è normalmente una proprietà (possibilmente configurabile) di una particolare implementazione, e non è correlata al controllo di congestione (a differenza della dimensione della finestra in TCP, per esempio). In particolare, ciò che il risponditore dovrebbe fare quando riceve una notifica SET_WINDOW_SIZE contenente un valore inferiore a quello attualmente in vigore non è definito. Quindi, attualmente non c'è modo di ridurre la dimensione della finestra di un'IKE SA esistente; puoi solo aumentarla. Quando si rinegozia un'IKE SA, la nuova IKE SA inizia con una dimensione della finestra pari a 1 finché non viene esplicitamente aumentata inviando una nuova notifica SET_WINDOW_SIZE.
La notifica INVALID_MESSAGE_ID viene inviata quando viene ricevuto un Message ID IKE al di fuori della finestra supportata. Questo messaggio Notify NON DEVE essere inviato in una risposta; la richiesta non valida NON DEVE essere riconosciuta. Invece, informa l'altra parte avviando uno scambio INFORMATIONAL con dati di notifica contenenti il Message ID non valido di quattro ottetti. L'invio di questa notifica è OPZIONALE, e le notifiche di questo tipo DEVONO essere limitate in frequenza.