Traducere rfc 1483

Limba engleză numele parametru va fi tradus, dar, de obicei, utilizat în continuare în forma sa originală. Acest lucru se datorează faptului că probabilitatea de a găsi o denumire în limba rusă la configurarea unui dispozitiv suficient de mic.

În prezentul document, termenii „comutare“ și „bridzhevanie» (bridging) vor fi utilizate în mod interschimbabil.

Tot aici, PDU va utiliza termenul: unitate de date de protocol - o unitate de date de protocol.

Acest document descrie două metode care sunt aplicate la transmiterea de date prin rețeaua ATM comutată și rutate protocoale. Aceasta susține protocoalele de transfer de date, care funcționează fără o conexiune (conexiune).

Prima metodă sprijină multiplexarea datelor diferitelor protocoale în același canal virtual (circuit virtual) ATM. Protocol, datele care sunt conținute în transmis PDU, identificat la poziția LLC IEEE 802.2 (Link Control logic). Mai mult, această metodă va fi numit «LLC-încapsulare“ (sau LLC-multiplexare).

A doua metodă este de a transfera date de protocoale diferite pe diferite canale virtuale ATM. Mai mult, această metodă va fi numit «VC-încapsulare“ (sau VC-multiplexare).

În ATM datele sunt transmise folosind celule cu lungime fixă. În consecință, atunci când pachetele de lungime variabilă formate prin protocoale diferite, este necesară segmentarea / restaura pachetele de date la / din celule. Bancomatul este angajată în nivelurile SAR (segmentare și reasamblare). Deci, RFC 1483 nu descrie noua metodologie utilizată la nivelurile SAR. În schimb protocoale de rețea PDU încapsulate în câmp Payload (conținutul) CPCS-pachet (partea comună de convergență subnivel) Al cincilea nivel de tip AAL - AAL5.

RFC 1483 descrie datele de protocol încapsulare direct prin stratul SCPC, ceea ce implică absența, în acest caz, nivelul SSCS (serviciu specific de convergență subnivelul). Când se utilizează, de exemplu, Frame Relay Serviciul PDU Specific Convergența subnivel (FR-SSCS) în transmiterea diferitelor protocoale folosite tehnici de multiplexare folosind NLPID (vezi. RFC 1294). Format FR-SSCS-PDU, și încapsularea IP și CLNP prin FR-SSCS în conformitate cu RFC 1294 discutat pe scurt în Anexa A.

câmpul Payload conține datele de utilizator și are o dimensiune de până la șaisprezece-1 februarie octetului.

câmp PAD (aliniere) este utilizat pentru alinierea dimensiunii SCPC PDU la o limită de 48-octetului (t. E. Prin împărțirea lungimea totală a pachetului de 48 ar trebui să fie nici un reziduu). Pachetul AAL5 SCPC-PDU este apoi transmis la nivelurile SAR, care se împarte în celula de 48 octeți.

Domeniul CPCS-UU (User-to-utilizator indicații - Afișarea-utilizator la utilizator) pot fi utilizate pentru transmiterea transparentă a informațiilor de utilizator. Acest câmp nu este reglementat de RFC 1483 și poate fi setat la orice valoare arbitrară.

Domeniul IPC (Partea indicator comun - indicator de partea comună) este utilizat pentru a alinia închiderea CPCS-PDU pentru o limită pe 64 de biți. Domeniul poate transporta funcții suplimentare, care pot fi ulterior identificate CCITT. În acest caz, în cazul în care acest câmp este folosit doar pentru a alinia la o limită pe 64 de biți, acesta trebuie să conțină valoarea 0x00.

Acest câmp indică lungimea în octeților Payload. Valoarea maximă a acestui câmp - 65535. Pentru a finaliza funcția (funcția avorta) folosind o valoare de lungime egală cu 0x00.

câmpul de control este folosit pentru a verifica pentru erori în pachet. Valoarea câmpului CRC este ignorat în calcul.

