Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Távközlési és Médiainformatikai Tanszék
Janky Ferenc Nándor
PROTOKOLL MEGVALÓSÍTÁSOK FPGA-N BELÜL Általános protokollkezelő keretrendszer kidolgozása VHDL nyelven
IPARI KONZULENS KRÓDI GÁBOR AITIA INTERNATIONAL ZRT.
TANSZÉKI KONZULENS DR. VARGA PÁL
BUDAPEST, 2013
Tartalomjegyzék Összefoglaló ..................................................................................................................... 6 Abstract............................................................................................................................ 7 Gyakran használt rövidítések jegyzéke ........................................................................ 8 1 Bevezetés ....................................................................................................................... 9 2 Irodalomkutatás ......................................................................................................... 10 2.1 ISO OSI referencia modell ................................................................................... 10 2.2 Az IEEE 802.3 szabványcsalád ............................................................................ 15 2.3 Address Resolution Protocol (ARP) ..................................................................... 19 2.4 Internet Protocol Version 4 (IPv4) ........................................................................ 21 2.5 User Datagram Protocol (UDP) ............................................................................ 26 2.6 Simple Network Management Protocol (SNMP) ................................................. 28 2.7 Fejlesztés során használt eszközök ....................................................................... 34 3 Tervezés ...................................................................................................................... 36 3.1 A munka állapota, készültségi foka a 2012/2013/I. félév elején .......................... 36 3.2 A munka állapota, készültségi foka a 2012/2013/II. félév elején ......................... 36 3.3 Specifikáció és rendszerterv ................................................................................. 37 3.4 VHDL modulok interfész- és funkcionális specifikációja .................................... 38 3.4.1 Általános interfész-ismertetés ........................................................................ 38 3.4.2 PDUQueue modul .......................................................................................... 40 3.4.3 ProtoModule_TXPart modul ......................................................................... 42 3.4.4 ProtoLayer ismertetés .................................................................................... 44 3.4.5
ProtoLayer-hez
csatlakozó
protokollvezérlő
interfész
és
működési
követelményei ......................................................................................................... 46 3.4.6 Protokollverem kialakítás ProtoLayer-ek összekapcsolásával ...................... 57 4 Implementáció és tesztelés......................................................................................... 59 4.1 Implementációs részletek ...................................................................................... 59 4.1.1 Kiegészítő modulok ....................................................................................... 59 4.1.2 PDUQueue modul .......................................................................................... 61 4.1.3 ProtoModule_TXPart modul ......................................................................... 63 4.1.4 ProtoLayer modul .......................................................................................... 64 4.1.5 EtherLayer modul .......................................................................................... 65
4.1.6 ARP modul .................................................................................................... 68 4.1.7 IPLayer modul ............................................................................................... 70 4.1.8 UDPLayer modul ........................................................................................... 71 4.1.9 SNMP modul ................................................................................................. 72 4.2 Mérési jegyzőköny és eredmények ....................................................................... 74 5 Összefoglalás és további célok .................................................................................. 79 Irodalomjegyzék............................................................................................................ 80
HALLGATÓI NYILATKOZAT Alulírott Janky Ferenc Nándor, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy hitelesített felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, 2013. 05. 25.
...……………………………………………. Janky Ferenc Nándor
Összefoglaló A kis memóriaigényű - connectionless, kapcsolatmentes - hálózati protokollok kezelése viszonylag könnyűszerrel kialakítható FPGA-n (Field Programmable Gate Array) keresztül. Amikor az alacsony-szintű protokollokat hardveres eléréssel valósítjuk meg, a protokollok gyors és kiszámítható szolgáltatást biztosítanak a magasabb rétegek felé. A szoftveresen implementált protokoll-megvalósítások számos befolyásoló tényezője megszűnik, az üzenettovábbítás így kisebb késleltetéssel és jitterrel történik. Az egyik ilyen zavaró tényező az alkalmazott operációs rendszer ütemezési algoritmusa. A feladat célja egy általánosított módszertan kialakítása volt protokollok FPGA-n belüli megvalósítására, valamint a módszertan validálása az SNMP (Simple Network Management Protocol) parciális implementációjával. A OSI (Open Systems Interconnection) referencia modell kiváló igazodási alapként szolgál a feladat megoldásához, mivel ennek alapkövei között szerepel, hogy átlátható módon támogassa a rendszerek összekapcsolását szolgáló szabványfejlesztést. A diplomamunka kapcsán megtervezett keretrendszer követi az OSI modell alapelveit, hierarchikusan egymásra rétegezhető és eszköztárat biztosít a PDU-k (Protocol-DataUnit) és IDU-k (Interface-Data-Unit) általános kezelésére, ezzel elősegítve tetszőleges protokoll implementálását VHDL (Very-High-Speed Integrated Circuits Hardware Description Language) nyelven történő leírással. A keretrendszer elkészültével a célként kitűzött alkalmazás rétegbeli SNMP, és annak működéséhez (és így a validáláshoz is) szükséges alsóbb rétegbeli, legelterjedtebben használt protokollok is realizálódtak. Munkám során a keretrendszer egésze mellett az IEEE 802.3 MAC (Medium Access Control) full-duplex része, az ARP (Address Resolution Protocol), az IPv4 (Internet Protocol version 4) részleges implementációja és az UDP (User Datagram Protocol) került megvalósításra. A rendszer elkészültével többféle mérési elrendezésben végeztem méréseket, amellyel ellenőriztem a rendszer működőképességét más gyártótól származó eszközökkel való összekapcsolással, illetve a megvalósított SNMP Trap küldés konformancia vizsgálatát is elvégeztem többféle hálózati menedzsment információ feldolgozására képes szoftverrel.
Abstract Efficient handling of connectionless networking protocol messages with low memory utilization could be achieved by using hardware acceleration. A flexible solution for this is to use FPGAs (Field Programmable Gate Array). When lower level protocols are implemented in such manner, they will provide fast and predictable service characteristics for their upper layer protocols. The software implementation of protocol handling introduces relatively long delay and high delay variation (a.k.a jitter). These could be eliminated by using the pure hardware implementation of the protocol stack. One root cause of the mentioned side effects is the hosting operating system’s scheduling algorithm. The purpose of this project is to develop generalized approach for implementing protocols using FPGA hardware, and to validate the theory with implementing an application layer protocol, the SNMP (Simple Network Management Prtocol) using the resulting framework. During these two semesters of the thesis work the designed framework has been developed in VHDL (Very-High-Speed Integrated Circuits Hardware Description Language). It follows the basic principles of the OSI reference presenting a general toolkit for the handling of PDUs (Protocol-Data-Unit) and IDUs (Interface-Data-Unit). Besides, it also provides solution for other frequently reappearing tasks in the aid of convenient and smoother implementation of various protocols. To utilize the final, hardware-accelerated, partial implementation of SNMP further lower layer protocols had to be implemented as well. These include the IEEE 802.3 MAC (Medium Access Control) with full-duplex operation, the ARP (Address Resolution Protocol) for handling Ethernet hardware and IPv4 protocol address space, the IPv4 without fragmentation and reassembly and the UDP (User Datagram Protocol), as the underlying transport protocol of SNMP. At the end of the final implementation, validating measurements have been made. These aimed to prove the correctness and the usability of the designed framework. The implemented system was tested against various link, network and transport layer hardware and software products from 3rd party vendors. Conformance testing was also carried out with a couple of network management software. 7
Gyakran használt rövidítések jegyzéke ASN.1
Abstract Syntax Notation 1
BER
Basic Encoding Rule
CLB
Configurable Logic Block
CSMA/CD
Carrier Sense Multiple Access with Collision Detection
DER
Distinguished Encoding Rule
FCS
Frame Check Sequence
FIFO
First-In-First-Out
FPGA
Field Programmable Gate Array
HTML
HyperText Markup Language
ICI
Interface Control Information
IDE
Integrated Development Environment
IDU
Interface Data Unit
IETF
Internet Engineering Task Force
IP
Internet Protocol
ISO
International Standardization Organization
LAN
Local Area Network
M/LSB
Most/Least Significant Bit
MAN
Metropolitan Area Network
MIB
Management Information Base
OSI
Open Systems Interconnection
PCI
Protocol Control Information
PDU
Protocol Data Unit
PHY
Physical Layer
PLS
Physical Layer Signaling
RAM
Random Access Memory
RFC
Request For Comments
SAP
Service Access Point
SDU
Service Data Unit
SNMP
Simple Network Management Protocol
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
VHDL
VHSIC hardware description language
8
1 Bevezetés A kis memóriaigényű - connectionless, kapcsolatmentes - hálózati protokollok kezelése viszonylag könnyűszerrel kialakítható FPGA-n (Field Programable Gate Array) keresztül. Amikor az alacsony-szintű protokollokat hardveres eléréssel valósítjuk meg, a protokollok gyors és kiszámítható szolgáltatást biztosítanak a magasabb rétegek felé. A szoftveresen implementált protokoll-megvalósítások számos befolyásoló tényezője megszűnik, az üzenettovábbítás így kisebb késleltetéssel és jitterrel történik. Az egyik ilyen zavaró tényező az alkalmazott operációs rendszer ütemezési algoritmusa. A feladat célja egy általánosított módszertan kialakítása protokollok FPGA-n belüli megvalósítására, valamint a módszertan validálása az SNMP (Simple Network Management Protocol) protokoll parciális implementációjával. A célként kitűzött alkalmazás rétegbeli SNMP működéséhez (és így a módszertan validáláshoz is) szükséges az alsóbb rétegbeli protokollok implementációja is, mint az SNMP szállítási rétegét
adó
UDP
(User
Datagram
Protocol),
az
UDP
számára
hálózati
csomagtovábbítási szolgálatokat biztosító IP (Internet Protocol) és az Ethernet MAC (Medium Access Control). Utóbbinak a fejlesztési környezet a fizikai részét már implementálja A keretrendszer kialakításához szükséges elméleti háttérhez hozzátartozik a legelterjedtebb protokoll modell feldolgozása és analizálása, valamint a cél eléréséhez szükséges protokollok leírásának részletes tanulmányozása. A feladat során a Xilinx IDE fejlesztői környezetet használtam, és az implementáció VHDL nyelven történt Xilinx Virtex 5 FPGA-ra, így az ezek alaposabb megismerése is szintén fontos elem volt a munka során. E dokumentum szerkezetét tekintve először a tanulmányozott irodalomból készített összefoglalót mutatom be, ami szorosan kapcsolódik az elvégzendő feladathoz. Ezután a feladatkiírás kielégítéséhez szükséges tervezési megfontolásokat ismertetem, amit az implementációs részletek bemutatása követ. Legvégül az elkészített rendszerrel elvégzett mérés eredményét közlöm, amit egy rövid összefoglalóval zárok le.
9
2 Irodalomkutatás 2.1 ISO OSI referencia modell A feladatban kulcsfontosságú szerepet játszik a protokollrétegek közti kommunikáció vizsgálata, mind szerkezeti, mind viselkedési szempontból. A cél az, hogy a protokollüzenetekben fel lehessen fedezni egy olyan mintát benne, amit aztán hatékonyan lehet hardver modulokkal modellezni, és így VHDL viselkedési leírást készíteni. Ezt szintetizálva és az FPGA-t felprogramozva elérhető a kívánt működés. Ehhez a vizsgálódást az ISO által szabványosított OSI referenciamodell[1] vizsgálatával kezdtem, melynek vonatkozó részei kerülnek ismertetésre ebben a fejezetben. Az OSI referencia modell célja, hogy alapjául szolgáljon a rendszerek összekapcsolását szolgáló szabványfejlesztési irányoknak, amellett, hogy a már a modell készítésekor létező szabványok is elhelyezhetőek legyenek a modellben. Míg a nyílt rendszerek összekapcsolásához szükséges architekturális alapelvek hatóköre elég tág, a szabvány főként a terminálokból, számítógépekből és egyéb információtovábbítási
célokat
szolgáló
eszközök
összekapcsolásából
álló
rendszerekkel
foglalkozik. A szabvány részletesen foglalkozik a modell szükségességének a kérdéseivel, az összekapcsolható entitásokkal és a modellezési alapelvekkel. Az OSI referencia modellben a rétegek az alapvető architekturális elemek. Ennek értelmében minden nyílt rendszert logikailag ilyen rétegek rendezett halmazából áll, amit vertikális formában szokás ábrázolni a könnyű áttekinthetőség kedvéért. A szomszédos rétegek a határaikon lévő alsóbb és felsőbb rétegekkel kommunikálnak közvetlenül a szolgáltatás-hozzáférési pontokon keresztül szolgálati primitívek által. A nyílt rendszerben található (N+1) rétegbeli entitások kommunikációja az (N) rétegben valósul meg, ahogy az az 1. és 2. ábrákon is látható.
10
1. ábra Az (N+1) réteg kommunikációja az (N) rétegben történik[1]
2. ábra Az (N) réteg entitásai között zajló horizontális kommunikáció a protokoll [1]
Vertikális kommunikáció SAP-okon (Service Acces Point) keresztül szolgálati primitívekkel és paramétereikkel történik, melynek fajtái (a kommunikáció fázisai során fellépő sorrendben): •
Kérés (Request)
•
Bejelentés (Indication)
•
Megerősítés (Confirm)
•
Válasz (Response)
A 3. ábra ilyen típusú szolgálati primitívek használatát és időbeli sorrendjét illusztrálja.
3. ábra A szolgálati primitívek időbeli sorrendjének illusztrálása[2]
11
A SAP-okon a szolgálati primitívvel átadásra kerülő interfész adatelem (IDU, Interface Data Unit) áll egyrészt a szolgálati adatelemből (SDU, Service Data Unit), amelyre a kért szolgáltatást venné igényben a felsőbb réteg, és az interfészvezérlési információból (ICI, Interface Control Information), ami részletesen megadja, hogy a felsőbb réteg milyen paraméterekkel kívánja igénybe venni a biztosított szolgáltatást. Ezt szemlélteti a 4. ábra.
4. ábra Az OSI modellben előforduló adatelemek[3]
A referencia modell alapelveinek megfelelően, ezek az axiómák egy olyan nyílt rendszer leírásához vezettek, ami a legtöbb felhasználási igényt kielégíti, amelyben hét réteg található:
Alkalmazás réteg:
amely a programok közti kommunikációért, és
(Application layer)
felhasználói információ átvitelért felel
Megjelenítési réteg:
amely a rendszer független adatmegjelenítésért felel
(Presentation layer)
Viszony réteg:
amellyel
tranzakciók,
(Session layer)
műveletsorozatok végezhetőek
Szállítási réteg:
amely
(Transport layer)
szolgálatokat biztosít
Hálózati réteg:
amely a hálózati kapcsolatokért felel, és útvonal
végponttól
12
dialógusok,
végpontig
összefüggő
értendő
átviteli
(Network layer)
független felület biztosít a szállítási réteg számára
Adatkapcsolati réteg:
amely a
(Data link layer)
kapcsolatokért
szomszédos felelős
hálózati (egy
entitások
vagy
több
közötti fizikai
összeköttetést is használhat) Fizikai réteg: (Physical layer)
amely a mechanikai és elektromos jellemzőit rögzíti az átvitelnek, emellett a fizikai kapcsolatokért és a bit átvitelért felelős az adatkapcsolati entitások között. A fizikai rétegbeli entitások között a valós fizikai közeg teremt összeköttetést
A felsorolt rétegek egymásra épülését szemlélteti az 5. ábra
5. ábra Az OSI referencia modell által definiált rétegek[4]
13
Az IETF (Internet Engineering Task Force) közösség által a réteges szerkezetű megközelítés nehezen kezelhetőnek tekinthető [5] abból a szempontból, hogy a réteges szerkezetből adódóan, az egyes rétegek funkcióit el kell végezni, mielőtt a PDU (Protocol Data Unit) a következő réteg számára átadásra kerül. Mivel ezek a rétegek különálló egységek, emiatt az egyes rétegeket a optimálisra kell tervezni, ami viszont nem jelenti azt, hogy ez által a rétegek összekapcsolásából létrejövő rendszer is az lesz. Gondoljunk csak például arra az esetre, amikor az egyes egymásra épülő rétegekben
bizonyos
funkcionalitások
redundánsan
vannak
megvalósítva
(pl.
hibavédelem, nyugtázás stb.). Ez megközelítés annak ellenére helyes, hogy az általuk készített standardok a TCP/IP modellbe illeszkednek, aminek elemei megfeleltethetőek a tágabb rendszerek leírását is támogató OSI modellnek. Az OSI referencia modell vizsgálata után adódik, hogy a feladat megoldásához -azaz általános protokollkezelés megvalósításhoz-, a legkézenfekvőbb mód, ha a fentebb ismertetett logikai struktúrát használó és megvalósító VHDL keretrendszer kerül kialakítása, mivel ez kellően általános megközelítést nyújt a protokollok kezelésére. A fentiek alapján a keretrendszerhez olyan modult és felhasználási módszert érdemes alkotni, amely megvalósítja a SAP-ot és a szolgálati primitíveket, valamint általános módszert biztosít az IDU és PDU kezelésre, ezáltal egyszerűsíti és segíti a különböző protokollok hardveres implementációinak a fejlesztését. Ha a megvalósítás elkészül, akkor a keretrendszer verifikálása történhet több protokoll
megvalósításával
teljesítményének
a
ellenőrzésével
belül.
keretrendszeren igazolható
használhatósága is.
14
a
Ezek
helyességének
és
működése
és
keretrendszer
2.2 Az IEEE 802.3 szabványcsalád Az IEEE 802.3-as szabványcsalád specifikálja a vezetékes Ethernet-et – amely egy LAN/MAN és hozzáférési hálózatbeli technológia az OSI hét rétegű modelljében megtalálható fizikai és adatkapcsolati rétegének közeg-hozzáférési részét [6]. A protokollcsalád részei a 6. ábrán láthatóak:
6. ábra Az Ethernet rétegei és interfészei [8]
Az Ethernet különböző fizikai rétegeihez különböző specifikációk tartoznak, de közös a közeghozzáférési vezérlés leírása. A MAC a továbbítandó információt keretezi, majd a PHY réteg ezeket a kereteket, a használt fizikai közegnek megfelelően kódolja/dekódolja (vonali kódolás, jelformálás). A szabvány két különböző működési módot különböztet meg [7]: fél duplex mód, amely estén kettő vagy több állomás osztozik a közös átviteli közegen, ekkor a szabvány által leírt CSMA/CD eljárás használandó duplex mód, amely esetén párhuzamos adásra és vételre van lehetőség állomáspárok között dedikált pont-pont összeköttetés esetén A MAC réteg a kliensei számára lehetővé teszi, hogy a helyi kliens a társ/távoli klienssel LLC adatelemeket cseréljenek ki az alábbi szolgálati primitívek használatával [7]: 15
MA_DATA.request ( destination_address, source_address, mac_service_data_unit, frame_check_sequence ), mellyel a helyi kliens kérheti saját adatelemének továbbítását MA_DATA.indication ( destination_address, source_address, mac_service_data_unit, frame_check_sequence, reception_status ), amellyel a MAC alréteg közli a helyi klienssel a társentitás által küldött adatelemet és paramétereit.
A MAC a következő funkciók megvalósításával biztosítja szolgálatait:
Adat beágyazás, kinyerés o Keretezés, keretszinkronizáció, kerethatárolás o Címzés, forrás- és célcím o Hibaészlelés
Közeghozzáférés vezérlés
A MAC által használt keretformátum és továbbítási irány, valamint a szolgálati primitív attribútumai és a keret elemei közötti leképzés a 7. ábrán látható (a továbbiakban a számértékek feltűntetése MSB-LSB bitsorrendben történik az írott anyagban, a szabvány a hálózati bájtsorrendet használja, azaz MSByte-LSByte) [7]:
16
7. ábra fent: Ethernet keretszerkezet és továbbítási sorrend, lent: szolgálati primitív és mezők kapcsolata [7]
Az előkiegyenlítő jel értéke 0x55, amely eredetileg az adó és a vevő közötti órajel-szinkronizációt hivatott biztosítani. A keretkezdet szimbólum értéke 0xD5. A keretben található címek lehetnek egyedi vagy csoport címek (üzenetszórás is – broadcast), és 6 bájtosak. A Length/Type mező, ha decimális értéke kisebb 1500-nál, a szállított adatelem méretét jelöli, ha nagyobb, akkor kizárólagosan azonosítja a MAC klienst. Ha a szállítani kívánt adatelem kisebb a minimálisan szállítható méretnél, akkor kiegészítésre kerül töltelékbájtokkal. A szabvány definiál egy úgynevezett interPacketGap (IPG) értéket, amely kertek küldése között kötelezően kivárandó időtartamot jelöli. Ez 96 bitidőnyi időtartamban került rögzítésre, ez időmértékben az jelzési sebességgel fordítottan arányosan csökken. Az FCS ellenőrzőösszeg az alábbi módon kerül számításra a védett mezők függvényeként a következő generátor polinommal [7]:
1.
A keret első 32 bitjét negálják
2.
A védett mezők n bitjét egy M(x) n-1 –ed fokú polinommal együtthatóival reprezentálhatók
3.
M(x)-et x32-ennel megszorozva polinom osztást kell végezni G(x)-szel, 17
ami 31-ed fokú polinomot ad maradékul, R(x) 4.
R(x) együtthatói egy 32-bites számmal reprezentálhatóak
5.
Ez a 32 bites bitsorozat negáltja adja az ellenőrzőösszeget, amivel mod32(k)=1-31 bithibát képesek vagyunk észlelni, az FCS a többi bájttal ellentétben természetes bitsorrenddel kerül továbbításra
A PHY réteg szolgálatait a MAC számára PLS, azaz Fizikai Jelzésszolgálat által nyújtja. Ezek a primitívek két csoportra oszthatóak [8]: 1.
Peer-to-Peer (társentitások közötti) PLS_DATA.request PLS_DATA.indication
2.
Sublayer-to-Sublayer (alrétegek közötti) PLS_CARRIER.indication PLS_SIGNAL.indication PLS_DATA_VALID.indication
Mivel a szabvány lehetővé teszi többféle fizikai rétegbeli technológia használatát (réz, optika, szabadtéri hullámterjedés), így kézenfekvőnek látszik egy fizikai közegtől független adatcserét biztosító eljárás kidolgozása. Erre a szabvány által specifikált MII (Media Independent Interface) biztosít lehetőséget, de ez esetben a kompatibilitás megtartása miatt egy ún. kibékítő alréteget (Reconcilation sublayer) kell alkalmazni, amely a szabványos PLS primitíveket leképzi az MII interfész jeleire [9]. A szabványban specifikált PLS.DataRequest szolgálati primitív egy bit továbbítását biztosítja a fizikai interfészen, ami külső PHY implementáció esetén praktikusan 100Mbit/s-os sebességen, alapsávi digitális jelátvitel esetén 100MHz-es órajelet igényel, ami elektromágneses kompatibilitás szempontjából nem előnyös, így az MII által használt négybites TXD[3:0] (4 bit = 1 nibble) adatvezeték ugyanezt a sebességet 25 MHz-es órajel esetén képes elérni. A Gigabit MII (GMII) nagyon hasonló az MII interfészhez, ugyanolyan jel elnevezéseket alkalmaz, csak az RXD és TXD adatbusz szélességek, illetve az órajel terjesztésében tér el. A GMII interfész főbb jellemzői:
1000 Mbit/s-os működés támogatása
Az adat és az elválasztó szimbólumok az órajelhez szinkronizáltak
Független adási és vételi, 8 bit széles adat utat biztosít, ezáltal lehetőséget ad a full-duplex működésre
Az IPG minimális értékét lecsökkentették 64 bitidőnyi időtartamra 18
2.3 Address Resolution Protocol (ARP) Az ARP-t [11] az IETF 826-os számú RFC-je írja le, melynek célja, hogy a hálózati címeket adatkapcsolati rétegbeli címekké fordítsa le. Eredetileg a DEC/Intel/Xerox 10Mbit-es Ethernethez tervezték, de általánosítva lett más típusú hálózatok kezelésére is. Ethernet II-es keret esetén az ARP EtherType kódja 0x0806. Az ajánlásban „Protokoll” néven az Ethernet szolgálatait használó hálózati protokollt értik. Az ARP a 8. ábran illusztrált csomagformátumot alkalmazza. Ebben nincsenek töltelékbájtok a címek között, tehát úgy kell a csomagra tekinteni, mintha egy bájtfolyam lenne, és csak három bájtpáros van szóként definiálva (ar$hrd, ar$pro és ar$op), amik MSB First szintaxissal kerülnek küldésre: ---|0 | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16| ------------------------------------------------------ | --0| Hardware Address Space (ar$hrd) | ---|--------------------------------------------------| --1| Protocol Adress Space (ar$pro) | ---|-------------------------------------------- ------| --2| B.len HWAddr ar$hln | B.len ProtoAddr ar$pln | ---|--------------------------------------------------| --3| Opcode ar$op [ares_op$REQUEST | ares_op$REPLY ] | ---|--------------------------------------------------| --.| ar$sha HWaddress OF sender, n=ar$hln | ---|--------------------------------------------------| --.| ar$spa Protoaddress OF sender, n=ar$pln | ---|--------------------------------------------------| --.| ar$tha HWaddress OF target, n=ar$hln | ---|--------------------------------------------------| --.| ar$tpa Protoaddress OF target, n=ar$pln | ---|--------------------------------------------------|
8. ábra Az ARP csomagformátuma
A csomag mezői Ethernet és IPv4 használata esetén a következőek:
ar$hrd = ares_hrd$Ethernet = 0x0001 => Fizikai címtartomány ar$pro = 0x0800 => Protokoll címtartomány ar$hln = 6 (6 bájt = 48 bit) => Fizikai címhossz ar$pln = 4 (4 bájt = 32 bit) => Protokoll címhossz ar$op = [ares_op$REQUEST | ares_op$REPLY] => Műveleti kód o ares_op$REQUEST = 0x0001 => Kérés kódja o ares_op$REPLY = 0x0002 => Válasz kódja ar$sha => A küldő fizikai címe ar$spa => A küldő protokoll címe ar$tha => A cél fizikai címe ar$tpa => A cél protokoll címe, melyek közül a fizikai címek az ar$hln mezőnek megfelelően 6 bájtosak, és a protokoll címek az ar$pln mező szerint 4 bájtosak, az Ethernet MAC és az IPv4 címek hosszához igazodva.
ARP kérés csomag akkor generálódhat, amikor hálózati csomag továbbítása esetén az útvonalválasztás meghatározza a következő hálózati csomópont hálózati 19
címét, és a továbbításhoz szüksége van még a <protokoll típus, hálózati célcím> páros alapján a következő hálózati csomópont adatkapcsolati rétegbeli címére. Ekkor az ARP modul megpróbálja megkeresni ezt a párost a táblázatában, és ha megvan, akkor a felhasználó modulnak visszaadja. Ha nincs találat, akkor a saját Ethernet MAC rétegének
MA_DATA.request
szolgálati
primitívét
felhasználva
küld
egy
üzenetszórásos keretet (célcím: 0xFFFFFFFFFFFF), amelynek forráscíme a saját adatkapcsolati rétegbeli címe, a Type/Length mező érték 0x0806, és a fentebb ismertetett ARP csomag a szolgálati adateleme. A kiküldött ARP csomagban a műveleti kód az ares_op$REQUEST értéket veszi fel, míg a küldő és a címzett protokoll címe és a küldő adatkapcsolati rétegbeli címe értelemszerűen a nekik megfelelő értékeket veszik fel, addig a címzett adatkapcsolati rétegbeli címe ebben a csomag érdektelen, de az ajánlás említi, hogy van arra lehetőség, hogy a 0xFFFFFFFFFFFF értéket vegye fel. A továbbiakban az egyszerűség kedvéért az adatkapcsolati rétegbeli címere fizikai címként hivatkozom. Az ARP kérés csomag vétele esetén az ajánlás a következő algoritmust specifikálja: (negatív döntési kimenetel estén a csomag eldobódik) ?Az én fizikai címtartományom megfelel a kérésben lévőnek? (ergo kompatibilis-e az adatkapcsolati rétegem a társentitáséval) [opcionálisan ellenőrizhető az ar$hrd mező értéke] Igen:
?Ismerem az ar$pro által megjelölt protokollt? [opcionálisan ellenőrizhető az ar$pln mező értéke] Igen:
Beolvasztás jelző:= Hamis Ha <protokoll típus, hálózati forráscím> páros szerepel a táblában, frissíteni kell a fizikai forráscímet az új információval a csomagból és Beolvasztás jelzőt Igazra állítani ?Én vagyok a hálózati célcím? Igen:
Ha a Beolvasztás jelző hamis, hozzáadni a <protokoll típus, hálózati forráscím, fizikai forráscím> hármast a címfordítási táblához. ?A műveleti kód ares_op$REQUEST? Igen:
megcserélni a küldő és cél fizikai és hálózati cím mezőket, úgy hogy aztán lokális fizikai cím a forrás fizikai cím mezőbe kerüljön bele, beállítani az ar$op mezőt ares_op$REPLY –ra és elküldeni a csomagot az új fizikai célcím részére azon a hardveren keresztül, ahol érkezett
Az ajánlás nem tartalmaz konkrét leírást arról, hogy a címfordítási táblának mekkora méretűnek kell/ajánlott lennie, illetve, hogy van-e és mekkora az egyes rekordok elévülési ideje. Mivel a táblázat mérete nincs definiálva, ezért akár az 0 vagy 1 elemű is lehet, amely reális lehetőség hardveres vagy akár szűkös erőforrásokkal 20
gazdálkodó protokoll-implementációk esetén. Ekkor, ha a felsőbb réteg az ARP modulhoz fordul címfordításért, lehet, hogy addig várnia kell, amíg a megfelelő címfordítási üzenetek kicserélődnek. További probléma ekkor az, hogy nincs nyugtázás, ezért az összes hibavédelmi eljárás az adatkapcsolati és fizikai réteg hibavédelmi és hibakorlátozó
módszereire
támaszkodik.
Mivel
az
ajánlás
nem
specifikálja
adatkapcsolati rétegtől függően az ares_op$REQUEST vétele esetén irányadó válaszadási időket és újrapróbálkozási kísérletek számát, így az implementáció tervezési részénél ezt figyelembe kell majd vennem – különösen fontos ez 0 vagy 1 elemű táblaméret esetén
2.4 Internet Protocol Version 4 (IPv4) Az Internet protokollt [12] egymással kapcsolatban álló, csomagkapcsolt számítógép hálózatokban történő felhasználásra tervezték. A protokoll lehetőséget biztosít adatblokkok, úgynevezett datagramok1, átvitelére a feladótól a címzettig, ahol a két fél rögzített hosszúságú címmel rendelkezik. A protokoll lehetőséget biztosít a hosszú datagramok tördelésére és összeállítására, ha a továbbítás olyan hálózati részben szükséges, amely nem képes a nagy csomagméretet kezelni. A protokoll a helyi hálózati protokollokra támaszkodik abban, hogy a hálózati szintű datagramokat a következő IP hálózati átjáróhoz vagy a célcímzettnek továbbítsa. Az internet modulok az internet fejlécben található címeket használják fel arra, hogy az internet datagramokat a céljuk felé továbbítsák. A továbbítási irány kiválasztását nevezik útvonalválasztásnak, vagy más néven routingnak. Az internet protokoll
minden
egyen
datagramot
egymástól
függetlenül
kezel,
teljesen
kapcsolatmentesen. A protokoll négy kulcsfontosságú működési elemet alkalmaz a szolgáltatás biztosítása érdekében: szolgáltatás típusa (Type of Service - TOS), élettartam (Time to Live - TTL), opciók (Options) és a fejléc ellenőrzőösszeg (Header Checksum). A TOS jelzési lehetőséget ad a kívánt szolgáltatási kritériumok jelzésére. A TTL megadja az internet adatelem élettartamának felső korlátját. A küldő állítja be
1
Datagram: önálló, független üzenet a hálózatban, melynek megérkezésére, kézbesítési idejére
és a szállított információ sértetlenségére semmilyen garancia nincs. A telegram analógiája alapján (távirat) értelmezhető, szabatos fordításban adat-távirat, adatelem. (http://docs.oracle.com/javase/tutorial/networking/datagrams/definition.html,2013.05.14)
21
feladáskor, és az útvonal mentén, feldolgozáskor csökken. Ha az értéke eléri a nullát, mielőtt a csomag eléri a célját, az megsemmisül. Az opciók segítségével speciális vezérlési funkciókat lehet alkalmazni szükség esetén, de az általános kommunikáció esetén nem szükséges alkalmazni azokat. Többek között időbélyegek, biztonság és speciális útvonalválasztás biztosítását teszi lehetővé. A fejléc ellenőrzőösszeg azt a célt szolgálja, hogy az adatelem feldolgozása esetén használt mezők helyesen kerüljenek továbbításra. A szállított adat tartalmazhat hibákat, azonban ha az ellenőrzőösszeg hibás, akkor a datagram azonnal elvetésre kerül a rendellenesség észlelője által. A protokoll nincs felvértezve a megbízható kommunikáció nyújtásához szükséges eszközökkel. Nincsenek nyugták, sem végponttól végpontig, sem a szomszédos csomópontok között. Nem létezik hibavédelem a szállított adat vonatkozásában, csakis a fejléc védett a fejléc ellenőrzőösszeg által. Nincs folyamszabályozás, amellyel a lassabb vevők szabályozhatnák a gyors adókat, ezzel elkerülve a csomag-elárasztást. Bármilyen egyéb észlelt hiba jelentésére az Internet Control Message Protocol (ICMP) használható. Az IP által használt címek fix hosszúságú címek 4 bájt, azaz 32 bit terjedelemben. Egy IP cím a hálózati címmel kezdődik, amit a helyi cím követ, amit maradék mezőnek is szokás hívni. Az ajánlás háromféle különböző osztályú címet definiál, ahol a hálózati cím rész rendre 8, 16 illetve 24 bitet foglal el, de ezt későbbi ajánlások kiegészítették az ún. Classles InterDomain Routing (CIDR) keretében, ami a hálózati címek kiosztását finomabb granularitással teszi lehetővé, ugyanis a hálózati cím rész itt összesen 33 féle hosszúságban állhat elő. Az eredeti, osztályokat definiáló címzés esetén a három osztály az a, b és c. Az a osztályú cím esetén a legmagasabb helyi értékű bit 0 értékű és a következő hét bit adja meg a hálózati címet, míg a maradék 24 a helyi címet. B osztályú címnél a két legfelsőbb bit értéke 102 és a következő 14 bit adja a hálózati, míg a maradék 16 a helyi címet. C osztályú cím esetén 110 2 értékű a legfelső három bit, míg a következő 21 bitből áll elő a hálózati cím, míg az utolsó nyolcból a helyi cím, ami így 256 különböző címet szolgáltathatna, de mivel a csupa 0 bit értékű és a csupa 1 értékű lokális cím foglalt így 254 megcímezhető entitást eredményez. A csupa nullaértékű lokális cím esetén az egész 32 bites cím a hálózat címét adja meg, míg a csupa 1 értékű az adott hálózat üzenetszórásos (broadcast) címe, amik minden hálózat estén foglalt címek.
22
Az internet csomag megjelölhető nem tördelhető csomagként. Az ekként megjelölt adatelemet semmilyen körülmények között nem szabad tördelni. Ha egy datagram nem továbbítható a címzett részére tördelés nélkül és emellett nem tördelhetőnek van megjelölve, akkor azt el kell dobni. Tördelés és újraegyesítés a helyi hálózatban használt adatkapcsolati protokollban használható, de ennek transzparensnek kell lennie az internet protokoll számára. Az internet fejléc szerkezete a 9. ábraán látható. ------------------
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |TYPE OF Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3
9. ábra IP fejléc szerkezete
A 4 bites Version mező jelzi az internet fejléc formátumát, amely az IPv4 esetén a 4-es értéket veszi fel. Az Internet Header Length (IHL) mező megadja a fejléc hosszát 32 bites szóhosszban, és egyben jelzi a szállított adat kezdetét a csomagban. Egy érvényes fejléc esetén az IHL értéke nagyobb vagy egyenlő, mint 5. A 8 bites Type of Service (TOS) mező indikálja az igénybevett szolgáltatás absztrakt minőségi paramétereit. A 16 bites Total Length mező az adatelem hosszát jelzi 8 bites egységekben, beleértve a fejlécet és az adatot is. A 16 bit összesen így 65535 bájt csomagméretet engedélyez, de ilyen hosszú csomagok a legtöbb helyi hálózat számára nem kézenfekvőek, de az összes entitásnak kezelnie kell a legalább 576 bájtos csomagokat, akár tördelve akár egyben érkeznek. Az ajánlás szerint a feladónak csak akkor javasolt 576 bájtnál nagyobb csomagokat küldenie, ha biztosítva van arról, hogy a célcím képes a nagyobb méretű csomagok fogadására. Az Identification 16 bites mező egy azonosító, amit a feladó rendel a csomaghoz, mely azonosító segítséget nyújt tördelés esetén a csomag újbóli összeállításához.
23
A 3 bites Flags mező vezérlési jelzéseket valósít meg, a 0. bitje fenntartott, logikai 0 értékűnek kell lennie. Az 1. bitje a DF bit, amelynek logikai 0 értéke jelzi, hogy a csomag szükség esetén tördelhető, míg 1-es érték esetén nem. A 2. bit 0 értéke jelzi, hogy a csomag az utolsó töredék, míg 1-es esetén azt mutatja, hogy a csomag tördelve lett. A Fragment Offset 13 bites mező jelzi, hogy az adott datagramon belül ez a töredék hová tartozik, mértékegysége 8 oktett, azaz 64 bites egységben adja meg a pozíciót. Az első töredék ofszetje nulla értéket kell, hogy felvegyen. A Time to Live (TTL) 8 bites mező megmutatja, hogy a csomag maximálisan mennyi ideig keringhet az interneten, ha ez a mező csupa értékű, akkor a csomagot meg kell semmisíteni. A Protocol mező 8 bitjén ábrázolják a felsőbb szintű protokoll azonosítóját, amelynek adatelemét az adott internet csomag szállítja. Az azonosítók a különböző protokollokhoz az Internet Assigned Numbers Authority (IANA) adminisztrálja2. A 16 bites Header Checksum mező szállítja a fejléc ellenőrző összeget, amelyet úgy kell számolni, hogy a fejlécben található összes 16 bites szót egyes komplemens aritmetikával összegeznek, majd az eredményt invertálják. Az ellenőrzőösszeg számításnál e mező értéke a csupa 0 bit. Az ajánlás szerint ez egyszerűen számítható és emellett a gyakorlati tapasztalat azt mutatja, hogy kellő védelmet nyújt a fejléc számára. A 32 bites Source Adress és Destination Adress mezők rendre a forrás és a cél internet címét tartalmazzák. Az Options mező változó hosszúságú lehet, de mindenképpen egy bájt egész számú többszöröse. Az ajánlás tartalmazza a rendelkezésre álló opciók részletes leírását, és felhasználási lehetőségeit. A Padding mező szerepe, hogy a fejléc hossza 32 bit egész számú többszöröse legyen, ugyanis az IHL mező által megadott hossz ebben az egységben értelmezendő. Az internet protokollt felhasználó modul (röviden felhasználó) minden egyes szolgáltatáskérés esetén meg kell, hogy adja a szolgáltatáshoz szükséges paramétert, mivel a protokoll közel memóriamentes, és nincs állapotkövetés a csomagküldések között sem. Az ajánlás által meghatározott küldéshez használható felhasználói interfészt
2
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
24
a SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result) primitív definiálja, ahol
src = forrás cím dst = célcím prot = protokollazonosító TOS = szolgáltatási osztály TTL = életben maradási idő BufPTR = puffer mutató len = puffer hossza Id = azonosító DF = nincs tördelés opt = opciók result = válasz a küldési kérésre o OK = a csomag rendben elküldésre került o Error = hiba az argumentumokban, vagy a helyi hálózaton
A vétel esetén a bejelentés szolgálati primitíve a RECV (BufPTR, prot, => result, src, dst, TOS, len, opt), ahol az egyes paraméterek a fenti értelmezés alapján azonosíthatóak. Ha a felhasználó csomagot szeretne küldeni, a Send primitív segítségével tudja megtenni. Az internet protokollt megvalósító modul ellenőrzi az argumentumokat, majd előkészíti és elküldi az üzenetet. Ha jók az argumentumok és a csomag átadásra került a helyi hálózat számára, akkor a sikeres válasszal tér vissza a felhasználó számára, egyébként hibát jelez. Ha egy adatelem érkezik a helyi hálózatról, az internet modul a protokollazonosító mezőben lévő érték alapján értesíti a megcímzett felhasználót, aki a RECV primitív segítségével veheti át a részére küldött adatot. Az értesítés menete nem meghatározott, bármilyen módon történhet, ami az adott platformon megvalósítható. Az ellenőrző összeg kiszámításának különböző módjaira a [13] ad ajánlást, amit szintén
tanulmányoztam,
mivel
hasonló
eljárást
lehet
alkalmazni
az
UDP
ellenőrzőösszeg kiszámításakor. A munkámhoz az MSB First szintaxis az érdekes, ez került alkalmazásra az egész rendszerben, mivel ez a hálózati bájtsorrend is. A 16 bites ellenőrzőösszeg számítása többféle módon elvégezhető. 16 bites akkumulátor esetén, ha baloldalon átvitel keletkezik, akkor minden esetben a carry bitet a legkisebb helyi értéken hozzá kell adni az eredményhez, mielőtt további összeadást végeznénk, azonban ez bonyolult hardveres leírást eredményezne. Ehelyett a kézenfekvő megoldás, hogy 32 bites akkumulátort kell alkalmazni, összeadni az összes műveleti tagot. Ekkor a 32 bites 25
akkumulátor felső 16 bitjében található az átvitelek összege. Az akkumulátor felső 16 bitjét ezután hozzá kell adni az alsó 16 bitjéhez. Ez az összeadás még eredményezhet átvitelt a 17-biten, amit még szintén hozzá kell adni az alsó 16 bithez. Ezzel így előáll a 16
bites
egyes
komplemens
aritmetikával
számolt
részösszeg,
amelyet
a
végfelhasználáshoz még bitenként invertálnak, mivel egyes komplemens számábrázolás esetén ez az összeg -1-szerese. Vétel esetén, ha a fejléc a fenti módon számított ellenőrző összeget tartalmazza, akkor ismét a leírt 32 bites akkumulátorral használt összeadási eljárást alkalmazva, a műveletsor végén 0-át, egész pontosan -0-t kell kapnunk, ami a csupa egyes bitnek felel meg a 16 bites ellenőrzőösszeg mezőben. Ebben az esetben jó eséllyel a fejléc nem hibásodott meg az átvitel során. Mivel a TTL értéke minden feldolgozás esetén változik, ezért az ellenőrzőösszeget minden ilyen esetben újra kell számolni, és minden hop esetén ellenőrzi azt a fogadó internet modul.
2.5 User Datagram Protocol (UDP) Az UDP-t [14] abból a célból definiálták, hogy a csomagkapcsolt számítógép hálózatok datagram alapú kommunikációját ki lehessen használni a hálózati protokoll szolgálatai felhasználva. Ez egy szállítási rétegbeli protokoll, és az ajánlásban a felhasznált hálózati protokollként az IPv4-et alkalmazzák. A protokoll eszköztárat biztosít az alkalmazás rétegbeli felhasználóinak, hogy üzeneteket
tudjanak
küldeni
más
alkalmazásoknak
minimális
protokolláris
mechanizmus alkalmazásával. Az UDP tranzakció-orientált, és kézbesítési valamint a duplikáció elleni garanciát nem kínál. Azok az alkalmazások, amelyek sorrendhelyes, megbízható adattovábbítást igényelnek a Transmission Control Protocol-t (TCP) érdemes használniuk szállítási protokollként. Az UDP csomag formátumát a 10. ábra illusztrálja: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Soure | Destination | | Port | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | data octets ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10. ábra Az UDP csomag formátuma
26
A Source Port egy 16 bites opcionális mező, melynek jelenléte esetén az érték azonosítja a küldő alkalmazást, és feltételezhető, hogy a válaszüzenetet a küldő alkalmazás ezen a porton fogja fogadni. Ha nincs használatban, akkor a csupa 0 bites érték jelzi ezt. A Destination Port 16 bites mező a cél IP címmel együtt nyer értelmet, mivel a hálózatban az
páros egyértelműen azonosít egy hálózati alkalmazást, amely részére az UDP datagram szól. A 16 bites Length mező megadja az UDP datagram teljes hosszát bájtokban mérve - beleértve a fejléc részt is -, ebből következik, hogy érvényes csomag esetén a minimális értéke 8. A szintén 16 bites Cheksum mező egyes komplemense az egyes komplemens aritmetikával összegzett, IP fejlécből származó információkból összeállított pszeudófejlécnek, az UDP fejlécnek és az adat rész 16 bites szavainak, amely szükség esetén 1 darab csupa 0 bitből álló bájttal kerülhet kiegészítésre, ha mérete nem 2 bájt egész számú többszöröse. A pszeudó-fejléc tartalmazza a cél és a forrás IP címét, az UDP protokoll azonosítóját és az UDP csomag hosszát. Mivel így az ellenőrzőösszeg része ez az információ, így ez egy bizonyos fokú védelmet ad a félreirányított csomagok ellen. A pszeudó-fejléc szerkezete - melynek mezeinek leírását az IPv4-es fejezetben részletesen bemutatok - a 11. ábraán látható: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | source address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | protocol | UDP length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11. ábra Az UDP ellenőrzőösszeg számításához használt pszeudó-fejléc szerkezete
Ha kiszámolt ellenőrzőösszeg nulla, akkor annak az egyes komplemense a csupa egyes bit, ami ebben a számábrázolásban a -0, tehát akkor az ebben formában kerül továbbításra. Ha az ellenőrzőösszeg mezőben csupa nulla szerepel, akkor az azt jelzi, hogy a feladó nem generált ellenőrzőösszeget, vagy az összegzés eredménye 0xFFFF lett, de mindkét estben a csomag érvényesnek minősül. Az UDP implementáció felhasználói interfészének támogatnia kell új fogadási portok létrehozását és azokon értelmezett fogadási műveletet, ami visszatérési értékként szolgáltatja a szállított adatot, a forrás IP címet és portot, továbbá lehetőséget kell 27
biztosítania arra, hogy a felhasználója datagramot tudjon küldeni egy általa meghatározott forrás IP címről és portról egy adott cél IP címre és portra. A protokoll IP implementációval szemben támasztott követelménye, hogy IP csomag fogadása esetén rendelkezésére álljon a feladó és a cél IP cím, és a protokoll mező az IP fejlécből, adás esetén hasonló követelményeket fogalmaz meg az ajánlás. Az UDP legfőbb felhasználási módja a Domain Name Service és a Trivial File Transfer alkalmazásrétegbeli protokollok.
2.6 Simple Network Management Protocol (SNMP) Az SNMP [15] architekturális modellje hálózatmenedzselő állomások és hálózati elemek összessége. A menedzsment állomások menedzselő alkalmazásokat hajtanak végre, amelyek monitorozzák és vezérlik a hálózati elemeket. Hálózati elemek lehetnek: hálózati csomópontok, átjárók, terminál kiszolgálók és bármi, ami rendelkezik menedzsment ágenssel (tehát akár a feladatban használt interfészkártya is), ami felelős a hálózatmenedzselési funkciók ellátásáért, amit a menedzsment állomásról kérvényeztek. A menedzsment információ továbbítására az ágens és menedzselő állomás között a SNMP protokoll használandó [15]. A
menedzsment
reprezentálják
információt
objektumokkal
és
a
menedzsment
értékekkel,
információs
amelynek
szerkezetét
bázisban szintén
szabványok specifikálják. Az Internettel kapcsolatos számos objektum modellezve van ilyen MIB-ben [14][17]. A MIB hierarchikus szerkezetű, egy gyökerű fa struktúrába szerveződik, az objektumok ebbe a fában helyezkednek el és pozíciójukat az objektumazonosító egyértelműen jelöli x.y.z… stb. formában, ahol x,y,z pozitív egész számokat jelölnek a MIB specifikációnak megfelelő tartományból. A
protokoll
valójában
ezen
objektumokon
való
lekérdezésekhez
és
módosításokhoz használandó (SET, GET PDU-k), amelynek hatására az ágens az SNMP-t használó menedzsment állomás által végrehajtott alkalmazás céljának megfelelő működést produkál, továbbá a kéretlen bejelentések (TRAP PDU-k) is objektumokhoz
kötődnek
általános
vagy
alkalmazás
specifikus
módon.
Természetesen az egyes ágensek nem valósíthatnak meg minden működést, illetve nem implementálhatják az információs bázisban található összes elemet, de ezt a protokoll képes megfelelő válaszüzenetben jelezni (tooBig, noSuchName, badValue, genErr). 28
Az SNMP a TCP/IP és OSI modellben a legfelső szinten helyezkedik el, azaz alkalmazás-rétegbeli protokoll. Szállítási rétegként leggyakrabban UDP-t használ. Az ágens a szabvány szerint a 161-es porton fogadja a menedzser által bármely szabad portjáról küldött SNMP PDU-kat, itt a tranzakciók kérés-válasz alapúak, míg az ágens által küldött bejelentéseket a menedzser 162-es porton fogadja [15]. Az SNMP PDU szerkezetét ASN.1-es [18] nyelven definiálták, és a reprezentációja is e szabvány által specifikált BER kódolást használja kivéve az OBJECT ID, ami a DER kódolást használja[18]. A BER kódolás szerkezete a 12. ábraán látható:
12. ábra A BER kódolás szerkezete [18]
A BER kódolás a zsargonban még Type-Length-Value (TLV) kódolásnak is hívják. A típusoknak léteznek osztályaik, lehetnek primitívek és összetett típusok. Például az SNMP PDU maga is egy összetett szerkezet, univerzális osztályú típussal. A Length mező kódolása három féle lehet: a rövid formátum esetén a mező első bitje 0 és a maradék 7 jelzi a hosszt, így összesen 127 bájtos hossz jelezhető. A második a hosszú formátum, ahol a mező első bitje ’1’, és emellett további 7 bit jelzi a hosszat megadó bájtok számát, majd ezt követik a tényleges hosszt megadó bájtok. Így összesen 127 bájton lehet ábrázolni a hosszúságot, amivel akár
bájt
hosszú adatszerkezet hosszát is le lehet írni. A harmadik formátum az indefinit, ahol a mező értéke 0x80, azaz a hosszú formátum nulla hosszbájt megjelöléssel, viszont ekkor az az érték végét az End-Of-Content típussal kötelező lezárni. Az objektumazonosító értéke önmagában is kódolt, amit egy rövid példán keresztül mutatok be: Példaként vegyük az 1.3.6.1.3.1024.1-es objektumazonosító teljes kódolását (BER+DER). Az 1.3.6.1.3-as OID az objektum fában a (ISO assigned OIDs)-(ISO Identified Organization)-(US Department of Defense)-(Internet)-(Experimental),
29
azaz kísérleti jelleggel használható objektumazonosítók, az 1024.1 pedig általam önkényesen választott azonosítók [20]. Az objektumazonosító DER kódolása 128-as alapú. Mivel az első tag csak 0,1,2, míg a második tag pedig a 0-39 terjedő értéket veheti fel decimálisan, így egy bájton lehet ábrázolni ezeket, úgy hogy az első számot megszorozzuk 40-nel és hozzáadjuk a második tagot. Jelen esetben 1*40+3 = 43, ami 2*16+11, azaz 0x2b. A további értékeket 1 bájton kódoljuk, ha decimálisan 128-nál kisebbek, ha nagyobbak, akkor többen. Ezek az egy vagy több átmeneti bájtok, amelyek megadják a bázist plusz egy maradékbájt, amely az ábrázolni kívánt szám és a bázis különbsége. A példában az 1024 lesz az első problémás érték. Mivel nagyobb, ezért átmeneti bájtot kell használnunk, amit az 8-ik helyi értéken lévő ’1’ jelez. Az átmeneti bájt alsó értéke, megadja 128-as bázis koordinátáját, 1024/128=8 a maradék bájt, pedig az érték és a koordinátaszor a bázisérték különbsége, 1024-8*128 =0, így a DER kódolt OID értéke: 0x26 0x06 0x01 0x03 0x88 0x00 0x01, amelynek hossza 7, így a teljes BER kódolt OID (OID típus = 0x06): 0x06 0x07 0x26 0x06 0x01 0x03 0x88 0x00 0x01.3
3
Az
OID
bináris
kódolásához
elérhetőek
online
http://www.viathinksoft.de/~daniel-marschall/asn.1/oid-converter/online.php
30
eszközök
is,
például:
Az SNMP üzenetek szerkezetét a 13. ábrán lehet áttekinteni:
13. ábra Az SNMP PDU struktúra, és PDU típusok [19]
A szabvány ASN.1-es jelölésmóddal definiálja a protokollüzenetek szerkezetét, ami egyben meghatározza azok binárisan kódolt formáját is a fentebb leírt BER kódolási szabályok alapján. Message ::= SEQUENCE { version INTEGER { version-1(0) }, community OCTET STRING, data ANY }
Azaz az SNMP üzenet egy szekvencia, amelynek kódja 0x30, ezt követi az üzenet hossza, a már ismertetett szintaxissal. Ezután a verzió mező jön, ami egy egész szám, kódja 0x02, az ASN.1-es szabvány definiálja az egész számok kódolásának módját abból a szempontból, hogy mekkora számhoz milyen ábrázolási tartományt használandó, azaz hány bájton reprezentált az egész szám az értékétől függően. A leírásból látszik, hogy az 1-es verziójú SNMP üzenet 0 értékű, ezt 1 bájt hosszon kell kódolni, azaz a már így előállt csomagkezdet 0x30 [hossz] 0x02 0x01 0x00, amit egy bájt
láncolat követ,
ami
a közösségi
azonosítót
hordozza. Ezt
alapszintű
authentikációhoz használatos, kódolása: OCTET STRING := 0x04 [hossz] [Community String].
31
A v1-es ajánlás 5 féle PDU-t definiál: PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-response GetResponse-PDU, set-request SetRequest-PDU, trap Trap-PDU }
A PDU típus BER kódolást tekintve egy kontextus specifikus, összetett típus, tehát az azonosítójának első három bitje 1012 értékű. A továbbiakban a Trap PDU szerkezetét tekintem át, mivel a feladathoz ennek az alapos ismerete szükséges. Ahogy látszik a Trap-PDU altípusának azonosítója 4-es, így a BER azonosító bájtja 101001002 értékű, ez hexadecimálisan 0xa4. Trap-PDU ::= [4] IMPLICIT SEQUENCE { enterprise OBJECT IDENTIFIER, agent-addr NetworkAddress, -- trap generic-trap INTEGER { coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5), enterpriseSpecific(6) }, specific-trap INTEGER, time-stamp TimeTicks, variable-bindings VarBindList }
Az enterprise jelöli a Trap üzenetet generáló objektumot annak objektum azonosítójával. Az agent-addr a Trap üzenetet generáló hálózati entitás hálózati címét adja meg. A generic-trap mezőben a fentebb deklarált eseményeket van lehetőség jelezni. A specific-trap egy küldő objektummal együtt értelmet nyerő információs mező. A time-stamp -pel mutatja meg a hálózati entitás utolsó inicializációja és a trap küldése 32
óta eltelt időt mutatja. A variable-bindings -ben lehet további információt közölni, amelynek szerkezetét az alábbi makrók írják le: VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } VarBindList ::= SEQUENCE OF VarBind
Eszerint a változó hozzárendelési lista változó hozzárendelések szekvenciája, mely hozzárendelések nevekből és értékekből álló párosokból állnak. A lista nem opcionális elem, de lehet nullaelemű is. Ekkor az érvényes szintaxisa 0x30 0x00, ahol a 0x30 a SEQUENCE OF típus BER kódja, míg a 0x00 jelöli, hogy az értékként hordozott mező hossza 0 bájt. Ahogy az a fenti leírásból látszik az ASN.1 kódolás és dekódolás nem egyszerű feladat, hozzávéve még az OID kódolást és dekódolást szintén nem egyszerűsödik a helyzet. A nehézséget hardveres környezetben az okozza, hogy nehéz felkészülni a mezők különböző ábrázolási módjaira, mivel akár többféle ekvivalens szintaxis is létezhet, már csak a BER kódolás hosszmegjelölés szerkezetét tekintve. Az SNMP PDU méretére a felső korlátot az első szekvencia BER kódolásából adódó hosszmegjelölés adja hosszú formátum esetén, ám ez a szám akkora, hogy a valódi korlátot az UDP szállítási réteg Length mezejének 16 bitje adja, így az SNMP PDU maximális mérete 65535-8 azaz, 65527 bájt lehet. Mivel hardveres feldolgozás esetén nem szükséges tárolni az egész PDU-t, hanem fogadás közben is lehet dekódolni azt, meghatározott késleltetéssel, így nem ez a kritikus pont, hanem a kihívást ebben a MIB tárolása és az abban való keresés okozza. Időzítés szempontjából a felhasználási céltól függenek az implementáció időzítési kritériumai. Az általános CPU-n futtatott programmal történő kódolás és dekódolás hatékonyabb lehet a hardveres realizációnál, mivel ott jellemzően magasabb órajelek mellett lehet memóriaműveleteket végezni. Ha azonban a realizált hálózati menedzsmentalkalmazás olyan, hogy SNMP üzenetben szállított információ az, ami időkritikus - például egy-vagy több esemény bekövetkezési idejének rögzítése, időbélyegzése, majd ennek a továbbítása egy hálózati menedzser számára -, ott egyértelműen hardveres realizáció szükséges. 33
2.7 Fejlesztés során használt eszközök A fejlesztés célplatformja Xilinx FPGA, így a fejlesztéshez a Xilinx ISE integrált fejlesztői környezetét használtam, amely tartalmazza többek között az iSim viselkedési szimulátort, mellyel az elkészített modulok viselkedési szimulációját és verifikációját lehet elvégezni. A céleszköz a kísérlethez a Xilinx Virtex 5 típusú XC5VLX50T jelzésű FPGA-ja, amely az Aitia Internataional ZRt. által készített GPlanar elnevezésű kártyán (lásd 14. és 15. ábra) foglal helyet, melyen két SFP foglalat található, amely így támogatja mind a réz mind az optikai Ethernetet.
14. ábra A GPlanar kártya
15. ábra A GPlanar architektúrája
34
Slice-ok száma
7200
Maximális elosztott memória
480 kbit
Felhasználható Blokk RAM
2160 kbit
GTP transzponderek száma
12
1. táblázat A Virtex-5 –ös XC5VLX50T típusú FPGA néhány adata
Az 1. számú táblázat a használt FPGA néhány főbb jellemzőjét foglalja össze. A Virtex-5-ben található Slice-ok abban különböznek az előző generációs FPGA-kban lévőktől, hogy 2-2 helyett 4-4 Flip-Flop-ot és LUT-ot tartalmaznak. A fejlesztés megkezdéséhez rendelkezésemre állt egy VHDL minta top-level design, amelynek tanulmányozása után el tudtam kezdeni az általam fejlesztett modulok integrálását. Ez a minta design tartalmazta a User Constraints File-t (UCF), ami rögzíti az időzítési kritériumokat, és az FPGA kivezetéseket hozzárendeli a designban lévő toplevel VHDL jelekhez. A top-level modulban helyet foglal egy úgynevezett applikációs modul, aminek az interfész jelei be voltak vezetékezve a top-level designba. A moduljaimat és általam megvalósított logikai hálózatot tehát az applikációs modulon belül kellett példányosítanom. A top-levelben helyet foglalt egy a GMII interfészt megvalósító modul, ami a GMII-n felül még a 802.3 –ben definiált ellenőrzőösszeg számítást is elvégezte. A GMII interfész modulnak a két kártyán található SFP foglalatnak megfelelően két interfésze van, amelyek a MAC_0 illetve MAC_1 előtaggal bírnak. Az interfész az általános jel és interfészismertetésben leírása került módon működik, azaz tartalmaz keretkezdet és végkijelölő jeleket az adatút mellett. A
kódfejlesztéshez
a
CollabNet
SubVersioN
verziókövető
rendszerét
használtam, amely nagyban segített a többféle implementációs út elágaztatásában és a sikeres változatok egyesítésében, illetve egyben a biztonsági mentés szerepét is betöltötte, mivel hálózati tárhelyre mentette a forrásfájlokat.
35
3 Tervezés 3.1 A munka állapota, készültségi foka a 2012/2013/I. félév elején Mivel az általános protokollkezelés kidolgozása FPGA felhasználásával a cél, így praktikusan tiszta lappal kellett indulnom a félév elején, és a végcél az volt, hogy általános módszertan kerüljön kidolgozásra, amellyel sokféle hálózati protokollt lehet megvalósítani. Meg kellett tervezni és implementálni a keretrendszert, amely alkalmas lesz a későbbiekben sokféle hálózati protokoll megvalósítására. A tárgyi félévben nem az FPGA specifikus részek kerültek előtérbe (úgy, mint például felhasznált CLB-k és blokk RAM-ok számának optimalizálása stb.), hanem általános rendszertervezési, és hardverleírási feladatok és az elkészített modulok logikai analizálása és viselkedési szimulációja, és szintetizálható VHDL leírás elkészítése volt a cél.
3.2 A munka állapota, készültségi foka a 2012/2013/II. félév elején A munkát a 2012/2013/II-es félévben a munkát az előző félév végi állapotából folytattam a modulok optimalizálásával. Az ipari konzulens javaslatára a bonyolult logikát
alkalmazó,
több
mint
5-6
bemeneti
jelet
feldolgozó
állapotgépek
egyszerűsítésével kezdtem. Első lépésként a PDUQueue modulban (ld. 3.4.2 és 4.1.2) optimalizáltam a hibakezelést, azzal, hogy a beépített FIFO hibakezelési mechanizmusát is felhasználtam, azaz a FIFO AlmostFullOffset generikus paraméterét a PDUQueue MAXPDUSize generikus paraméterének megfelelően úgy állítottam be, hogy a várakozási sorba egy maximális méretű csomag mindenképpen beleférjen, ellenkező esetben nem kerül beengedésre. A félév során elvégzendő feladatok: az ARP modul, az IP réteg, az UDP réteg és végül az SNMP részleges, működőképes implementációja a keretrendszer segítségével. Az implementáció után a tesztelés és verifikáció részfeladathoz a mérési elrendezések tervezése, és mérések elvégzése, kiértékelése volt a cél.
36
3.3 Specifikáció és rendszerterv Tekintve a kiírásban szereplő végcélt, ami egy alkalmazásrétegbeli protokoll implementálása az elkészített keretrendszer használatával, a rendszer tervezésekor az elsődleges szempont az volt, hogy az illeszkedjen a megismert protokoll-verem modellekhez, azaz a modulok is úgymond „rétegezhetőek”, egymás után hierarchikusan láncba fűzhetőek legyenek. Ezt a megközelítést követve még egy másik problémát is rövidre zárunk. Az általában hardverrel implementált hálózati protokollok egy bizonyos szint után már nem csak a saját felelősségi körükhöz tartozó PCI részeket állítják elő és értelmezik. Egy komponens ISO/OSI rétegeken átnyúlva több réteg feladataiért felel (pl. egy IPv4-et megvalósító modul generálja az Ethernet MAC keretet is önmagában), ami ezáltal rontja az egész rendszer flexibilitását. Tegyük fel, hogy később egy másik protokollt akarnánk használni, akkor vagy ismét implementáljuk ugyanazt a részt (ami felesleges, és erőforrást nem kímél), vagy majd akkor kell áttérni egy olyan modulszerkezetre, ami a kérdéses rétegek között biztosítja a megfelelő megközelítést, de ez még nem garantálja, hogy esetleg másik rétegekben nem ütközünk hasonló problémába. Az egyes protokoll rétegek, ahogy az már korábban ismertetésre került, a SAPokon keresztül, szolgálati primitívekkel kommunikálnak egymással. A feladat része ennek a kommunikációnak a megvalósítása is. A szolgálati primitíveknek többnyire protokollfüggő paraméterei vannak, de a struktúrája állandó, egyik része az ICI, a másik az SDU. Ebből adódik, hogy célszerű a keretrendszer elemeit két részre osztani: egy állandó rész, amely protokolltól függetlenül újra ás újra felhasználható, és egy változó rész, ami azon felül, hogy megvalósítja az adott protokollműködést, biztosítja a protokoll szabványa által specifikált felületet a magasabb és az alacsonyabb rétegek felé. A fentiek figyelembevételével az 16. ábrán látható rendszervázlat született a probléma megoldására.
37
(N-1;N) ICI kimenet
(N;N+1) ICI bemenet Protokollfüggő rész
(N-1;N) ICI bemenet
N-1. réteg
Vezérlés
PDU kimenet
(N;N+1) ICI kimenet
N. réteg
Adási irány megvalósítás
N+1. réteg
Adat
SDU bemenet
Állandó rész
PDU bemenet
Vételi irány megvalósítás SDU kimenet
16. ábra Általános rendszervázlat egy protokollrétegre
A 16. ábra alapján magyarázatra szorul, hogy miért érdemes különválasztani az adási és a vételi irány megvalósítást: a protokollok alapvetően vagy fél-duplex, vagy duplex kommunikációt használnak. Magától értetődően a duplex működés már magában foglalja a fél-duplex működést is. A kívánt működést a protokollfüggő rész és az állandó rész közötti vezérlő interfészen keresztül lehet megvalósítani megfelelő vezérléssel. Így a duplex és a fél-duplex működés már architekturálisan is támogatva van.
3.4 VHDL modulok interfész- és funkcionális specifikációja A következőkben áttekintésre kerülnek az előbbiekben megadott rendszervázlat kielégítésére megtervezett VHDL modulok interfész és funkcionális specifikációja, valamint az általánosan használt vezérlőjelek és adatfolyam formátumok.
3.4.1 Általános interfész-ismertetés A hálózati protokollok adatelemeinek általános alapegysége az oktett. Az egy oktettnél nagyobb illetve kisebb adat utak használata illesztési feladatokat igényelne, ami jelentősen megnövelné a rendszer késleltetését és komplexitását. Ezért az adatút szélessége célszerűen 8 bites a rendszerben, ami remekül illeszthető a célplatformon található GMII interfész be- illetve kimeneteire, mivel azok szintén 8 bites szélességet 38
alkalmaznak. Nagyobb sebesség esetén a végső kimeneti modul kimenetén, azaz majd az Ethernet réteg után lehetőség van áttérni szélesebb adatbuszra, például egy FIFO segítségével, természetesen megfelelően ügyelve az alul- és túlcsordulásra. A moduloknak a specifikáció alapján a végfelhasználás környezetében tudniuk kell engedélyezést kérni az erőforrás hozzáféréshez (például az adatkapcsolati réteg mellett más egyéb FPGA modul is hozzáfér a fizikai réteg vezérlőhöz), erre általánosan egy bejelentés és egy nyugtázás handshake jel kerül bevezetésre (az interfészspecifikációkban ezek rendre Ind és Ack nevű jelek). A hibakezelés érdekében a ki- és bemeneti adatbuszoknak rendelkezniük kell hiba ki- és bemenetekkel, tehát mind az adatbemenet tudja jelezni, ha hibatörtént a modulok közötti átvitel során, mind a forrás is tudja jelezni, ha nála történt hiba az adatkezelés során. A handshake menete az, hogy az adatforrásként funkcionáló modul Ind jel magas logikai értékkel jelzi, hogy érvényes protokoll-adatelem kezdetét szeretné továbbadni, amellett, hogy a kimeneti hibajelet alacsonyan tartja. A fogadó modul, ha képes a vételre az Ack jel logikai ’1’ értékével jelzi ezt. A forrás modul, ha bármilyen oknál fogva mégsem tudja megkezdeni az átvitelt, akkor Ind jel visszavételével elállhat az adástól. A nyugtázást a fogadó modul időkorlát nélkül visszatarthatja, viszont ha a kimeneti hibajelzéssel válaszol, akkor a küldő modulnak a küldeni szánt adatot el kell vetnie. Mivel egy protokoll adatelem összefüggő bájtok sorozata, ezért az adat ki- és bemenethez használandóak PDU kezdet és végkijelelő jelek (rendre SOP - Start of PDU és EOP - End of PDU). Az adatvonal csoportokhoz használatos egy adatérvényesség jelző bemenet (DV - Data Valid), ami órajel felfutó él mellett jelzi, hogy az adatvonalakon érvényes adat található. Ez a gyakorlatban írás engedélyező jelként használható a modulok közti átvitel esetén. Összefoglalva: egy PDU kezdetét az SOP és DV jelek órajel felfutó élre történő szinkron felfutása jelzi, míg a PDU utolsó oktettjét az EOP felfutó éle jelzi, így a következő órajelnél a DV és az EOP jeleknek már alacsony értéket kell felvenniük. Handshake-es átvitelt a PDU kezdet után megszakítani csak hibajelzéssel lehet, hibajelzés nélkül az átvitel mindaddig tart, amíg a végkijelölő szimbólum (DV és EOP) meg nem érkezik.
39
A handshake jelenléte nem minden esetben kívánatos, például ha a felhasználás helyén egy adott protokollréteget (N. réteg) megvalósító modul és az őt használó réteg (N+1. réteg) csak egyke a rendszerben, vagy ha egy réteget megvalósító modul kimenetét több felsőbb rétegbeli modul is veszi. Így ilyen esetekben a handshake az N. réteg bemenetén illetve kimenetén elhagyható. Emiatt a következő modulok tervezésénél azt az elvet követtem, hogy ez az attribútum generikus legyen, és példányosításkor választható meg a kívánt interfész működési mód a megfelelő generikus paraméterek állításával.
3.4.2 PDUQueue modul A PDUQueue modul feladata, hogy tárolni tudjon PDU-kat, hibatűrően, figyelve a túl és az alulcsordulásra. Három fő interfésszel rendelkezik: egy kimeneti, egy bementi és egy vezérlési. Az interfészek az általános interfész-ismertetőben leírt módon, az ott ismertetett vezérlőjelek használatával képesek működni és a hibakezelést annak megfelelően megvalósítva végzik. A PDUQueue modul vázlatát a 17. ábra szemlélteti.
Vezérlési adat és vezérlőjelek
Bemeneti adat és vezérlőjelek
Kimeneti adat és vezérlőjelek
PDU Queue
17. ábra PDUQueue modul interfész vázlat
A modul VHDL interfész leírása: COMPONENT PDUQueue IS generic ( DataWidth SYNC_IN SYNC_OUT SYNC_CTRL MINPDUSize MAXPDUSize MaxPDUToQ ); PORT (
: : : : : : :
INTEGER := BOOLEAN := BOOLEAN := BOOLEAN := INTEGER := INTEGER := INTEGER :=
40
DefDataWidth; false; true; false; DefMinPDUSize; DefMaxPDUSize; DefPDUToQ
CLK : IN STD_LOGIC; CE_In : IN STD_LOGIC; CE_Out : IN STD_LOGIC; RST : IN STD_LOGIC; -------------------------------------------------------------- IN interface signals DIN : IN STD_LOGIC_VECTOR(DataWidth-1 downto 0); DINV : IN STD_LOGIC; In_SOP : IN STD_LOGIC; In_EOP : IN STD_LOGIC; In_Ind : IN STD_LOGIC; In_ErrIn : IN STD_LOGIC; In_Ack : OUT STD_LOGIC; In_ErrOut : OUT STD_LOGIC; -------------------------------------------------------------- OUT interface signals DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 downto 0); DOUTV : OUT STD_LOGIC; Out_SOP : OUT STD_LOGIC; Out_EOP : OUT STD_LOGIC; Out_Ind : OUT STD_LOGIC; Out_ErrOut : OUT STD_LOGIC; Out_Ack : IN STD_LOGIC; Out_ErrIn : IN STD_LOGIC; -------------------------------------------------------------- Control interface signals CTRL_DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 downto 0); CTRL_DV : OUT STD_LOGIC; CTRL_SOP : OUT STD_LOGIC; CTRL_EOP : OUT STD_LOGIC; CTRL_ErrOut : OUT STD_LOGIC; CTRL_Ind : OUT STD_LOGIC; CTRL_Ack : IN STD_LOGIC; CTRL_FWD : IN STD_LOGIC; CTRL_Pause : IN STD_LOGIC; CTRL_DROP_ERR : IN STD_LOGIC; -------------------------------------------------------------- Extra user signals USER_IN : IN STD_LOGIC_VECTOR(USER_width-1 downto 0); USER_Out : OUT STD_LOGIC_VECTOR(USER_width-1 downto 0); USER_Out_CTRL : OUT STD_LOGIC_VECTOR(USER_width-1 downto 0) ); END COMPONENT PDUQueue;
A modul PDU feldolgozás során elvárt működése, hogy detektálja a bejövő PDU-kat, és elhatároltan tárolja azokat. További működési elvárás, hogy ha a várakozási sorban érvényes csomagok vannak, akkor azokat az alábbi ciklus szerint kezelje: a vezérlési interfészen keresztül a vezérlést értesítve átadja a PDU-t mindaddig a vezérlő számára, amíg az nem rendelkezik a sorsáról. A vezérlő a CTRL_Pause jellel tetszőlegesen felfüggesztheti a feldolgozást (például, ha több órajelt igénylő háttérművelet elvégzése szükséges), a CTRL_FWD jellel a PDU fel nem dolgozott részeit továbbíthatja a sor kimenetén, a CTRL_DROP_ERR jellel jelezheti, hogy a tárgyi PDU eldobásra kerüljön, vagy ha hiba történt a feldolgozás során. További elvárt működés, hogy a kimeneti és bementi működést megvalósító részegységek függetlenek és külön-külön engedélyezhetőek legyenek. A modulnak lehetősséget kell biztosítania továbbá „sávon kívüli” jelzések átvitelére a PDU-k mellett, amiket a User_In bementeken lehet bevezetni, és az aktuális ciklusnak megfelelően a User_Out illetve User_Out_CTRL kimenteken lehet fogadni.
41
Várhatóan a fenti modul megvalósításával önmagában lehetővé válik a protokoll adatelem fogadása két réteg között, illetve a vezérlési-továbbítási működés lehetővé teszi, hogy PDU fogadás esetén a protokollvezérlési információ és a szolgálati adatelem egymástól elválasztható legyen. A vezérlési interfésszel megvalósítható lesz a magas szintű csomag eldobás és továbbítási mechanizmus.
3.4.3 ProtoModule_TXPart modul A PDUQueue lehetővé teszi a „vételi” irányú PDU kezelést, megvalósítva a PCI leválasztást a PDU-ról. Adás esetén az is követelmény, hogy a protokollt megvalósító logika által generált PCI rész, és a felsőbb rétegektől érkező SDU rész összefűzhető legyen egy bájtfolyammá, azaz egy összefüggő PDU-vá. A tárgyi modul feladata az, hogy fogadja a sorosan érkező PCI és SDU rész bájtjait, majd ezeket egy PDU-vá összefűzve továbbítsa a kimenetén az alatta elhelyezkedő, szintén ugyanilyen modul SDU bemenete számára, ezzel biztosítva a rétegezhető szerkezetet. A PDU PCI és SDU része külön-külön adatelemként modellezhető, azok az előbb specifikált PDUQueue modul felhasználásával kezelhetőek/tárolhatóak. Ez tehát kezdetnek 2 db PDUQueue modult implikál. Megoldandó feladat a PCI sor és az SDU sor kimenetének összefűzése, amihez célszerűen ismét egy PDUQueue modul használható, mivel annak ki- és bemente különkülön engedélyezhető. A magas szintű kezelés érdekében a PDUQueue-k belső interfészei handshake-es módon kell, hogy működjenek. A kimeneti sor ezek után már autonóm módon tudja kezelni az összeállított PDU-kat. További feladata, hogy a modul fel legyen készülve olyan protokollok kezelésére, ami szolgálatot nyújt magasabb rétegek felé. Emellett lehetnek olyan PDU-i is, amik nem tartalmaznak magasabb rétegből érkező SDU-t, ezt praktikusan úgy kezelje, hogy a két adatbemenete közül csak a PCI-t vezérelve olyan összeállítási ciklus hajtódjon végre, amelyik nem vár SDU részt. Ellenkező esetben, ha az SDU előbb rendelkezésre áll, mint a PCI rész, akkor normális összeállítási ciklus hajtódjon végre, azaz meg kell várni, amíg a PCI rész eleje a bementi sorban rendelkezésre áll, és meg kell kezdeni a PDU összeállítás az PCI SDU részekből. A 18. ábra illusztrálja a tárgyi modul interfészeit.
42
PCI adat be és vezérlőjelek
ProtoModule_TXPart SDU adat be és vezérlőjelek
18. ábra ProtoModule_TXPart modul interfész vázlat
A modul VHDL interfész leírása: COMPONENT ProtoModule_TXPart IS GENERIC ( DataWidth : INTEGER := DefDataWidth; SYNC_IN_SDU : BOOLEAN := false; SYNC_IN_PCI : BOOLEAN := false; SYNC_OUT : BOOLEAN := false; MINSDUSize : INTEGER := DefMinSDUSize; MAXSDUSize : INTEGER := DefMaxSDUSize; MaxSDUToQ : INTEGER := DefPDUToQ; MINPCISize : INTEGER := DefPCISize; MAXPCISize : INTEGER := DefPCISize; MaxPCIToQ : INTEGER := DefPDUToQ ); PORT ( CLK : IN STD_LOGIC; CE : IN STD_LOGIC; RST : IN STD_LOGIC; ------------------------------------------------------------PCI_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 downto 0); PCI_DINV : IN STD_LOGIC; PCI_SOP : IN STD_LOGIC; PCI_EOP : IN STD_LOGIC; PCI_Ind : IN STD_LOGIC; PCI_ErrIn : IN STD_LOGIC; PCI_USER_In : IN STD_LOGIC_VECTOR(USER_width-1 downto 0); PCI_Ack : OUT STD_LOGIC; PCI_ErrOut : OUT STD_LOGIC; ------------------------------------------------------------SDU_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 downto 0); SDU_DINV : IN STD_LOGIC; SDU_SOP : IN STD_LOGIC; SDU_EOP : IN STD_LOGIC; SDU_Ind : IN STD_LOGIC; SDU_ErrIn : IN STD_LOGIC; SDU_USER_In : IN STD_LOGIC_VECTOR(USER_width-1 downto 0); SDU_Ack : OUT STD_LOGIC; SDU_ErrOut : OUT STD_LOGIC; ------------------------------------------------------------DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 downto 0); DOUTV : OUT STD_LOGIC; Out_SOP : OUT STD_LOGIC; Out_EOP : OUT STD_LOGIC; Out_Ind : OUT STD_LOGIC; Out_ErrOut : OUT STD_LOGIC; USER_Out : OUT STD_LOGIC_VECTOR(USER_width-1 downto 0); Out_Ack : IN STD_LOGIC; Out_ErrIn : IN STD_LOGIC ); END COMPONENT ProtoModule_TXPart;
43
PDU adat ki és vezérlőjelek
3.4.4 ProtoLayer ismertetés A ProtoLayer modul tulajdonképpen a fentebb specifikált két modult foglalja egységbe, a könnyebb felhasználhatóság kedvéért. Az interfészei tehát a fenti modulok uniójából képezhető. A ProtoLayer-nek azonban meg kell valósítania egy fontos feladatot: kiegészítő sorokat kell létesítenie, amelyek a több rétegen átívelő paramétereket és attribútumokat továbbítják a már összeállított PDU-k illetve a már kinyert SDU-k mellett mind küldési, mind fogadási irányban. Ennek fontosságát illusztrálandó példa, hogy az SNMP modulnak tudnia kell a Menedzser IP címét és cél portját is, viszont közvetlenül csak az UDP interfésszel van kapcsolatban. Az UDP rétegeknek a cél és forrás IP címre az UDP protokoll adatelem összeállításához nincs szüksége, viszont mivel ő az IP réteg interfészével is kapcsolatban van, és az ottani szolgálati primitívben viszont át kell adni a címeket, ezért szükségszerű, hogy ilyen mechanizmust opcionálisan támogasson a ProtoLayer. Az előbbieket leszámítva, mivel a
ProtoLayer
egy
burkoló
modulként
funkciónál
a
PDUQueue
és
a
ProtoModule_TX_Part modulok körül, így ebben a formában azoknak a vonatkozó működési specifikációnak kell majd eleget tennie. A ProtoLayer blokkvázlata a 20. ábrán látható.
SDU adat be és vezérlőjelek PDU ki adat és vezérlőjelek
ProtoModule_TXPart PCI adat be és vezérlőjelek
ProtoLayer
PDU be adat és vezérlőjelek
PDU Queue
SDU adat ki és vezérlőjelek
PCI adat ki és vezérlőjelek
19. ábra A ProtoLayer modul blokkvázlata is interfészei
44
A modul VHDL interfész leírása: COMPONENT ProtoLayer IS generic( DataWidth : INTEGER := DefDataWidth; RX_SYNC_IN : BOOLEAN := false; RX_SYNC_OUT : BOOLEAN := false; RX_CTRL_SYNC : BOOLEAN := false; TX_CTRL_SYNC : BOOLEAN := false; TX_SYNC_IN : BOOLEAN := false; TX_SYNC_OUT : BOOLEAN := false; TX_AUX_Q : BOOLEAN := false; TX_AUX_widthDW : INTEGER := DefAuxWidth; RX_AUX_Q : BOOLEAN := false; RX_AUX_widthDW : INTEGER := DefAuxWidth; MINSDUSize : INTEGER := DefMinPDUSize; MAXSDUSize : INTEGER := DefMaxPDUSize; MaxSDUToQ : INTEGER := DefPDUToQ; MINPCISize : INTEGER := DefMinPDUSize; MAXPCISize : INTEGER := DefMinPDUSize; MaxPCIToQ : INTEGER := DefPDUToQ ); PORT( CLK : IN STD_LOGIC; CE : IN STD_LOGIC; RST : IN STD_LOGIC; -----------------------------------------------------------PCI_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 downto 0); PCI_DINV : IN STD_LOGIC; PCI_IN_SOP : IN STD_LOGIC; PCI_IN_EOP : IN STD_LOGIC; PCI_IN_Ind : IN STD_LOGIC; PCI_IN_ErrIn : IN STD_LOGIC; PCI_IN_USER_In : IN STD_LOGIC_VECTOR(USER_width-1 downto 0); PCI_IN_Ack : OUT STD_LOGIC; PCI_IN_ErrOut : OUT STD_LOGIC; ------------------------------------------------------------SDU_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 downto 0); SDU_DINV : IN STD_LOGIC; SDU_IN_SOP : IN STD_LOGIC; SDU_IN_EOP : IN STD_LOGIC; SDU_IN_Ind : IN STD_LOGIC; SDU_IN_ErrIn : IN STD_LOGIC; SDU_IN_USER_In : IN STD_LOGIC_VECTOR(USER_width-1 downto 0); SDU_IN_Ack : OUT STD_LOGIC; SDU_IN_ErrOut : OUT STD_LOGIC; ------------------------------------------------------------PDU_DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 downto 0); PDU_DOUTV : OUT STD_LOGIC; PDU_Out_SOP : OUT STD_LOGIC; PDU_Out_EOP : OUT STD_LOGIC; PDU_Out_Ind : OUT STD_LOGIC; PDU_Out_ErrOut : OUT STD_LOGIC; PDU_Out_USER_Out : OUT STD_LOGIC_VECTOR(USER_width-1 downto 0); PDU_Out_Ack : IN STD_LOGIC; PDU_Out_ErrIn : IN STD_LOGIC; ------------------------------------------------------------PDU_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 downto 0); PDU_DINV : IN STD_LOGIC; PDU_IN_SOP : IN STD_LOGIC; PDU_IN_EOP : IN STD_LOGIC; PDU_IN_Ind : IN STD_LOGIC; PDU_IN_USER_In : IN STD_LOGIC_VECTOR(USER_width-1 downto 0); PDU_IN_ErrIn : IN STD_LOGIC; PDU_IN_ErrOut : OUT STD_LOGIC; PDU_IN_Ack : OUT STD_LOGIC; ------------------------------------------------------------CTRL_DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 downto 0); CTRL_DV : OUT STD_LOGIC; CTRL_SOP : OUT STD_LOGIC; CTRL_EOP : OUT STD_LOGIC; CTRL_ErrOut : OUT STD_LOGIC; CTRL_Ind : OUT STD_LOGIC; CTLR_USER_Out : OUT STD_LOGIC_VECTOR(USER_width-1 downto 0); CTRL_Ack : IN STD_LOGIC; CTRL_FWD : IN STD_LOGIC; CTRL_Pause : IN STD_LOGIC; CTRL_DROP_ERR : IN STD_LOGIC; ------------------------------------------------------------SDU_DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 downto 0); SDU_DOUTV : OUT STD_LOGIC; SDU_Out_SOP : OUT STD_LOGIC; SDU_OUT_EOP : OUT STD_LOGIC; SDU_OUT_Ind : OUT STD_LOGIC;
45
SDU_OUT_USER_Out : OUT STD_LOGIC_VECTOR(USER_width-1 downto 0); SDU_OUT_ErrOut : OUT STD_LOGIC; SDU_OUT_ErrIn : IN STD_LOGIC; SDU_OUT_Ack : IN STD_LOGIC; -----------------------------------------------------------------============================================================----------------------------------------------------------------TX_AUX_Out : OUT STD_LOGIC_VECTOR(TX_AUX_widthDW*DataWidth-1 TX_AUX_outV : OUT STD_LOGIC; TX_AUX_in : IN STD_LOGIC_VECTOR(TX_AUX_widthDW*DataWidth-1 RX_AUX_Out : OUT STD_LOGIC_VECTOR(RX_AUX_widthDW*DataWidth-1 RX_AUX_OutV : OUT STD_LOGIC; RX_AUX_in : IN STD_LOGIC_VECTOR(RX_AUX_widthDW*DataWidth-1 ); END
downto 0); downto 0); downto 0); downto 0)
COMPONENT ProtoLayer;
3.4.5 ProtoLayer-hez csatlakozó protokollvezérlő interfész és működési követelményei Az előbbiekben specifikált modulok lehetőséget biztosítanak a protokollrétegek közötti szolgálati adatelemek kezelésére, és a vezérlés átadására a protokollfüggő modulnak, ami megvalósítja a protokoll által elvégzendő logikát és eljárásokat, és biztosítja a protokollfüggő bemeneteket. A protokollt megvalósító modul feladatai közé tartozik, hogy az ICI alapján generálja a PCI információt, ami után az SDU-t fűzve előáll az adott réteg PDU-ja. Erre a ProtoLayer PCI bemenete szolgál. További feladata, hogy egy PDU vétele esetén, a PCI alapján eldöntse, hogy mit kell kezdeni az adott PDU-val. Erre a ProtoLayer PCI adat kimenet és vezérlőjelek interfésze szolgál, melyek ismertetésére már sor került a vonatkozó fejezetben. A ProtoLayer blokkvázlata és interfészei a 20. ábrán tekinthető meg. A megvalósított protokoll feladata, hogy minden protokollfüggő adatot, amelyek átívelnek a rétegek között, illetve a bemeneti feldolgozás során állnak elő, a ProtoLayer kiegészítő bemenetire vezesse, és a kimeneteket a megfelelő kiegészítő kimenetekkel összerendelje. További feladata, hogy a ProtoLayer modult megfelelően példányosítsa. A protokoll modullal szemben követelmény, hogy ha úgynevezett első hibás (azaz az első órajel estén a hibajel magas) SDU érkezik, akkor ne írjon PCI részt a ProtoLayerbe (a konzisztencia megőrzése miatt), viszont a nem első hibás SDU érkezése esetén mindenképp injektálja a PCI részt. A gyorsabb működése érdekében, ilyenkor már nem szükséges már megvárni az SDU végét.
46
SDU adat be és vezérlőjelek PDU ki adat és vezérlőjelek
ProtoModule_TXPart
PDU be adat és vezérlőjelek
Protokollfüggő bemenetek az alsóbb rétegek felől
Protokollfüggő kimenetek az alsóbb rétegek felé
Protokoll
PDU Queue
PCI adat ki és vez.
PCI adat be és vezérlőjelek
ProtoLayer SDU adat ki és vezérlőjelek
Megvalósítandó protokoll
Protokollfüggő bemenetek a felsőbb rétegek felől Protokollfüggő kimenetek a felsőbb rétegek felé
20. ábra A teljes rendszervázlat
A protokoll modul alkalmazhat elő- illetve utófeldolgozást, ha az egész adatelemen értelmezett műveletet kell végeznie (például ellenőrzőösszeg számítást). Ekkor jelzéseket a megfelelő User_In bemeneteken keresztül lehet továbbítani a kimeneten figyelő moduloknak. Általánosan is érvényes az, hogy a sok adatot érintő műveleteket érdemes az adatmozgatással egyben végezni, mivel van rá lehetőség. Ilyen például az UDP ellenőrzőösszeg számítás adás esetén, ahol a teljes UDP fejlécet csak a szállított szolgálati adatelem teljes feldolgozása esetén lehet előállítani. A diplomaterv kiírásnak megfelelően, a modell verifikálását az SNMP alkalmazásrétegbeli protokoll részleges implementációjával kell elvégeznem, így a fentebb megtervezett modulok mellet protokollvezérlőként még implementálni kell az UDP-t, ami az SNMP szállítási rétegét biztosítja, egy hálózati és egy adatkapcsolati rétegbeli protokollt. Mivel napjainkban az IPv4 és az 802.3 LAN a legelterjedtebb, ezért a választás ezekre esett, továbbá, mivel e protokollok működéséhez elengedhetetlen az ARP, így ennek implementálása az elkészített keretrendszer felhasználásával is a további feladatok közé tartozik. Ezen protokollok működési specifikációit a vonatkozó szabványok és ajánlások tárgyalják, amelyek az irodalomkutatás részben részletesen ismertetésre kerülnek. 47
A protokollvezérlő modulok interfészeinek rendelkezniük kell a fentebb specifikált protokollvezérlő interfész jelekkel, amelyek a felhasználástól és a szabványtól függően tartalmazhatnak további jelzés és adatvezetékeket. Ezek a többlet vezetékek, habár a tervezési fázishoz kapcsolódnak, szorosan függenek az implementációtól, így ezek ismertetése az implementációs részben fog megtörténni. Összefoglalva tehát a végcél az, hogy a keretrendszer működésének verifikálásához a keretrendszer felhasználásával implementálni kell a következő protokollokat:
Ethernet MAC
ARP
IPv4
UDP
SNMP
3.4.5.1 Az Ethernet MAC modul A munkaterv kiírásnak megfelelően az első félévben célként a megtervezett modulok implementálásának a 40%-a volt kitűzve célul, ami magán a keretrendszer elkészítésén kívül, a tárgyi félévben az Ethernet MAC modul-t foglalja magában. A cél az, hogy a tervezett modul legyen képes több MAC címre is hallgatni, melyek számosságát fordítási időben lehessen konfigurálni generikus paraméterrel, és működés közben azok konfigurálhatóak legyenek. Mivel a célkörnyezetben (és napjainkban egyre gyakrabban) csupán a full-duplex működési mód van használatban, így a CSMA/CD működési mód nem kerül megvalósításra. A tervezett modul VHDL interfész-specifikációja az alábbiakban olvasható: COMPONENT EthernetLayer IS generic( DataWidth : RX_SYNC_IN : RX_SYNC_OUT : TX_SYNC_IN : TX_SYNC_OUT : MINSDUSize : MAXSDUSize : MaxSDUToQ : MINPCISize : MAXPCISize : MaxPCIToQ : NumOfMacAddresses : ); PORT( CLK : IN CE : IN RST : IN
INTEGER := BOOLEAN := BOOLEAN := BOOLEAN := BOOLEAN := INTEGER := INTEGER := INTEGER := INTEGER := INTEGER := INTEGER := INTEGER :=
DefDataWidth; false; false; false; false; DefMinSDUSize; DefMaxSDUSize; DefPDUToQ; DefPCISize; DefPCISize; DefPDUToQ; DefNumOfMacAddr
STD_LOGIC; STD_LOGIC; STD_LOGIC;
48
-----------------------------------------------------------WR_EN : IN STD_LOGIC; RD_EN : IN STD_LOGIC; ADDR : IN STD_LOGIC_VECTOR(INTEGER(CEIL(LOG2(REAL(NumOfMacAddresses))))-1 DOWNTO 0); ADDR_DATA_IN : IN STD_LOGIC_VECTOR( MacAddrSize-1 DOWNTO 0); ADDR_DATA_OUT : OUT STD_LOGIC_VECTOR( MacAddrSize-1 DOWNTO 0); ADDR_DV : OUT STD_LOGIC; -----------------------------------------------------------DstMacAddr_In : IN STD_LOGIC_VECTOR( MacAddrSize-1 DOWNTO 0); SrcMacAddr_In : IN STD_LOGIC_VECTOR( MacAddrSize-1 DOWNTO 0); EthType_In : IN STD_LOGIC_VECTOR( EtherTypeSize-1 DOWNTO 0); ------------------------------------------------------------DstMacAddr_Out : OUT STD_LOGIC_VECTOR( MacAddrSize-1 DOWNTO 0); SrcMacAddr_Out : OUT STD_LOGIC_VECTOR( MacAddrSize-1 DOWNTO 0); EthType_Out : OUT STD_LOGIC_VECTOR( EtherTypeSize-1 DOWNTO 0); ------------------------------------------------------------SDU_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 DOWNTO 0); SDU_DINV : IN STD_LOGIC; SDU_IN_SOP : IN STD_LOGIC; SDU_IN_EOP : IN STD_LOGIC; SDU_IN_Ind : IN STD_LOGIC; SDU_IN_ErrIn : IN STD_LOGIC; SDU_IN_USER_In : IN STD_LOGIC_VECTOR(USER_width-1 DOWNTO 0); SDU_IN_Ack : OUT STD_LOGIC; SDU_IN_ErrOut : OUT STD_LOGIC; ------------------------------------------------------------PDU_DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 DOWNTO 0); PDU_DOUTV : OUT STD_LOGIC; PDU_Out_SOP : OUT STD_LOGIC; PDU_Out_EOP : OUT STD_LOGIC; PDU_Out_Ind : OUT STD_LOGIC; PDU_Out_ErrOut : OUT STD_LOGIC; PDU_Out_USER_Out : OUT STD_LOGIC_VECTOR(USER_width-1 DOWNTO 0); PDU_Out_Ack : IN STD_LOGIC; PDU_Out_ErrIn : IN STD_LOGIC; ------------------------------------------------------------PDU_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 DOWNTO 0); PDU_DINV : IN STD_LOGIC; PDU_IN_SOP : IN STD_LOGIC; PDU_IN_EOP : IN STD_LOGIC; PDU_IN_Ind : IN STD_LOGIC; PDU_IN_USER_In : IN STD_LOGIC_VECTOR(USER_width-1 DOWNTO 0); PDU_IN_ErrIn : IN STD_LOGIC; PDU_IN_ErrOut : OUT STD_LOGIC; PDU_IN_Ack : OUT STD_LOGIC; ------------------------------------------------------------SDU_DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 DOWNTO 0); SDU_DOUTV : OUT STD_LOGIC; SDU_Out_SOP : OUT STD_LOGIC; SDU_OUT_EOP : OUT STD_LOGIC; SDU_OUT_Ind : OUT STD_LOGIC; SDU_OUT_USER_Out : OUT STD_LOGIC_VECTOR(USER_width-1 DOWNTO 0); SDU_OUT_ErrOut : OUT STD_LOGIC; SDU_OUT_ErrIn : IN STD_LOGIC; SDU_OUT_Ack : IN STD_LOGIC ); END COMPONENT EthernetLayer;
Az interfészeiről annyit lehet elmondani, hogy ahogy az előbbiekben leírásra került, a PDU és SDU kezdetű kimenetek, az általános részt valósítják meg. Ahogy látszik, a modul a cél, a forrás, és az EtherType/Length mező értékét párhuzamos adat ki illetve bemeneteken szolgáltatja/fogadja. A kimeneti és bemeneti oldalon itt nincs szükség az interfészvezérlő információ sorba állításra, mivel ez a modul már közvetlenül a fizikai rétegvezérlő modullal fog kommunikálni adás esetén. Vétel esetén, a kimeneti oldalon mindig az aktuális szolgálati adatelemhez tartozó ICI értékek fognak megjelenni, amelyek az SDU_OUT_SOP jel értéke alatt lesznek érvényesek. Használat előtt az állomás MAC címeit konfigurálni kell. Alapértelmezésként az üzenetszórásos címre hallgat a modul, amely a belső memóriájának legfelső címén 49
helyezkedik el, azaz a NumOfMacAddresses-1 -es címen. Emiatt az erre a címre történő írást célszerű elkerülni. Ennek a generikus paraméternek a minimális értéke 2, a fenti okból kifolyólag. A konfigurációra a WR_EN, RD_EN, ADDR, ADDR_DATA_IN, ADDR_DATA_OUT és ADDR_DV jelek használhatóak, értelemszerűen. 3.4.5.2 ARP modul Az ARP modul implementációjánál 0 elemű tábla adminisztrálását terveztem, mivel a hardver esetében a táblázatkezelés nem annyira kézenfekvő, illetve konvencionális memória használata esetén keresni kell a memóriában. Ha nincs indexelés, vagy esetleg egy rendezett tárolási mód alkalmazva, akkor lineáris keresést kellene alkalmazni, ami lelassítja a működést, mivel ez a tábla méretének megfelelő órajel ciklust venne igénybe a legjobb esetben is. Indexelés és rendezés estén pedig a memória menedzselése rendkívül bonyolítaná a leírást és szintetizált hardvert. Megoldást
jelenthetne
kisméretű
CAM
(Content
Addressable
–
Memory
tartalomcímezhető memória) alkalmazása, ami néhány rekord tárolására lenne alkalmas, és 1-2 órajel alatt eredményt szolgáltatna. Az ARP modult teljesen az ajánlás szerint tervezem megvalósítani, még az opcionális részeket is, azzal a megszorítással, hogy ar$hrd és ar$pro értékeket, a lehetséges értékek közül csak a 0x0001 és 0x0800-t esetén kezelje, azaz Ethernet adatkapcsolati réteget és IPv4 hálózati protokollt támogassa. Mivel az IP modul erre a modulra
fog
támaszkodni
minden
egyes
datagram
küldés
során,
így
az
implementációnak rendkívül robosztusnak kell lennie, és támogatnia kell a full-duplex működést. A jellemzőket tekintve kell, hogy legyen egy ARP felhasználói interfésze, ahol a felhasználó modul be tudja adni a cél IP címet, és rendelkeznie kell egy kérést jelző bemenettel. A választ egy cél MAC cím kimenet és egy érvényes/érvénytelen válasz jelzéskimenet fogja szolgáltatni. Terveim szerint a kérések újrapróbálkozásának száma és a leidőzítési időkorlát generikus paraméterként állítható kell, hogy legyen, úgy ahogy a figyelt IP címek száma is. Minden egyes konfigurált IP címhez tartoznia kell egy MAC címnek is, amivel a modul fogadott kérés esetén kitölti a HWAOS mezőt. A konfigurációt az EtherLayer modulnál tervezett módon lehet majd betölteni a modulba. A tervezett ARP modul VHDL interfészleírása: COMPONENT ARPModule IS GENERIC(
50
DataWidth TX_SYNC_OUT RX_SYNC_IN NumOfAddresses CLK_freq TimeOUT RetryCnt
: : : : : : :
INTEGER := BOOLEAN := BOOLEAN := INTEGER := REAL REAL INTEGER :=
DefDataWidth; true; true; DefNumOfIPAddr; --Maximum 16, := 125.0; --Clock frequency IN MHz := 500.0; --timeout IN ms 3 --retry count
); PORT( CLK : IN STD_LOGIC; RST : IN STD_LOGIC; CE : IN STD_LOGIC; CFG_CE : IN STD_LOGIC; ----------------------------------DST_MacAddr_Out : OUT STD_LOGIC_VECTOR(MacAddrSize-1 DOWNTO 0); SRC_MacAddr_Out : OUT STD_LOGIC_VECTOR(MacAddrSize-1 DOWNTO 0); EType_Out : OUT STD_LOGIC_VECTOR(EtherTypeSize-1 DOWNTO 0); PDU_DOUT : OUT STD_LOGIC_VECTOR(DataWidth-1 DOWNTO 0); PDU_DOUTV : OUT STD_LOGIC; PDU_Out_SOP : OUT STD_LOGIC; PDU_Out_EOP : OUT STD_LOGIC; PDU_Out_Ind : OUT STD_LOGIC; PDU_Out_ErrOut : OUT STD_LOGIC; PDU_Out_Ack : IN STD_LOGIC; PDU_Out_ErrIn : IN STD_LOGIC; ----------------------------------DST_MacAddr_In : IN STD_LOGIC_VECTOR(MacAddrSize-1 DOWNTO 0); SRC_MacAddr_In : IN STD_LOGIC_VECTOR(MacAddrSize-1 DOWNTO 0); EType_In : IN STD_LOGIC_VECTOR(EtherTypeSize-1 DOWNTO 0); PDU_DIN : IN STD_LOGIC_VECTOR(DataWidth-1 DOWNTO 0); PDU_DINV : IN STD_LOGIC; PDU_In_SOP : IN STD_LOGIC; PDU_In_EOP : IN STD_LOGIC; PDU_In_Ind : IN STD_LOGIC; PDU_In_ErrIn : IN STD_LOGIC; PDU_In_Ack : OUT STD_LOGIC; PDU_In_ErrOut : OUT STD_LOGIC; ----------------------------------ARP_ReqUest : IN STD_LOGIC; ARP_DST_IP_addr : IN STD_LOGIC_VECTOR(IPAddrSize-1 DOWNTO 0); ARP_DST_MAC_addr : OUT STD_LOGIC_VECTOR(MACAddrSize-1 DOWNTO 0); ARP_RESPONSEV : OUT STD_LOGIC; ARP_RESPONSE_ERR : OUT STD_LOGIC; ----------------------------------------------------------------------Management IF ----------------------------------IPADDR_WR_EN : IN STD_LOGIC; MACADDR_WR_EN : IN STD_LOGIC; IPADDR_RD_EN : IN STD_LOGIC; MACADDR_RD_EN : IN STD_LOGIC; ADDR : IN STD_LOGIC_VECTOR(INTEGER(CEIL(LOG2(REAL(NumOfAddresses))))-1 DOWNTO 0); ADDR_DATA_IN : IN STD_LOGIC_VECTOR( MACAddrSize-1 DOWNTO 0); --Shared with IP ADDR IPADDR_DATA_OUT : OUT STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); --Shared with IP ADDR MACADDR_DATA_OUT : OUT STD_LOGIC_VECTOR( MACAddrSize-1 DOWNTO 0); --Shared with IP ADDR IPADDR_DV : OUT STD_LOGIC; MACADDR_DV : OUT STD_LOGIC; StatusVec : OUT STD_LOGIC_VECTOR(31 DOWNTO 0) ); END COMPONENT ARPModule; END ARPModulePkg;
3.4.5.3 IPv4 modul Az IP modul tervezett implementációjában a tördelés és összeállítást (fragmentation and reassembly) nem tervezem megvalósítani, mivel minden különböző töredékekhez tartozó vett csomaghoz 64 kB-s puffer allokálása lenne szükséges, amire nem telne az FPGA szűkös memória erőforrásaiból, továbbá az összeállítás feleslegesen komplex memóriaműveleteket eredményezne. A címzési tárházból viszont a megfelelő működéshez szükséges implementálni a címfeldolgozást és útvonalválasztást. A 51
protokoll-leírásban szereplő opciók szintén „felesleges funkciók”, amiket a mindennapi gyakorlatban nem igen alkalmaznak. Vétel esetén azonban az IHL mező alapján figyelni kell a fejléc méretére, hogy gond nélkül le lehessen választani az IP fejlécet a bájtfolyamról. A modulnak kezelnie kell több saját IP címet, interfészt kell implementálni az ARP modul felé, hogy fel tudja használni a címfordítási szolgálatait. További tervezett funkcionalitás, hogy az internet fejléc hosszat jelölő mezője alapján az esetleges Ethernet tölteléket le kell vágnia a modulnak. A modulnak továbbá interfésszel kell rendelkeznie a MAC réteg felé, ami a keretrendszerbeli jelek esetén automatikusan teljesül, tehát a cél és forrás fizikai címet és az EhterType-ot kezelő ki- és bemenetekkel kell, hogy rendelkezzen. Az előzetes tervek alapján itt kihasználásra kerül majd az adatmozgatás közbeni műveletvégzés és a PDUQueue sávon kívüli jelzésre alkalmas tárháza, mivel fogadás esetén a tervezett működés szerint egy előfeldolgozó modul ellenőrzi a verziószámot, a fejléc ellenőrzőösszeget, és az IHL mező alapján jelzi a kimeneten található utófeldolgozó modulnak, hogy meddig tart fejléc, illetve, hogy hibátlan volt-e. Ennek a párhuzamosításnak köszönhetően a kimeneti logika mérete csökken, és már csak a további szerkezeti validálás, valamint a címzési feladatok várnak rá. További felhasználandó elem az eszköztárból a ProtoLayer kiegészítő várakozási sora küldési irányban, mivel az ARP lekérdezés a tervek szerint az küldési rész bemeneti oldalán fog végbe menni, így szükséges, hogy az IP PDU mellett haladjon az információ. Az adási irány bemeneti interfészét a tervezet szerint csak handshakes üzemmódban lehet majd használni, mivel az adási bemeneten több műveletet kell elvégezni, így a szinkronizálás kulcsfontosságú a konzisztencia megőrzéséhez. A tervezett VHDL interfész: COMPONENT IPLayer IS generic( DataWidth RX_SYNC_IN RX_SYNC_OUT -- TX_SYNC_IN TX_SYNC_OUT NumOfIPAddresses PacketToQueue TTL MTU ); PORT( CLK RST CE CFG_CE
: : : : : : : : :
: : : :
INTEGER := BOOLEAN := BOOLEAN := BOOLEAN := BOOLEAN := INTEGER := INTEGER := INTEGER := INTEGER :=
IN IN IN IN
DefDataWidth; false; false; false; Just IN Sync mode false; DefNumOfIPAddr; DefPDUToQ; DefTTL; IPDefMTU
STD_LOGIC; STD_LOGIC; STD_LOGIC; STD_LOGIC;
52
------------------------------------------------------------Management IF -----------------------------------------------------------WR_EN : IN STD_LOGIC; RD_EN : IN STD_LOGIC; CFG_ADDR_WR : IN STD_LOGIC; CFG_ADDR : IN STD_LOGIC_VECTOR( INTEGER(CEIL(LOG2(REAL(NumOfCFGRegs))))-1 downto 0); ADDR : IN STD_LOGIC_VECTOR( INTEGER(CEIL(LOG2(REAL(2*NumOfIPAddresses))))-1 downto 0); DATA_IN : IN STD_LOGIC_VECTOR( IPAddrSize-1 downto 0); DATA_OUT : OUT STD_LOGIC_VECTOR( IPAddrSize-1 downto 0); DOUTV : OUT STD_LOGIC; ------------------------------------------------------------ARP IF -----------------------------------------------------------ARP_Request : OUT STD_LOGIC; ARP_DSTIPAddr : OUT STD_LOGIC_VECTOR( IPAddrSize-1 downto 0); ARP_ResponseV : IN STD_LOGIC; ARP_ResponseErr : IN STD_LOGIC; ARP_DstMacAddr : IN STD_LOGIC_VECTOR( MacAddrSize-1 downto 0); ------------------------------------------------------------IP IF -----------------------------------------------------------DstIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 downto 0); SrcIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 downto 0); Prot_In : IN STD_LOGIC_VECTOR( IP_ProtSize-1 downto 0); Length_In : IN STD_LOGIC_VECTOR( 15 downto 0); ------------------------------------------------------------DstIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 downto 0); SrcIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 downto 0); Prot_Out : OUT STD_LOGIC_VECTOR( IP_ProtSize-1 downto 0); Length_Out : OUT STD_LOGIC_VECTOR( 15 downto 0); ------------------------------------------------------------EthernetLayer IF -----------------------------------------------------------DstMacAddr_In : IN STD_LOGIC_VECTOR( MacAddrSize-1 downto 0); SrcMacAddr_In : IN STD_LOGIC_VECTOR( MacAddrSize-1 downto 0); EthType_In : IN STD_LOGIC_VECTOR( EtherTypeSize-1 downto 0); DstMacAddr_Out : OUT STD_LOGIC_VECTOR( MacAddrSize-1 downto 0); SrcMacAddr_Out : OUT STD_LOGIC_VECTOR( MacAddrSize-1 downto 0); EthType_Out : OUT STD_LOGIC_VECTOR( EtherTypeSize-1 downto 0); ------------------------------------------------------------SDU_DIN : IN STD_LOGIC_VECTOR( DataWidth-1 downto 0); SDU_DINV : IN STD_LOGIC; SDU_IN_SOP : IN STD_LOGIC; SDU_IN_EOP : IN STD_LOGIC; SDU_IN_Ind : IN STD_LOGIC; SDU_IN_ErrIn : IN STD_LOGIC; SDU_IN_USER_In : IN STD_LOGIC_VECTOR( USER_width-1 downto 0); SDU_IN_Ack : OUT STD_LOGIC; SDU_IN_ErrOut : OUT STD_LOGIC; ------------------------------------------------------------PDU_DOUT : OUT STD_LOGIC_VECTOR( DataWidth-1 downto 0); PDU_DOUTV : OUT STD_LOGIC; PDU_Out_SOP : OUT STD_LOGIC; PDU_Out_EOP : OUT STD_LOGIC; PDU_Out_Ind : OUT STD_LOGIC; PDU_Out_ErrOut : OUT STD_LOGIC; PDU_Out_USER_Out : OUT STD_LOGIC_VECTOR( USER_width-1 downto 0); PDU_Out_Ack : IN STD_LOGIC; PDU_Out_ErrIn : IN STD_LOGIC; ------------------------------------------------------------PDU_DIN : IN STD_LOGIC_VECTOR( DataWidth-1 downto 0); PDU_DINV : IN STD_LOGIC; PDU_IN_SOP : IN STD_LOGIC; PDU_IN_EOP : IN STD_LOGIC; PDU_IN_Ind : IN STD_LOGIC; PDU_IN_USER_In : IN STD_LOGIC_VECTOR( USER_width-1 downto 0); PDU_IN_ErrIn : IN STD_LOGIC; PDU_IN_ErrOut : OUT STD_LOGIC; PDU_IN_Ack : OUT STD_LOGIC; ------------------------------------------------------------SDU_DOUT : OUT STD_LOGIC_VECTOR( DataWidth-1 downto 0); SDU_DOUTV : OUT STD_LOGIC; SDU_Out_SOP : OUT STD_LOGIC; SDU_OUT_EOP : OUT STD_LOGIC; SDU_OUT_Ind : OUT STD_LOGIC; SDU_OUT_USER_Out : OUT STD_LOGIC_VECTOR( USER_width-1 downto 0); SDU_OUT_ErrOut : OUT STD_LOGIC; SDU_OUT_ErrIn : IN STD_LOGIC; SDU_OUT_Ack : IN STD_LOGIC; -------------------------------------------------------------Status : OUT STD_LOGIC_VECTOR(7 downto 0) ); END COMPONENT IPLayer;
53
3.4.5.4 UDP modul Az UDP tervezett implementációját egy az egyben az ajánlásnak megfelelően tervezem, azzal a kivétellel, hogy a modul nem fog tudni 64 kB-os datagramokat kezelni, csupán az MTU méretűt. Megvalósítja a portok bejegyzésének lehetőségét, és az ellenőrzőösszeg számítást, szintén az adatmozgatás közbeni feldolgozást kihasználva. A felhasználók felé az ajánlás által leírt interfészt biztosítja, és használja a tervezett IP-t megvalósító modult. Szintén használja majd a ProtoLayer kiegészítő várakozási sorait, ám ezúttal mindkét irányban, mivel a paraméterek mindkét irányban átívelőek. A portok számát generikus paraméterként lehet megadni. Az adási irány bemeneti interfészét a tervezet szerint csak handshake-es üzemmódban lehet majd használni, mivel az adási bemeneten több műveletet kell elvégezni, így a szinkronizálás kulcsfontosságú a konzisztencia megőrzéséhez. A tervezett VHDL interfész: COMPONENT UDPLayer IS GENERIC( DataWidth : INTEGER := DefDataWidth; RX_SYNC_IN : BOOLEAN := false; RX_SYNC_OUT : BOOLEAN := false; -- TX_SYNC_IN : BOOLEAN := false; Just IN Sync mode TX_SYNC_OUT : BOOLEAN := false; NumOfUDPPorts : INTEGER := DefNumOfUDPPorts; PDUToQueue : INTEGER := DefPDUToQ ); PORT( CLK : IN STD_LOGIC; RST : IN STD_LOGIC; CE : IN STD_LOGIC; CFG_CE : IN STD_LOGIC; ------------------------------------------------------------Management IF -----------------------------------------------------------WR_EN : IN STD_LOGIC; RD_EN : IN STD_LOGIC; ADDR : IN STD_LOGIC_VECTOR( INTEGER(CEIL(LOG2(REAL(NumOfUDPPorts))))-1 DOWNTO 0); DATA_IN : IN STD_LOGIC_VECTOR( UDPPortSize+1-1 DOWNTO 0); --Format : V|PORT = 1+ 16 bit DATA_OUT : OUT STD_LOGIC_VECTOR( UDPPortSize+1-1 DOWNTO 0); DOUTV : OUT STD_LOGIC; ------------------------------------------------------------IP IF -----------------------------------------------------------IP_DstIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); IP_SrcIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); IP_Proto_In : IN STD_LOGIC_VECTOR( IP_ProtSize-1 DOWNTO 0); IP_Length_In : IN STD_LOGIC_VECTOR( 15 DOWNTO 0); ------------------------------------------------------------IP_DstIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); IP_SrcIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); IP_Proto_Out : OUT STD_LOGIC_VECTOR( IP_ProtSize-1 DOWNTO 0); IP_Length_Out : OUT STD_LOGIC_VECTOR( 15 DOWNTO 0); ------------------------------------------------------------UDP IF -----------------------------------------------------------DstIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); SrcIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); DstPort_In : IN STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); SrcPort_In : IN STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); Length_In : IN STD_LOGIC_VECTOR( UDPLengthSize-1 DOWNTO 0); ------------------------------------------------------------DstIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); SrcIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); DstPort_Out : OUT STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); SrcPort_Out : OUT STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); Length_Out : OUT STD_LOGIC_VECTOR( UDPLengthSize-1 DOWNTO 0);
54
------------------------------------------------------------Framework IF -----------------------------------------------------------SDU_DIN : IN STD_LOGIC_VECTOR( DataWidth-1 DOWNTO 0); SDU_DINV : IN STD_LOGIC; SDU_IN_SOP : IN STD_LOGIC; SDU_IN_EOP : IN STD_LOGIC; SDU_IN_Ind : IN STD_LOGIC; SDU_IN_ErrIn : IN STD_LOGIC; SDU_IN_USER_In : IN STD_LOGIC_VECTOR( USER_width-1 DOWNTO 0); SDU_IN_Ack : OUT STD_LOGIC; SDU_IN_ErrOut : OUT STD_LOGIC; ------------------------------------------------------------PDU_DOUT : OUT STD_LOGIC_VECTOR( DataWidth-1 DOWNTO 0); PDU_DOUTV : OUT STD_LOGIC; PDU_Out_SOP : OUT STD_LOGIC; PDU_Out_EOP : OUT STD_LOGIC; PDU_Out_Ind : OUT STD_LOGIC; PDU_Out_ErrOut : OUT STD_LOGIC; PDU_Out_USER_Out : OUT STD_LOGIC_VECTOR( USER_width-1 DOWNTO 0); PDU_Out_Ack : IN STD_LOGIC; PDU_Out_ErrIn : IN STD_LOGIC; ------------------------------------------------------------PDU_DIN : IN STD_LOGIC_VECTOR( DataWidth-1 DOWNTO 0); PDU_DINV : IN STD_LOGIC; PDU_IN_SOP : IN STD_LOGIC; PDU_IN_EOP : IN STD_LOGIC; PDU_IN_Ind : IN STD_LOGIC; PDU_IN_USER_In : IN STD_LOGIC_VECTOR( USER_width-1 DOWNTO 0); PDU_IN_ErrIn : IN STD_LOGIC; PDU_IN_ErrOut : OUT STD_LOGIC; PDU_IN_Ack : OUT STD_LOGIC; ------------------------------------------------------------SDU_DOUT : OUT STD_LOGIC_VECTOR( DataWidth-1 DOWNTO 0); SDU_DOUTV : OUT STD_LOGIC; SDU_Out_SOP : OUT STD_LOGIC; SDU_OUT_EOP : OUT STD_LOGIC; SDU_OUT_Ind : OUT STD_LOGIC; SDU_OUT_USER_Out : OUT STD_LOGIC_VECTOR( USER_width-1 DOWNTO 0); SDU_OUT_ErrOut : OUT STD_LOGIC; SDU_OUT_ErrIn : IN STD_LOGIC; SDU_OUT_Ack : IN STD_LOGIC; -------------------------------------------------------------Status : OUT STD_LOGIC_VECTOR(7 DOWNTO 0) ); END COMPONENT UDPLayer;
3.4.5.5 Az SNMP modul Az SNMP modul konzulens általi specifikáció alapján legyen képes egy meghatározott vállalati OID alatt, az EventIn bemeneten jelzett sorszámú vállalat specifikus SNMP TRAP PDU-t küldeni. Ha egyszerre több bemeneten érkezik jelzés, akkor több PDU kerül kiküldésre, az alacsonyabb sorszámútól a magasabbik felé. A modul legyen képes monitorozni a helyi hálózati összeköttetések állapotát olyan módon, hogy azok megszakadása esetén küldjön linkDown generikus Trap-et, majd helyreállítás után küldjön linkUp Trapet. A modul legyen képes több egyidejű linkállapot változás kezelésére, de úgy, hogy az alacsonyabb pozíciójú bementek magasabb prioritást élvezzenek azaz, hogy az alacsonyabb sorszámú bementekhez tartozó jelzés előbb kerüljön elküldésre. A modul használja fel a tervezett UDP-t megvalósító modul szolgálatait, és implementálja annak interfészét.
55
A modul rendelkezzen konfigurációs bemenetekkel, ahol beállítható és lekérdezhető a TRAP fogadó menedzser szerver címe és a cél TRAP UDP port valamint a helyi entitás ágens UDP port. Lehetőség szerint a modul implementálja újraindítás esetén a warmStart, és első indítás estén a coldStart trap küldését. Az RFC1115-nek megfelelően tartson nyilván időinformációt, és azt a trapekben megfelelően küldje el a menedzser részére. A modul interfészjeleinek VHDL leírása az alábbi: COMPONENT SNMPModule IS -============ GENERIC( DataWidth : INTEGER := 8; CLK_freq : REAL := 125.0; TX_SYNC : BOOLEAN := false; NumOfEvents : INTEGER := 32; --max 255, transferred in specific trap NumOfLinks : INTEGER := 2 --max 255 ); PORT( CLK : IN STD_LOGIC; CE : IN STD_LOGIC; CFG_CE : IN STD_LOGIC; RST : IN STD_LOGIC; ------------------------------------------------------------UDP IF -----------------------------------------------------------DstIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); SrcIPAddr_In : IN STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); DstPort_In : IN STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); SrcPort_In : IN STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); Length_In : IN STD_LOGIC_VECTOR( UDPLengthSize-1 DOWNTO 0); ------------------------------------------------------------DstIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); SrcIPAddr_Out : OUT STD_LOGIC_VECTOR( IPAddrSize-1 DOWNTO 0); DstPort_Out : OUT STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); SrcPort_Out : OUT STD_LOGIC_VECTOR( UDPPortSize-1 DOWNTO 0); Length_Out : OUT STD_LOGIC_VECTOR( UDPLengthSize-1 DOWNTO 0); -------------------------------------------------------------- RX INterface signals PDU_DIN : IN STD_LOGIC_VECTOR( DataWidth -1 DOWNTO 0); PDU_DINV : IN STD_LOGIC; PDU_IN_SOP : IN STD_LOGIC; PDU_IN_EOP : IN STD_LOGIC; PDU_IN_INd : IN STD_LOGIC; PDU_IN_ErrOUT : OUT STD_LOGIC; PDU_IN_Ack : OUT STD_LOGIC; PDU_IN_ErrIN : IN STD_LOGIC; -------------------------------------------------------------- TX INterface signals PDU_DOUT : OUT STD_LOGIC_VECTOR( DataWidth -1 DOWNTO 0); PDU_DOUTV : OUT STD_LOGIC; PDU_OUT_SOP : OUT STD_LOGIC; PDU_OUT_EOP : OUT STD_LOGIC; PDU_OUT_INd : OUT STD_LOGIC; PDU_OUT_ErrOUT : OUT STD_LOGIC; PDU_OUT_Ack : IN STD_LOGIC; PDU_OUT_ErrIN : IN STD_LOGIC; -------------------------------------------------------------- MGMT INputs WR_EN : IN STD_LOGIC; RD_EN : IN STD_LOGIC; CFG_ADDR : IN STD_LOGIC_VECTOR( SNMPAddrWidth-1 DOWNTO 0); DATA_IN : IN STD_LOGIC_VECTOR( SNMPDataWidth-1 DOWNTO 0); RD_DV : OUT STD_LOGIC; DATA_OUT : OUT STD_LOGIC_VECTOR( SNMPDataWidth-1 DOWNTO 0); ----SNMP TRAP INitiator INput EventIN : IN STD_LOGIC_VECTOR( NumOfEvents -1 DOWNTO 0); LinkStatusIn : IN STD_LOGIC_VECTOR( NumOfLinks -1 DOWNTO 0) -); END COMPONENT SNMPModule;
56
3.4.6 Protokollverem kialakítás ProtoLayer-ek összekapcsolásával A megtervezett protokoll megvalósító modul lehetőséget biztosít arra, hogy az SDU kimentet összekösse egy másik PDU bemenetével, illetve fordítva is; továbbá a réteg között interfész specifikus jeleket összekötve protokollvermet lehessen kialakítani. Ezt az összeköttetést a 21-es ábra szemlélteti.
ProtoModule_TXPart
ProtoLayer PDU be adat és vezérlőjelek
PDU Queue
PCI adat ki és vezérlő-jelek
PCI adat be és vezérlőjelek
PDU ki adat és vezérlőjelek
N+1. réteg
N. réteg
SDU adat be és vezérlőjelek
SDU adat ki és vezérlőjelek
PDU be adat és vezérlőjelek
PDU Queue
PCI adat ki és vezérlő-jelek
SDU adat be és vezérlőjelek
SDU adat ki és vezérlőjelek
Protokollfüggő bemenetek a felsőbb rétegek felől
Protokollfüggő kimenetek az alsóbb rétegek felé
Megvalósítandó protokoll
Megvalósítandó protokoll Protokollfüggő kimenetek a felsőbb rétegek felé
Protokollfüggő bemenetek az alsóbb rétegek felől
ProtoModule_TXPart
ProtoLayer
Protokollfüggő bemenetek a felsőbb rétegek felől
Protokollfüggő kimenetek az alsóbb rétegek felé
PDU ki adat és vezérlőjelek
PCI adat be és vezérlőjelek
N-1. réteg
Protokoll X
Protokollfüggő kimenetek a felsőbb rétegek felé
Protokollfüggő bemenetek az alsóbb rétegek felől
Protokoll Y
21. ábra Protokollt megvalósító modulok összekapcsolása (20 -as ábra elemeinek összekapcsolása)
Ez az architektúra azonban még nem biztosítja azt, hogy egy protokoll szolgálatait több, magasabb rétegbeli protokoll használhassa, így ez még nem megfelelő az általános protokoll megvalósításához. 3.4.6.1 Arbitrációs modul Ahhoz, hogy több protokoll modult egymáshoz tudjunk illeszteni, egy arbitrációs modulra van szükség, ami adási irányban valamilyen arbitrációs eljárás szerint hozzáférést biztosít a használandó protokoll modulhoz, és a bemeneti jeleken való osztozást megoldja. A kimeneti jeleket egyszerű a csatlakoztatott modulok számára csak olvasható buszként mindegyik modulba be kell vezetni. Az arbitrációs modulban kell kódolni azt, hogy az adott réteg protokoll diszkriminátora alapján a kérdéses adatelem mely modul számára kerül további feldolgozásra. Példaként álljon, hogy az UDP port mező alapján melyik modul számára kerüljön továbbításra az adatelem. Követelmény az arbitrációs modul számára, hogy a címfordítási tábla módosítható legyen. Ez például egy Ethernet-IP modul összeköttetésnél annyira nem problémás, de 57
egy alkalmazás rétegbeli protokoll esetén a portok konfigurálhatóak, így azt az arbiternek is le kell tudnia követni. Általánosan megfigyelhető, hogy a protokollok a SAP-on keresztül átadják a protokoll diszkriminátort a szolgálati primitívekben. Ennek köszönhetően külön címbuszra nincs szükség az arbiter külső interfészein, mivel majd csak az a modul kapja a bemeneteket, amelyik részére szólnak, illetve az arbiter modul tudja, hogy melyik bemenetein érkezet a kérés, így az már kijelöli a címet. Az arbitrációs modulban lehetőség lesz arra, hogy a protokoll modul kimenete annak bemenetére visszavezethető legyen. A leírt arbitrációt a 22. ábra illusztrálja.
Bemenetek
Kimenetek Protokoll
Bemenetek
Kimenetek Protokoll
Kimenetek
Kimenetek
Bemenetek
Bemenetek
Kimenetek
Arbitrációs modul
Bemenetek
Protokoll
Kimenetek
Bemenetek
22. ábra Az arbitrációs modul elhelyezkedése a rendszerben
A rendelkezésre álló szűkös időbeli erőforrások miatt a generikus N-bemenetű arbitrátor helyett csak egy 2 bemenetű arbitrátor készült el, mivel a megvalósítandó protokollok működéséhez ez is elegendő. Emellett az előzetesen megtervezett komplex konfigurálható arbiter helyett a feladat megoldásához elegendő egy nem konfigurálható arbiter az EtherLayer és az ARPModule – IPLayer páros közé, mivel ezek protokoll diszkriminátora szabványok illetve ajánlások által rögzített, így a protokollok vételi oldalán a saját diszkriminátorra komparálva a csomag helyben, hibajelzés nélkül eldobható.
58
4 Implementáció és tesztelés Az implementáció célplatformja egy Xilinx gyártmányú Virtex 5 típusú FPGA, így a megvalósítás során egy bizonyos fokig szükséges volt hardver-függő elemeket használni, mint például a Virtex 5-ös FIFO primitív, azonban ennek cseréje esetlegesen csak a primitív elnevezés cseréjével jár. A többi felhasznált elem mind általános primitív, tehát D tárolók, regiszterek és összeadók. A következőkben az elkészített modulok felsorolása, bemutatása, és szimulációs teszteredmények bemutatása lesz olvasható. A bemutatás a bottom-up elvet követi, mivel az egyes nagyobb modulok felhasználják, tartalmazzák a kisebb modulokat. A viselkedési szimulációs hullámformák az interfészjelek sokasága miatt azonban csupán a meghatározó csoportok viselkedéséről mutat majd képet a teljesség igénye nélkül. A bemutatás végén pedig az elkészült rendszerrel végzett tesztek jegyzőkönyvei tanulmányozhatóak.
4.1 Implementációs részletek 4.1.1 Kiegészítő modulok A tervezés során többször felmerülő problémákra, feladatokra igyekeztem általános, újrafelhasználható megoldást készíteni, ezek leginkább a protokollvezérlő modulok megvalósításakor előkerülő megvalósítási sémákat hivatottak kezelni. Ezek a Serializer, a DeSerializer és a MiniCAM modulok. 4.1.1.1 Serializer modul A Serializer modul egy generikus sorosító egység, amelynek két generikus paramétere a DataWidth és a ToSer, melyek közül az első a soros adatbusz szélességét jelöli, tehát egyfajta adategységet, míg a második a sorosítani kívánt adategység mennyiséget. A modul PIn nevű bementének a szélessége a két generikus paraméter szorzata, és ez az úgymond „párhuzamos” bemenet. A működés tekintetében a Start jel felfutó éle indítja a sorosítást, míg a kimenő interfész megfelel az általános jel és interfészismertető részben leírt specifikációnak. Ez a modul arra használható, hogy a fejléc számára deklarált sokbites vektort a bementére kötve, és a Start jellel parancsot
59
adva előállítja adatfolyam formájában a fejlécet, vagy akár a csomagot is alkalmazásrétegbeli protokoll esetén. COMPONENT Serializer IS generic( DataWidth : INTEGER := DefDataWidth; ToSer : INTEGER := DefToSer ); PORT( CLK : IN STD_LOGIC; RST : IN STD_LOGIC; CE : IN STD_LOGIC; Start : IN STD_LOGIC; Ser_Start : OUT STD_LOGIC; Complete : OUT STD_LOGIC; -------------------------------------------PIn : IN STD_LOGIC_VECTOR(DataWidth*ToSer-1 downto 0); SOut : OUT STD_LOGIC_VECTOR(DataWidth-1 downto 0); OuTV : OUT STD_LOGIC ); END COMPONENT Serializer;
4.1.1.2 DeSerilazer modul A DeSerializer modul egy generikus párhuzamosító egység, amely a sorosan érkező adatfolyamból előállít egy vektorból álló kimenetet. A soros bemenet szélessége megegyezik a generikus paraméterként megadott DataWidth-tel, míg a párhuzamos kimenet szélessége a ToDeSer és a DataWidth paraméter szorzatával egyezik meg. A modul tartalmaz egy számlálót, így ha paraméternél hosszabb soros adatfolyam érkezik, akkor is érvényes kimenetet ad, amelyet a POutV jellel tud jelezni, azonban ha a soros bemeneten a vég-kijelölő jel előbb érkezik meg, mint kellene, akkor azt POut_err jellel képes jelezni. Ez a modul remekül használható protokoll fejlécek vagy akár kisebb csomagok fogadása esetén azok párhuzamosítására, a párhuzamos kimenet megfelelő pozíciójaihoz hozzárendelt kisebb vektorokkal az információ kényelmesen kezelhető. A modul deklarációja VHDL nyelven: COMPONENT DeSerializer IS generic( DataWidth : INTEGER := DefDataWidth; ToDeSer : INTEGER := DefToDeSer ); PORT( CLK : IN STD_LOGIC; RST : IN STD_LOGIC; CE : IN STD_LOGIC; -------------------------------------------SIn : IN STD_LOGIC_VECTOR(DataWidth-1 downto 0); Ser_DV : IN STD_LOGIC; Ser_SOP : IN STD_LOGIC; Ser_EOP : IN STD_LOGIC; Ser_ErrIn : IN STD_LOGIC; POut : OUT STD_LOGIC_VECTOR(DataWidth*ToDeSer-1 downto 0); POuTV : OUT STD_LOGIC; POuT_err : OUT STD_LOGIC ); END COMPONENT DeSerializer;
60
4.1.1.3 MiniCAM, tartalom-címezhető kisméretű memória A MiniCAM egy kisméretű, tartalom-címezhető memóriát megvalósító modul. Habár a generikus paraméterei tetszőleges számú elemet engednek, nem érdemes sokkal használni, mivel a sok komparátor nagy kombinációs logikát eredményezhet. Az InitToFF generikus paraméterrel megadhatjuk, hogy a memória utolsó rekeszét inicializálja csupa egyes bitre. Ez az üzenetszórásos címeknél hasznos, mivel így megspórolunk egy beírást a felkonfigurálásnál. A CFG_CE engedélyezés esetén lehetőség van a beírásra, illetve olvasásra. A CAM_ kezdetű bemenetek szolgálnak a tartalom-címezhető bemenetekként. A keresés indítása után a MatchV magas értéke jelzi, hogy a találatjelző kimenet érvényes, amely mellett, ha Match kimenet is magas, akkor eleme a memóriának a keresett elem, és az Addr_Out kimeneten megjelenik a címe, ellenkező esetben pedig nincs találat. COMPONENT MiniCAM IS generic( DataWidth Elements InitToFF ); PORT( CLK RST CE CFG_CE WR_EN RD_EN DIN ADDR_In CAM_DIN CAM_SRCH Match MatchV DOUT ADDR_Out DOUTV ); END COMPONENT MiniCAM;
: : :
: : : : : : : : : : : : : : :
INTEGER := INTEGER := BOOLEAN :=
IN IN IN IN IN IN IN IN IN IN OUT OUT OUT OUT OUT
DefDataWidth; DefCAMElems; true
STD_LOGIC; STD_LOGIC; STD_LOGIC; STD_LOGIC; STD_LOGIC; STD_LOGIC; STD_LOGIC_VECTOR(DataWidth-1 downto 0); STD_LOGIC_VECTOR(INTEGER(CEIL(LOG2(REAL(Elements))))-1 downto 0); STD_LOGIC_VECTOR(DataWidth-1 downto 0); STD_LOGIC; STD_LOGIC; STD_LOGIC; STD_LOGIC_VECTOR(DataWidth-1 downto 0); STD_LOGIC_VECTOR(INTEGER(CEIL(LOG2(REAL(Elements))))-1 downto 0); STD_LOGIC
4.1.2 PDUQueue modul A PDUQueue modul implementációjában központi szerepet játszik a felhasznált FIFO tároló, amely a Virtex 5-ös FPGA-ban a beépített blokk RAM-ot felhasználva, a kiegészítő logikát megvalósítva, beépített primitívvel példányosítható. A tárgyi FPGAban 4-féle alap FIFO primitív használható, melyek adatbusz szélessége, működési módjai és jelzési korláti konfigurálhatóak generikus paraméterekkel. Mivel alapesetben az Ethernet keret maximális hossza 1518 bájt, az adatszélesség a rendszerben 8 bites, ahhoz hogy a protokollmezők kezelése és a részek illesztése egyszerűbb legyen, ezért a választás a 36K-s FIFO-ra esett, mivel ebben 16 bites szélességen 2000 bájt tárolható, 61
így egy teljes keret problémamentesen elfér késedelmes feldolgozás esetén is. A konfigurációja 18bit x 2K felosztás, First-Word-Fall-Through FIFO mód, regiszterezett kimenettel, amely esetén 16 bites adatbemenet mellett 2 bit paritás bement is használható. Az összesen 18 bites buszszélességbe kényelmesen belefér a tervezett 8 bites adatút és még a kiegészítő jelek párhuzamos átvitelére is van mód. A modulban két fő állapotgép található, az egyik a vételi oldal menedzseléséért felel, míg a másik a specifikált vezérlési-továbbítási ciklust produkálja. A modulban a túlcsordulás elleni védelemért a vételi állapotgép felel, a FIFO AlmostFullOffset flagével karöltve, amely a generikus paraméterként megadott maximális PDU méret függvényében állítódik be szintézisidőben. Átvitel során, hiba esetén, ha az adatelem első bájtjánál található a hibajel, nem íródik semmi a sorba - míg ha máskor érkezik hibajel az átvitel során, akkor az addigi töredék bekerül. Ezekből következik, hogy célszerű a hibajelet az adatelem eleje felé terjeszteni, mert így előbb utóbb, az egész adatelemre hatással lesz, így kezelve a hibahelyzetet. Ezt teszi a PDUQueue is, minden szint után a hibajelet egy órajellel az adatelem kezdete felé tolja. A 23. ábrán látható a PDUQueue modul implementációs blokkvázlata.
Vezérlési adat és vezérlőjelek
Vezérlési késleltetés és felülírás Feldolgozási állapotgép
Vételi állapotgép
Bemeneti adat és vezérlőjelek
Bemeneti vezérlés Bemeneti késleltetés és felülírás
Olvasás vezérlés
Beírás vezérlés
FIFO36 (FWFT,18x2K konfigurációban) Bementi adat és vezérlés
Vezérlés
Vezérlési adat Kimeneti adat és vezérlőjelek
Kimeneti vezérlőjelek
Kimeneti adat és vezérlés
Kimeneti késleltetés és felülírás
PDUQueue
23. ábra A PDUQueue implementációs blokkdiagramja
A megvalósítás során a specifikációnak megfelelően implementálva lett mind a handshake-es és a handshake nélküli adattovábbítás mindegyik interfészen, ami példányosításkor generikus paraméterekkel állítható. Ezeken felül az állapotgépben kódolásra került egy PASS-THROUGH mód, ami akkor áll fent, ha a CTRL_FWD vezérlőjel folyamatosan magas értéket vesz fel. Ez a mód az adási irány megvalósításnál hasznos, mivel ott a tervezés alapján nincs szükség a vezérlési ciklusra. A teljes 62
rendszer implementálása után azonban ismeretessé vált, hogy a kódolás miatt több erőforrást foglal így a modul, mintha az entitáshoz tartozna egy másik architekturális leírás, ami csak az egyszerűsített továbbítási funkciókat tartalmazza. Ez az egyszerűsítés további fejlesztési lehetőséget hordoz magában.
4.1.3 ProtoModule_TXPart modul Az adási rész implementálása nagyban épít az előbb ismertetett PDUQueue modulra. Egész pontosan három darab került felhasználásra benne. Egy, ami a sorosan érkezett PCI-ket tárolja, egy, ami az SDU-kat tárolja, és egy, amiben az összeállított PDU-k várakoznak a továbbításra. Mindhárom sor PASS_THROUGH üzemmódban működik, azaz a CTRL_FWD jel magas állapotban került rögzítésre. A modul tartalmaz egy állapotgépet, ami a multiplexert vezérli a PCI, SDU és PDU sor között, valamint a kezeli a handshake jeleket, és a PDU kimenő sor kimeneti és bemeneti engedélyezését vezérli. Az SDU és PCI sor kimenete, valamint a PDU sor bemente handshake-es üzemmódban került példányosításra, a magas szintű kezelés lehetőségének érdekében. Az implementációnál különös figyelmet kellett fordítani a hibakezelésre, mivel ebben az adat két különálló sorból származhat, melyek közül bármelyik bárhol tartalmazhat hibajelet. A hibahely előfordulásának alapvetően két fajtája fordul elő a rendszerben: az első fajta, ami, az adatelem kezdetkijelölő jelekkel együtt áll be, ekkor a PDUQueue-ba nem íródik bele semmi a hibás csomagból, míg a másik esetben nem az első bájtnál érkezik a hibajel, ekkor az adatelem addigi hibátlan töredéke beíródik a tárolóba, és onnan továbbításra is kerül. A cél, hogy megőrizze a modul a sorok közti konzisztenciát, azaz, hogy minden PCI rész az eredetileg neki megfelelő SDU résszel legyen összefűzve. A fentiekből következik, hogy a protokollt megvalósító modulnak nem kell PCI részt generálnia akkor, hogy az SDU első bájtja hibás volt, mivel az már nem kerül be az SDU sorba. Minden egyéb esetben viszont szükséges a PCI generálás, és a hibát majd ez a modul autonóm módon lekezeli azzal, hogy a kiolvasott, feltehetően hibamentes PCI rész kiolvasása után tovább folytatja az SDU résszel, amelynek hibajele az összeállítási sorban fogja már jelezni majd a hibát. Egy lehetséges eset, hogy valamilyen okból kifolyólag nem kell PDU-t küldenie az adott rétegnek az SDU vétele után, például az IPLayer modulban, az SDU vétele indítja a működési ciklust, és az SDU beírással párhuzamosan ARP-zik, viszont ha nem válaszol a célcím, akkor az IP küldési részének állapotgépe hibát injektál a PCI részbe. Ebből adódóan a
63
ProtoModule_TX_Part összeállítási állapotgépének leírásában úgy lett megoldva, hogy ha nem csak PCI rész van, és hiba van a PCI-ben, a konzisztencia megőrzése végett akkor is kerüljön kiolvasásra az SDU rész. A rendszer hatékonyságát növeli ebben az esetben, ha a protokollt megvalósító modul a PCI rész második bájtjába injektálja a hibajelet, mivel a PDUQueue hibasiettető mechanizmusa azt eredményezi, hogy az összeállítási sor bemenetén az adatelem kezdetkijelölő jel és a hibajel egy órajelben esnek, így a hibás csomag nem terjed tovább. A tárgyi modul implementációs vázlatát a 24. ábra szemlélteti. V. V.
Be
PDUQueue (PCI sor, PASS_THROUGH)
Ki
S.
MUX SDU adat be és Be vezérlőjelek
PDUQueue (SDU sor, PASS_THROUGH)
V.
PCI adat be és vezérlőjelek
Összeállítás vezérlés & Ki- és bemenet engedélyezés
Be
PDUQueue (PDU sor)
Ki
PDU adat ki és vezérlőjelek
ProtoModule_ TXPart
Ki
24. ábra ProtoModule_TXPart implementációs vázlat
4.1.4 ProtoLayer modul Ahogy a tervezési részben már ismertetésre került, ennek a modulnak a feladatkörének egyik része, hogy becsomagolja a fentebb említett modulokat, a könnyebb és egységesebb kezelés miatt. A feladatának a másik része egy Serializer – PDUQueue – DeSerializer modul együttes sorba kapcsolásával és egy-egy vezérlő állapotgép megvalósításával történik, amely a vezérlőjeleket a PDUQueue kimenetén szolgálja. A közbeiktatott PDUQueue bemenete nem handshake-es, míg a kimenete az, így a vezérlési állapotgép tudja ütemezni a kiegészítő információk léptetését. Ezen kisegítő várakozási sorokat alkotó modulok megléte a RX_AuxQ és a TX_AuxQ generikus
logikai
paraméterekkel
szintézisidőben
állíthatóak
példányosításánál. A ProtoLayer implementációját a 25. ábra illusztrálja.
64
a
ProtoLayer
Kiegészítő adat kimenet Adási oldal
Kiegészítő adat bemenet Adási oldal
PDUQueue (TX_AUXQ)
(Opcionális)
DeSerializer
Serializer V.
Összeállítás vezérlés & Ki- és bemenet engedélyezés
V.
S.
PDU adat ki és vezérlőjelek
PDUQueue (PDU sor)
Ki
V.
Be
Ki
PDUQueue (PCI sor, PASS_THROUGH)
Be
PCI adat be és vezérlőjelek
Ki
PDUQueue (SDU sor, PASS_THROUGH)
Be
SDU adat be és vezérlőjelek
MUX
ProtoModule_TX Part
ProtoLayer PDUQueue
Bementi adat és vezérlés Bemeneti Bemeneti adat és késleltetés és vezérlőjelek felülírás
FIFO36 (FWFT,18x2K konfigurációban)
Bemeneti vezérlés
Beírás vezérlés
Kimeneti adat és vezérlés
Olvasás vezérlés
Serializer
Kiegészítő adat bemenet Vételi odal
Kimeneti adat és vezérlőjelek
Vezérlési késleltetés és felülírás
Vezérlési adat és vezérlőjelek
Kimeneti vezérlőjelek
Feldolgozási állapotgép
Vételi állapotgép
Kimeneti késleltetés és felülírás
DeSerializer PDUQueue (RX_AUXQ)
Vezérlési adat Vezérlés
(Opcionális) Kiegészítő adat kimenet Vételi odal
25. ábra A teljes modul implementációs vázlata (fent:24.ábra, lent: 23.ábra, szaggatott kerettel az opcionális kiegészítő modulok)
4.1.5 EtherLayer modul A specifikációnak megfelelően full-duplex mód került megvalósításra. A NumOfMacAddresses generikus paraméterrel lehet beállítani a példányosított modul MAC címeinek a számát. Ha a beállított érték N, akkor a felhasználható konfigurálható címek száma N-1, mivel egy címet fenn kell tartani a broadcast cím számára, amelyet a modul konfigurál maga számra reset után. Ezt mutatja az alapértelmezett 2-es érték, ami egy konfigurálható címet biztosít így. Két állapotgép, egy Serializer, egy DeSerializer, egy MiniCAM, egy Padder modul és a ProtoLayer valósítja meg az Ethernet MAC adatkapcsolati réteget. Az 65
adásoldali állapotgép feladata, hogy az adási irányban regisztrálja az ICI bemenetre adott adatot, és előállíttatja a fejlécet a Serializer vezérlésével, majd a felhasznált ProtoLayer modul PCI bementére továbbítja azt. Ez a működés valósítja meg az MA_DATA.request szolgálati primitívet, amiben a megfelelő bemeneti adatvezeték hordozzák a szolgálati primitív által definiált attribútumokat. A vételi oldali logika megvalósításához szükséges vezérlést egy másik állapotgép adja, felel a fázisok észlelésért és vezérlőjelek előállításért, vezérli MAC cím ellenőrzéséhez használt MiniCAM memóriát, és rendelkezik a vett keret sorsáról a CAM kimenete alapján. A modul a specifikációnak megfelelően a MiniCAM modulban tárolja a saját MAC címeit. Az ellenőrzés során a CAM modul párhuzamosan komparálja az összes regisztrált MAC címmel a feldolgozás alatt lévő keret célcímét, így néhány órajel alatt ez az ellenőrzés elkészül. Ezalatt a fő vételi modul regiszterbe tölti a fejléc információit: a célcímet, a forráscímet és az EtherType/Length mezőt. Ha a célcím ellenőrzés sikeres, akkor CTRL_FWD jellel jelezi a ProtoLayer modulnak, hogy továbbítandó a felsőbb réteg felé a szállítandó SDU. Amikor a kimeneti PDUQueue modul megkezdi a továbbítást a beállított módon, addigra az ICI kimeneteken érvényes lesz
a
vett
keretből
kinyert
információ.
Ez
a
működés
megvalósítja
az
MA_DATA.indication szolgálati primitívet, amiben a megfelelő kimeneti adatvezeték hordozzák a szolgálati primitív által definiált attribútumokat. A tárgyi modul implementációs vázlata a 26. ábrán tanulmányozható.
SDU adat be és vezérlőjelek
PDU ki adat és vezérlőjelek
IPG PDU ki adat és vezérlőjelek
EthPadder
Adási állapotgép
ProtoModule_TXPart
PCI adat be és vezérlőjelek
DSTMacAddr,SRCMacAddr,Etype bemenet
ProtoLayer Serializer PDU Queue
PDU be adat és vezérlőjelek
SDU adat ki és vezérlőjelek
PCI adat ki és vezérlő-jelek
MiniCAM
DeSerializer
EtherLayer
DSTMacAddr,SRCMacAd dr,Etype kimenet
26. ábra Az EtherLayer implementációs vázlata
66
Vételi állapotgép
Az implementáció után viselkedési szimulációt végeztem, majd annak eredményét analizálva megállapítottam, hogy a modul az előzetes specifikációnak megfelelően működik. Többféle konfigurációban végeztem szimulációt és mindegyik esetében kielégítő lett a végeredmény.
27. ábra Az EtherLayer működésének teljes szimulációja
A 27. ábra egy MAC cím felkonfigurálási fázist, és annak verifikálását illusztrálja, valamint több PDU küldést és fogadást ebben a sorrendben. A teszteléshez példányosított modulnál a NumOfMacAddresses attribútum 3-as értékű volt, és a két felkonfigurált MAC cím a 0x50E5493904A2 és a 0x000117F3F786 volt. Ezt az ábrán a wr_en és rd_en jelek magas értéke jelzi. Ezután az MA_DATA.request került tesztelésre két csomaggal, melyek késleltetés után kerültek kiadásra, mivel az adási modul kimenete le van tiltva, amíg nem várakozik teljes PDU a kimeneti sorban. Ezeket követően négy Ethernet keret vételével teszteltem a vételi részt. A négy keret közül az első nem a modulnak címződött, egy broadcast, kettő pedig a konfigurált címekre szólt. Az SDU_doutv érvényességet jelző vezetéken látható, hogy az első nem került továbbításra a felsőbb modulok felé, a többi pedig a megfelelő kimeneteket produkálva igen (dstmacaddr_out, srcmacaddr_out, ethtype_out az sdu_out_sop impulzus alatt).
67
4.1.6 ARP modul Az ARP modult az előzetes specifikációhoz igazodva implementáltam, felhasználva az EthernetLayer modul implementálásánál megszerzett tapasztalatokat. A keretrendszer a használatóságát már bizonyította egyszer, azonban az ARP szerkezetét tekintve nem teljesen hasonló az általános architektúrához, mivel egy felső protokollról van szó, amin nem nyújt átviteli szolgáltatásokat felsőbb rétegeknek. Tehát ebből adódóan az egész ProtoLayer modul felhasználása felesleges lenne, de annak egy részegysége továbbra is kitűnően alkalmazható, mégpedig a PDUQueue modul. Az ARP csomagok fogadása először egy Pass-Through módban lévő sorba érkezik, melynek bemeneti beállításai az ARP modul bemeneti beállításait követik, viszont a kimenete mindenképpen handshake-es, mivel így a feldolgozó modul magas szinten tudja kezelni a sorban várakozó üzenteket. A már ismertetett protokoll-megvalósító eszköztárból a modul felhasználja a DeSerializer és a MiniCAM modulokat a bejövő ARP csomagok kezelésére. A DeSerializer (8, ARP PDU hossz/8)4 -as generikus konfigurációval kerül példányosításra, és a soros bementét a várakozási sor kimenet adja. Ezzel megoldódik az ARP csomag kifejtése, és a DeSerializer gondoskodik az esetleges Ethernet töltelék levágásáról is, a modul párhuzamos kimeneti jelére le vannak képezve az ARP csomagszerkezetnek megfelelően az egyes mezőket reprezentáló vektorok, ezzel megvalósítva a mezőkezelési funkciókat. Ezek után az ar$tpa mező, amely a cél protokoll címét szállítja, rá van vezetve a MiniCAM keresési bemenetére, annak cím kimenete pedig egy ugyanolyan méretű RAM címbemenetére, amelynek adat kimenete szolgáltatja válaszként elküldendő MAC címet. A vételi állapotgép felügyeli az egész működést, validálja az ARP mezőket, ezzel a csomag érvényességét ellenőrzi. Ha a fogadott csomag egy kérés, akkor értesíti a válaszküldésért felelős állapotgépet, és átadja neki a válaszként küldendő MAC címet. Ha a vett csomag egy válasz, és van függőben lévő kérése a kérésért felelős állapotgépnek, és az ar$spa megegyezik a kérésként elküldött IP címmel, akkor értesíti az állapotgépet, és átadja neki a küldő MAC címét. Az ARP csomag összeállítási oldalon a struktúra a fentiekhez hasonló, csak DeSerializer helyett Serializer modul található, amelynek párhuzamos adatbemenetén
4
Ez a jelölésmódja a VHDL modulok generikus paramétereinek bizonyos értékre történő
rögzítésének
68
egy ARP csomag méretű regiszter található, amelyet a megfelelő küldési állapotgép írhat. Ebből az elrendezésből kettő található, egy a kérés csomagok, egy pedig a válasz csomagok összeállításához. A két állapotgép az ARP modul PDU kimenetéhez egy arbitertől kér hozzáférést a kimenethez, ami handshake-es kimeneti beállítás esetén kikerül a kimenetre is. Aki megkapja a hozzáférést, annak az ARP csomagja kerül ki a kimenetre. Fontos implementációs részlet, hogy kérés estén az alapértelmezett MAC és IP címet a modul regiszterezi, mégpedig a konfiguráció során a 0-s címre beírtat, így ezek fognak szerepelni a kérésben. Emellett az összes konfigurált IP címhez a neki megfelelő címre érvényes MAC címet kell beírni a konfiguráció során. A modul generikus paraméterei között a TimeOut-tal és a RetryCount-tal lehet beállítani a válasz időkorlátját és az újrapróbálkozások számát. A számításhoz meg kell adni az órajelet is, amiről a modul jár. Az idő mértékegysége ms-ban, míg a frekvenciáé MHz-ben értendő. Az időkorlát nem lesz pontos, mivel az egyszerűbb logika érdekében az időt számláló számláló legfelső bitjének felfutó éle lesz a TimeOut jel a designban, ami eltérhet a megadottól. Ha az adott számú újrapróbálkozás megvolt, és nem érkezett válasz a kérésre, akkor a modul a kimeneti hibajellel jelzi ezt a felhasználó modulnak. Siker esetén az érvényes válasz jel magas értéke mellett az ARP_DstMACAddr kimenetre kiteszi a cél fizikai címét. A modul implementációja a 28. ábrán látható. Serializer
Kimeneti adat és vezérlőjelek
ARP Modul
ARP válasz csomag
DeSerializer Kimeneti adat és vezérlőjelek
Ar$tpa
MiniCAM
ARP csomag
Cím
Válasz állapotgép
RAM Válaszolandó fizikai cím
Feldolgozási állapotgép
28. ábra ARP modul implementációs blokkvázlata
69
Válasz fizikai cím
Serializer
PDU Queue
ARP interfész
Arbiter vezérlőjelek
Soros ARP válasz csomag
Bemeneti adat és vezérlőjelek
Kérés állapotgép
ARP kérés csomag
Soros ARP kérés csomag
Válasz Fizikai cím
Arbiter
4.1.7 IPLayer modul Az IPv4 implementációjánál a tervezési fázisban lefektetett irányt követtem. Mivel ez a modul a többinél sokkal több paraméterrel rendelkezik, ezért annak érdekében, hogy csökkentsem a bemenetek számát, bevezettem egy konfigurációs címregisztert is, amellyel először ki kell választani a konfigurálandó paramétert, majd utána lehet írási ciklusokkal konfigurációt végezni. A konfigurációs címek a forrásfájlban egyértelműen dokumentálva vannak, és a szimulációs test bench-ben és a valós rendszer konfigurációs szkriptjében is található rá példa, hogy pontosan miként zajlik a konfigurációs ciklus. A routing táblát egy a MiniCAM modul alapján megírt IPCAM modul és egy RAM valósítja meg. A routing úgy valósul meg, hogy a modul megnézi, hogy a célcím az adott alhálózaton található-e, vagy sem, ha nem, akkor felkonfigurált alapértelmezett átjáró felé küldi a csomagot, ha igen, akkor pedig közvetlenül a címzettnek. Ez az IPCAM segítségével történik, aminél íráskor a hálózati cím mellett az alhálózati maszkot is be kell írni, és keresés esetén a keresett címet maszkolja az összes maszkkal, és ha úgy van egyezés, akkor van a célcím a helyi hálózaton található, az IPCAM kimeneti címe egy memóriába van vezetve, ami tárolja a küldéshez használandó fizikai forráscímet, kvázi azonosítja a kimenő interfészt. Küldési oldalon a bemeneten található állapotgép ARP-zik, vezérli a fejléc összeállítást, egy segédmodul eközben kiszámolja a fejléc ellenőrzőösszegét, majd a Serializer sorosítja, és ProtoLayer PCI bementére adja az adatot. Fogadási oldalon egy elő feldolgozó modul ellenőrzi a fejléc ellenőrzőösszegét, és a sávon kívüli jelzésre alkalmas User_In bemenetre adja az IP fejlécet kijelölő és az ellenőrzőösszeg érvényességét megadó jelet, amit a kimeneti oldalon lévő állapotgép figyel a vezérlési kimeneten. Ha vége az IP fejlécnek, és érvényes az összeg, illetve nem töredék a csomag, akkor CTRL_FWD jellel továbbítja a felsőbb réteg felé, ha nem, akkor CTRL_DROP_ERR jel segítségével eldobja azt. Az IPLayer modul implementációs blokkvázlatát a 29. ábra szemlélteti.
70
ARP interfész SDU adat be és vezérlőjelek EtherLayer interfész PDU ki adat és vezérlőjelek
Adási állapotgép
IPCAM és RAM
DSTIPAddr,SRCIPAddr, Protocol,Length bemenet
ProtoLayer Vételi előfeldolgozó PDU be adat és vezérlőjelek
PCI adat be és vezérlőjelek
Előfeldolgozott adat és vezérlés
PCI adat ki és vezérlő-jelek
IPLayer
PCI Regiszter
EtherLayer interfész
Serializer
Ellenőrző összeg számítás
SDU adat ki és vezérlőjelek
Vételi állapotgép DeSerializer
MiniCAM
Konfigurációs modul és regiszterek
Konfigurációs interfész
DSTIPAddr,SRCIPAddr,Protocol, Length kimenet
29. ábra IPLayer implementációs blokkvázlat
4.1.8 UDPLayer modul Az UDP-t az előzetes specifikációnak megfelelően implementáltam, azzal a megszorítással, hogy csak a link MTU-nyi, azaz 1500 bájtos csomagokat tud kezelni. Ez abból fakad, hogy az ellenőrzőösszeget az egész szállított szolgálati adatelemből kell számolni, így a vétel esetén szükség van egy bemeneti elő-feldolgozóra, ami tartalmaz egy PDUQueue modult. Ha a vett ellenőrzőösszeg hibás, akkor a ProtoLayer előtti bemeneti sorból már nem kerül át a csomag további feldolgozásra. Adás estén ezt a tárolást a ProtoLayer küldési részének SDU sora végzi. Az implementáció követi a kidolgozott paradigmát, alkalmazza a Serializer, a DeSerializer és a MiniCAM modulokat, a már többször vázolt struktúrában. Főbb különbség, hogy mind adási, mind vételi irányban használja a ProtoLayer kiegészítő sorait az IP címek és a hossz továbbításához. A tárgyi modul megvalósítását a 30. ábra illusztrálja.
71
SDU adat be és vezérlőjelek
IPLayer interfész adat
PDU ki adat és vezérlőjelek
Adási állapotgép
ProtoLayer IPLayer interfész be
PDU be adat és vezérlőjelek
Vételi előfeldolgozó
PCI adat be és vezérlőjelek
SDU adat be
Ellenőrző összeg számítás
SDU adat ki és vezérlőjelek
Vételi DeSerializer állapotgép
UDPLayer
PSZ. fejléc
Serializer SrcIPAddr,DstIPAddr kimenet
Előfeldolgozott adat és vezérlés
PCI adat ki és vezérlő-jelek
PCI Regiszter
IPLayer interfész ki
DSTIPAddr,SRCIPAddr, DstPort,SrcPort,Length bemenet
Konfigurációs interfész
MiniCAM (Port ell.)
DstPort,SrcPort,Length kimenet
30. ábra UDPLayer implementációs blokkvázlata
4.1.9 SNMP modul Az SNMP implementációjában szintén alkalmaztam a konfigurációs címmel kiválasztott
írási
megoldást,
hasonlóan
ahhoz,
amit
az
IPLayer
modulban
implementáltam. Mivel itt is több konfigurálható paraméter van, ezzel a megoldással lehet csökkenteni az interfészjelek számát. A konfiguráció címek hozzárendelése a forrásfájl deklarációs részénél megtalálható, és a konfigurációs eljárásra példát a szimulációs fájlban, és a megvalósított rendszer inicializációs szkriptjében lehet találni. Konfigurálandó értékek: az ágens IP címe, és az UDP forrás portja, valamint a menedzser IP címe és célportja, ami a gyakorlatban SNMP Trap esetén a 162 –es UDP port. A feladat megvalósításához kétféle PDU szerkezet szükséges: egyik, amelyik a vállalat-specifikus üzeneteket hordozza, és egy, amelyik a linkeseményekkel kapcsolatosakat. Az előbbi PDU nulla darab változó hozzárendelést tartalmaz, mivel az információt a Trap PDU SpecificTrap mezeje hordozza, e szerkezetet megvalósító jelek és modulok az _Event postfixet kapták a kódban. Az utóbbi esetében a változó hozzárendelési listában két változó is továbbításra kerül: az egyik a 1.3.6.1.2.1.2.2.1.1.X OID-vel, ahol X az interfész indexét jelöli és 1-től 255-ig terjedhet, mivel 1 bájton került ábrázolásra; a másik pedig 1.3.6.1.2.1.2.2.1.2.X OID-vel, ahol X szintén az interfész indexet jelöli. A 1.3.6.1.2.1.2.2 az SNMP MIB-2 -ben definiált interfészkehez kapcsolódó csomópont alatt, az interfésztáblát jelöli (ifTable), az utána lévő .1-es csomópont az ifEntry-t jelzi. Az ifEntry utáni .1 és .2 rendre az ifIndex és az ifDescr 72
csomópontot jelöli a MIB-ben. Mivel ez egy táblázat, ezért ezután még szükség van az interfész indexére, amit az előbbiekben leírt X változó ad meg. Az ifIndex a MIB definíció alapján egész, míg az ifDescr DisplayString, azaz olyan OCTET_STRING, amely csak nyomtatható karaktereket tartalmaz. Tehát az implementációban a modul változóként elküldi az interfész sorszámát, míg a leírásban szöveges formátumban „ethX” karakterláncot, ahol X szintén az interfészt jelöli, azonban itt az indexelés 0-tól kezdődik. A modul alkalmazza az eddig jól bevált paradigmát: a két jelregiszter két Serializer párhuzamos bementére megy. A kétféle Trap generálásához két állapotgép tartozik, mindegyik a saját sorosító egységét vezérli. A kimeneten arbitrátor található, és így kapcsolódik a modul kimeneti interfészéhez. A coldStart és a warmStart Trap küldést az Event állapotgép valósítja meg, mivel ezek szintén generikus trapek, amiknek nem szükséges változó hozzárendelést tartalmazniuk. A trap PDU-ba szükséges még úgynevezett TimeTick-et küldeni, ami az eltelelt századmásodpercek számát jelzi valamilyen kitüntetett esemény óta [16]. Ez úgy lett megvalósítva, hogy a modul felprogramozáskor 0-ra inicializálja a 32 bites számlálót, és ekkor generálódik egy coldStart trap is, ami 0-s TimeTick-kel kerül elküldésre, majd ezt a számlálót minden századmásodpercben növeli a modul, függetlenül az engedélyező jel értékétől. A további reset jelek nem nullázzák az időszámlálót, és a reset hatására az állapotgép warmStart Trap-et küld. A vállalat-specifikus esemény hatására kiváltott Trap-ek az EventIn bemeneti vektort alkotó logikai jelek felfutó élére kerülnek küldésre. A kisebb sorszámú a fontosabb, tehát kvázi-egyidejűség esetén, azaz, ha ugyanazon órajel esetén több helyi értéken is 1-esbe áll 0-ról a bemenet, akkor először a legkisebb sorszámú Trap fog elküldődni, majd így szépen sorban a magasabb sorszámú felé, amíg el nem fogy a bemeneti esemény. Ez a struktúra és viselkedés jellemző a linkállapot kezelésre is, csak ott a másik állapotgép állítja össze az SNMP PDU-t. A linkállapot bemenethez érdemes megjegyezni, hogy a linkDown Trap-et a 0-1 átmenet jelzi, míg link státusz akkor lesz ismét normális, és kerül elküldésre a linkUp trap, ha a megfelelő bementi pozícióban volt 1-0 átmenet. Azaz a link szakadt állapotát aktív magas logikai érték, míg az üzemszerű állapotát az alacsony logikai érték jelzi, ezt a felhasználáskor figyelembe kell venni.
73
A vállalatot azonosító OID az implementációban az experimental részfa alól választottam ki önkényesen, de ezt a kódban jól megjelölt helyen könnyedén át lehet írni, ugyanúgy, ahogy az azonosításhoz szükséges Community String-et is, amit az implementációban az ipari konzulensem vállalatának neve alapján AitiaINC-nek rögzítettem. A 31. ábrán az SNMP modul megvalósítási vázlata tanulmányozható.
Serializer Soros SNMP Event Trap üzenet
Arbiter
Kimeneti adat és vezérlőjelek
SNMP Event PDU Regiszter
Esemény állapotgép
Esemény regiszter
Linkállapot állapotgép
Esemény regiszter
Esemény Bemenet
Arbiter vezérlőjelek SNMP Link PDU Regiszter
Serializer Soros SNMP Link Trap üzenet
SNMP Modul
Linkállapot Bemenet
31. ábra SNMP modul implementációs blokkvázlata
4.2 Mérési jegyzőköny és eredmények Mérést végezte:
Janky Ferenc Nándor Kródi Gábor
Mérés helye:
Aitia International Zrt., 1039 Budapest, Czetz János u. 48-50.
Mérés időpontja:
2013.05.15
Méréshez használt eszközök:
GPlanar kártya, S/N: ProtoType-2, Feltöltött firmware: a diplomaterv mellékleteként benyújtott kódból fordított bitfájl. 2 db 1000BASE-Ts SFP modul behelyezve, az 1-es foglalatban 3COM 3CSFP93-as típusú, S/N: L1WPB36039080. a 0-s foglalatban Finisar FCLF-85203 as, S/N: PMQ1NM9
TP-Link TL-SG 1008v6.5 GigaBit Ethernet Switch, S/N:1226130076
74
DLink
DES-1008D.G2
10/100
FastEthernet
switch,
S/N:B21K645024462
TP-Link WA-801ND Wireless N Access Point, S/N:N/A
Lenovo ThikPad Edge E430 notebook, Windows 7 Enterprise Service Pack 1
Desktop PC, Windows XP Professional Service Pack 3
Mérési elrendezés a 32. ábrán részletesen tanulmányozható. A GPlanar kártya 0s interfésze össze lett dugva a gigabites switch 5-ös portjával. A két switch közötti összeköttetés létrehozása után a 10/100 switch-hez csatlakoztatva lett a laptop, ami a mérés során átjáróként funkcionált a 10.10.0.0/24-es és 10.0.0.0/24 -es alhálózat között. A fizikai interfészek statikus IP cím konfigurálása után ezt a Windows regisztrációs adatbázisának HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\ Parameters\IPEnableRouter paraméterének 0x00000001 értékűre állításával lehetett elérni. A kvázi-router vezetékes és vezeték nélküli interfészén is indítottam egy Wireshark capture-t, így az átmenő forgalom teljesen monitorozott volt. Az SNMP menedzserként funkcionáló asztali számítógépen szintén indítottam egy Wiresharkos monitorozást, és emellett elindítottam a WebNMS SNMP utilities Trap Viewer alkalmazását. A community-t beállítottam AitiaINC-re, mivel a kártya ezt használva küldi a Trap-eket, majd a Start gomb megnyomásával elindítottam a Trap figyelést. Ezt követően a GPlanar kártyán lévő FPGA-t felprogramoztam, és a ChipScope library-n alapuló kliensszoftver segítségével felkonfiguráltam a modulokat a mellékletben megtalálható inicializációs szkripttel. Ez a szkript reseteli a modult, aminek hatására a coldStart Trap máris kiküldődött. Emellett, mivel első indulás volt, a linkállapot regiszter észlelte az 1-es bemenet LOS jelét, így egy linkDown Trap is kiment a menedzser felé. Ezután egy resetet adtam a modulnak, ekkor egy warmStart Trap érkezett, amiben a TimeTick már nem 0 értékű volt, hanem az első indítás óta eltelt századmásodperceket mutatta.
75
A FPGA-n levő firmware 2 link és 32 esemény figyelésére rögzített generikus paraméterekkel lett lefordítva. A mérést ezután az SNMP modul EventIn bementének 0x00000000-ről 0xFFFFFFFF-re egyszerre történő átállításával szimuláltam 32 egyidejű bemeneti eseményt, aminek a hatására a modul elkezdte küldeni a vállalat specifikus Trap-ek, a Trap-eket az összes megfigyelési ponton ellenőriztem, ezekben a specificTrap értéke rendre 0-tól 31-ig változott. A linkállapot változást a kártya 1-es portjának egy fel nem használt egyéb Ethernet portba dugdosásával értem el. Kihúzások esetén a diplomatervvel kapcsolatos elvárásoknak megfelelően érkezett a linkDown trap, míg a bedugás esetén a linkUp trap. A változó hozzárendelési listát az összes megfigyelési ponton ellenőriztem, beleértve az TrapViewerben is, természetesen a linknek megfelelő azonosítóval érkezett, és a karakterlánc is megfelelő volt az ifDescr értékeként. A mérési eredmények alapján kijelenthető, hogy az FPGA-val megvalósított SNMP Trap üzenetküldés megvalósítása tehát funkcionálisan megfelel az elvárásoknak.
76
32. ábra A mérési elrendezés ábrája
77
IP cím: 10.0.0.112/24 MAC cím: 6c:f0:49:78:0d:09 SNMP Manager SW: WebNMS SNMP utilities – TRAP viewer SNMP Trap port: 162 + Wireshark Monitorozás
Port 1
Port 5
TP-Link TL-SG 1008v6.5
Port 1
Lenovo ThikPad Edge E430 +Wireshark monitorozás
DLink DES-1008D.G2
Port 2 Port 3
Port 7
IP cím: 10.10.0.254/24 MAC cím: B8:88:E3:E2:01:39
IP cím: 10.0.0.78/24 MAC cím: 08:3E:8E:A2:7A:A3
Irodai Ethernet szegmens
TP-Link WA-801ND SSID: AITIA-TARGYALO
IP cím: 10.10.0.11/24 Alapértelmezett átjáró: 10.10.0.254/24 MAC cím: 00:11:22:33:00:0b SNMP Manager: 10.0.0.112:162 UDP SNMP Agent port: 162
A mérési eredmények igazolják, hogy a modul a specifikációnak megfelelően működik. Ezzel egyúttal azt is igazoltam, hogy a megtervezett keretrendszer alkalmas különféle protokollok megvalósítására, hiszen az SNMP modul csak egy a megvalósított öt protokoll közül, és közvetlenül csak az UDP implementációval áll kapcsolatban. Azonban mindegyik protokollt implementáló modul a réteges szerkezetnek megfelelően csak a vele közvetlen kapcsolatban álló rétegekkel kommunikál, így igazodik az ISO/OSI modellhez, ebből adódik, hogy már egy sikeres SNMP PDU elküldésnek a szükséges feltétele, hogy az összes alsóbb szintű protokoll megfelelően működjön, de a mérés során nem egy, hanem számos üzenet elment, és minden tervezett funkció sikeresen működött. A Wiresharkkal elkapott csomagokban szépen látszik a működés, minden UDP csomag megfelelő ellenőrzőösszeggel érkezett. Az IP csomagok célcíme a 10.0.0.112 volt, ami az SNMP modulban megadott menedzser IP címe. Az IP csomag kiküldése előtt, mivel a menedzser nem a helyi alhálózaton volt, ezért az IPLayer modul az alapértelmezett átjáró felé küldte a csomagot. Ehhez az ARP modult vezérelve ARP kérést küldött az átjárónak, hogy megtudja a fizikai címét, majd az összeállított IP csomagot átadta az Etherlayer-nek, úgy hogy a cél fizikai cím az átjáró fizikai címe volt. Az EtherLayer összeállította a MAC keretet, majd a GMII interfészen keresztül kiküldte azt. A mérési eredmények megtalálhatóak a beadott mellékletek között.
78
5 Összefoglalás és további célok A diplomaterv kiírásban a cél egy általánosított módszertan kialakítása volt protokollok FPGA-n belüli megvalósítására, valamint a módszertan validálása az SNMP protokoll részleges implementációjával. Az OSI referencia modell kiváló igazodási alapként szolgál a feladat megoldásához, mivel ennek alapelvei között szerepel, hogy alapjául szolgáljon a rendszerek összekapcsolását szolgáló szabványfejlesztési irányoknak. A diplomamunka kapcsán megtervezett keretrendszer VHDL nyelven leírásra került. A rendszer követi az OSI modell alapelveit, eszköztárat biztosít a PDU és IDU általános kezelésére és egyéb protokoll adatelem kezeléshez szükséges feladatokhoz is megoldást kínál, ezzel elősegítve tetszőleges protokoll implementálását. A célként kitűzött alkalmazás-rétegbeli SNMP parciális implementációja, és annak működéséhez (és így a validáláshoz is) szükséges alsóbb rétegbeli, legelterjedtebben használt protokollok is megvalósításra kerültek a munka során. Ezek a protokollok az IEEE 802.3 MAC részének full-duplex működési módja, az Ethernet-tel és IPv4-gyel kompatibilis ARP protokoll, az IPv4 részlegesen (kihagyva a tördelést és az opciók kezelését), valamint az UDP protokollok voltak. A keretrendszer amellett, hogy a célnak megfelelően működik és végzi a dolgát, még sok helyen optimalizálható, így akár még hatékonyabb működés is elérhető vele. A protokoll implementációk esetén is van lehetőség javításra, például az ARP modulban egy kisméretű tábla adminisztrálása, akár a keretrendszer részeként megtalálható MiniCAM modullal, akár egy elemű regiszterrel, mivel ez meggyorsítaná a hálózati címfordítást. A keretrendszer működőképességét a munka végén mérésekkel igazoltam. Ez alapján az elkészített modulok a kitűzött specifikációnak megfelelően működnek, ezzel igazolva a kidolgozott modellt és architekturális mintát. Ezzel a Diplomatervezés I. és II. tárgy kapcsán a diplomatervezési feladatkiírásomban szereplő összes feladatot elvégeztem.
79
Irodalomjegyzék [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18]
[19] [20]
ISO/IEC 7498-1, Information technology - Open Systems Interconnection Basic Reference Model: The Basic Model, 1994 http://www.erg.abdn.ac.uk/~gorry/course/images/primitives.gif, 2012.12.03, Szolgálati primitívek ábra http://www.6test.edu.cn/~lujx/linux_networking/images/0131777203/graphics/0 3fig04.gif, 2012.12.02, ISO OSI adatelemek ábra http://baluinfo.com/wp-content/uploads/2010/06/osi-model-.gif, 2012.12.02, ISO OSI rétegek R.Bush, D.Meyer, Some Internet Architectural Guidelines and Philosophy, RFC3439, 2002 IEEE Std 802.3, IEEE Standards for Local and Metropolitan Area Networks: Part 3, Section 1,p1-3, 2008 IEEE Std 802.3, IEEE Standards for Local and Metropolitan Area Networks: Part 3, Section 1,p46-55, 2008 IEEE Std 802.3, IEEE Standards for Local and Metropolitan Area Networks: Part 3, Section 1,p111-114, 2008 IEEE Std 802.3, IEEE Standards for Local and Metropolitan Area Networks: Part 3, Section 2,Clause 22,p9-23, 2008 IEEE Std 802.3, IEEE Standards for Local and Metropolitan Area Networks: Part 3, Section 3,Clause 35,p5, 2008 D.C.Plummer, An Ethernet Address Resolution Protocol, RFC826, 1982 Internet Protocol, DARPA Internet Program Protocol Specification, RFC791,1981 R.Braden,D.Borman,C.Partridge, Computing the Internet Checksum, RFC1071,1988 J. Postel, User Datagram Protocol, RFC768, 1980 J.Case,M.Fedor,M.Schoffstall,J.Davin, A Simple Network Management Protocol (SNMP), RFC1157, 1990 M.Rose,K.McCloghire, Structure and Identification of Management (SMI) Information for TCP/IP-based internets, RFC1155, 1990 K.McCloghire,M.Rose, Management Information Base for Network Management of TCP/IP-based internets, RFC1156, 1990 ITU-T Rec. X.690, Information technology – ASN.1 encoding rules:Specification of Basic Encoding Rules (BER),Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 2008 forrás: http://www.linux-france.org/article/gvallee/snmp/pdu.jpg, 2012.12.02, SNMP PDU szerkezetek ábra Vadims Podans, How to encode Object Identifier to an ASN.1 DER encoded string http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=13, 2012
80
