Den framväxande nästa generation routrar uppvisar både hög prestanda och rik funktionalitet, såsom stöd för virtuella privata nätverk och QoS. För att uppnå detta inkorporeras per-flow köande och snabb IP-filtrering i routerhårdvaran. Hanteringen av ett nätverk som omfattar sådana anordningar och en effektiv användning av den nya funktionaliteten medför nya utmaningar. Ett verkligt distribuerat näthanteringssystem är en attraktiv kandidat för att ta itu med dessa utmaningar. I den här artikeln beskriver vi hur aktiva nätverkstekniker kan användas för att möjliggöra snabb och enkel distribution av distribuerade nätverkshanteringsapplikationer i IP-nätverk. Vi beskriver ett prototypsystem där äldre routrar förstärks med en kompletterande aktiv motor, vilket möjliggör ett säkert utförande och snabb installation av nya distribuerade applikationer i nätverksskiktet. Detta system kan gradvis integreras i dagens IP-nätverk och möjliggör smidig övergång från IP till programmerbara nätverk. Detta görs med betoning på effektiv användning av nätresurser, vilket är något dunkelt av många av dagens lösningar på hög nivå. Den överväldigande majoriteten av IP-nätverkshanteringssystemen är centraliserade kring vissa ledningsstationer. Chefen frågar de hanterade objekten, bygger en vy över nätverket, och skickar varningar om ett problem upptäcks. Chefen kan också försöka vidta korrigerande åtgärder genom att skicka konfigurationskommandon till nätverksenheter. Det finns många nackdelar med en centraliserad arkitektur, som blir tydligare med tillväxten i nätverksstorlek och komplexitet. I takt med att antalet kontrollerade element ökar ökar också kraven på beräkningskraft från ledningssystemet och bandbredden från det nätverk som ansluter det. I ett stort nät är en del av de kontrollerade enheterna långt borta från ledningsstationen, vilket innebär att kontrollslingorna har långa förseningar och att trafikslöseriet är större delar av nätverksbandbredden. För att lindra skalbarhetsproblemen har distribuerade kontrollarkitekturer föreslagits under de senaste åren. De flesta av dessa lösningar delegerar några av de centrala förvaltningsuppgifter till distribuerade programvaruagenter eller fjärrobjekt. Användningen av distribuerade objektparadigm sammanfattar detaljerna i genomförandet. Abstractions, såsom Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM) och Remote Method Inokation (RMI), är till hjälp för att utforma och bygga distribuerade system, men de döljer den verkliga kostnaden för genomförande detaljer. Till följd av detta tenderar sådana distribuerade system i många fall att vara ineffektiva i sin användning av nätresurser, främst i sin användning av bandbredd. En annan nackdel med agentbaserade system är att denna typ av delegation inte stöder ett verkligt distribuerat agentsystem där agenter kan kommunicera med sina grannar för att effektivt utföra distribuerade uppgifter. Vår syn på nätverkshantering kräver en effektiv distribution av ledningsuppgiften i nätverket. En annan viktig fråga i distribuerade agentsystem för ledning och kontroll är var dessa agenter befinner sig. Det är uppenbart att detta har stor inverkan på prestandan eftersom det påverkar fördröjningen i kontrollslingan. I allmänhet, mjukvaruagent lösningar antar förekomsten av tillgängliga värdar för att köra sina program-nivå program. En optimal plats för en agent skulle finnas i routerkärnan, där all nödvändig lokal information finns tillgänglig, och åtgärder kan vidtas lokalt. En sådan lösning anses dock vara opraktisk på grund av oförmågan att störa routerns driftsbegränsningar i realtid. Det är tydligt att ju närmare det kontrollerade systemet agenten befinner sig, desto bättre kan den prestera. I detta arbete föreslår vi en arkitektur som gör det möjligt att enkelt distribuera distribuerade nätverkshanteringsapplikationer i IP-nätverk. Arkitekturen uppmuntrar till effektiv användning av nätverksresurser, men bibehåller fortfarande den enkla utvecklingen av tillämpningar. Vi använder det aktiva nätverket som ett ramverk som gör det möjligt att distribuera och genomföra nätverkshanteringstillämpningar i nätverkets routrar. I vår arkitektur består en nod av två logiska enheter: en vidarebefordrings-IP-mekanism och en allmän exekveringsmiljö som vi kallar den aktiva motorn (AE). Mekanismen för vidarebefordran av IP ansvarar för den uppgift som för närvarande utförs av IP-routrar, nämligen att vidarebefordra ett IP-paket enligt lokala tabeller. Den aktiva motorn är en exekveringsmiljö på användarnivå som komplement till vidarebefordringsmekanismen. Ett väldefinierat gränssnitt gör det möjligt för den aktiva motorn att både övervaka och styra speditionskomponenten. Denna arkitektur gör det möjligt för oss att samtidigt köra flera distribuerade nätverkshanteringsprogram. En session är en samling program (agenter) som injiceras i nätverket av auktoriserade användare och utförs i de aktiva motorerna. Agenterna kan migrera från nod till nod och kopiera sig själva. Agenter som tillhör samma session i olika noder kan samarbeta i sitt arbete genom att utbyta datameddelanden. Med hjälp av ett väldefinierat nätverksskiktsgränssnitt, nämligen en databas för hanteringsinformation (MIB), kan auktoriserade agenter samla in lokal information och kontrollera vidarebefordran. Andra programdistributionsmekanismer kan integreras också; i synnerhet kan populära program grupperas i bibliotek som kommer att vara en del av den aktiva motorn. Ett stort problem med att lägga till en distribuerad kontrollmekanism för IP är säkerhet och säkerhet. Ett system är säkert om ingen applikation kan förstöra eller skada korrekt utförande av andra applikationer. Ett system är säkert om alla operationer, inklusive åtkomst till data, autentiseras (dvs. endast auktoriserade sessioner kan utföra åtgärder och/eller komma åt privata data). I vår arkitektur uppnås säkerhet genom att separera exekveringsmiljön från vidarebefordringsmekanismen, och med hjälp av ett väldefinierat programprogrammeringsgränssnitt (API) mellan dem. Vår arkitektur använder flera säkerhets- och säkerhetsmekanismer, som diskuteras senare. En viktig fråga vid utbyggnaden av en skalbar distribuerad nätapplikation är adresseringssystemet som ska användas. Agenter bör naturligtvis kunna skicka meddelanden till en känd destination. Men i många fall känner agenterna inte till adresserna till fjärragenter som de vill kommunicera med. Detta kan bero på nätverkets storlek eller förändringar i nätverkets topologi. Namngivningssystem som de som används av CORBA kan bidra till att kommunicera i sådana scenarier, men kostnaden för att använda dem är hög och ofta oförutsägbar. Däremot använder vi ett mycket enkelt och effektivt adresseringsläge som gör det möjligt för agenter att skicka meddelanden till närmaste relevanta agenter. Den baseras på vidarebefordringsmekanismens förmåga att avlyssna särskilt märkta paket och omdirigera dem till den aktiva motorn. Den logiska separationen av routern gör att vi kan definiera en enhetlig miljö och API för förvaltningsprogram (agenter). Vår aktiva motor isolerar mjukvaruagenterna från den leverantörsberoende routern API. Det kan också hjälpa i analysen av algoritmprestanda. Fysiskt kan speditmekanismen och den aktiva motorn antingen befinna sig på olika maskiner eller på kärnsidan inuti samma låda. Denna struktur gör det möjligt att uppgradera alla kommersiella off-the-shelf IP (COTS) router till en nod i vår arkitektur bara genom att lägga till en kompletterande aktiv motor. Detta är en naturlig utvecklingsväg från dagens IP-nätverk till framtida hanterbara nätverk. Vi implementerade vår arkitektur och byggde en fungerande nätverksprototyp. Den aktiva motorn är främst skriven i C, och demonstreras på ett nätverk bestående av mjukvaruroutrar som körs på FreeBSD PC och COTS routers (för närvarande CISCO 2500) med en kompletterande aktiv motor. För närvarande stöder vi Java som programmeringsspråk för den aktiva koden, men arkitekturen är byggd med handtag för att tillåta användning av andra språk. Resten av artikeln är organiserad enligt följande. Vi ger en kort översikt över det system vi byggde. Vi diskuterar relaterat arbete inom nätverkshantering och aktiva nätverk. Vi beskriver systemarkitekturen och informationsflödet. Vi visar arkitekturkapaciteten med två exempel på genomförande. Vi diskuterar sedan det framtida arbetet och ger våra avslutande kommentarer. I detta avsnitt ger vi en allmän översikt över vår arkitektur. För bekvämlighetens skull använder vi aktiv nätverksterminologi. I synnerhet kallas vårt nätverk nod en aktiv nod, och paketen som bär agenternas kod och kommunikationen bland dem kallas aktiva paket (denna trafik kallas aktiv trafik). Som tidigare nämnts består en aktiv nod i vårt system av två enheter: en IP-router och en adjungerad aktiv motor (AE). IP router komponenten utför IP vidarebefordran, grundläggande routing, och filtrering som är en del av de funktioner som utförs av dagens COTS IP routers. IP-filtreringen möjliggör avledning av aktiva paket (eller andra paket som anges av en auktoriserad session) till den aktiva motorn. Den aktiva motorn är en miljö där kod inkapslad i aktiva paket kan köras. Denna kod kan ange hur kod och data relaterade till en specifik uppgift ska hanteras. En logisk distribuerad uppgift identifieras av ett globalt unikt nummer som kallas sessions-id (det unika id är en kombination av sessionsoriginatorns IP-nummer och ett lokalt tilldelat unikt nummer). När kod associerad med en icke-existerande session anländer, utförs den och skapar en process som hanterar alla paket av den sessionen. En sådan process kan antingen endast hantera ett enda datapaket och avsluta (kapsel), eller existera i AE under en lång tidsperiod, hantera många datapaket som krävs av många nätverkshanteringsprogram. För att utföra nätverkslageruppgifter måste sessionerna ha tillgång till routerns nätverkslagerdata, såsom topologiska data (grann-IDs), routingdata, prestandadata (packets tappade, paket vidarebefordrade, CPU-användning, etc.), och mer därtill. Vi använder Simple Network Management Protocol (SNMP) som gränssnitt mellan routern och AE. Standard SNMP-agenter finns i alla routrar och möjliggör ett läs-/skrivgränssnitt till en standard MIB. För att kunna utföra distribuerade uppgifter måste en aktiv nod kunna kommunicera med andra aktiva noder. Att upprätthålla fullständig topologiinformation vid alla noder skalas inte. För att ta itu med detta problem stöder vi ett topologi-blind adresseringsläge som gör det möjligt för en nod att skicka ett paket till närmaste aktiva nod i en viss riktning. Detta läge är användbart för topologi lärande, robust drift, stöd för heterogena (aktiva och icke aktiva) miljöer, och så vidare. Vi stöder också det explicita adresseringsläget där ett paket skickas till en specifik aktiv nod.  Den första generationen distribuerade näthanteringssystem använde delegering för att minska belastningen på ledningsstationen genom att göra det möjligt för förvaltaren att köra processer på avlägsna platser [1]. Detta paradigm har ett strikt föräldra-barn (eller klient-server) förhållande mellan chefen och dess agenter. Nästa generation använde CORBA för att hantera distribuerade uppgifter [2]. Senare, distribuerade objektinfrastrukturer som DCOM och Java RMI använder samma grundläggande idéer för objektkommunikation. De flesta agentbaserade system (inte nödvändigtvis för nätverkshantering) [3] befinner sig i tillämpningsskiktet och har därför inte tillgång till nätlagerinformation. Ett nytt första steg för att ta itu med behovet av agenter för att samverka med nätverkslagerinformation presenterades av Zapf et al. Denna förordning träder i kraft den tjugonde dagen efter det att den har offentliggjorts i Europeiska unionens officiella tidning. De tillät sina applikationsskiktagenter att få tillgång till routerinformation genom en mellanbaserad applikation i routern med hjälp av SNMP. Andra intressanta arbeten presenterades av Hjálmtýsson et al. Denna förordning träder i kraft den tjugonde dagen efter det att den har offentliggjorts i Europeiska unionens officiella tidning. De byggde ett system där installerade agenter kan manipulera dataströmmar i en router, och föreslog en ny router design. Även om Hjálmtýssons arbete liknade detta arbete, föreslog han en ny routerdesign som inte är lätt att använda i nuvarande nätverk. Det mesta av arbetet med aktiva nät [6] syftade till att ersätta dagens IP-paradigm och därmed förbises IP-baserade tillämpningar. Medan önskvärdheten av detta är diskutabel, vårt mål är att använda aktiva nätverk tekniker för att hantera IP-nätverk och gradvis förbättra dem med mogna aktiva nätverk tekniker. Liknande mål söktes i BBN Smart Packet projektet [7], som använder små enpacket skript för förvaltning program. Detta projekt begränsas av den lilla maximala programstorleken och bristen på mjukt tillstånd underhåll. I vår design separerar vi den aktiva motorn från routerspeditionsmekanismen. Ett liknande tillvägagångssätt rapporterades nyligen av Amir et al. [8] De begränsar dock omfattningen av sin aktiva server till tillämpningsnivån och begränsar därmed dess kapacitet. Bhattacharjee m.fl. [9] föreslog också ett liknande tillvägagångssätt, men för en mycket begränsad aktiv server som endast kan stödja en given uppsättning funktioner. I de flesta andra arbeten är de aktiva och icke-aktiva delarna inte väl åtskilda. Intressant nog undkom SNMP meddelandet om de flesta aktiva nätverksprojekt utom några (t.ex. [10] ). I allmänhet har större delen av forskningen på aktiva nät [6] inte lagt märke till behovet av att få tillgång till information på lokal nivå. Vi anser att användningen av SNMP är det mest attraktiva alternativet för att integrera aktiv nätverksteknik med befintliga routrar. Vårt mål är att utforma ett system som möjliggör enkel och snabb distribution av distribuerade nätverkshanteringsapplikationer. Följande principer vägledde vår design. Allmänhet och enkelhet -Byggande applikationer bör vara lätt för en stor bas av programmerare. Systemet bör därför inte begränsas till ett enda språk och bör stödja språk i allmänhet. Noden bör också vara allmän nog att stödja både långa - och kortlivade program. Modularitet -Vi delar in noden i moduler med ett tydligt definierat API mellan dem. I synnerhet valde vi att separera spediteringsmekanismen för en vanlig router från den driftsmiljö där paketen utförs. Vi använder också, så mycket som möjligt, väl accepterade standarder, såsom Java, SNMP, och Active Network Encapsulation Protocol (ANEP) [11], för API. Driftskompatibilitet och heterogenitet - Troligtvis kommer aktiva noder att samexistera med icke-aktiva routrar. Dessutom verkar stegvis införande av aktiva noder med samexisterande routrar vara en naturlig utvecklingsväg. I ett sådant scenario är det mycket osannolikt att ett program som körs på en aktiv nod uttryckligen kan känna till adresserna till sina aktiva grannar. Därför stöder vi "blind" adressering, där den aktiva noden inte behöver veta adress eller plats för andra aktiva noder. Nätverk Layer Interface -Det är mycket viktigt för ett program att ha enkel och standard tillgång till den lokala informationen på en nod, eftersom i många program de åtgärder som vidtas av paketet beror på denna information. Denna tillgång bör stödja läs- och skrivoperationer, eftersom en förvaltningsapplikation bör kunna vidta korrigerande åtgärder. Kostnadssynlighet -Även om vi vill sammanfatta de flesta av de tekniska detaljerna för att förenkla utvecklingen av applikationer, anser vi att tillämpningen måste vara medveten om kostnaderna, både när det gäller nodresurser (CPU, minne, etc.) och globala nätresurser (bandbredd och fördröjning). Därför använder vi inte avancerade distribuerade verktyg som CORBA och Java RMI, som i allmänhet döljer en stor del av den faktiska kostnaden för programmeraren. Säkerhet och säkerhet - Att lägga till ny funktionalitet bör inte påverka den befintliga nätverksdriften. Dessutom bör ett otillåtet program för hantering inte kunna påverka något annat program. Systemet bör stödja säkerhet och robusthet på alla nivåer. Mot bakgrund av ovanstående principer valde vi att använda den aktiva nätverkstekniken för våra behov. Denna teknik möjliggör en flexibel genomförandemiljö för hanteringstillämpningar, utan behov av att definiera nya protokoll och standarder. Detta resulterade i den arkitektur som beskrevs tidigare. Denna enkla modulstruktur stöder driftskompatibilitet och kräver inte att den specifika adressen för nästa aktiva humle är känd. Denna struktur möjliggör enkel stegvis utbyggnad i heterogena nät och är också robust eftersom ingen aktiv trafik inte kan påverkas av aktiv trafik. En viktig enhet i vår design är sessionen. Logiskt sett är en session en distribuerad uppgift som utförs i nätverket. En session har en unik nätverksID; därmed kan olika program på olika noder tillhöra samma session, och utbyta 141 information med aktiva datapaket. Detta begrepp om en session är tillräckligt allmänt för att stödja både långvariga processer och kortsiktiga kapslar. De fina detaljerna i konstruktionen beskrivs nedan. Systemets huvudkomponenter är ( Bild. 1): • Diverter -En del av routern som gör det möjligt att avleda paket till AE baserat på deras IP/UDP-huvuden. Den nya generationen högpresterande IP-routrar har detta alternativ implementerats som en del av router hårdvara [12]. Edge routers som hanterar lågbandsbredd länkar kan utföra denna funktion i programvara, som visas i vår prototyp. • Aktiv chef - Kärnan i AE är den aktiva chefen. Denna modul genererar sessioner, samordnar dataöverföring till och från sessioner och städar upp efter en session när den avslutas. Medan en session är levande, den aktiva chefen övervakar sessionsresursanvändning, och kan besluta att avsluta sin verksamhet om den förbrukar för mycket resurser (CPU-tid eller bandbredd) eller försöker bryta mot dess åtgärdsbehörigheter. • Säkerhetsflödesmodul -Den här modulen finns i kärnutrymme under IP-utmatningsrutinen. Varje anslutning sessionen vill öppna måste registreras med denna modul för att tillåta övervakning av nätverksanvändning av sessioner. Registreringen kommer att göras av våra levererade objekt, transparent för applikationsutvecklaren. Modulen är ännu inte helt implementerad. • Router-gränssnitt -Den här modulen gör det möjligt för sessioner att komma åt routern MIB. Det implementeras som ett Java-objekt som kommunicerar med routern med hjälp av SNMP. Vi arbetar för närvarande på att förbättra prestanda genom att caching populära MIB objekt. Designen gör det möjligt att implementera flera språk samtidigt, men eftersom den nuvarande implementeringen endast hanterar Javapaket kommer vi att begränsa beskrivningen till detaljer om Javaimplementationen. Genomförandet av andra språk kan kräva viss anpassning i enlighet med de språkspecifika kraven. Därefter beskriver vi flödet av paket genom systemet. Observera att ett icke-aktivt paket inte passerar genom AE, eftersom avsändaren känner igen det som sådant, och därför paketet tar snabbspåret till dess utgångsport. Alla aktiva paket inkluderar ett standardalternativ som innehåller paketets unika sessionsID, en innehållsbeskrivning (data, språk) med mera (Fig. 2).................................................................. Alla paket skickas till den aktiva managern. Om ett paket inte tillhör en befintlig session och innehåller kod, utlöser det skapandet av en session. Om det är ett datapaket kastas det och ett Internet Control Messages Protocol (ICMP)-liknande felpaket kan skickas. En sessionsskapande innebär bland annat autentisering (inte implementerad), skapande av ett kontrollblock för sessionen, skapande av en skyddad katalog för att lagra sessionsfiler, öppnande av en privat kommunikationskanal genom vilken sessionen tar emot och skickar aktiva paket och körning av koden. Fyra UDP-portnummer (3322-5) tilldelas aktiv nätverksforskning. I vårt system använder vi de två första på följande sätt. Den första, den blinda adressanpassningen, används för att skicka aktiva paket till ospecificerade noder i en viss riktning (dvs. mot någon avlägsen destination). Avsändaren i den första aktiva noden på rutten till den destinationen avlyssnar paketet och skickar det till AE. Avsändaren behöver därför inte känna till adressen till nästa aktiva nod. Det andra UDP-portnumret (den explicita aktiva porten) används för att skicka ett aktivt paket till en specifik aktiv nod. Detta paket vidarebefordras genom det snabba spåret av alla mellanliggande aktiva noder, och omdirigeras inte förrän det når sin destination. Eftersom vi förväntar oss att de flesta nätverksprogrammering ska vara stabila, försöker vi inte optimera kapselmodellen. Därför är vi mindre bekymrade över programstorleken, eftersom program inte kommer att sändas ofta. En mekanism för att återmontera ett program från en kedja av upp till 256 UDP paket genomförs för närvarande i AE.  Säkerhet och säkerhet är av stor betydelse för utbyggnaden av aktiva nät. Ett system är säkert om ingen applikation kan förstöra eller skada korrekt utförande av andra applikationer. I synnerhet bör AE som helhet inte leda till routing av icke-aktiva förpackningar. Ett system är säkert om alla operationer, inklusive åtkomst till data, autentiseras (dvs. endast auktoriserade sessioner kan utföra åtgärder och/eller komma åt privata data). Vår arkitektur stöder både säkerhet och säkerhet, även om den för närvarande inte är fullt genomförd. I varje design står man inför dilemmat att välja mellan friheten att tillåta mer sofistikerade sessionsbeteenden (t.ex. ställa in MIB-variabler, avleda icke-aktiva paket) och rädslan för ett möjligt säkerhetshål. Vårt tillvägagångssätt möjliggör flera säkerhetsnivåer via autentisering och sessionsklassificering. Varje session är auktoriserad att använda specifika tjänster (MIB-åtkomst för läsning eller skrivning, avleda icke-aktiva paket) och resurser (CPU-tid, bandbredd, minne). Eftersom det är viktigt att garantera både säkerhet och trygghet för att främja användningen av aktiva nät, kan man inledningsvis välja att vara mer restriktiv när det gäller att godkänna tjänster och gradvis tillåta mer sofistikerade tjänster. Vårt första bekymmer är att se till att icke-aktiva paket inte påverkas av aktiva paket. Detta uppnås lätt genom den logiska separationen av AE från routern. Där AE är en separat maskin och separationen är fysisk inte bara logisk, som vi förutser som den naturliga utvecklingsvägen för IP-nätverk, kommer inte ens en krasch av AE att påverka icke-aktiva data. Nästa steg i säkerheten är att se till att en session inte kommer att korrumpera eller ens peta på andra sessionsdata. Vi uppnår detta genom användning av Java SecurityManager. Det gör att vi kan styra sessionen kör miljö; i synnerhet förhindrar vi sessioner från att använda inhemska metoder och begränsa användningen av filsystemet. Skadlig eller felaktig överanvändning av systemets resurser är av stor betydelse. I detta syfte har vi för avsikt att övervaka användningen av CPU-tid genom sessioner. Vi införde sträng kontroll över användningen av kommunikationskanalen till omvärlden. TCP-anslutningar kan endast öppnas genom en tillåten session med hjälp av våra medföljande metoder som övervakar bandbreddsförbrukningen. Ett försök att använda Javametoder blockeras genom att kontrollera IP-lagret i AE. En otillåten anslutning kommer att släppas. UDP-paket kan endast skickas via managern, som återigen kan övervaka bandbreddsanvändningen. Vi byggde ett litet heterogent nätverk bestående av både FreeBSD-baserade aktiva routrar och COTS routrar (för närvarande använder vi CISCO 2500 routrar och Lucent Technologies RABU PortMaster3) med en kompletterande aktiv komponent. FreeBSD routrar är datorer som kör FreeBSD, med rutten för routing. I dessa datorer, AE och router coreside i samma maskin. Figur 3 visar den topologi som används för prestandamätningar. I byggandet av prototypen siktade vi på funktionalitet, inte prestanda. Därför var många delar av systemet inte optimerade för prestanda. Ändå testade vi kapaciteten hos vår prototyp. Därför bör fördröjningen av ett aktivt paket genom systemet behandlas som en övre gräns på vad som kan åstadkommas och lasten mäter som en lägre gräns. Vårt första experiment var att mäta s s Figur 2. fördröjning av ett aktivt paket genom en aktiv nod. För detta ändamål använde vi en session på Heshvan som vidarebefordrar varje paket den tar emot till destinationen på paketet. Java applikationer på tishrey och kislev (Fig. 3) byta UDP-paket med antingen blind adressering (diverterad vid heshvan) eller explicit adressering (skickad av Heshvans router). Paketen var ca 500 byte långa, och nätverket hölls utan ytterligare trafik för att förhindra köande fördröjning från att påverka resultaten. Den genomsnittliga restiden (RTD) för ett paket utan omdirigering var 1,37 ms. Det 90-procentiga konfidensintervallet är 1,37 ± 0,0047 ms, cirka 0,68 procent brett. Den genomsnittliga FoTU för ett paket med avledning var 11,20 ms. Det 90-procentiga konfidensintervallet är 11,20 ± 0,022 ms, ungefär 0,39 procent brett. Den genomsnittliga fördröjningen genom Heshvans aktiva motor var (11,2 -1,37)2 = 4,915 ms. Observera att Heshvan är en Pentium-maskin med 64 Mbytes minne som körs på 200 MHz. Det är uppenbart att AE-prestandan vid nätverkshantering begränsas av minnesåtkomsthastigheten, inte av processorns beräkningskraft. Vi gjorde inte ett fullskaligt stresstest, men upprepade ovanstående experiment med tio sessioner aktiva i Heshvan, och förseningen genom AE förändrades inte. Traceroute är en viktig nätverkshanteringsapplikation. Vi beskriver flera implementeringar av en generalisering av spårvägsprogrammet i [13]. Våra program kan samla in all tillgänglig nätverksinformation längs en rutt via SNMP. Dessutom kan programmet startas vid vilken nod som helst, inte nödvändigtvis på rutten, och rapporterna kan skickas till vilken värd som helst i nätverket. Olika implementationer syftar till att optimera olika kriterier, såsom att minimera termineringstid eller bandbredd overhead. En fullständig detaljerad beskrivning av genomförande- och resultatanalysen samt beskrivningar av andra tillämpningar, såsom flaskhalsdetektering och spridning av ad hoc-meddelanden, återfinns i [13]. Sedan starten av den aktiva nätverksidén har det gjorts en sökning efter "dödarapplikationen", den som starkt kommer att kräva aktiv nätverksteknik. Vi anser att nätverkshantering är en domän där aktiv nätverksteknik kan visa sig vara mycket betydelsefull. Applikationer som adaptiv kontroll, routerkonfiguration, elementdetektering, nätverksmappning och säkerhetshantering (inkräktardetektering, bekämpning av överbelastningsattacker) är bara några exempel där aktiv nätverksteknik framgångsrikt kan tillämpas. Vår arkitektur stöder också lösningar på andra problem som inte nödvändigtvis ingår i nätverkshanteringen, såsom sökmaskar, smart mail, multicast, hop-to-hop flödeskontroll med mera. Den ytterligare förseningen av paket i aktiva nät är en fråga som har tagits upp tidigare, och som andra har påpekat anser vi att den lilla avmattningen kompenseras av de stora besparingar som kan uppnås i trafikvolymen. I vår prototyp, icke-aktiva paket lider bara försumbar ytterligare fördröjning av divergeraren, och en rimlig fördröjning vid AE. Utformning och analys av algoritmer för en sådan miljö är ett viktigt problem. Vi tog ett första steg i denna riktning i [14].  REFERENSER
I ABLE REF-arkitekturen föreslås också separation mellan router och aktiv motor, SNMP används för att kommunicera dem, och "blind adressering" systemet erbjuder ett slags nätverkstransparens.
Active Networks for Efficient Distributed Network Management
{'venue': None, 'journal': 'IEEE Communications Magazine', 'mag_field_of_study': ['Computer Science']}