Formatul Payload pentru rutate PDU ISO

ISO Protocoale rutabile identificat NLPID domeniu octetului. Acest câmp este o parte a câmpului de date de protocol. valori de câmp NLPID administrate de organizații ISO și CCITT. Aceste valori sunt definite în ISO / IEC TR 9577. Document Unele dintre valorile utilizate sunt listate în Anexa C.

Valoarea 0x00 câmpul definit NLPID ISO / IEC TR 9577, ca rețea de nivel zero (Null rețea Layer) sau de instalare inactivă (inactive Set). ATM-capsulare câmp zero, valoarea 0x00 este considerată ca fiind eronată.

ISO încapsularea poate fi utilizat pentru transmiterea de IP-trafic. În ciuda faptului că IP nu este un protocol ISO, există o anumită valoare pentru el NLPID egal 0xCC. Cu toate acestea, nu este necesar să fie utilizată transmiterea prin rețeaua ATM-un astfel de format de transmisie de date. date de protocol IP care urmează să fie transmise în același mod ca și alte date de protocol non-ISO.

Protocoale non-ISO sunt identificate prin SNAP-antet, care urmează imediat LLC-antet. Prezența SNAP-LLC-antet identifică antetul cu valoarea 0xAA-AA-03. Formatul SNAP-header:

Formatul Payload pentru PDU IP rutate

4.2 LLC-încapsulare pentru protocoale cu punte.

Atunci când tipul de LLC-încapsularea protocolului dial-up este identificat printr-un SNAP-antet. La transferul de protocoale non-ISO rutate, prezența SNAP-header identifică valoarea LLC-header egal cu 0xAA-AA-03. Când este pornit transmisia valorii câmpului de protocol de date OUI SNAP-titlu egal cu 0x00-80-C2. identificatorul protocolului Dial-up este conținută în câmpul PID. O caracteristică suplimentară a PID câmp este o indicație dacă câmpul de protocol FCS dial-PDU conține - de control - sau nu. (În acest caz, există FCS, calculează expeditor de pachete, de exemplu, un adaptor de stație de lucru de rețea Ethernet de rețea). Listă de PID, care poate fi utilizat în ATM-încapsulare este prezentată în Anexa B.

Când este pornit câmpul de protocol de transmisie de date AAL5 SCPC Capacitate incarcare-PDU trebuie să aibă una dintre următoarele formate. aliniere Byte adăugat, dacă este necesar, după câmpul PID pentru a alinia câmpul de informații este 4-octetului limită.

802.6 Câmpul PID este folosit doar pentru o singură valoare, spre deosebire de alte tipuri de PDU. Prezența sau absența unei cantități CB bit de control indicate în antetul MAC a cadrului.

câmpuri antet de transport, și se termină PDU 802.6 prin intermediul rețelei de ATM-uri este menținut pentru a asigura modul de înlănțuire (Înlănțuire). câmp PDU Header conține BAsize, indicând lungimea PDU. Dacă 802.6 Podul nu este capabil de a lucra cu acest domeniu (de ex. E. Nu se ajunge), astfel încât podul nu poate transmite PDU segmentată (cu excepția cazurilor în care PDU-ul este primit în întregime), și nu este în măsură să calculeze și să inserați lungimea valoarea BAsize în domeniu. În cazul în care câmpul poate fi utilizat, Podul 802.6 poate primi întreaga lungime a PDU, introduceți-l în câmpul corespunzător al primului segment și trimite imediat segmentul primit în 802.6 rețea. Astfel, podul poate începe transmiterea PDU 802.6 înainte de a primi întreaga PDU.

Notă: Titlul și sfârșitul cadrului încapsulat nu poate fi pur și simplu copiate la transmiterea informațiilor în rețeaua 802.6. BEtag, conținute în cadrul încapsulate pot intra în conflict cu valoarea BEtag anterioară a trecut la pod.

