SE511812C2 - ADSL-transmissionssystem inkluderande router med proxy- funktion baserad på hantering av DHCP-meddelanden - Google Patents

Description

511 812 2 UI 25 b) UI Systemarkitekturen bör inriktas mot att åstadkomma ett minimum av protokolloverhead i alla de olika segmenten i end-to-end-arkitekturen.

Varhelst och närhelst det är möjligt bör standardiserade protokoll användas. Det torde vara möjligt att finna de erforderliga funktionerna inom det stora utbudet av för närvarande tillgängliga Internet-protokoll.

PPP-säkerhet är inte särskilt hög, därför bör användningen av PPP begränsas till att tillhandahålla enkel verifiering av destinationsval och redovisning (accounting). Ent-to-end-säkerhet bör tillhandahållas med andra medel.

Eftersom ADSL-teknologi är ny, bör den valda lösningen för ”ADSL Termination Unit Remote” (ATU-R), hållas så enkel som möjligt. Detta reducerar risken att välja funktionalitet i ATU-Rzen som slår fel och resulterar i en onödigt hög initialkostnad och möjligheten att ATU-Rzen kommer att behöva ersättas om den ej fungerar ordentligt.

Kravet på kundkonfigurering bör hållas på ett minimum.

Det finns naturligtvis ingen självklar lösning som uppfyller ovan nämnda kravlista. Om så vore fallet, skulle det redan finnas en konsensus, till exempel i ADSL Forum, när det gäller end-to-end-arkitekturen för system av denna typ. Om någon av de ovan nämnda faktorerna anses ha en högre prioritet än de övriga, blir uppgiften att projektera en lämplig arkitektur mycket enklare. Eftersom, emellertid, alla faktorerna är viktiga, är det nödvändigt att inrikta sig på att, så långt som möjligt, uppfylla alla kraven. Den 20 30 35 3 511 812 föreliggande uppfinningen föreslår en lösning när det gäller tillhandahållandet av ett multipel-värddator- /multipel-tjänst-scenario som uppfyller de listade kraven OVafl .

Det kan antas att PPP över ATM används i accessnätet.

Det finns två sätt att ge bredbandsanvändare access till multipel-tjänster, som t.ex. ISP:er, eller företagsinterna nät. En lösning är att ha L2TP-accesskoncentratorn (LZTP Access Concentrator), LAC:n, på en, eller flera, platser se A.Valencia draft ietf Den andra lösningen kräver för att ansluta kunder till olika tjänster, et al, ”Layer Two Tunneling Protocol ”L2TP"”, pppext-l2tp-10.txt, March 1998. användning av full L2~konnektivitet på begäran, dvs, ett nationellt, eller regionalt, kopplat (swithced) ATM-nät.

Ehuru detta är den lösning som har antagits för befintliga PSTN/ISDN-nät, implementeras i en nära framtid för det kopplade ATM-nätet. är det ej troligt att denna lösning kan LAC:n kan användas istället för en accessrouter eftersom den tillhandahåller L2-funktioner oberoende av L3- protokoll, adress-, dirigerings- och säkerhetssystem. Dessa system bör implementeras end-to-end mellan kunderna och deras ISP:er, eller företagsnät. LAC:n gynnar en generisk anslutning iven multitjänstleverantörsmiljö. Dess viktigaste funktioner är att ansluta kunder till deras rätta destinationer, och att tillhandahålla AAA- funktionalitet för L2-access och kärnnätresurser (core network resources).

Om kunder har ett ”Local Area Network” (LAN), eller ett hemnät som de önskar ansluta till ADSL-linjen, föreslår den föreliggande uppfinningen en lösning med antingen en separat fastighetsområdesrouter (premises router) och ATU- R, liknande den aktuella situationen för ISDN, eller en 511812 4 integrerad ATU-R och fastighetsomràdesrouter med den funktionalitet som beskrivs i det följande.

Eftersom hantering av lokala PPTP-, eller L2TP-tunnlar är en väsentlig uppgift, och användningen av sådana UI lösningar innebär en stor protokolloverhead, IP/PPP/LZTP/IP/Ethernet, och kontroll av tunnelarrangemanget, bör lokala tunnel-lösningar undvikas.

Istället föreslås att fastighetsomràdesroutern tjänstgör lo som en PPP-proxy å värddatorernas vägnar. Routern ansluter till ATU-Rzen genom ATM25-gränssnittet. Proxy-funktionen baseras på användning av DHCP-meddelanden som genereras från värddatorerna och överföring av den information som behövs av fastighetsomràdesroutern för att upprätta PPP- |5 sessionerna. Som kommer att framgå senare, kräver den föreslagna lösningen ej användning av NAT (Network Address Translator), se K. Egevang, P. Francis, ”The IP Network Address Translator (NAT)” RFC 1631, May 1994, som har fundamentala problem med att bryta end-to-end-modellen av 20 Internet-konnektiviteten och transporten. NAT är applikationsberoende och ej skalbar. Dessutom har den problem med att stödja säkerhets- och verifieringsprotokoll, som t.ex. IPSEC. Användning av NAT som PPP-proxy kräver att användarnamn och verifieringsinformationen för uppsättning av PPP-sessioner IJ UI matas in i NAT:en statiskt, eller dynamiskt, av http eller annat hjälmedel. Slutligen; NAT projekterades ursprungligen för att bevara publika IP-adresser, vilket ej är något krav i den miljö som involverar fleranvändar-/singeltjänst- 30 scenarier. Emellertid är NAT en lämplig lösning för fleranvändar-/singeltjänst-scenarier (t.ex. fast IP- access för företagsinïerna nät).

Enligt en första aspekt av den föreliggande uppfinningen tillhandahålles ett ADSL-transmissionssystem h! \J anpassat att stödja :illhandahållandet av s 511 812 telekommunikationstjänster till kunder på en multipel- värdator-/multipel-tjänst-basis, där nämnda ADSL- transmissionssystem inkluderar en LAC, och ett L2-kärnnät anpassat för anslutning till: ~ Internet-nätet via en ISP's LNS; - ett företags-LAN; och - ett flertal (plurality) kundterminaler; karakteriserat av att nämnda system inkluderar en fastighetsomràdesrouter och en ATU-R, anpassad att ansluta nämnda flertal kundterminaler, via en DSLAM, till nämnda LAC, där nämnda fastighetsomràdesrouter är anpassad att tjänstgöra som en PPP-proxy à nämnda kundterminalers vägnar, i vilken proxy-funktionen baseras på användning av DHCP-meddelanden genererade av nämnda kundterminaler, och överföring av information som nämnda fastighetsomràdesrouter behöver för att upprätta PPP- sessioner.

Nämnda fastighetsomràdesrouter och ATU-R kan vara integrerade, Nämnda fastighetsomràdesrouter kan vara ansluten till nämnda ATU-R genom ett ATM25-gränssnitt.

Kundterminaler kan tilldelas en lokal, privat adress när de är startas/laddas (booted).

Nämnda fastighetsomràdesrouter kan inkludera en DHCP- server, och nämnda lokala, privata adresser kan tilldelas av nämnda DHCP-server. 511 812 of 6 30 Kundterminaler kan anpassas att initiera upprättande av en VIP genom påverkan av en programstyrd tangent (soft key).

Nämnda kundterminaler kan anpassas att sända ett DHCPDISCOVER-meddelande som innehåller nämnda kundterminals FQDN, i DHCP-fältet DHCP-fältet ”authentication information field", ”host name", och en verifieringskod i till nämnda fastighetsomràdesrouter, för att upprätta en VIF.

Nämnda fastighetsområdesrouter kan anpassas att, vid få en IP- adress från en ISP och upprätta en PPP-anslutning till mottagning av nämnda DHCPDISCOVER-meddelande, ISP:n via nämnda LAC, där nämnda PPP-anslutning konfigureras mellan nämnda fastighetsområdesrouter och nämnda LAC, med användning av LCP, och sålunda etablerar en PPP-proxy.

Nämnda LAC kan anpassas att identifiera en destinations-LNS, baserad på nämnda kundterminals FQDN, och att kontrollera huruvida en L2TP-tunnel existerar, eller ej, mot LSN:en, och om ingen tunnel finnes, kan nämnda LAC anpassas att upprätta en L2TP-tunnel mot nämnda LSN.

