Inledning

Den här rapporten beskriver några intressanta ämnen som behandlades vid 44:e IETF-mötet i Minneapolis, 1999.

En del av uppgifterna är hämtade från de inspelade IETF-sändningarna och några från tillhörande Internet-Drafts som finns att tillgå via IETF’s hemsidor. Eftersom det många gånger varit svårt att ta del av den utsända informationen p.g.a. dålig bildkvalité, har det ibland lett till att helhetssynen försvunnit.

Jag har ägnat en hel del tid åt multicast-området, men även ämnen som MobileIP och Quality of Service och berörs.

Jag har tittat på skillnader med Ipv4 och Ipv6 protokollen då det gäller mobilitet, samt olika intressanta betalningsmetoder som UMTS kan erbjuda.

Dense-mode PIM som används för att minimera onödig multicast-trafik beskriv lite mer i detalj.

Multicast

Allmänt

Adressalokering vid användning av multicast-tjänster har tidigare fungerat relativt bra. Detta beror på till en viss del på att inte så stor del av Internet-användarna har haft möjligheten att utnyttja sig av dessa tjänster. Idag är situationen annorlunda. Trenden visar att allt fler kommer att vilja ut nyttja multicast vid olika typer av gruppkommunikation eller underhållning, vartefter tekniken byggs ut.

Adresser

För att inte adresserna ska ta slut bör möjligheten att allokera multicastadresser dynamiskt finnas. Den statiska tilldelningen är idag alldeles för kostsam med avseende till hur adresserna måste kunna fördelas.

Arbetsgruppen Multicast Address Allocation (MALLOC) arbetar med denna ovan nämnda möjlighet att kunna allokera adressser dynamiskt. Ett protokoll som för tillfället är intessant Multicast Address Dynamic Client Allocation Protocol (MADCAP). Protokollet hanterar dynamisk adressallokering som sker mellan klient och server.

Ett problem som kvarstår att lösa är TTL scoping. Det uppstår nämligen fel när TTL scoping ska tillämpas över större områden. Det diskuterades en del om MADCAP Scoope Nesting Option under MALLOC-mötet, en funktion som ska kunna hantera TTL scoping över större områden.

Multicast-träd

För att multicast-trafik ska kunna förmedlas till rätt användare måste ett multicast-träd sättas upp. När en ny användare ansluter sig till multicast-gruppen eller då en redan befintlig gruppmedlem väljer att lämna multicast-gruppen, kommer det att ske förändringar i trädstrukturen. Detta är något som är kostsamt att hantera och därför påverkar effektiviteten och kvalitén hos multicast-tjänsterna.

För att trädstrukturernas upprätthållandet ska kunna bestå krävs det att inblandade routrar besitter en viss tillståndsinformation. Just på den här punkten arbetar grupper från IETF mycket på och målet är att kunna minimera överflödig information som routrarna är tvingade att befatta sig med.

PIM- Protocol Independent Multicast

Dense-mode PIM 

Här nedan beskrivs lite om hur Dense-mode PIM hanterar multicasttrafik. Tanken är att minimera all onödig trafik som kan belasta olika nätverk vid sändning av datagram.

Dense-mode PIM förutsätter att alla mottagarna på resp. downstream är villiga att ta emot multicastdatagram, vilka källan sänder ut. Detta innebär att alla datagrammen inledningsvis breder ut sig på nätverkets olika delar, för att sedan med hjälp av en mekanism kunna avgöra om den aktuella delen av nätverket behöver ta del av multicasttrafiken eller ej.

Mekanismen som styr förfarandet kallas för prune state. Detta tillstånd kan vara prune off, vilket innebär att vidarebefordringsförfarandet är avstängt. Det finns en timer som efter ett specifikt tidsintervall aktiverar vidarebefordringen och då uppkommer det s.k. tillståndet forward state.

För att vidarebefordringarna ska hanteras effektivt utnyttjas trädstrukturer. Varje träd har en rot, source root, som når ut till alla medlemmarna i gruppen.

För att hantera broadcastmeddelanden som når ut till icke önskade delar av nätverket använder dense mode PIM en metod som kallas reverse path forwarding (RPF).

Jämförs PIM-DM med andra multicast routing protocol vilka använder en inbyggd mekanism för att utforska den närliggande topologin, så har PIM-DM en enklare uppbyggnad och är inte knutet något speciellt protokoll. Detta medför dock lite extra overhead och belastar i vissa fall belastas icke berörda delar nätverket, vilket kunde ha undvikits med mer vetskap om topologin.

Dense-mode PIM initierar några tillstånd hos en router när den källan börjar sända multicasttrafik. Detta innebär att routern är tvungen att kunna skapa en ingång för att kunna vidarebefordra trafiken om det inte redan finns tillgängligt. Informationen som behandlas är bl.a. källadressen, gruppadressen, utgående interface m.m.

För att en uppdaterad bild av omgivningen ständigt ska finnas tillgänglig hos resp. router sänds Hallo-messages ut med jämna mellanrum.

Reliable Multicast Transport

Under detta möte diskuterades strategier för att kunna standarisera Reliable Multicast, men målet var inte att komma fram till någon standard för tillfället.

Två fundamentala strategier för standardisering som berördes var följande:

• building-block approach
• whole-protocol approach

Det var skilda åsikter vad det gäller valet av strategi.