802.6 pod poate „ucide“ rezultat AAL5 CPCS-PDU setarea lungimea câmpului la 0. Dacă trimiterea de pod de informații a început deja să transmită segmente de PDU în rețeaua 802.6, iar apoi a fost informat resetat AAL5 CPCS-PDU, el poate genera imediat celule MOA, provocând reset 802.6 PDU la puntea de recepție. Astfel, celula MOA poate conține o valoare incorectă a câmpului de lungime în capătul PDU.

Când VC-încapsulare sau VC-multiplexare date protocol sunt transmise prin rețeaua ATM este identificat printr-un VC, m. E., Fiecare protocol folosește un VC separat. Astfel, nu este nevoie de o cameră suplimentară în multiplexare informații Payload AAL5-CPCS-PDU, care reduce lărgimea de bandă utilizată și CPU switch-uri.

Parametrul „protocol de transmitere de identificare a“ poate fi configurat negociat manual sau automat în timpul procesului de configurare a conexiunii prin utilizarea procedurilor de semnalizare. Detaliile alarmei vor fi stabilite ulterior. În RFC mai târziu.

5.1 VC-încapsulare protocoale rutate.

PDU dirijate protocoale trebuie plasate în Payload AAL5 SCPC-PDU. Formatul Payload este prezentat mai jos:

Dimensiunea acestui câmp poate fi de până la șaisprezece-1 februarie octetului

Formatul Payload pentru PDU rutate

5.2 Protocoale încapsulare-VC bridzhuemyh.

PDU comutate protocoale trebuie plasate în câmpul Payload AAL5 CPCS-PDU în mod similar, așa cum este descris la punctul 4.2, cu excepția faptului că numai câmpuri sunt incluse în urma PID. Când este pornit câmpul de protocol de transmisie de date AAL5 SCPC Capacitate incarcare-PDU trebuie să aibă una dintre următoarele formate.

LAN FCS (în funcție de VC)

Formatul Payload pentru dial-Ethernet / 802.3 PDU

PAD 0x00-00-00 sau 0x00-00-XX

LAN FCS (în funcție de VC)

Formatul Payload pentru dial-802.4 / 802.5 / FDDI PDU

12 <Мультипротокольная инкапсуляция через AAL5

Notă Câmpul 802.5 AC (Access Control - Access Control) nu contează în afara

LAN 802.5. În principiu, acesta poate fi transmis în câmpul PAD ultimul octet. Acest octetul poate fi setat la orice valoare arbitrară (XX în figură).

Formatul Payload pentru dial 802.6 PDU

BPDU, structura care este definită în 802.1 (d) și 802.1 (g)

Formatul Payload pentru BPDU

În cazul Ethernet, 802.3, 802.4, 802.5 și prezența FDDI sau absența unui câmp FCS (verifica suma) utilizat VC este identificat, adică. E. Când configurarea VC convenită manual sau automat, suma de control trebuie să fie utilizată sau nu. PDU, care conține o sumă de control, iar PDU, judecătorii nu conțin, sunt considerate ca aparținând diferitelor protocoale, chiar dacă acestea aparțin aceluiași protocol dial-up.

6Kommutatsiya în rețeaua M AT

Un comutator (sau orice alt dispozitiv) ATM, rețea care funcționează cu protocoalele de încapsulare trebuie să sprijine implementarea funcțiilor respective: inundare (flading), redirecționarea (transferul) și filtrul (filtrarea) comutată PDU.

Inundațiile PDU trimiterea în toate direcțiile posibile, cu excepția faptului că pe care a fost primită PDU. În mediul ATM acest lucru înseamnă trimiterea PDU în toate VC, în care PDU poate fi trimis. Într-o implementare practică, acest lucru poate însemna trimiterea o copie separată a PDU în fiecare VC sau utilizarea multicast (multicast) VC.