Nämnda LSN och nämnda LAC kan arrangeras att förhandla om ett CALL-id för nämnda PPP-anslutning.

Nämnda L2TP-tunnel kan överföras på ATM, eller Frame- Relay.

Nämnda LNS kan anpassas att verifiera nämnda kundterminal med användning av CHAP, eller PAP, efter upprättande av nämnda LZTP-tunnel.

Uu lu un 30 v 511 812 Nämnda PPP-proxy i nämnda fastighetsomràdesrouter kan anpassas att ta emot en IP-adress från en ISP-domän genom IPCP.

Nämnda fastighetsområdesrouter kan anpassas att lägga till nämnda IP-adress till en vidarekopplingstabell (forwarding table) placerad i nämnda “ fastighetsomràdesrouter, där nämnda vidarekopplingstabell kan associera IP- och MAC-adresser till PPP/ATM VC:er, och nämnda fastighetsomràdesrouter kan anpassas att erbjuda nämnda adress till den kundterminal som utfärdade nämnda DHCPDISCOVER, och sålunda ge ett virtuellt gränssnitt, for nämnda kundterminal, en IP-adress som kan användas när datapaket skall sändas till nämnda ISP.

Nämnda fastighetsomràdesrouter kan anpassas att utföra vägval baserat antingen på nämnda IP-adress, eller på nämnda virtuella gränssnitt, för uppströms trafik.

For nedströms trafik kan nämnda fastighetsomràdesrouter anpassas att hämta IP-paket fràn PPP-paketen och sända dem i MAC-ramar till nämnda kundterminal, och en destinations-MAC-adress för MAC- ramarna kan hämtas/härledas från nämnda vidarekopplingstabell.

Nämnda kundterminal, eller nämnda L2-kärnnät, kan PPP-förbindelser, antingen nämnda LAC, eller nämnda LNS, kan anpassas att anpassas att koppla ned (tear down) och avsluta (terminate) overksamma PPP-förbindelser för vilka tidsovervakningstiden löpt ut (timed out).

