Inizialmente, le sessioni APPN (Advanced Peer-to-Peer Networking) supportavano solo le connessioni peer-to-peer??? utilizzando le connessioni LU (Logical Unit) 6.2. Tuttavia, la funzionalità APPN è valida anche se la rete è in grado di supportare il traffico SNA (Systems Network Architecture) legacy (ad esempio LU 0, 1, 2).
In APPN, non esiste più il concetto di fine primaria e secondaria di una sessione. Qualunque endpoint scelga di avviare la sessione diventa il principale e invia l'operazione BIND. Con il traffico SNA legacy, tuttavia, l'estremità secondaria chiede al metodo di accesso alle telecomunicazioni virtuali (VTAM) di avviare la sessione. Non esiste alcun concetto di nodo che non sia in grado di inviare BIND in APPN. Per questo motivo, è necessario un supporto speciale per le LU secondarie legacy che non possono emettere BIND.
Il richiedente/server (DLUR/DLUS) LU dipendente risolve il problema delle LU dipendenti nelle reti APPN, dove il server è implementato in VTAM 4.2 e il richiedente può trovarsi in un nodo di rete (NN) o in un nodo finale (EN) nella rete.
Nessun requisito specifico previsto per questo documento.
Il documento può essere consultato per tutte le versioni software o hardware.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Viene stabilita una coppia di sessioni LU 6.2 tra il flusso DLUR e il flusso di controllo DLUS (come Activate LU, Deactivate LU, Activate physical unit (PU), Deactivate PU, LOGON, INITIATE) su queste sessioni tra DLUS e DLUR. Il DLUR trasmette i messaggi alle risorse appropriate.
Le LU secondarie dipendenti (Secondary Dependent LU, DLU) possono avviare sessioni inviando una richiesta di avvio alla DLUR, che quindi la mette su una delle pipe della LU 6.2.
Una volta che la richiesta della sessione viene trasmessa, le comunicazioni DLUS e DLUR sono completate.
Una volta che VTAM/DLUS riceve la richiesta di sessione, il VTAM determina la posizione dell'applicazione e invia una richiesta CDINIT-LOCATE all'host dell'applicazione, richiedendo l'invio di un BIND al database secondario.
Questo supporto in APPN VTAM è noto come Session Services Extensions, il che implica che i servizi di sessione SNA legacy sono stati inviati ad APPN.
Le estensioni del servizio di sessione supportano inoltre l'avvio e l'accodamento di sessioni di terze parti fino a quando non diventa disponibile un partner di sessione, oltre a una sessione secondaria avviata.
Una volta che l'applicazione riceve la notifica che deve inviare BIND a una LU legacy, BIND viene inviato attraverso la rete APPN. Non è incapsulato. Il traffico SNA legacy e il traffico APPN utilizzano la stessa intestazione SNA e possono coesistere sulla rete APPN.
Sebbene il VTAM sia a conoscenza dell'avvio della sessione, il traffico di sessione non deve passare attraverso il VTAM o il router CIP (Channel Interface Processor) collegato. Utilizzando gli algoritmi APPN, l'amministratore di rete che fornisce funzionalità server di rete all'host applicazioni seleziona il miglior percorso attraverso la rete, che fornisce la classe di servizio (CoS) appropriata.
Quando viene ricevuta un'identificazione di scambio (XID), DLUR segnala ai punti di controllo dei servizi di sistema (SSCP) che i relativi servizi sono necessari inviando una richiesta di attivazione di un'unità fisica (REQACTPU) alla DLUS. Successivamente, DLUS emette la richiesta ACTPU.
Figura 6
In questo flusso, Branch Network Node/DLUR (BrNN/DLUR) ha ricevuto un XID dall'unità di elaborazione a valle, che indica a DLUR di richiedere i servizi SSCP da DLUS. In tutti gli XID02 o XID32 il bit di richiesta ACTPU è impostato, quindi REQACTPU è stato inviato. Se non è attiva alcuna "pipe", viene inviata prima una richiesta BIND 'individuate' per avviare la pipe.
DLUS restituisce quindi la risposta positiva +RSP REQACTPU seguita dalla richiesta ACTPU.
DLUR fornisce il supporto per l'arresto automatico della rete (ANS) in modo simile al supporto ANS fornito da NCP (Network Control Program). Se è stata attivata una CPU con ANS = CONT specificato, tutte le sessioni LU-LU esistenti vengono mantenute al termine della pipe.
DLUR rifiuta qualsiasi traffico SSCP-PU/LU proveniente dal dispositivo dipendente.
A seconda della successiva attivazione del dispositivo dipendente, DLUR può interrompere la sessione LU-LU.
Nella Figura 7, tutte le sessioni (SSCP-PU, SSCP-LU e LU-LU) sono state stabilite e i dati scorrono attraverso la sessione LU-LU.
Nella Figura 8, si è verificata un'interruzione della rete che ha interrotto le pipe DLUs-DLUR e, di conseguenza, la sessione SSCP-PU e SSCP-LU.
La sessione LU-LU continua, in quanto non passa attraverso il router Cisco CIP-N interessato.
Nella Figura 9, le DLUS di backup iniziano a subentrare, vengono stabilite le pipe, vengono attivate le risorse (ACTPU, un'unità logica attiva [ACTLU]) e DLUR invia le informazioni sulla sessione (unità logica primaria [PLU], LU1) su una risposta ACTLU.
Le sessioni vengono ora ristabilite tramite il nuovo SSCP. Le successive sessioni LU-LU determineranno il riconoscimento della sessione da DLUR a VTAM3.
Quando si verifica il ripristino in VTAM1, può verificarsi un riavvio e le sessioni SSCP-PU e SSCP-LU possono essere disattivate dalla VTAM3 e riattivate dalla VTAM1, ripristinando la configurazione originale senza interrompere le sessioni LU-LU.