Network Working Group Juha Heinanen Reguest for Comments: 1483 Telecom Finland July 1993 Traduzione a cura di Jinko - jinko.hmn@gmail.com (Maggio 2007) Distribuita da .::http://www.rfc.altervista.org::. Incapsulazione Multiprotocollo su ATM Adaptation Layer 5 Stato di questo Documento Questo documento specifica una traccia di protocollo Internet standard per la comunita? Internet, e richiede discussioni e suggerimenti per migliorie. Per la standardizzazione e lo stato di questo protocollo si faccia riferimento all?edizione corrente dell'"Internet Official Protocol Standards". La distribuzione di questo documento non e' soggetta a limitazioni. Sunto Questo appunto descrive due metodi di incapsulazione per il collegamento alla rete con traffico trasportato su ATM AAL5. Il primo metodo permette il multiplexing di protocolli multipli sun un singolo circuito virtuale ATM, mentre il secondo metodo assume che ogni protocollo sia rinviato in un circuito virtuale ATM separato. 1. Introduzione Le reti basate su una modalita' di trasferimento asincrono (ATM) hanno sviluppato un crescente interesse per applicazioni su aree estese e locali. Questo appunto descrive due metodi differenti, per il collegamento alla rete con traffico trasportato, con connessioni di tipo Routed e bridged Protol data Units (PDUs), su una rete ATM. Il primo metodo permette il multiplexing di protocolli multipli sun un singolo circuito virtuale ATM. Il protocollo di un trasporto PDU viene identificato dal prefisso PDU e dall'intestazione IEEE. 802.2 Controllo Collegamento Logico (LLC). Il metodo e seguentemente chimato "Incapsulazione LLC" e un sottinsieme di esso e' stato ben presto definito per SMSDS [1]. Il secondo metodo e' implicitamente multiplexato dal protocollo di strato piu' alto dal circuito virtuale ATM (VCs). Questo viene in seguito denominato "VC Based Multiplexing". L'ATM e' un metodo di trasferimento basato su cella che richiede informazioni sulla lunghezza della variabile dell'utente, e viene segmentata e riassemblata dalle celle di lunghezza stabilita. questo appunto non specifica un nuovo metodo di segmentazione e riassemblaggio (SAR) per PDU di tipo Bridged e Routed. Invece, i PDU sono trasportati nel capo Payload delommon Part Convergence Sublayer (CPCS) PDU dell' ATM Adaptation Layer type 5 (AAL5) [2]. Si noti che questo appunto decrive solo come i PDU routed e Bridged sono direttamente trasportati sul CPCS del AAL5,quando il servizio Specific Convergence Sublayer (SSCS) di AAL5 e' vuoto. Se il Frame Relay Service Specific Convergence Sublayer (FR-SSCS), come definito in I.36x.1 [3], e' usato su il CPCS di AAL5, dopo i PDU Routed e Bridged sono trasportati usando il metodo di multiplexing NLPID descritto nella RFC 1294 [4]. L' appendice A (la quale e' solo per informazione) mostra il formato del FR-SSCS-PDU cosi' come sono incapsulati IP e CLNP su FR-SSCS in accordo con l' RFC 1294. 2. Selezione del Metodo di Multiplexing E' previsto che il multiplexing basato su VC, sara' dominante negli ambienti dove la creazione dinamica di un largo numero di ATM VCs e' veloce ed economica. Queste condizioni sono probabilmente le prime a prevalere in reti ATM private. L'incapsulazione LLC, d'altra parte, puo' essere desiderabile quando non e' pratico per una ragione o per l'altra avere un VC separato per ogni protocollo trasportato. Questo e' il caso, per esempio, se la rete ATN supporta solo Cirtuiti Virtuali (semi) Permanenti (PVCs) o se il caricarsi diventa pesante sul numero simultaneo di VCs. Quando due stazioni ATM vogliono scambiare traffico collegato alla rete connectionless, la selezione di multiplexing viene fatta da entrambi tramite configurazione manuale (in caso dei PVC) o da segnalazione delle procedure B-ISDN (in caso di VC switchati). I dettagli di segnalzione B-ISDN sono ancora sotto studio nel CCITT [5]. Puo', tuttavia, essere presupposto che, i messaggi di segnalzione B-ISDN contentongo elementi di informzione della compatibilita' di basso livello, il quale permettera' la negoziazione AAL5 e il trasporto (incapsulazione) del protocollo. 3. Disposizione della struttura AAL5 Nessuna difficolta' quando il metodo multiplexing viene selezionato, PDU routed e bridged saranno incapsulati dentro il capo Payload del AAL5 CPCS-PDU. La struttura di AAL5 CPCS-PDU รจ mostrata sotto: Formato AAL5 CPCS-PDU +-------------------------------+ | . | | . | | CPCS-PDU Payload | | fino a 2^16 - 1 ottetti) | | . | | . | +-------------------------------+ | PAD ( 0 - 47 ottetti) | +-------------------------------+ ------- | CPCS-UU (1 ottetto) | +-------------------------------+ | CPI (1 ottetto) | +-------------------------------+CPCS-PDU Trailer | Lunghezza (2 ottetti) | +-------------------------------| | CRC (4 ottetti) | +-------------------------------+ ------- Il campo Payload contiene le informazioni utente fino a 2^16 - 1 ottetti. Il campo PAD adatta i CPCS-PDU per inserirli esattamente nelle celle dell'ATM tali che l'ultimo Payload delle celle dei 48 ottetti generato dal sublayer di SAR, avremo il giusto pezzo di CPCS-PDU, giustificato nelle celle. Il campo CPCS-UU (User-to-User indication), viene usato per trasferire in modo trasparente le informazioni CPCS user to user. Il campo non ha funzione sotto il multiprotocollo di incapsulazione ATM descritto in questo appunto e quindi puo' essere settato con qualunque valore. Il campo CPI (Common Part Indicator) allineato alla parte di CPCS-PDU di 64 bits. Le possibili funzioni addizionali sono per ulteriori studi in CCITT. Quando solo la funzione di allineamento dei 64 bit viene usata , questo campo sara' codificato come 0x00. La lunghezza del campo indica la lunghezza, in ottetti, del campo Payload. Il massimo valore per la lunghezza di questo campo e' 65535 ottetti. La lunghezza del capo codificata come 0x00 viene usata per le funzioni di terminazione. Il campo CRC protegge l'intero CPCS-PDU eccetto il campo CPU in se stesso. 4. Incapsulamento LLC L'incapsulamento LLC e' necessario quando vari protocolli sono trasportati sullo stesso VC. Per permettere che il ricevente processi correttamente il CPCS_PDU ricevuto, il campo Payload deve contenere le informazioni necessarie ad identificare il protocollo di PDU routed o bridged. Nell'incapsulamento LLC questa informazione e messa in un'intestazione LLC posta davanti il PDU trasportato. Anche se questo appunto si occupa solo dei protocolli che operano su LLC Servizio di tipo 1 (unacknowledged connectionless mode), lo stesso incapsulamento applicato solo ai protocolli operanti su LLC Servizio di tipo 2 (connection-mode). In ultimo caso l'intestazione e/o il contenuto dell'intestazione LLC , differirebbe da quanto indicato sotto. 4.1 Incapsulamento LLC per Protocolli Routed Nell'incapsulamento LLC il protocollo del PDU Routed identificato premettendo il PDU da un'intestazione del LLC dello IEEE 802.2, il quale e' possibilmente seguito da uno IEEE 802.1a. dall'intestazione SubNetwork Attachment Point (SNAP). Nell'operazione LLC di tipo 1, l'intestazione LLC consiste in tre campi di un ottetto: +------+------+------+ | DSAP | SSAP | Ctrl | +------+------+------+ Nell'intestazione LLC per protocolli Routed, il campo di controllo ha sempre il valore 0x03 che specifica l'ordine delle informazioni non numerate del PDU. Il valore 0xFE-FE-03 dell'intestazione LLC indica che segue un routed ISO PDU (vedasi [6] e l'Appendice B). Il valore 0x03 del campo di controllo specifica l'ordine delle informazioni non numerata del PDU. Per i routed ISO PDU la struttura del campo AAL5 CPCS-PDU del Payload risulta essere la seguente: Formato Payload per ISO PDUs Routed +-------------------------------+ | LLC 0xFE-FE-03 | +-------------------------------+ | . | | ISO PDU | | (fino a 2^16 - 4 ottetti) | | . | +-------------------------------+ Il protocollo ISO routed viene identificato da un campo NLPID di un ottetto che fa parte del Protocol Data. I valori di NLPID sono amministrati dal CCITT e dall'ISO. Sono definiti nell'ISO/IEC TR 9577 [6] e alcuni di quelli correntemente definiti sono elencati nell'Appendice C. Un valore 00x00 di NLPID viene definito nell'ISO/IEC TR 9577 come Livello Nullo della Rete o Insieme Inattivo. Poiche' non ha importanza all'interno del contesto di questo schema di incapsulamento, un valore 0x00 dell' NLPID non e' valido sotto l'incapsulazione ATM. Inoltre sarebbe possibile usare il suddetto incapsulamento per l'IP, poiche', anche se non un protocollo ISO, l'IP ha un valore 0x00 di NLPID definito per esso. Questa disposizione non deve essere usata. Invece, l'Ip e' incapsulato come tutti gli altri protocolli routed non-ISO identificandolo nell'intestazione SNAP che immeditamente segue l'intestazione LLC. La presenza di un intestazione SNAP viene identificata dal valore 0xAA-AA-03 nell'intestazione LLC. Un intestazione SNAP e' della forma: +------+------+------+------+------+ | OUI | PID | +------+------+------+------+------+ L'identificativo unico del tre-ottetto (OUI), identifica un'organizzione che amministra il significato dei seguenti due ottetti del Protocollo di Identificazione (PID). Insieme identificano un distinto protocollo routed o bridged. Il valore 0x00--00-00 di OUI specifica che il seguente PID e' Ethertype. La struttura del campo AAL5 CPCS-PDU Payload per i PDU routed non-ISO, risulta essere il seguente: Formato Payload per non-ISO PDUs Routed +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-00-00 | +-------------------------------+ | EtherType (2 ottetti) | +-------------------------------+ | . | | Non-ISO PDU | | (fino a 2^16 - 9 ottetti) | | . | +-------------------------------+ Nel caso particolare di un Internet IP PDU, il valore di ethertype e' 0x08-00: Formato Payload per IP PDUs Routed +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-00-00 | +-------------------------------+ | EtherType 0x08-00 | +-------------------------------+ | . | | IP PDU | | (fino a 2^16 - 9 ottetti) | | . | +-------------------------------+ Questo risulta compatibile con l'RFC 1042 [7], Tutti i cambiamenti nella disposizione dell'intestazione specificata nell' RFC 1042 dovrebbero essere seguiti da questo appunto. 4.2 Incapsulazione LLC per Protocolli Bridged Nell'incapsulazione LLC bridged i PDU sono incapsulati identificando nell'intestazione di SNAP il tipo di mezzo di comunicazione bridged. Come nel protocollo routed non-ISO, la presenza dell'intestazione SNAP e' indicata dal valore 0xAA-AA-03 dell'intestazione LLC. Con i protocolli Bridged il valore dell'OUI dell'instestazione SNAP e' il codice 0x00-80-C2 dell'organizzazione 802.1a l'attuale tipo del media bridged e' specificato dai due ottetti del PID. Addizionalmente, il PID indica se l'originale Frame Check Sequence (FCS) viene conservato dentro il Bridged PDU. I valori del tipo media (PID) che possono essere usati nell'incapsulazione ATM sono elencati nell'Appendice B. Il campo AL5 CPCS-PDU Payload che trasporta un PDU Bridged, avra' una delle seguenti disposizioni. Il riempimento e' aggiunto dopo che il campo di PID se necessario per allineare il campo di informazioni dell'utente della PDU limitato ai quattro ottetti. Formato Payload per PDUs Bridged Ethernet/802.3 +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-80-C2 | +-------------------------------+ | PID 0x00-01 or 0x00-07 | +-------------------------------+ | PAD 0x00-00 | +-------------------------------+ | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ | LAN FCS (se il PID e' 0x00-01)| +-------------------------------+ Formato Payload for Bridged 802.4 PDUs +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-80-C2 | +-------------------------------+ | PID 0x00-02 or 0x00-08 | +-------------------------------+ | PAD 0x00-00-00 | +-------------------------------+ | Frame Control (1 ottetto) | +-------------------------------+ | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ | LAN FCS (if PID is 0x00-02) | +-------------------------------+ Formato Payload per PDUs Bridged 802.5 +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-80-C2 | +-------------------------------+ | PID 0x00-03 or 0x00-09 | +-------------------------------+ | PAD 0x00-00-XX | +-------------------------------+ | Frame Control (1 octet) | +-------------------------------+ | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ | LAN FCS (if PID is 0x00-03) | +-------------------------------+ Si noti che il campo 802.5 Access Control (AC) non ha significato al di fuori della sottorete 802.5 locale. Puo' essere cosi' considerato come l'ultimo ottetto dei tre del campo PAD, che puo' essere settato a qualsiasi valore (XX). Formato Payload per PDUs Bridged FDDI +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-80-C2 | +-------------------------------+ | PID 0x00-04 or 0x00-0A | +-------------------------------+ | PAD 0x00-00-00 | +-------------------------------+ | Frame Control (1 octet) | +-------------------------------+ | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ | LAN FCS (if PID is 0x00-04) | +-------------------------------+ Formato Payload per PDUs Bridged 802.6 +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-80-C2 | +-------------------------------+ | PID 0x00-0B | +---------------+---------------+ ------ | Riservato | BEtag | Intestazione +---------------+---------------+ PDU | BAsize | Comune +-------------------------------+ ------- | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ | | | Trailer PDU Comune | | | +-------------------------------+ Si noti che le intestazioni Common Protocol data PDU, sono l'unica scelta per il valore di PID, poiche' la presenza di un CRC-32 viene indicata nell'intestazione dal bit CIB, del frame del MAC. L'intestazione Common Protocol Data Unit (PDU) e il Trailer 802.6 sono convogliati per permettere il pipeling in uscita del bridge alla sottorete 802.6. Specificamente, l'intestazione Common PDU contiene il campo BAsize, il quale contiene la lunghezza del PDU. Se questo campo non e' disponibile all'uscita bridge 802.6, allora il bridge non puo' cominciare a trasmettere il PDU segmentato finche' non abbia ricevuto l'intero PDU, abbia calcolato la lunghezza ed abbia inserito la lunghezza nel campo BAsize. Se il campo e' disponibile, il bridge d'uscita 802.6 puo' estrarre la lunghezza del campo BAsize dell'intestazione del Common PDU, la inserisce nel campo corrispondente del primo segmento ed immediatamente trasmette il segmento sulla subnetwork 802.6. Quindi il bridge puo' cominciare a trasmettergli l'80.2.6 PDU prima di ricevere il PDU completo. Si noti che l'intestazione e il trailer PDU comuni del frame incapsulato, non dovrebbero essere copiati semplicemente al subnetwork 802.6 uscente perche' il valore incapsulato di BEtab puo' essere in conflitto con il precendete valore di BEtag trasmesso dal bridge. Un bridge dell'ingresso 802.6 puo' terminare un AAL5 CPCS-PDU settando a zero la lunghezza del campo. Se il bridge di uscita ha gia' iniziato a trasmettere segmenti del PDU alla subnetwork 802.6 e dopo notifica che il AAL-5 CPCS-PDU e' stato terminato, esso puo' immediatamente generare una cella EOM , che induce il PDU 802.6 ad essere respinto dal bridge ricevente. Una tal cella EOM potrebbe, ad esempio, contenere un valore non valido nel capo lunghezza del Common PDU Trailer. +-------------------------------+ | LLC 0xAA-AA-03 | +-------------------------------+ | OUI 0x00-80-C2 | +-------------------------------+ | PID 0x00-0E | +-------------------------------+ | | | BPDU come definito da | | 802.1(d) o 802.1(g) | | | +-------------------------------+ 5. Multiplexing basato su VC Nel multiplexing basato su VC, il protocollo trasporatato di collegamento della rete viene identificato implicitamente dal VC che che collega le due stazioni ATM, cioe' ogni protocollo deve essere inviato su un VC separato. Non c'e' quindi la necessita' di includere esplicitamente le informazioni di funzionamento del multiplexing nel Payload del AAL5 CPCS-PDU. Cio' provoca la minima larghezza di banda e un overhead dell'elaborazione. Come indicato sopra, il protocollo trasportato puo' essere configurato manualmente e dinamicamente negoziato durante la creazione della chiamata usando le procedure di segnalazione. I particolari della segnalazione saranno definiti successivamente nelle altre RFC quando i relativi standard saranno diventati disponibili. 5.1 Multiplexing basato su VC di Protocolli Routed I PDU di protocollo routed, saranno trasportati come tali nel Payload del AAL5 CPCS-PDU. Il formato del campo Payload del AAL5 CPCS_PDU, diventera' cosi': Formato Payload per PDUs Routed +-------------------------------+ | . | | PDU trasportato | | (fino a 2^16 - 1 ottetti) | | . | | . | +-------------------------------+ 5.2 Multiplexing basati su VC di Protocolli Bridged I PDU dei protocolli Bridged saranno trasportati dentro il Pabyload del AAL5 CPCS-PDU esattamente come descritto nella sezione 4.2 salvo che solo i campi dopo il campo PID, sono inclusi. Il campo Payload del ALL5 CPCS_PDU trasporta un PDU Bridged,quidi, avra' uno dei seguenti formati: Formato Payload per PDUs Bridged Ethernet/802.3 +-------------------------------+ | PAD 0x00-00 | +-------------------------------+ | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ |LAN FCS (opzione VC dipendente)| +-------------------------------+ Formato Payload per PDUs Bridged 802.4/802.5/FDDI +-------------------------------+ | PAD 0x00-00-00 or 0x00-00-XX | +-------------------------------+ | Frame Control (1 ottetto) | +-------------------------------+ | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ |LAN FCS (opzione VC dipendente)| +-------------------------------+ Si noti che il campo 802.5 Access Control (AC) non ha significato fuori della subnetwork 802.5 locale. Puo' essere considerato come l'ultimo ottetto dei tre ottetti del campo PAD, il quale nel caso di 802.5 puo' essere settato a qualsiasi valore (XX). Formato Payload per PDUs Bridged 802.6 +---------------+---------------+ ------- | Riservato | BEtag | Intestazione +---------------+---------------+ PDU | BAsize | Comune +-------------------------------+ ------- | Indirizzo di destinazione MAC | +-------------------------------+ | | | (frame MAC rimanente) | | | +-------------------------------+ | | | Trailer PDU Comune | | | +-------------------------------+ Formato Payload per BPDUs +-------------------------------+ | | | BPDU come definito da | | 802.1(d) o 802.1(g) | | | +-------------------------------+ Nel caso di ethernet, 802.3, 802.4, 802.5, dei FDDI PDU la presenza o assenza del trailing LAN FCS sara' identificata implicitamente dal VC, poiche' il campo PID non viene incluso. I PDU con la LAN FCS e i PDU senza LAN FCS sono considerati appartenenti a protocolli differenti anche se il media type e' lo stesso. 6. Bridging in una rete ATM Un interfaccia ATM che funge come un bridge, deve poter riempire,spedire, e filtrare i PDU bridged. Il riempimento e' realizzato mandando il PDU a tutte le destinazioni adate possibili. Nell'ambiente ATM questo significa trasmettere il PDU attraverso ogni relativo VC. Cio' puo' essere compiuto esplicitamente copiandolo in ogni VC usando un multicast VC. Per spedire un PDU, un bridge deve poter associare un indirizzo MAC di destinazione con un VC. E' impensabile e forse impossibile richiedere ai bridge di configurare staticamente un associazione per ogni indirizzo MAC di destinazione possibile con un VC. Di conseguenza, gli ATM bridge devono fornire abbastanza informazioni per permettere ad una interfaccia ATM di imparare dinamicamente le dstinazioni altrui, oltre l'insieme di stazioni ATM. Per portare a termine l'apprendimento dinamico, un bridged PDU sara' conforme all'incapsulamento descritto all'interno della parte 4. In questo modo, l'interfaccia di ricezione ATM sapra' esaminare il bridged PDU e apprendere l'associazione tra la destinazione altrui e una stazione ATM. 7. Per Ulteriori Studi Dal momento che la standardizzazione di ATM multicasting e' incompleta, i meccanismi di indirizzazione e segnalazione, i dettagli relativi alla negoziazione del metodo multiplexing cosi' come la risoluzione degli indirizzi, vengono lasciate ad ulteriori RFC. Ringraziamenti This document has evolved from RFCs [1] and [4] from which much of the material has been adopted. Thanks to their authors T. Bradley, C. Brown, A. Malis, D. Piscitello, and C. Lawrence. In addition, the expertise of the ATM working group of the IETF has been invaluable in completing the document. Special thanks Brian Carpenter of CERN, Rao Cherukuri of IBM, Dan Grossman of Motorola, Joel Halpern of Network Systems, Bob Hinden of Sun Mircosystems, and Gary Kessler of MAN Technology Corporation for their detailed contributions. Considerazioni di sicurezza I problemi di sicurezza non sono richiamati in questo appunto Riferimenti [1] Piscitello, D. and Lawrence, C., "The Transmission of IP Datagrams over the SMDS Service". RFC 1209, Bell Communications Research, March 1991. [2] CCITT, "Draft Recommendation I.363". CCITT Study Group XVIII, Geneva, 19 - 29 January, 1993. [3] CCITT, "Draft Recommendation I.36x.1". CCITT Study Group XVIII, Geneva, 19-29 January, 1993. [4] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay". RFC 1294, Wellfleet Communications, Inc. and BBN Communications, January 1992. [5] CCITT, "Draft text for Q.93B". CCITT Study Group XI, 23 September - 2 October, 1992. [6] Information technology - Telecommunications and Information Exchange Between Systems, "Protocol Identification in the Network Layer". ISO/IEC TR 9577, October 1990. [7] Postel, J. and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks". RFC 1042, ISI, February, 1988. Appendice A. Incapsulazione di Multiprotocollo su FR-SSCS I.36x.1 definisce un Frame Relaying Specific Convergence Sublayer (FR-SSCS) da usare sulla parte superiore del AAL type 5 per il Frame Relay/ATM interworking. Il servizio offerto da FR-SSCS corrisponde al servizio Core per il Frame Relaying descritto in I.233. Un FR-SSCS-PDU consiste in un campo di indirizzo Q.922 seguito da un campo informazione Q.922. I flag Q.922 e i FCS sono omessi, poiche' le funzioni corrispondenti sono fornite da AAL. La figura sottostante mostra un FR-SSCS-PDU incorporato nel Payload di un AAL5 CPCS-PDU: FR-SSCS-PDU in Payload di AAL5 CPCS-PDU +-------------------------------+ ------- | Campo di indirizzo Q.922 | Intestazione FR-SSCS-PDU | (2-4 ottetti) | +-------------------------------+ ------- | . | | . | | Campo di Informazione Q.922 | Payload PDU FR-SSCS | . | | . | +-------------------------------+ ------- | AAL5 CPCS-PDU Trailer | +-------------------------------+ I PDU bridged e routed sono incapsulati dentro l'FR-SSCS-PDU come definito nell'RFC 1294. Il campo informazioni Q.922 inizia con un campo di controllo Q.922 seguito da un ottetto PAD opzionale che viene usato per allineare il resto del frame fino a un limite conveniente per il mittente. Il protocollo del PDU trasportato allora viene identificato premettendo alla PDU un ISO/CCITT Network Layer Protocol ID (NLPID). Nel caso particolare di un IP PDU, l'NLPID e' 0xCC e il FR-SSCS-PDU ha la seguente struttura: Formato FR-SSCS-PDU per IP PDUs Routed +-------------------------------+ | Campo di Indirizzo Q.922 | | (2 o 4 ottetti) | +-------------------------------+ | 0x03 (Controllo Q.922) | +-------------------------------+ | NLPID 0xCC | +-------------------------------+ | . | | IP PDU | | (fino a 2^16 - 5 ottetti) | | . | +-------------------------------+ Si noti che secondo l'RFC 1294 il campo d'indirizzo Q.922 sara' di 2 o 4 ottetti, ovvero un campo di indirizzo di 3 ottetti non e' supportato. Nel caso particolare di un CLNP PDU, l'NLPID e' 0x81 e l'FR-SSCS-PDU avra' la seguente struttura: Formato FR-SSCS-PDU per CLN PDUs Routed CLNP +-------------------------------+ | Campo di Indirizzo Q.922 | | (2 o 4 ottetti) | +-------------------------------+ | 0x03 (Controllo Q.922) | +-------------------------------+ | NLPID 0x81 | +-------------------------------+ | . | | Resto del CLNP PDU | | (fino a 2^16 - 5 ottetti) | | . | +-------------------------------+ Si noti che nel caso di protocolli ISO la struttura del primo ottetto del campo NLPID del PDU e' se stesso e non verra' cosi' ripetuto. Il suddetto incapsulamento si applica soltanto ai protocolli routed che hanno assegnato un unico NLPID. Per gli altri protocolli routed (e per i protocolli bridged), e' necessario fornire un altro meccanismo per una facile identificazione del protocollo. Cio' puo' essere realizzato usando un valore 0x80 dell'NLPID per indicare che sengue in intestazione IEEE 802.1a SubNetwork Attachment Point (SNAP). Consultare l'RFC 1294 per maggior dettagli relativi all'incapsulazione multiprotocollo su FRCS. Appendice B. Lista dei valori localmente assegnati di OUI 00-80-C2 con FCS preservati senza FCS preservati Media ------------------ -------------------- -------------- 0x00-01 0x00-07 802.3/Ethernet 0x00-02 0x00-08 802.4 0x00-03 0x00-09 802.5 0x00-04 0x00-0A FDDI 0x00-05 0x00-0B 802.6 0x00-0D Fragments 0x00-0E BPDUs Appendice C. Lista parziale degli NLPID 0x00 Null Network Layer or Inactive Set (not used with ATM) 0x80 SNAP 0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0xCC Internet IP Indirizzo degll'Autore Juha Heinanen Telecom Finland PO Box 228 SF-33101 Tampere Finland Phone: +358 49 500 958 Email: Juha.Heinanen@datanet.tele.fi