Nämnda fastighetsomràdesrouter och nämnda LAC kan anpassas att utfora utformning av trafik (perform traffic shaping, när PPP-anslutningar förmedlas av CBR ?VC:er, och en VP kan upprättas mellan nämnda DSLAM och nämnda LAC. 511812 Nämnda fastighetsområdesrouter kan anslutas till nämnda ATU-R via ett ATM25-gränssnitt.

Nämnda ATU-R kan vara ett enkelt modem med ATM25- gränssnitt mot en kundterminalsida, och nämnda lll fastighetsomràdesrouter kan ha ett flertal Ethernet-portar.

En Ethernet-kontakt (plug) anpassad att därtill möjliggöra anslutning för ett flertal kundterminaler kan 10 tillhandahållas för varje abonnent.

Nämnda fastighetsomràdesrouter kan vara anpassad att tillhandahålla skikt 3-kundseparering med hjälp av brandväggar.

Nämnda VIF kan implementeras genom att skapa en andra anordningsdriver och en andra bindning till ett existerande nätgränssnitt. 20 Enligt en andra aspekt av den föreliggande uppfinningen tillhandahàlles ett ADSL-transmissionssystem, anpassat att stödja tillhandahållandet av telekommunikationstjänster till kunder pà en multipel- värddator-/multipel-tjänst-basis, där nämnda ADSL- 25 transmissionssystem inkluderar en LAC, och ett L2-kärnnät anpassat för anslutning till: - Internet-nätet via en ISP's LNS; ett företags-LAN; och u; Ö | ett flertal kundterminaler; karakteriserat av att nämnda system inkluderar en accessrouter som har samma funktionalitet so: u; k!! fastighetsområdesroutern i ADSL-transmissionssysteme: IJ Uu 35 9 511812 skildrat i nàgot av de föregående styckena, och en ATU-R, anpassad att ansluta nämnda flertal kundterminaler till nämnda LAC, där nämnda accessrouter är anpassad att tjänstgöra som en PPP-proxy à nämnda kundterminalers vägnar, där proxy-funktionen baseras pà användning av DHCP- meddelanden som genereras av nämnda kundterminaler, och som förmedlar information som krävs av nämnda fastighetsomràdesrouter för att upprätta PPP-sessioner.

För varje ATU-R-bryggning i nämnda ADSL- transmissionssystem kan nämnda accessrouter anpassas att implementera ett fjärrbryggsgränssnitt.

Nämnda accessrouter är anpassad att terminera Ethernet, och nämnda ATU-R är anpassad att utföra cellbuffring.

Enligt en tredje aspekt av den föreliggande uppfinningen tillhandahàlles i ett ADSL-transmissionssystem inkluderande en LAC och ett L2-kärnnät anpassat för anslutning till: Internet-nätet via en ISP's LNS; - ett företags-LAN; och - ett flertal kundterminaler; en metod att stödja tillhandahàllandet av telekommunikationstjänster till kunder på en multipel- värddator-/multipel-tjänst-basis karakteriserad av att ett flertal kundterminaler ansluts, via en en ATU-R och en DSLAM, LAC, där nämnda fastighetsomràdesrouter är anordnad att fastighetsomràdesrouter, till nämnda använda DHCP-meddelanden som genereras av nämnda kundterminaler för att överföra information som nämnda 10 511 812 30 fastighetsområdesrouter behöver för att upprätta PPP- sessioner, så att nämnda fastighetsområdesrouter tjänstgör som en PPP-proxy för nämnda kundterminaler.

En lokal, privat adress kan tilldelas varje kundterminal när nämnda kundterminal startas/laddas (booted).

Nämnda lokala, privata adresser kan tilldelas genom DHCP från en DHCP-server placerad i samma fastighetsområdesrouter.

En VIF kan upprättas som svar på påverkan av en programvarustyrd knapp på nämnda kundterminal.

Nämnda kundterminaler kan sända ett DHCPDISCOVER~ meddelande som innehåller nämnda kundterminals FQDN, i DHCP-fältet fältet fastighetsområdesrouter, "host name", och en verifieringskod i DHCP- ”authentication information field", till nämnda för att upprätta nämnda VIF.

Nämnda fastighetsområdesrouter kan, vid mottagning av nämnda DHCPDISCOVER-meddelande, och upprätta en PPP-anslutning till ISP:n via nämnda LAC, få en IP-adress från en ISP och nämnda PPP-anslutning kan konfigureras mellan nämnda fastighetsomràdesrouter och nämnda LAC, med användning av LCP, och sålunda etablera en PPP-proxy.

Nämnda LAC kan identifiera en destinations-LNS, baserad på nämnda kundterminals FQDN, och kan kontrollera huruvida en LZTP-tunnel existerar, eller ej, mot LSN:en, och om ingen tunnel existerar, kan nämnda LAC upprätta en LZTP-tunnel mot nämnda LSN.

Nämnda LSN och nämnda LAC kan förhandla om ett CALL-id för nämnda PP?-anslutning. 30 i "si *ëiíí i 11 Nämnda LZTP-tunnel kan överföras pà ATM, eller Frame- Relay.

Nämnda LNS kan, efter upprättande av nämnda L2TP- tunnel, verifiera nämnda kundterminal med användning av CHAP, eller PAP.

Nämnda PPP-proxy i nämnda fastighetsområdesrouter kan ta emot en IP-adress från en ISP-domän genom IPCP.

Nämnda fastighetsområdesrouter kan lägga till nämnda IP-adress till en vidarekopplingstabell (forwarding table) placerad i nämnda fastighetsomràdesrouter, där nämnda vidarekopplingstabell kan associera IP- och MAC-adresser till PF?/ATM VC:er, och nämnda fastighetsomràdesrouter kan erbjuda nämnda adress till den kundterminal som utfärdade nämnda DHCPDISCOVER, och sålunda ge en VIF för nämnda kundterminal en IP-adress som kan användas när datapaket sänds till nämnda ISP.

Nämnda fastighetsomràdesrouter kan utföra vägval baserat antingen på nämnda IP-adress, eller pà nämnda virtuella gränssnitt, för uppströms trafik.

För nedströms trafik kan nämnda fastighetsomràdesrouter anpassas att hämta IP-paket från PPP-paketen och sända dem i MAC-ramar till nämnda kundterminal, och en destinations-MAC-adress för MAC- ramarna kan hämtas/härledas från nämnda vidarekopplingstabell.

Nämnda kundterminal, eller nämnda L2-kärnnät, kan koppla ned PPP-förbindelser, och antingen nämnda LAC, eller nämnda LNS, kan avsluta overksamma PPP-förbindelser för vilka tiden för tidsövervakningen löpt ut (timed out). 511 812 12 Nämnda fastighetsomràdesrouter och nämnda LAC kan utforma trafik när PP?-anslutningar förmedlas av CBR PVC:er, och kan upprätta en VP mellan nämnda DSLAM och nämnda LAC.

Nämnda fastighetsområdesrouter kan tillhandahålla skikt-3-kundseparering med hjälp av brandväggar.

Nämnda VIF kan implementeras genom att skapa en andra l0 anordningsdriver och en andra bindning till ett existerande nätgränssnitt.

Enligt en fjärde aspekt av den föreliggande uppfinningen tillhandahàlles en fastighetsomrádesrouter för 15 användning i ett ADSL-transmissionssystem karakteriserad av att nämnda fastighetsomrádesrouter är anpassad att tjänstgöra som en PP?-proxy på uppdrag av kundterminaler i vilken proxy-funktionen baseras på användning av DHCP- meddelanden, genererade av nämnda kundterminaler och som 20 förmedlar information som nämnda fastighetsomràdesrouter behöver för att upprätta PPP-sessioner.

Nämnda fastighetsomràdesrouter kan vara integrerad med en ATU-R.

Nämnda fastighetsomràdesrouter kan vara anpassad för anslutning till en ATS-R genom ett ATM25-gränssnitt.

Nämnda fastigheïsomràdesrouter kan inkludera en DHCP- 30 server anpassad att generera lokala, privata adresser.

Nämnda fastighetsomràdesrouter kan vara anpassad att ta emot DHCPDISCOVER~:eddelanden sända av en kundterminal innehållande nämnda kundterminals FQDN, i DHCP-fältet ”host name", och en verifieringskod i DHCP-fältet ”authentication u: k) information field”.

IJ: Lu 11: ld511' 3:12: 13 Nämnda fastighetsområdesrouter kan vara anpassad att, vid mottagning av nämnda DHCPDISCOVER-meddelande, få en IP- adress från en ISP och upprätta en PPP-anslutning till ISP:n via en LAC.

En PPP-proxy för en kundterminal i nämnda fastighetsområdesrouter kan vara anpassad att ta emot en IP-adress från en ISP-domän genom IPCP.

Nämnda fastighetsområdesrouter kan vara anpassad att lägga till en IP-adress till en vidarekopplingstabell placerad i nämnda fastighetsomràdesrouter, där nämnda vidarekopplingstabell är anordnad att associera IP- och MAC-adresser till PPP/ATM VC:er, och nämnda fastighetsområdesrouter kan vara anpassad att erbjuda nämnda adress till en kundterminal som har utfärdat en DHCPDISCOVER, och sålunda ge ett virtuellt gränssnitt för nämnda kundterminal en IP-adress som kan användas när datapaket sänds till en ISP.

Nämnda fastighetsområdesrouter kan anpassas att utföra vägval baserat antingen pà en IP-adress, eller pà ett virtuellt gränssnitt, för uppströms trafik.

För nedströms trafik kan nämnda fastighetsomràdesrouter vara anpassad att hämta IP-paket från PPP-paket och sända dem i MAC-ramar till en kundterminal, och en destinations-MAC-adress för MAC- ramarna kan hämtas/härledas från nämnda vidarekopplingstabell.

Nämnda fastighetsområdesrouter kan anpassas att utforma trafik när PPP-anslutningar förmedlas av CBR PVC:er. 511 812 20 30 14 Nämnda fastighetsomràdesrouter kan anpassas att tillhandahålla skikt-3-kundseparation med hjälp av brandväggar.

Utförandeformer av uppfinningen kommer nu att beskrivas med hjälp av exempel med referenser till de medföljande figurerna i vilka: Figur l illustrerar, i schematisk form, den övergripande kommunikationsarkitekturen som den föreligggande uppfinningen avser.

Figur 2 illustrerar en händelsesekvens för upprättande av end-to-end-konnektivitet för kommunikationsarkitekturen som visas i Figur 1.

Figur 3 illustrerar end-to-end-protokollarkitekturen för den föreliggande uppfinningen.

Figur 4 illustrerar PPP-proxy i en accessrouter.

Figur 5 illusterar en gruppaccesslösning enligt den föreliggande uppfinningen.

Figur 6 illusterar ett entjänsts tjänstescenario.

Figur 7 illusterar policybaserat vägval baserat på kall-IP-adress.

Figur 8 illusterar virtuella gränssnitt på en router.

Figur 9 illusterar ett scenario med multi-tjänster per varddator. 35 5i11 812 15 För att bistå läsaren med att bättre förstå den föreliggande patentspecifikationen presenteras nedan en förteckning över termer som används i denna.

AAA ATU-R CHAP DHCP DNS DSLAM FQDN IPCP IPSEC ISP LAC LCP [-4 Z U) NÄT PA? m O w Authentication Authorisation Accounting ADLS Termination Unit-Remote Challenge Handshake Administration Protocol Dynamic Host Configuration Protocol Domain Name Service Digital Subscriber Line Access Multiplexer Fully Qualified Domain Name Internet Protocol Control Protocol IP Security Internet Service Provider L2TP Access Concentrator Link Control Protocol LZTP Network Server Network Address Translator Password Authentication Protocol Point Of Presence 511 812 16 PPP Point to Point Protocol PVC Permanent Virtual Circuit 5 QOS Quality of Service RADIUS« Remote Access Dial-in User Service SVC Switched Virtual Circuit 10 VBI Virtual Bridge Interface VIF Virtual Interface 15 VPN Virtual Private Network En lösning enligt den föreliggande uppfinningen för multipel-användar-/multipel-tjänst-scenariot kommer nu att beskrivas. Det antas, som tidigare framförts, att PPP över 20 ATM används i accessnätet. Det finns två sätt att ge bredbandsanvändare access till multipel-tjänster, t.ex.

ISP:er, eller företagsnät. Den lösning som används i den föreliggande uppfinningen är att få LZTP Accesskoncentrator (LAC) pà en eller flera platser att ansluta kunder till 25 olika tjänster.

LAC:n valjes istället för en accessrouter eftersom den tillhandahåller L2-funktioner oberoende av L3-protokoll, adress-, vägvals- och säkerhetssystem. Dessa planer bör 30 implementeras end-to-end mellan kunderna och deras ISP:er, eller företagsnät. LAC:n gynnar en generisk anslutningsbarhet i en multipel-tjänsteleverantörsmiljö.

Dess viktigaste funktioner är att ansluta kunder :ill deras ratta destinationer, och att tillhandahålla AAA- funktionalitet för L2-access och kärnnätresurser (core ga UI network resources).

I~J UI 30 17 511 812 Om kunder har ett ”Local Area Network” (LAN), eller ett hemnät som de önskar ansluta till ADSL-linjen, föreslår den föreliggande uppfinningen en lösning med antingen en och ATU- R, liknande den i dagens situationen för ISDN, eller en separat fastighetsområdesrouter (premises router) integrerad ATU-R och fastighetsomràdesrouter.

Fastighetsområdesroutern tjänstgör som en PPP-proxy på uppdag av värddatorerna, se Figur 1. Routern ansluter till ATU-Rzen genom ATM25-gränssnittet. Proxy-funktionen baseras på användning av DHCP-meddelanden genererade från värddatorerna och förmedlande den information som fastighetsområdesroutern behöver för att upprätta PPP- sessionerna. Den föreslagna lösningen kräver ej användning av NAT (Network Address Translator).

Figur l visar den end-to-end-kommunikationsarkitektur som den föreliggande uppfinningen avser. En, eller flera, PC:ar fastighetsomràdesrouter, vilken i sin tur är ansluten till (kundterminaler) ansluts till en en ATU-R via ett ATM25-gränssnitt. Fastighetsomràdesroutern kan tillhandahålla: - sändingsfiltrering (broadcast filtering); - effektivare access än en brygga; dvs färre paket att läsa; - PPP-proxy; - en DHCP-server för privata adresser; - en DHCP-proxy för ISP-tilldelade adresser; - enklare QDS-implementering; och 511 812 18 - brandväggs- och NAT-kapacitet, om så erfordras ATU-Rzen är ansluten till en DSLAM som utför VC- multiplexering och därefter via en ATM-switch till en LAC 5 och L2-kärnnätet. ISP-routrar, som ger Internet-access, och företags-LAN kan också länkas till L2-kärnnätet, via L2TP- nätservrar (LNS).

Vid systemstart (boot) tilldelas varje PC en lokal, 10 privat adress för intern kommunikation. Det privata adressutrymmet baseras på REC 1918, se Y. Rekhter et al.:”Address Allocation for Private Internets", RFC 1918, February 1996, och skall ej kollidera med det privata adressutrymmet som skulle kunna grupperas av företagsnät, 15 eller vissa ISP:er. Adressen kan tilldelas PC:n antingen manuellt, eller genom DHCP, se R. Droms: ”Dynamic Host Configuration Protocol", RFC 1541, October 1993. I det senare fallet implementeras en DHCP-server i fastighetsområdesroutern_ När en användare önskar ansluta 20 till en ISP, eller ett företagsnät, kommer steg (1) till (7) nedan, att utföras. Meddelandeutväxlingen som ingår i utförandet av dessa steg illustreras i Figur 2. 1. En användare klickar på ikonen pà den bordsdator som 25 representerar en anslutning till, till exempel, en ISP. Denna handling exekverar ett program som börjar upprätta ett virtuellt gränssnitt (VIF) i PC:n. IP- stacken blir komplicerad om PC:n redan har en VIF för någon annan tjänst. Scenariot med flera samtidiga 30 anslutningar till PC:n är knappast lämpligt ur säkerhetssynpunkt. VIF-implementeringsfrågor behandlas senare i denna specifikation. 2. Det virtuella gränssnittet behöver en IP-adress for dess konfigurering (ifconfig) i PC:n. Denna adress QJ u kommer att användas som en kall-IP-adress när paket 20 25 19 511 812 sänds över gränssnittet. För att åstadkomma detta, sänds ett DHCPDISCOVER-meddelande, se Figur 2, med användarens ”Fully Qualified Domain Name” - FQDN (t.ex. bill@telia.net) inkluderad i det valfria DHCP- fältet ”host name” och verifieringskoden i det valfria fältet ”authentication information field”. Dessa bàda fält definieras i RFC 2132, se S. Alexander; R. Droms: ”DHCP Options and BOOTP Vendor Extensions, RFC 2132", March 1997, respektive utkastet RFC om verifierade DHCP, se R. Droms: ”Authentication for DHCP-messages", draft-ietf-dhc-authentication-04.txt. August 1997.

Verifieringen var ursprungligen avsedd att användas för klientverifiering vid en DHCP-server, men fälten kan också användas för de ändamål som föreslås i den föreliggande uppfinningen. Inga tillägg till det aktuella DHCP-protokollet behövs.

Vid mottagandet av DHCPDISCOVER:n får fastighetsomràdesroutern, genom PPP, IP-adressen från ISP:n. Routern fungerar således som en DHCP-proxy för IP-adresser tilldelade från ISP:n. Routern upprättar en PPP-anslutning till ISP:n via LAC:n. Det använder den information som förmedlas i fälten som nämnts ovan. Först konfigureras PPP-anslutningen mellan routern och LAC:n med användning av LCP (Link Control Protocol).

LAC:n identifierar destinations-LNS:en (L2TP Network Server) baserad på användarens FQDN. Den kontrollerar sedan om det finns en LZTP-tunnel mot denna LSN.

Om detta är fallet, förhandlar LAC:n och LSN:en om CALL-id för PPP-anslutningen, se Figur 3, som illustrerar end-to-end-protokollarkitekturen för systemet i den föreliggande uppfinningen. Om det ej finns någon L2TP-tunnel, kommer en L2TP-tunnel att upprättas först. L2TP-tunneln kommer att överföras 511 812 20 antingen med ATM-, Frame-Relay-, eller annan överforingsteknolcgi. 5.' LNS:en verifierar sedan användaren baserat på CHAP, 5 eller PAP, se Figur 2. 6. PPP-proxyn i fastighetsomràdesroutern :ar emot en IP- adress från ISP-domänen genom IPCP (IP Control Protocol), se Figur 2. 7. Fastighetsomràdesroutern lägger först till IP-adressen till sin vidarekcpplingstabell som associerar (käll)IP- och MAC-adresser till PPP/ATM VC:er. Det erbjuder sedan adressen till den värddator som 15 utfärdade DHCPDISCOVER:n. Det virtuella gränssnittet for PC:n har nu en IP-adress som används när paket sänds till ISP:n, se Figur 2.

Protokollstackarna som arbetar i olika delar av 20 systemet illustreras i diagramform i Figur 3.

Kundterminalprotokollstacken inkluderar protokoll i övre skikt, som finns pà IP pà Ethernet.

Fastighetsområdesrouterstacken inkluderar IP som finns på Ethernet och PPP. PPP finns på AAL5 som finns på ATM och 25 det fysiska skiktet. I ATU-Rzen finns ATM som finns på det fysiska skiktet och ADSL. I DSLAM:en finns AIM som finns på ADSL och det fysiska skiktet, liksom är fallet med ASTM- switchen. I LAC:n finns PPP som finns på AAL5 och L2TP.

AAL5 finns på ATM och det fysiska skiktet, och LZTP finns 30 på IP och/eller ATM och/eller Frame Relay, där valet beror u: på den transmissionsteknologi som används mellan LAC:n och LNS:en. LNS:en har en protokollstack lämplig for den :ka LNS:en med LAC:n och transmissionsteknologierna for vidare överföring.

Sh: transmissionsteknologi som används för att 1 U1 -_\ 30 21 511 8'|2 Denna process, beskriven under hänvisning till steg (1) till (7) ovan, illustreras i Figur 4 för en arkitektur som använder en ATU-R som en fjärrbrygga.

Transmissionskedjan för uppströms meddelanden, som initieras av en användare som klickar på en ikon, dvs aktiverar en programstyrd knapp, startar med överföringen av ett DHCPDISCOVER-meddelande. Kedjan för nedströmsmeddelanden, som initieras som svar på DHCPDISCOVER-meddelandet, slutar med ett DHCPOFFER innehållande en IP-adresstilldelning av en VIP till en ISP.

För uppströmstrafiken kommer fastighetsomràdesroutern att utföra vägval antingen baserat på käll-IP-adressen (dvs policyvägval), eller baserat på virtuella gränssnitt pà routern. För nedströmstrafiken hämtar routern först IP- paketen från PP?-paketen, och sänder dem sedan i MAC- ramarna till värddatorn. Ramarnas destinations-MAC-adress överför den adress som hittats i routerns vidarekopplingstabell.

PPP-förbindelser bryts ned antingen av värddatorer, eller nätet. LAC:n, eller LNS:en, kan terminera overksamma PP-förbindelser vilkas tidsövervakningstid löpt ut. En värddator avslutar sin session genom att sända DHCPRELEASE- meddelandet som indikerar att det inte längre behöver dess IP-adress. Fastighetsomràdesroutern kopplar, vid mottagning av meddelandet, ned PPP-förbindelsen, associerad med adressen, genom att sända LCP Terminate Request- meddelandet. Meddelandet kommer att tas emot av LNS:en som svarar med ett Terminate-Response och utfärdar L2TP Call- Disconnect-Reply till LAC:n. Det senare utförs för att frigöra PPP:arna som tilldelats Call-ID i tunneln mellan LAC:n och LNS:en.

Fastighetsomràdesroutern och LAC:n terminerar, i detta kommunikationsscenario, ATM och AAL5, Se Figur 3. De 511812 22 utformar trafik om PPP-anslutningarna överförs av CBR PVC:er. LAC:n utför ej verifiering för varje PPP eftersom detta redan är utfört för deras underliggande PVC:er. Det använder endast FQDN för att identifiera destinationerna.

För att minimera besväret med att sätta upp individuella U: PVC:er genom ATM-nätet, kan en VP-förbindelse sättas upp mellan DSLAM:en och LAC:n. DSLAM:en utför sålunda VC- multiplexering. UBR-, eller CBR ATM-tjänsteklassen kan användas för PVC:erna. Om CBR används och PVC:erna hopar 10 sig på VP-förbindelser, per VC, måste utformandet utföras av LAC:n. Detta eftersom den hopgyttrade trafiken av utformade input-VC:er ej utformas eftersom celler från olika VC:er är sammanklumpade. 15 Det är möjligt att använda samma lösning som den ovan beskrivna, med en ATU-R som arbetar som en fjärrbrygga, se Figur 4, som illustrerar en PPP-proxy i en accessrouter.

All den beskrivna funktionaliteten hos fastighetsområdesroutern kommer då att vara placerad i en 20 accessrouter som fungerar som en PPP-proxy. Accessroutern kan vara antingen en fristående utrustning placerad emellan ATM-switchen och LAC:n, eller, mera sannolikt, integrerad i LAC:n. 25 För varje bryggad ATU-R implementerar accessroutern ett virtuellt brygg-gränssnitt. Utsända paket sprids uppströms mot accessroutern, tagande ADSL-bandbredd i anspråk och behandlas i accessroutern. Därför kanske detta tillvägagångssätt inte passar bra i fall där kunder har 30 många ?C:ar som använder PPP-accessproxy. Bryggskapande innebär mer utrustning och funktionalitet i accessnätet.

Det döljer också ATM QoS. Detta tillvägagångssätt kan emellertid vara av intresse för kunder med endast några få PC:ar anslutna till ATU-Rzen via Ethernet. u; 1/1 30 35 54 11f fffsf 1f2 23 ATU-Rzen stöder brygginkapslingsmode RFC 1483, se J.

Heinanen: ”Multiprotocol Encapsulation over ATM Adaption Layer 5, RFC 1483", July 1993. kommer att terminera Ethernet, kan nollinkapsling också Eftersom accessroutern användas för detta speciella kommunikationsscenario.

ATU-R:en måste utföra cellbuffring för att klara stora skurar som kan förväntas tas emot på Internetgränssnittet.

Det måste också utforma uppströmstrafiken om CBR utnyttjas.

För nedströmsriktningen erfordras buffring för Ethernetramning inkluderande AAL5's SAR (Segmentation And Reassembly). Accessroutern måste utforma per-VC om CBR används för PVC:erna.

Gruppaccess är en lösning där flera slutanvändare delar ett enda ADSL-modem. Ett sådant scenario kan vara av intresse i byggnader med flera våningar där ett nät används för att ansluta våningarna till ATU-R:en. Det kan erbjudas som en làgbudgetlösning för Internetaccess, eller som en bas för lokala operatörer som driver sin egen tjänsteplattform och önskar lägga till Internetaccess till de lokala tjänsteerbjudandena.

I denna lösning, som illustreras i Figur 5, ansluter fastighetsområdesroutern till ATU-Rzen genom ATM25- gränssnittet. Ett flertal kundterminaler länkas till Ethernet-terminaler, som tillhandahålles på ”en per- våning”-basis. Ethernetterminalerna ansluts till en fastighetsomràdesrouter, som i sin tur ansluts till en ATU- R. ATU-Rzen är ansluten till en LAC via en DSLAM och ATM- switch. Proxy-funktionen baseras på användning av DHCP- meddelanden som genereras av värddatorerna och överför den information som fastighetsområdesroutern behöver för att upprätta PPP-sessionerna. ATU-Rzen kan vara ett enkelt modem, företrädesvis med ATM25 som gränssnitt mot kundsidan. En lämplig router med det erforderliga antalet Ethernetportar ansluts till ATU-Rzen. En Ethernetkontakt 511 812 24 (plug) tillhandahàlles pà varje våning vilket gör det möjligt för användaren att ansluta en, eller flera, PC:ar till den dedicerade fastighetsområdesrouterporten, placerad i en låst låda någonstans i byggnaden, t.ex. i källaren.

Routern tillhandahåller skikt-3-separering av kunderna genom användning av brandväggar och fungerar som en PPP- Un proxy à värddatorernas vägnar. Värddatorerna använder angreppssättet med det virtuella gränssnittet som tidigare beskrivits.

För närvarande är tilldelning av IP-adresser icke- geografisk, och en värddator behöver sålunda inte vara fysiskt samlokaliserad med en domän för att vara del av den, men den måste ha en giltig IP-adress från denna domän. 15 Detta leder till slutsatsen att multipla IP-adresser måste tilldelas en värddator om denna värddator samtidigt tillhör multipel-domäner, såvida inte en NAT används, i vilket fall problemet överförs till NAT-boxen, som behöver ha adresser från multipel-domäner.

Lösningen på problemet att tilldela multipla IP- adresser till ett enda nätgränssnitt, Ethernet, eller ATM, är antingen att tillämpa alias-funktion, implementerad i Linux, eller att utnyttja begreppet virtuellt gränssnitt, VIF (Virtual Interface). VIF:en emulerar ett nätgränssnitt, lu Un annat än det fysiskt existerande gränssnittet, medan det fortfarande använder det fysiska gränssnittet för överföring. Detta gör det möjligt att ha multipla logiska nät på ett fysiskt nät. 1 VI -en kan antingen implementeras genom användning av ll en tunnel som skapar ett nytt IP-paket och sänder tillbaka det till IP-skiktet (IP/IP, IP/PTP/IP eller IP/LZTP/IP), eller genom att skapa en andra anordningsdriver och en andra bindning till det befintliga nätgränssnittet. Det u: \/ senare kommer ej att resultera i någon ökad 2 0 I J 'Ju v51x1” 812 25 protokolloverhead och är därför den lösning som föreslås av den föreliggande uppfinningen.

Det allmänna (generic) problemet med multipla virtuella gränssnitt hos en värddator är hur värddatorerna avgör vilken IP-adress som skall användas när de kommunicerar med en fjärrdestinationstjänst. Detta kan lösas antingen genom att utföra policybaserat vägval i värddatorns IP-stack, en lösning som knappast kommer att vara praktiskt genomförbar inom en rimlig tidsram, eller genom att utnyttja förmågan att specificera router i värddatorns vägvaltabell. Detta kan utföras med värddatorstackar som för närvarande används, och är därför den lösning som rekommenderas.

Det sätt på vilket den lösning som föreslås av den föreliggande uppfinningen löser de olika tjänstescenarierna inriktade på ADSL-spridningen kommer nu att beskrivas.

Om en värddator skall anslutas till en (single) fjärrtjänst, är lösningen mycket okomplicerad och detsamma gäller för ett scenario i vilket en enstaka värddator är ansluten till ett lokalt LAN, liksom också är fallet för ett scenario med en LAN-miljö med flera (multiple) PC:ar.

Vägvalstabellen och arkitekturen visas i Figur 6.

Metoden att upprätta gränssnittet och uppdatera vägvalstabellen beskrivs nedan. 1. Ett virtuellt gränssnitt tar emot en IP-adress såsom tidigare beskrivits. 2. Innan gränssnittet kan användas, måste vägvalstabellen modifieras för att kunna meddela IP-skiktet när paket S . _» lf vidarebefordras genom detta gränssnitt. Det A SD i llande programmet specificerat sedan den QX V k (ll IS (Il f 511 812 26 St) mottagna lokala IP-adressen (pri.va.te.gw) som default-gateway. 3. Slutligen specificerar den en ingång och anger att gatewayzen nås genom VIF:en (isp.pub.lic.host).

Figur 6 visar vägvalstabellen som länkar nätadressen, nätmasken, gateway-adressen och gränssnittsadressen för denna utforandeform. IP:n kan länka antingen till en VIF med använding av gränssnittsadressen isp.pub.lic.host, eller till en Etherdrive med användning av gränssnittsadressen pri.va.te.host. Data sänds sedan över Eth HW, till gateway pri.va.te.gw. en Ethernet highway, som i sin tur tillhandahåller länken till ISP PPP-länken.

Det finns emellertid två sätt att implementera bindningen i fastighetsområdesroutern. Det forsta är att tillämpa policybaserat vägval i routern och den andra är att använda virtuella gränssnitt på routern.

När policybaserat vägval används, kommer routern att vidarebefordra paketen till de olika PPP-rören baserade på IP-källadress. fastighetsomràdesroutern att skapa en bindning mellan För att åstadkomma detta kommer värddator-IP-adressen och PPP-sessionen vid tiden for PPP- upprättandet och DHCP-baserad adresstilldelning, se värddatorvägvalstabell visad i Figur 7.

Figur 7 visar två anslutningar, från värddator l och 2, via Ethernet-highwayzen till gatewayzen betecknad Både värddator l och värddator 2 arbetar Etherdrv. Emellertid pri.va.te.gw. v~~r~x .- _.. genom v- eller Etherdrive, tillhandahålles policy-vägval baserat på käll-IP-adress till en företags-PPP-länk, eller en ISP PPP-länk, via gatewayzen pri.va.te.gw. 2, 51 1” 912 Med ”virtual interfaces on router”-implementeringen, tilldelar routern individuella, lokala IP-adresser på fastighetsomràdesgränssnittet för att representera vart och ett av de olika PPP-rören mot det publika nätet. Den motsvarande lokala IP-adressen (pri.va.te.gwl/gw2) kommuniceras sedan till värddatorerna i DHCP~erbjudandet, se Figur 8.

Att konfigurera mer än en VIF på värddatorerna är ett avsevärt mera komplext problem. Emellertid måste en lösning finnas (be found) om det skall vara möjligt att nà multipel-tjänster från en singel-värddator.

Som tidigare beskrivits, kan de funktioner som behövs i värddatorerna för att bestämma vilken IP-adress som skall användas när de kommunicerar med en fjärrtjänst implementeras genom policybaserat vägval, eller genom att utnyttja förmågan att specificera vägar i värddatorvägvalstabellen. Det senare är möjligt med aktuella värddatorstackar och är därför den rekommenderade lösningen, se Figur 9, som visar användningen av tvà VIF:ar och en Etherdrive som innehåller adresserna crp.sub.net.host, isp.pub.lic.host, respektive pri.va.te.host2. Värddatorvägvalstabellen är inkluderad i Figur 9.

I detta fall behövs en explicit specifikation över vilka paket som skall dirigeras till företagsnätet (vi antar att ISP är defaultvägen). ISP:n bör användas för alla andra paket som sänds från värddatorn.

Eftersom PPP, enligt aktuell definition, inte kan användas för att kommunicera undernätsmasker, mäste värddatorkonfigurationen utföras manuellt, eller genom förinstallerad mjukvara. I båda fallen behöver' 511 812 28 lu Un företagsnätadministratörerna vara involverade för att specificera vilka undernät som tillhör deras företagsnät.

Det behöver emellertid inte vara absolut nödvändigt att stödja detta scenario, eftersom många företag ej accepterar samtidiga förbindelser till Internet-nätet och företagsnätet.-I-detta scenario behövs vissa säkerhetsimplementeringar i högre skikt för att tillfredställa nätansvariga för företagsnät.

Som framgår av det föregående tillhandahåller den föreliggande uppfinningen en en-to-end-arkitektur för kommunikationsscenariot med multipla värddatorer/multipla tjänster.

Den föreliggande uppfinnigen tillhandahåller en lösning för den funktionalitet som behövs i en fastighetsomràdesrouter. Ett viktigt inslag i det föreslagna angreppssättet med DHCP/PPP-proxy är att kundutrustning kan konfigureras automatiskt, eftersom ingen användarinformation lagras i fastighetsomràdesroutern.

Dessutom utnyttjar detta angreppssätt standardprotokoll, och PC-protokollstacken hàlles enkel.

Mutipeltjänster kan accessas samtidigt från en singel- värddator till kostnaden av viss ökning av komplexitet i värddatorstackarna och fastighetsområdesroutern_ Lyckligtvis förbjuds detta scenario ofta av säkerhetsskäl av företagsnätsadministratörer när det gäller Dessa två faktorer kan distanskörning (remote working). leda till beslutet att ej stödja detta scenario.

Den säkerhet som tillhandahàlles av PPP är otillräcklig för ”hemmatjänster” (home working service) där hög säkerhet är ett krav. Den föreslagna lösningen använde: PPP endast för att välja destinationstjänst 29 511 812 f baserad pà användarnamnet som finns i PPP. Säkerhet i högre skikt (t.ex. IPSEC) rekommenderas för scenarier med höga säkerhetskrav.

Claims (56)

511 812 30 PATENTKRAV

1. Ett ADSL-transmissionssystem, anpassat att stödja tillhandahàllandet av telekommunikationstjänster till 5 kunder pà multipel-värddator-/multipel-tjänst-basis, där nämnda ADSL-transmissionssystem inkluderar en LAC, och ett L2-kärnnät anpassat för anslutning till: - Internet-nätet via en ISP's LNS; - ett företags-LAN; och - ett flertal kundterminaler; IS k ä n n e t e c k n a t av att nämnda system inkluderar en fastighetsomràdesrouter och en ATU-R, anpassad att ansluta nämnda flertal kundterminaler, via en DSLAM, till nämnda LAC, där nämnda fastighetsomràdesrouter är anpassad att tjänstgöra som en PPP-proxy à nämnda kundterminalers 20 vägnar, där proxy-funktion baseras på användning av DHCP- meddelanden som genereras av nämnda kundterminaler, och som förmedlar information som nämnda fastighetsomràdesrouter behöver för att upprätta PP?-sessioner. 25

2. Ett ADSL-transmissionssystem, enligt patentkrav l, k ä n n e t e c k n a t av att nämnda fastighetsomràdesrouter och ATU-R är integrerade.

3. Ett ADSL-transmissionssystem, enligt patentkrav 1, 30 k ä n n e t e c k n a t av att nämnda fastighetsomràdesrouter är ansluten till nämnda ATU-R genom tt ATM25-gränssnitt.

4. Ett ADSL-transmissionssystem, enligt något av föregående patentkrav, k ä n n e t e c k n a t av att bl u IJ Un u; u: “síi 31 kundterminaler är tilldelade en lokal, privat adress när de startas/laddas.

5. Ett ADSL-transmissionssystem, enligt patentkrav 4, k ä n n e t e c k n a t av att nämnda fastighetsområdesrouter inkluderar en DHCP-server, och av att nämnda lokala, privata adresser är tilldelade av nämnda ÛHCP"SGIVGI .

6. Ett ADSL-transmissionssystem, enligt antingen patentkrav 4, eller patentkrav 5, k ä n n e t e c k n a t av att kundterminaler är anpassade att initiera upprättande av en VIF genom påverkan av en programstyrd knapp.

7. Ett ADSL-transmissionssystem, enligt patentkrav 6, k ä n n e t e c k n a t av att nämnda kundterminaler är anpassade att sända ett DHCPDISCOVER-meddelande som innehåller nämnda kundterminals FQDN, i DHCP~fältet ”host name", och en verifieringskod i DHCP-fältet ”authentication information field", till nämnda fastighetsomràdesrouter, for att upprätta en VIP.

8. Ett ADSL-transmissionssystem, enligt patentkrav 7, k ä n n e t e c k n a t av att nämnda fastighetsomrádesrouter är anpassad att, vid mottagning av nämnda DHCPDISCOVER-meddelande, få en IP-adress fràn ISP och upprätta en PPP-förbindelse till ISP:n via nämnda LAC, där nämnda PPP-förbindelse konfigureras, mellan nämnda fastighetsområdesrouter och nämnda LAC, med användning av LCP, och sålunda upprättar en PPP-proxy.

9. Ett ADSL-transmissionssystem, enligt patentkrav 8, k ä n n e t e c k n a t av att nämnda LAC är anpassad att identifiera en destinations-LNS, baserat på nämnda kundterminals FQDN, och att kontrollera huruvida en LZTP- tunnel finns mot LSN:en, eller ej, och om någon tunnel ej 511 812 ä 32 finnes, anpassas nämnda LAC att upprätta en L2TP-tunnel mot nämnda LSN.

10. Ett ADSL-transmissionssystem, enligt patentkrav 9, k ä n n e t e c k n a t av att nämnda LSN och nämnda LAC är anordnade att förhandla om ett CALL-id för nämnda PPP- anslutning.

11. Ett ADSL-transmissionssystem, enligt patentkrav 10, k ä n n e t e c k n a t av att nämnda LZTP-tunnel överförs på ATM, eller Frame-Relay.

12. enligt patentkrav ll, k ä n n e t e c k n a t Ett ADSL-transmissionssystem, av att nämnda LNS är anpassad att verifiera nämnda kundterminal med användning av CHAP, eller PAP, efter upprättande av nämnda L2TP-tunnel.

13. Ett ADSL-transmissionssystem, enligt patentkrav 12, k ä n n e t e c k n a t av att nämnda PPP-proxy i nämnda fastighetsomràdesrouter är anpassad att ta emot en IP- adress från en ISP-domän genom IPCP.

14. Ett ADSL-transmissionssystem, enligt patentkrav 13, k ä n n e t e c k n a t av att nämnda fastighetsomràdesrouter är anpassad att lägga till nämnda IP-adress till en vidarekopplingstabell placerad i nämnda fastighetsområdesrouter, och av att nämnda vidarekopplingstabell associerar IP- och MAC-adresser till PPP/ATM VC:er, anpassad att erbjuda nämnda adress till den kundterminal DECPDISCOVER, för nämnda kundterminal en IP-adress av att nämnda fastighetsomràdesrouter är som utfärdade nämnda och sålunda ge ett virtuellt gränssnitt som kan användas när datapaket sänds till nämnda ISP.

15. Ett ADSL-transmissionssystem, enligt patentkrav 14, (J: '<1 'll 511111812 33 k ä n n e t e c k n a t av att nämnda fastighetsomràdesrouter är anpassad att utföra vägval baserat antingen på nämnda IP-adress, eller på nämnda virtuella gränssnitt, för uppströms trafik.

16. Ett ADSL-transmissionssystem, enligt antingen patentkrav 14, eller patentkrav 15, k ä n n e t e c k n a t av att, för nedströms trafik, nämnda fastighetsomràdesrouter är anpassad att extrahera IP-paket från PPP-paketen och sända dem i MAC-ramar till nämnda kundterminal, och av att en destinations-MAC-adress för MAC-ramarna hämtas från nämnda vidarekopplingstabell.

17. Ett ADSL-transmissionssystem, enligt något av patentkraven 6 till 16, k ä n n e t e c k n a t av att nämnda kundterminal, eller nämnda L2-kärnnät, är anpassad/anpassat att koppla ned PPP-anslutningar, och av att antingen nämnda LAC, eller nämnda LNS, är anpassade att terminera overksamma PPP-anslutningar vilkas tidsövervakningstid löpt ut.

18. Ett ADSL-transmissionssystem, enligt nàgot av patentkraven 6 till 17, k ä n n e t e c k n a t av att nämnda fastighetsområdesrouter och nämnda LAC är anpassade att utforma trafik när PPP-anslutningar överförs av CBR PVC:er, och av att en VP kan upprättas mellan nämnda DSLAM och nämnda LAS.

19. Ett ADSL-:ransmissionssystem, anpassat att stödja tillhandahàllandet av telekommunikationstjänster till kunder pà mul:ipe1-värddator-/multipel-tjänst-basis, där nämnda ADSL-transmissionssystem inkluderar en LAC, och ett L2-kärnnät anpassat för anslutning till: - Internet-nätet via en ISP's LNS; 30 511 812 34 - ett företags-LAN; och - ett flertal kundterminaler; k ä n n e t e c k n a t av att nämnda system inkluderar en accessrouter som har samma funktionalitet som fastighetsområdesroutern i ADSL-transmissionssystemet enligt något av patentkraven l till 18, och en ATU~R, anpassad att ansluta nämnda flertal kundterminaler till nämnda LAC, där nämnda accessrouter är anpassad att tjänstgöra som en PPP-proxy à nämnda kundterminalers vägnar, där proxy-funktionen baseras på användning av DCHP- meddelanden som genereras av nämnda kundterminaler, och cverfor information som nämnda fastighetsomràdesrouter behover for att upprätta PPP-sessioner.

20. Ett ADSL-transmissionssystem, enligt patentkrav 19, k ä n n e t e c k n a t av att för varje ATU-R-bryggning i nämnda ADSL-transmissionssystem anpassas nämnda router att implementera ett fjärrbrygg-gränssnitt.

21. Ett ADSL-transmissionssystem, enligt patentkrav 20, k ä n n e t e c k n a t av att nämnda accessrouter är anpassad att_terminera Ethernet, och av att nämnda ATU-R är anpassad att utföra cellbuffring.

22. Ett ASSL-transmissionssystem, enligt något av patentkraven 6 till 18, k ä n n e t e c k n a t av att nämnda fastighetsområdesrouter är ansluten till nämnda ATU- R via ett ATM25-gränssnitt.

23. Ett ADSL-transmissionssystem, enligt patentkrav 22, k ä n n e 2 e c k n a t av att nämnda ATU-R är ett enkelt modem med ATM25-gränssnitt till en kundterminalsida, och av att nämnda fastighetsomràdesrouter har ett flertal Ethernet-portar. 35 5:1:ll1i: tš3i1 2 i 35

24. Ett ADSL-transmissionssystem, enligt patentkrav 23, k ä n n e t e c k n a t av att en Ethernet-kontakt, anpassad att möjliggöra anslutning av ett flertal kundterminaler därtill, tillhandahàlles till varje abonnent.

25. Ett ADSL-transmissionssystem, enligt patentkrav 24, k ä n n e t e c k n a t av att nämnda fastighetsomràdesrouter är anpassad att tillhandahålla skikt-3-kundseparering med hjälp av brandväggar.

26. Ett ADSL-transmissionssystem, enligt något av patentkraven 6 till 18, eller patentkraven 22 till 25, k ä n n e t e c k n a t av att nämnda VIF implementeras genom att skapa en andra anordningsdriver och en andra bindning till ett befintligt nätgränssnitt.

27. I ett ADSL-transmissionssystem, som inkluderar en LAC och ett L2-kärnnät, anpassat för anslutning till: - Internet-nätet via en ISP's LNS; ett företags-LAN; och - ett flertal kundterminaler; en metod att stödja tillhandahàllandet av telekommunikationstjänster till kunder på multipel- värddator-/multipel-tjänst-basis k ä n n e t e c k n a d av att ett flertal kundterminaler, via en fastighetsområdesrouter, en ATU-R och en DSLAM, ansluts till nämnda LAC, där nämnda fastighetsomràdesrouter är anordnad att använda DHCP-meddelanden genererade av nämnda kundterminaler för att förmedla information som nämnda fastighetsområdesrouter behöver för att upprätta PPP- 511 812 36 UI \ll k) v sessioner, så att nämnda fastighetsområdesrouter tjänstgör som en PP?-proxy for nämnda kundterminaler.

28. En metod, k ä n n e t e c k n a d av att en lokal, privat adress enligt patentkrav 27, tilldelas varje kundterminal när nämnda kundterminal startas/laddas.

29. En metod, k ä n n e t e c k n a d av att nämnda lokala, enligt patentkrav 28, privata adress tilldelas genom DHCP från en DHCP-server placerad i nämnda fastighetsområdesrouter. eller

30. En metod, enligt antingen patentkrav 28, patentkrav 29, k ä n n e t e c k n a d av att en VIF etableras som svar på påverkan av en programvarustyrd knapp på nämnda kundterminal.

31. En metod, enligt patentkrav 30, k ä n n e t e c k n a d av att nämnda kundterminal sänder ett DHCPDISCOVER-meddelande innehållande nämnda kundterminals FQDN, i DHCP-fältet verifieringskod i DHCP-fältet ”authentication information för att ”host name", och en field", till nämnda fastighetsområdesrouter, etablera nämnda VIF.

32. En metod, e c k n a d av att nämnda enligt patentkrav 31, k ä n n e t fastichetsomràdesrouter, vid mottagning av nämnda DHCPSISCOVER-meddelande, upprättar en PPP-förbindelse till ISP:n via nämnda LAC, och får en IP-adress från en ISP och av att nämnda PPP-förbindelse, mellan nämnda fast: hctsomrádesrouter och nämnda LAC, konfigureras med användning av LCP, och sålunda upprättar en P?P-proxy.

33. En metod, enligt patentkrav 32, 37 511 812 k ä n n e t e c k n a d av att nämnda LAC identifierar en destinations-LNS, baserad på nämnda kundterminals FQDN, och kontrollerar huruvida en L2TP-tunnel finns mot LSN:en, eller ej, och, om någon tunnel ej finns, av att nämnda LAC upprättar en L2TP-tunnel mot nämnda LSN.

34. En metod, k ä n n e t e c k n a d av att nämnda LSN och nämnda LAC enligt patentkrav 33, förhandlar om ett CALL-id för nämnda PPP-anslutning.

35. En metod, k ä n n e t e c k n a d av att nämnda L2TP-tunnel överförs enligt patentkrav 34, med ATM, eller Frame-Relay.

36. En metod, k ä n n e t e c k n a d av att nämnda LNS, efter enligt patentkrav 35, upprättande av nämnda L2TP-tunnel, verifierar nämnda kundterminal med användning av CHAP, eller PAP.

37. En metod, k ä n n e t e c k n a d av att nämnda PPP-proxy i nämnda enligt patentkrav 36, fastighetsområdesrouter tar emot en IP-adress från en ISP- domän genom IPCP.

38. En metod, k ä n n e t e c k n a d av att nämnda enligt patentkrav 37, fastighetsomràdesrouter lägger till nämnda IP-adress till en vidarekopplingstabell placerad i nämnda fastighetsomràdesrouter, av att nämnda vidarekopplingstabell associerar IP- och MAC-adresser till PPP/ATM VC:er, och av att nämnda fastighetsomràdesrouter erbjuder nämnda adress till den kundterminal som utfärdade nämnda DHCPDISCOVER, och sålunda ger en VIP for närnda kundterminal en IP-adress som kan användas när datapaket sänds till nämnda ISP. 511812 38 35

39. En metod, enligt patentkrav 38, k ä n n e t e c k n a d av att nämnda fastighetsomràdesrouter utför vägval baserat antingen på nämnda IP-adress, eller på nämnda virtuella gränssnitt, för uppströms trafik.

40. En metod, enligt patentkrav 39, k ä n n e t e c k n a d av att, för nedströms trafik, nämnda fastighetsområdesrouter hämtar IP-paket från PPP- paketen och sänder dem i MAC-ramar till nämnda kundterminal, och av att en destinations-MAC-adress för MAC-ramarna hämtas från nämnda vidarekopplingstabell.

41. En metod, enligt något av patentkraven 31 till 40, k ä n n e t e c k n a d av att nämnda kundterminal, eller nämnda L2-kärnnät, kopplar ned PPP-anslutningar, och av att antingen nämnda LAC, eller nämnda LNS, avslutar overksamma PPP-förbindelser för vilka tidsövervakningstiden löpt ut.

42. En metod, enligt något av patentkraven 31 till 41, k ä n n e t e c k n a d av att nämnda fastighetsomràdesrouter och nämnda LAC utformar trafik när PPP-förbindelser överförs av CBR PVC:er, och av att etablera en_VP mellan nämnda DSLAM och nämnda LAC.

43. En metod, enligt patentkrav 42, k ä n n e t e c k n a d av att nämnda fastighetsområdesrouter tillhandahåller skikt 3- kundseparation med hjälp av brandväggar.

44. En metod, enligt något av patentkraven 31 till 43, k ä n n e t e c k n a d av att nämnda VIF implementeras genom att skapa en andra anordningsdriver och en andra bindning till ett befintligt nätgränssnitt. Un 51.21” 8.212 39

45. En fastighetsomràdesrouter, for användning i ett ADSL- transmissionssystem, enligt något av patentkraven 1 till 18, eller patentkraven 22 till 25, av att nämnda fastighetsomràdesrouter är anpassad att k ä n n e t e c k n a d tjänstgöra som en PPP-proxy à kundterminalers vägnar, där proxy-funktion är baserad på användning av DHCP-meddelanden genererade av nämnda kundterminaler och som överför information som nämnda fastighetsomràdesrouter behöver för att etablera PPP-sessioner.

46. En fastighetsomràdesrouter, enligt patentkrav 45, k ä n n e t e c k n a d av att nämnda fastighetsomràdesrouter är integrerad med en ATU-R.

47. En k ä n n e t e c k n a d av att nämnda fastighetsomràdesrouter, enligt patentkrav 45, fastighetsomràdesrouter är anpassad för anslutning till en ATU-R genom ett ATM25-gränssnitt.

48. En fastighetsomràdesrouter, enligt antingen patentkrav 46, eller patentkrav 47, k ä n n e t e c k n a d av att nämnda fastignetsomràdesrouter inkluderar en DHCP-server anpassad att generera lokala, privata adresser.

49. En fastighetsområdesrouter, enligt patentkrav 48, k ä n n e t e c k n a d av att nämnda fastighezsomràdesrouter är anpassad att ta emot DHCPDISCOVER-meddelanden sända av en kundterminal, och som innehåller nämnda kundterminals EQDN i DHCP-fältet ”host name", och en verifieringskod i DHCP-fältet ”authentication information field”.

50. En fastignetsomràdesrouter, enligt patentkrav 49, k ä n n e t e c k n a d av att nämnda fastighezsområdesrouter är anpassad att, vid mottagning lll 511 812 40 nämnda DHCPDISCOVER-meddelande, få en I?-adress från en ISP och upprätta en PPP-förbindelse till IS?:n via en LAC.

5l. En fastighetsområdesrouter, enligt patentkrav 50, k ä n n e t e c k n a d av att en PPP-proxy, för en lJl kundterminal, i nämnda fastighetsomràdesrouter, är anpassad att ta emot en IP-adress från en ISP-domän genom EPCP.

52. En fastighetsomràdesrouter, enligt patentkrav 51, 10 k ä n n e t e c k n a d av att nämnda fastighetsområdesrouter är anpassad att lägga till en IP- adress till en vidarekopplingstabell placerad i nämnda fastighetsomràdesrouter, där nämnda vidarekopplingstabell är anordnad att associera IP- och MAC-adresser till PPP/ATM |5 VC:er, och av att nämnda fastighetsomràdesrouter är anpassad att erbjuda nämnda adress till en kundterminal som har utfärdat en DHCPDISCOVER, och sålunda ge ett virtuellt gränssnitt för nämnda kundterminal en I?-adress som kan användas när datapaket sänds till en IS?.

53. En fastighetsområdesrouter, enligt patentkrav 52, k ä n n e t e c k n a d av att nämnda fastighetsområdesrouter är anpassad att utföra vägval baserat antingen på en IP-adress, eller på ett virtuellt gränssnitt, för uppströms trafik. IJ U:

54. En fastighetsområdesrouter, enligt antingen patentkrav 52, eller patentkrav 53, k ä n n e t e c k n a d av att, för nedströms trafik, nämnda fastighetsomràdesrouter är 30 anpassad att extrahera IP-paket från PP?-paket och sända dem i MAC-ramar till en kundterminal, där en destinations- MAC-adress för MAC-ramarna hämtas från nämnda vidarekopplingstabell. u: u-

55. En fastighetsområdesrouter, enligt något av patentkraven 47 till 54, k ä n n e t e c k n a d av att 41 511 812 nämnda fastighetsomràdesrouter är anpassad att utforma trafik när PPP-förbindelser överförs med CBR PVC:er.

56. En fastighetsomràdesrouter, enligt patentkrav 55, k ä n n e t e c k n a d av att nämnda fastighetsområdesrouter är anpassad att tillhandahålla skikt-3-kundseparering med hjälp av brandväggar.