MBONE Deployment (mboned)

Här följer beskrivning av vad arbetsgruppen MBONE Deployment Working Group arbetar med.

Gruppen ska bl.a. agera som ett forum för att koordinera utvecklingen av multicast routing på Internet. Detta kan exempelvis innebära…

• granskning aktuella rapporter som behandlar utvecklingen av MBONE-teknologin och sedan själva producera sammanställningar som tar upp de olika erfarenheterna.
• utveckling av mekanismer ovh procedurer som tillverkar och upprätthåller en MBONE-databas över dess topologi.
• ta fram riktlinjer för användandet av multicast-adresser.

1. MRM manager – kontrollerar allting
2. Test manager – för analys av data
3. Test sender and test receiver – för rapportering av data

MobileIP

Mötet IP Routing for Wireless/Mobile Hosts WG

Inledandevis berördes Mobile IPv6 protokollet där bl.a dess nuvarande status behandlades. Nedan ges en beskrivning på olika skillnader mellan IPv4 och IPv6 som främst berör de mobila aspekterna.

Det trycktes mycket på vilka krav som ställs på MobileIP. En kvinna från Ericsson menade att de huvudsakliga kraven är MobileIP ska vara oberoende och uppfylla Quality of Service.

En del av tiden lades på att beskriva hur arkitekturen ska se ut. Mobilitetsmekanismen ska vara oberoende av vilken typ av nätverkstopologi som man ansluter sig till. Det är viktigt att begeppet mobilitet baseras på användaren och inte enheten som sköter tekniska biten.

Det talades även mycket om begreppen Home AAA Server och Proxy AAA. Vissa tveksamheter rådde vad det gäller olika lager vid tunnling.

Stor del av tiden lades på nya lösningar. Charles Perkins från Sun inledde med att beröra dynamiska adresser för MN och HA. Jag fick uppfattningen att dynamisk adressallokering av mobila noder är något som man vill kunna hantera för att på ett effektivt sätt kunna utnyttja IP-adresser.

Det uppkom stora diskussioner om privata adresser, vilket innebär att en mobil nod använder samma adress på olika nätverk.

För övrigt pratades det lite om identifiering och transparens.

Problem som finns att beakta är bl.a. hantering av brandväggar, handover och de svaga säkerhetsaspekterna. Sedan vill man även att Mobile IP ska utvecklas för cellulära system.

Skillnader mellan mobilitet i IPv4 och IPv6

IPv6 har ärvt många egenskaper från IPv4 när man tittar på mobilitetsaspekterna. Det finns dock flera nya egenskaper i IPv6 som erbjuder en bättre mobilitet för användarna. Nedan beskrivs några av skillnaderna mellan de båda versionerna.

• Route Optimization har byggts in i IPv6-protokollet med en bättre funktionallitet. Detta innebär att protokollet hanterar direkt routing mellan en godtycklig nod till en mobil nod utan att trafiken måste skickas via den mobila nodens hemnätverk för att sedan vidarebefodras av dess hemagent.

• Med IPv6-protokollet kan en mobil node nu använda sin co-address som källadress i IP-huvudet vilket underlättar filtreringsförfarandet hos de routrar som använder "ingress filtering".
• Användandet av co-address som källaadress i IP-paketen förenklar routing av multicast-trafik som den mobila noden kan tänkas sända. Dettta ska jämföras med IPv4-protokollet där den mobila noden är tvungen att tunnla multicast-trafiken till sin hemagent för att noden ska kunna använda sin hemadress på ett transparent sätt.
• Ipv6-protokollet använder sig av IPsec för att hantera olika säkerhetskrav. Så fungerar inte IPv4 som istället är beroende av sina egna säkerhetsmekanismer.
• I IPv6-protokollet tunnlar paket till sin mobila nod (som inte befinner sig på hemnätet) med hjälp av IPv6 Routing header hellre än att använd IP encapsulation som Ipv4 är tvungen att utnyttja. Resultatet blir att mindre overhead behöver sändas då IP Routing header används.

Quality of Service

Quality of Service är viktigt för att garantera användarna en viss kvalité på överförningarna. Det handlar ofta om att kunna överföra stora mängder information på en kort tidsperiod samt att det inte uppstår för mycket förluster som skapar omsändningar. Vid filöverföringar måste alla paket tas emot korrekt, medan vid ljud- och bildöverföringar ligger kravet mer på att dataströmmen är kontinuerlig.

Quality of Service är en viktig term som omnäms gång på gång inom flera arbetsområden. Speciellt när man pratar om tredje generationens mobiltelefonsystem (UMTS) kommer termen Quality of Service i fokus. Kraven på är där väldigt stora och det finns olika indelningar som behandlar Quality of Service på flera olika nivåer, olika serviceklasser.

Betalningsprinciper - UMTS

Något som säkert kommer att komma mer inom en snar framtid är nya metoder för att ta betalt av användarna. Idag betalar man oftast ett pris för hur länge man t.ex. har utnyttjat en uppkoppling mot Internet. UTMS erbjuder en rad olika modeller för hur en användare ska debiteras, dessa är:

• Time based charging – tidsbaserad, som dagens telefoni.
• Charging per service – beroende på vilken service som erbjuds.
• Flat rate charging – en fast engångsavgift.
• Quality of Service based charging – beroende på efterfrågad kvallité.