(12) United States Patent
`BOrella et al.
`
`USOO6587433B1
`(10) Patent No.:
`US 6,587,433 B1
`(45) Date of Patent:
`Jul. 1, 2003
`
`(54) REMOTEACCESS SERVER FOR MULTIPLE
`SERVICE CLASSES IN PNETWORKS
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`(75) Inventors: Michael S. Borella, Naperville, IL
`(US); Igor Lasic, Brighton, MA (US);
`Ikhlaq S. Sidhu, Vernon Hills, IL (US);
`Vandana Upadhyay, Evanston, IL (US)
`(73) Assignee: 3Com Corporation, Santa Clara, CA
`(US)
`-
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`c:
`(*) Notice:
`
`(21) Appl. No.: 09/247,836
`(22) Filed:
`Feb. 10, 1999
`
`Related U.S. Application Data
`(60) Provisional application No. 60/109,953, filed on Nov. 25,
`1998.
`(51) Int. Cl. ............................. H04J 3/14; HO4L 12/56
`(52) U.S. Cl. ....................... 370/230; 370/235; 370/401;
`370/420
`(58) Field of Search ................................. 370/230, 252,
`370/352, 389, 391, 395.21, 395.42, 401,
`420, 421, 444, 236, 230.1, 231, 235
`
`1/2000 Bertin et al. ................ 370/468
`6,011,804 A
`6,160,793 A 12/2000 Ghani et al. ................ 370/236
`6,167,027 A 12/2000 Aubert et al. ............... 370/230
`6,249,519 B1 * 6/2001 Rangachar .................. 370/356
`OTHER PUBLICATIONS
`Memorandum entitled Remote Authentication Dial In User
`Server (RADIUS) by C. Rigney, A. Rubens, W. Simpson and
`S. Willens, dated Apr. 1997.
`* cited by examiner
`Primary Examiner-Chau Nguyen
`Assistant Examiner. Soon-Dong Hyun
`(74) Attorney, Agent, or Firm McDonnell Boehnen
`Hulbert & Berghoff
`(57)
`
`ABSTRACT
`
`A method and System for assigning priority or classes of
`Service of messages delivered in a packet-based network.
`The method and System allows for implementation of dif
`ferentiated classes of Service according to the requirements
`of the network application or user.
`19 Claims, 6 Drawing Sheets
`
`600
`Establish Connection
`to RAS
`
`Router Stamping
`
`-—-
`
`
`
`610
`Determine DS Byte
`For Router Card
`
`620
`Stamp Packet With
`DS Byte
`
`
`
`
`
`
`
`
`
`630
`Restamp Packet
`Accordingly
`
`640
`Terminate and
`Reallocate
`Resources
`
`GUEST TEK EXHIBIT 1006
`Guest Tek v. Nomadix, IPR2019-00211
`
`

`

`U.S. Patent
`
`Jul. 1, 2003
`
`Sheet 1 of 6
`
`US 6,587,433 B1
`
`XIRIOAALTHN «HI
`
`ÅNOH?ICHTCHIJL
`
`GIOIACHOI
`
`I "OIH
`
`
`
`

`

`U.S. Patent
`
`Jul. 1, 2003
`
`Sheet 2 of 6
`
`US 6,587,433 B1
`
`
`
`(INIVO SSOEIRIOGH
`
`XINHOAVALGHN
`
`
`
`CHOV HRIGH LNI
`
`YHGHLÍTORI
`
`(IRIVO
`
`90€.
`
`NCISI/IJL
`
`
`
`
`
`

`

`U.S. Patent
`
`Jul. 1, 2003
`
`Sheet 3 of 6
`
`US 6,587,433 B1
`
`VER IHL
`
`TOS
`
`TOTAL LENGTH
`
`-
`
`IDENTIFICATION
`
`FRAGMENT OFFSET
`
`| TIME-TO-LIVE PROTOCOL
`
`HEADER CHECKSUM
`
`SOURCE ADDRESS
`
`DESTINATION ADDRESS
`
`OPTIONS
`
`P HEADER
`
`FIG. 3
`
`

`

`US. Patent
`
`Jul. 1, 2003
`
`Sheet 4 0f 6
`
`US 6,587,433 B1
`
`mmh>mwa
`
`mmh>mmn
`
`mmh>mwn
`
`th>mmn
`
`mmh>mmn
`
`mmh>mmn
`
`mmh>mmn
`
`~m9>mmn
`
`_mE>Mm
`
`_mh>mw
`
`_mF>mw
`
`_mb>mm
`
`aaDa
`
`eaa
`
`ab>mmn
`
`Wh>mm9
`
`wb>mmfl
`
`mh>mmn
`
`vww
`
`NNV
`
`omv
`
`Ev
`
`c;EvNS
`
`Gov
`
`
`
`Hm<m<H<nHAEOMEMam:
`
`v
`
`.Uum
`
`Mmh<21th<
`
`NH<ZZHHJ<~HF<
`
`Zami4<>M<QZOUmm
`
`
`P42<mma"MU—>mnD.Mmm3
`
`m2<zmm9a o;
`
`Wh>mmo
`
`wh>mma
`
` l:35:H2.22.HHH 3%2832a
`aESECm9:36
`
`a=::m0<d=¥_
`
`UEm<¢U¥mU<H
`
`<44mz0mqm<zu:2
`
`
`

`

`U.S. Patent
`
`Jul. 1, 2003
`
`Sheet S of 6
`
`US 6,587,433 B1
`
`F G 5
`Modem Stamping
`
`one to RAS
`
`510
`Determine DS Byte
`For Modem Card
`
`520
`Stamp Packet With
`DS Byte
`
`7
`
`530
`Restamp Packet
`Accordingly
`
`Terminate and
`Reallocate
`Resources
`-
`
`
`
`
`
`
`
`
`
`
`
`|
`
`

`

`U.S. Patent
`
`Jul. 1, 2003
`
`Sheet 6 of 6
`
`US 6,587,433 B1
`
`F G 6
`Router Stamping
`
`Establish Connection
`
`to RAS
`
`
`
`610
`Determine DS Byte
`For Router Card
`
`620
`Stamp Packet With
`DS Byte
`
`630
`Restamp Packet
`Accordingly
`
`640
`Terminate and
`Reallocate
`Resources
`
`

`

`1
`REMOTEACCESS SERVER FOR MULTIPLE
`SERVICE CLASSES IN PNETWORKS
`
`STATEMENT OF RELATED APPLICATION
`This application claims the benefit under 35 U.S.C. S 119
`(e) of U.S. Provisional Patent Application Serial No. 60/109,
`953, filed Nov. 25, 1998, entitled “Remote Access Server for
`Multiple Service Classes in IP Networks” for all common
`Subject matter disclosed therein.
`
`FIELD OF THE INVENTION
`This invention relates in general to a method and device
`for providing different levels or classes of packet delivery
`Service in a packet-based network.
`
`15
`
`BACKGROUND OF THE INVENTION
`Today, Internet Protocol or “IP networks such as the
`Internet currently Support a Single class of best-effort Service
`to deliver digital information packets carried by the network
`between, for example, a remote access server (“RAS' or
`Network Access Server “NAS”) and a remote host. In a
`typical Single class of Service network, all information
`packets transmitted between Source and destination RAS
`devices are treated as equal in priority. The network makes
`no differentiation or distinction between different packets
`and thus all packets are of the same priority and Subject to
`the same network delivery latencies and delayS.
`Next-generation remote access Servers will need to
`explicitly Support multiple classes of Service to implement
`new applications and Services, Such as live motion Video or
`Voice-over-IP services that require real-time packet delivery
`performance. These classes of Service may operate on a
`packet-by-packet basis and include options to differentiate
`the priority of packet forwarding and routing between pack
`ets on difference connections. Packet delivery classes of
`Service can be based on pre-defined throughput, delay, jitter,
`and loSS parameters. The network delivery option param
`eters are expected to be administratively initiated and
`enforced by the network on either a per-user or per-traffic
`type basis.
`For example, a network user may have an agreement with
`the network operator such that the network will stamp all of
`the users packets with a class of Service defined by the
`particular per hop behavior (“PHB”) of the packet. Or, the
`PHB of the packet could be based according to the type of
`traffic generated (i.e., low delay for remote login or high
`throughput for file transfer). Given the PHB of the packet,
`each router between the Source and destination RAS will
`Serve or deliver the user's packets according to the class of
`service described by the PHB marked in the packet. In this
`example, a packet marked with a PHB indicating low
`latency might be served before a packet marked for high
`throughput.
`There is a great deal of latitude within the context of the
`framework for establishing different classes and Subclasses
`of network traffic, as well as employing various queuing,
`forwarding and packet dropping disciplines. It is likely that
`traffic classification will be based on both technical and
`administrative concerns.
`Regardless of the particular classes of Service, each packet
`must be stamped with an appropriate PHB to indicate the
`classes of service of the packet. This stamping of the PHB
`in a packet may occur in many different places in the
`network, for example, at the user's initiating WorkStation, a
`remote access Server providing access to users, a first-hop
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,587,433 B1
`
`2
`router, a gateway or even other places within the network. A
`packet may also be stamped with a PHB more than once as
`it travels across different networks owned by different enti
`ties. For Security and accountability purposes, it may be
`desirable to limit the stamping of the PHB of packets in
`devices controlled by the users.
`Naturally, any sort of service differentiation must be
`accompanied by an appropriate pricing Scheme So that users
`will act efficiently with respect to the priority level they
`chose and thus the network resources that they consume.
`Network Service providers are currently Seeking more lati
`tude in their Service contracts with users. Implementing a
`differential Service Scheme according to pricing will give
`them this latitude.
`While there is a great deal of debate today currently
`focused on Stamping and restamping issues, RAS devices
`will play a major role in Supporting multiple Service classes.
`Needed is a system and method to efficiently implement
`stamping and management of PHB service levels in RAS
`devices.
`
`SUMMARY OF THE INVENTION
`In accordance with an illustrative embodiment of the
`invention, a method and device for implementing differen
`tial packet delivery Services through a packet-based network
`is provided. According to the illustrative embodiment, a
`remote access server (“RAS") device provides differential
`packet delivery through the network according to a “per-hop
`behavior” or Differential Service Code Point (DSCP) field
`within the transmitted packets.
`According to an aspect of the invention, the RAS device
`receives and interfaces a variety of different types of con
`nections accessing the network Such as data connections
`from the PSTN or from other networks. The RAS device is
`capable of marking packets transmitted to the network with
`the appropriate DSCP to provide a desired class of service
`as the packet is transmitted through the network.
`According to another aspect of the invention, a RADIUS
`or DIAMETER server maintains the class of service for
`various users accessing the network. In an exemplary
`embodiment, the RADIUS/DIAMETER server maintains
`the appropriate DS bytes associated with each user. The DS
`byte contains the DSCP indicating the appropriate class of
`Service for a user. The RAS device accesses the RADIUS/
`DIAMTER server device to obtain the appropriate DS byte
`to mark the packets for a particular user.
`In addition, according to other aspects of the invention, a
`variety of other methods for marking packets according to
`other criteria Such as on a per-modem basis can also be
`implemented.
`The present embodiments allow users to Select a desired
`class of Service according to the particular requirements of
`the network application or user. For example, network
`applications with real-time delivery or large bandwidth
`requirements can Specify and receive the appropriate packet
`delivery service to implement the desired service. The
`ability to control and charge applications and users fees
`according to the network resources they consume provides
`the ability to efficiently allocate and utilize network
`CSOUCCS.
`The foregoing and other features and advantages of an
`illustrative embodiment of the present invention will be
`more readily apparent from the following detailed
`description, which proceeds with references to the accom
`panying drawings.
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 shows an exemplary network acceSS architecture
`implementing the present embodiment;
`
`

`

`US 6,587,433 B1
`
`15
`
`25
`
`35
`
`40
`
`3
`FIG. 2 shows a high level diagram of a network with a
`remote acceSS Server architecture implementing the current
`embodiment of the invention of the system of FIG. 1;
`FIG. 3 shows an embodiment of a preferred IP header of
`a packet in the system of FIG. 1;
`FIG. 4 shows an illustrative embodiment of an exemplary
`user profile of a user of system of FIG 1;
`FIG. 5 shows a method of stamping packets by the
`modem card in the RAS of FIG. 2;
`FIG. 6 shows a method of a stamping packets by the
`router card in the RAS of FIG. 2.
`DESCRIPTION OF AN ILLUSTRATIVE
`EMBODIMENT
`Exemplary Remote Network Access System
`FIG. 1 shows an exemplary remote network access SyS
`tem Suitable for implementing an illustrative embodiment of
`the invention. The remote network access system 30 pro
`vides a variety of different types of users access to an IP
`network or other type of packet-based network through a
`RAS 22.
`In the example of FIG. 1, the system includes user
`customer premises equipment (“CPE”) 40 and telephony
`device 44 connected via a communication line 46 over a
`Public Switched Telephone Network (“PSTN”) 24 via a
`Second communication line 23 to a Remote AcceSS Server
`(RAS) 22. In this embodiment, RAS 22 is shown providing
`users dial-up access through the PSTN 24 and as well as
`access from other networks, Such as a local area nework
`(“LAN”) 54. Of course, RAS devices can also provide
`access from a number of other devices and communication
`networks as well. RAS 22 may be connected by connection
`21 to the packet based network, Such as an IP network 20.
`Communication lines 46 and 23 may be analog lines, or they
`may be digital lines (such as T1-carrier lines), or they may
`be a combination of analog and digital lines. Communica
`tion lines 46 and 23 need not be physical wire connections,
`and may instead be composed partially or entirely of wire
`less transmission technology, Such as radio frequency (RF)
`communication. An example of one embodiment of Such
`communication lines could be a cellular telephone link.
`Also shown in FIG. 1 is a second CPE 50 preferably
`connected through a networking card and cable 52 to a local
`area network (“LAN”) 54. The LAN 54 is connected
`through communication line 56 to RAS 22, so that CPE 50
`may access the IP network 20. Communication line 56 is
`preferably a leased line, Such as a leased T1 communication
`line. Other communication line implementations are poS
`sible as well. LANs are well known by those having skill in
`the art, as is the technology and methodology for accessing
`an IP network through an RAS from a LAN-based CPE.
`Telephone 60 may be used to form a connection across
`communication line 62 through PSTN 24 and across com
`munication line 23 to access RAS 22. Communication line
`62 may be an analog circuit-Switched connection provided
`by the telephone Subscriber loops, local end offices, trunk
`connections and toll Switches of the PSTN. Such a
`telephone-based System may be used for IP telephony using
`Voice over IP (“VoIP) connections provided by the IP
`network 20. For example, Voice Signals are digitized and
`packetized at RAS 22 according to the Internet Protocol
`("IP") and transported across the network 20 to a remote
`device. Similarly, the System could be used to communicate
`information using Dual Tone Multi Frequency (DTMF)
`Signaling, or Voice signaling, for example.
`CPES 40 and 50 accessing the network 20 may each
`consist of a general purpose computing platform (such as an
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`IBM PC compatible computer) running an operating System,
`such as Windows 95TM, Windows 98TM, or Windows NTTM,
`all from Microsoft Corporation, or a UNIX operating sys
`tem. Of course other commercially available computer and
`operating Systems may alternatively be used as well. CPES
`40 and 50 may be at the home or office of a user, or they may
`be at Some other location.
`Telephony device 44 is preferably a modem communica
`tion device, such the U.S. ROBOTICSTM 56K
`FAXMODEM, manufactured by 3Com Corporation. At the
`customer premise, modems are typically used to Send digital
`data Signals over an analog PSTN connection, as previously
`described, or a digital connection. Typically, a modem
`converts digital data Signals into an analog modulation So
`that digital data can be transmitted over the bandwidth
`limited connection through the PSTN. A second modem
`reverses the process in order to provide the recovered digital
`bit stream to a remote device, Such as a computer System.
`Modems are standardized by the International Telecommu
`nication Union, Telecommunication Standardization Section
`(ITU-T) as part of the well-known “V” series of standards,
`including, for example, Recommendation V.90 and Recom
`mendation V.34. The ITU-T Recommendations V.90 and
`V.34 are incorporated by reference herein.
`In addition to analog modems, other telephony devices
`may also be used in this embodiment of the invention. For
`example, Digital Subscriber Line (DSL) modems and cable
`modems, both bi-directional and unidirectional having a
`telco return, may also be used. It should be noted that
`although the word “modem” is used, which has its origins in
`the analog oriented phrase “MOdulator-DEModulator,” no
`limitations are implied. Both analog and digital Systems are
`Supported, and “modem” is not necessarily used here to
`describe the technology of telephony device 44. Telephony
`device 44 may be external to user CPE 40, as shown in FIG.
`1, or it may be internal. Internal telephony devices are also
`well known.
`The connections illustrated in FIG. 1 between the PSTN
`24 and CPE40, and between the PSTN 24 and telephone 60,
`are provided as examples of typical connections. Those
`skilled in the art of data communication will appreciate that
`the examples are not limiting, in number or kind, the user
`connections to which the preferred embodiments are appli
`cable.
`Exemplary Remote Access Server
`The various users connecting to the network 20 can be
`interfaced and provided access to the network by RAS 22.
`RAS 22 is a network device that concentrates a number of
`dial-up or dedicated access connections onto a shared
`medium to interface and access the network 20. Typically,
`Internet Service Providers (ISPs) use devices similar to RAS
`22 to serve analog modem users who dial into the ISP
`network from the Public Switched Telephone Network. The
`RAS architecture, however, has wide applicability and can
`applied to provide access to and from ISDN, ADSL, Frame
`Relay, X.25 and T1-carrier users. Similar such devices
`having these capabilities are currently available from Several
`companies, including 3Com Corporation, Ascend
`Communications, Livingston Enterprises, Multitech, and
`others. A preferred device is the Total ControlTM Enterprise
`Network Hub, available from 3Com Corporation. The Total
`ControlTM Enterprise Network Hub is described in the patent
`to Dale E. Walsh et al., U.S. Pat. No. 5,525,595, which is
`incorporated by reference herein.
`FIG. 2 shows the architecture of a preferred embodiment
`of RAS 22. The illustative embodiment includes a variety of
`application cards such as modem cards, T1/ISDN, network
`
`

`

`US 6,587,433 B1
`
`15
`
`25
`
`35
`
`40
`
`S
`interface and egreSS cards, router cards, and management
`cards. The disclosed embodiment uses T1 lines, but those
`skilled in the art of data communication will appreciate that
`the example is not limiting, in number or kind, the connec
`tions to which the preferred embodiments are applicable.
`“HDM” is acronym for “high-density modem,” indicating
`that each card performs modem functions for a plurality of
`data channels. For example, each high-density modem
`200A-C may perform modem functions for 23B channels
`plus 1D channel for an ISDN Primary Rate Interface, 24
`DSO channels for a T1 line and 30 channels for an E1 line.
`RAS 22 includes a plurality of high-density modems
`200A-C each having a T1/ISDN telephone line interface
`202A-C. The high-density modems 200A-C communicate
`with other devices in the RAS and a network interface 204
`over a packet system bus (S-bus) 206. This packet bus 20
`can be implemented with a version of Ethernet, ATM, or
`another packet network fabric technology on the physical
`layer. The high-density modems 200A-C, the T1/ISDN
`telephone line interfaces 202A-C, and the network interface
`204 are preferably on individual printed circuit boards or
`cards arranged in a chassis.
`By providing a set of high-density modems 200 and a
`robust computing platform in the network interface 204, a
`Single chassis can process many hundreds of calls through
`RAS 70 simultaneously.
`In the embodiment of FIG. 2, each high-density modem
`200A-C has its own T1/ISDN telephone line interface
`202A-C connected to an ISDN PRI or T1 line at connections
`23A-C, respectively. Connections 23A-C may service con
`nection 23 in FIG. 1, for example. The T1/ISDN telephone
`line interface 202 is connected to the high-density modem
`cards by a Time Division Multiplex (TDM) bus 208A-C.
`The TDM bus 208 and the T1/ISDN telephone line interface
`202 of FIG. 2 are described in further detail in U.S. Pat. No.
`5,525,595.
`The T1/ISDN telephone line interface 202 card is com
`posed of two separate modules, an incoming call interface
`module and an incoming call application module. The
`interface module physically receives the incoming T1 span
`lines at connections 62A-C, converts the Signals into a
`digital TTL format, and delivers the Signals to the incoming
`call application module. The interface module recovers
`clock signals and data from the incoming T1 signals, and
`also transmits outgoing digital telephone signals represent
`ing digital data to the T1 lines at connections 23 A-C. The
`application module provides framing of recovered T1 data to
`extract the T1 DSO channel data and then Switches the
`channel data every twenty four time slots on the TDM bus
`208 to the corresponding high-density modem 200.
`An alternative for connecting the T1/ISDN telephone line
`interface cards 202A-C to the high-density modems
`200A-C would be to provide a plurality of T1/ISDN tele
`phone line interface cards 202 and distribute channel data to
`the modems via a TDM bus with extra highway lines, as
`described in Schoo et al., U.S. patent application Ser. No.
`08/970,834, “DISTRIBUTED PROCESSING OF HIGH
`LEVEL PROTOCOLS, SUCH AS REAL TIME TRANS
`PORT PROTOCOLS, IN A NETWORK ACCESS
`SERVER,” which is hereby incorporated by reference.
`The network interface 204 consists of a general purpose
`computing platform (Such as an IBM PC) running an oper
`ating system such as Windows 95TM, Windows 98TM, or
`Windows NTTM from Microsoft Corporation, or UNIX. The
`network interface card 204 contains Software and hardware
`modules to perform call routing, modem configuration and
`other features as Set forth and described for the gateway
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`modules in U.S. Pat. No. 5,525,595 and U.S. Pat. No.
`5,577,105, “TELEPHONE CALL ROUTING AND
`SWITCH ING TECHNIO UES FOR DATA
`COMMUNICATIONS, issued to Baum et al., also incor
`porated by reference herein. Such a network interface card
`is available from 3Com Corporation under the trade name
`EDGESERVERTM, which is further described in U.S. patent
`application Ser. No. 08/813,173, “COMMUNICATION
`ACCESS CHASSIS WITH GENERAL PURPOSE COM
`PUTING PLATFORM, issued to William Verthein et al.,
`incorporated by reference herein.
`Managing dispersed Serial lines, modem pools for large
`numbers of users simultaneously connected to the RAS to
`access the network 20 can create the need for Significant
`administrative Support. Since modem pools are by definition
`a link to the outside world, they require careful attention to
`Security, authorization and accounting of users accessing the
`network. This can be achieved by managing a single "data
`base' of users, which allows for authentication (verifying
`user name and password) as well as configuration informa
`tion detailing the type of Service to deliver to the user (for
`example, SLIP, PPP, telnet, rlogin). In one embodiment, the
`RAS 22 is able to perform administrative tasks such as user
`authentication, accounting, and logging of user Sessions.
`RAS 22 may also optionally include a number of man
`agement cards and router cards or other types of application
`cards necessary to implement System functions. Router card
`212 can be employed as network egreSS cards. Data from
`connection Sessions accessing the RAS 22 are Sampled and
`converted to digital bitstreams. With the router card
`installed, the bitstreams are packetized and transmitted on
`the packet bus to the router card 210. The router card 210
`removes any link-layer headers from each packet, Such as
`Ethernet, HDLC, or PPP headers and transmits the resulting
`IP packet to an egreSS card. Alternatively, the modem cards
`200 may contain knowledge of IP headers and transmit the
`IP packets directly to the RAS gateway. The network man
`agement card 212 can perform administrative taskS Such as
`user authentication, accounting and logging.
`Exemplary RADIUS/DIAMETER Server
`Alternatively, user authentication may be implemented
`outside of the RAS 22 to be handled within a RADIUS or
`DIAMETER server 32. RADIUS (Remote Authentication
`Dial In User Service) follows a client/server model where a
`RAS 22 operates as a client of the RADIUS server 32.
`Similarly, DIAMETER follows a client/server model that
`has evolved from RADIUS. The present embodiment may
`be utilized with a RADIUS and/or DIAMETER server, but
`for the sake of clarity, only the RADIUS server 32 will be
`discussed here. In the present embodiment, the RAS 22
`client is responsible for passing user information to desig
`nated RADIUS servers 32, and then acting on the response
`returned by the RADIUS server 32. RADIUS servers 32 are
`responsible for receiving user connection requests, authen
`ticating the user, and then returning all configuration infor
`mation necessary for the RAS client to provide service to the
`user. A RADIUS server 32 can act as a proxy client to other
`RADIUS servers or other kinds of authentication server.
`For the RADIUS/DIAMETER alternative, each dial-up
`user has a profile on the RADIUS server 32. The profile
`contains information Such as user ID/password pairs, default
`serial line protocols and MTUs (maximum transfer units).
`For SLIP and PPP, this may include values such as IP
`address, Subnet mask, MTU,desired compression, and
`desired packet filter identifiers. For character mode users,
`this may include values Such as desired protocol and host.
`RADIUS is extensible; thus, it can be programmed to
`
`

`

`7
`Support Virtually any user information. In this embodiment,
`a user profile may include a class of Service field to indicate
`which class of Service the packets from the user may utilize
`as described in more detail with reference to FIG. 4.
`When a client is configured to use RADIUS/DIAMETER,
`a user of the client presents authentication information to the
`client. This might be implemented with a customizable login
`prompt, where the user is expected to enter their username
`and password. Alternatively, the user might use a link
`framing protocol such as the Point-to-Point Protocol (PPP),
`which has authentication packets to carry this information.
`Once the client has obtained Such information from a user,
`it may choose to authenticate the user's acceSS using
`RADIUS. To do so, the client creates an “Access-Request'
`containing Such Attributes as the user's name, the user's
`password, the ID of the client and the Port ID which the user
`is accessing. To implement Security, transactions between
`the client and RADIUS server are authenticated through the
`use of a shared Secret, which is not sent over the network. In
`addition, any user passwords are Sent encrypted between the
`client and RADIUS server, to eliminate the possibility that
`Snooping on an unsecure network could determine a user's
`password.
`The RADIUS server 32 can also support a variety of
`methods to authenticate users Seeking access to the network.
`When provided with the user name and original password
`given by the user, RADIUS can support PPP, PAP or CHAP,
`UNIX login, and other authentication mechanisms.
`RADIUS transactions are comprised of variable length
`Attribute-Length-Value 3-tuples. New attribute values can
`be added without disturbing existing implementations of the
`protocol. When a password is present, it is hidden using a
`method based on the RSA Message Digest Algorithm MD5
`as know to those skilled in the art.
`The Access-Request is submitted from the client 22 to the
`RADIUS server 32 via the network 20. If no response is
`returned within a length of time, the request is re-Sent a
`number of times. The client 22 can also forward requests to
`an alternate Server or Servers not shown in the event that the
`primary Server is down or unreachable. An alternate Server
`can be used either after a number of tries to the primary
`server fail, or in a round-robin fashion. Retry and fallback
`algorithms are the topic of current research and are not
`Specified in detail in this document.
`Once the RADIUS server 32 receives the request, it
`validates the Sending client. A request from a client 22 for
`which the RADIUS server 32 does not have a shared secret
`should be silently discarded. If the client is valid, the
`RADIUS server 32 consults a database of users to find the
`user whose name matches the request. The user entry in the
`database contains a list of requirements that must be met to
`allow access for the user. This always includes verification
`of the password, but can also specify the client(s) or port(s)
`to which the user is allowed access. The RADIUS server 32
`may make requests of other Servers in order to Satisfy the
`request, in which case it acts as a client. If any condition is
`not met, the RADIUS server 32 sends an “Access-Reject”
`response indicating that this user request is invalid. If
`desired, the Server may include a text message in the
`Access-Reject that may be displayed by the client to the
`user. No other Attributes are permitted in an Access-Reject.
`If all conditions are met and the RADIUS server 32
`wishes to issue a challenge to which the user must respond,
`the RADIUS server 32 sends an “Access-Challenge”
`response. It may include a text message to be displayed by
`the client to the user prompting for a response to the
`challenge, and may include a State attribute. If the client
`
`8
`receives an Access-Challenge and Supports challenge/
`response it may display the text message, if any, to the user,
`and then prompt the user for a response. The client then
`re-Submits its original Access-Request with a new request
`ID, with the User-Password Attribute replaced by the
`response (encrypted), and including the State Attribute from
`the Access-Challenge, if any. Only 0 or 1 instances of the
`State Attributes should be present in a request. The server
`can respond to this new Access-Request with either an
`Access-Accept, an Access-Reject, or another AcceSS
`challenge.
`If all conditions are met, the list of configuration values
`from the user' user profile are placed into an "AcceSS
`Accept response to be transmitted back to the client.
`In a typical dial-up session with RADIUS authentication,
`the client dials into the ISP and initiates a (Point-to-Point
`Protocol) PPP connection with the RAS 22. During the PPP
`Setup and negotiation, the client transmits a user ID and
`password in response to the RAS login request. The RAS 22
`passes this information to the RADIUS server 32, which
`authenticates the user in a local user database. At this time,
`the RADIUS server 32 may pass administrative information
`back to the client and/or the RAS 22. The RADIUS Server
`32 is also notified by the RAS 22 when the user's connection
`is dropped. RADIUS servers 32 log and timestamp all such
`activity. For more information on RADIUS, see Request For
`Comment RFC-2138, “Remote Authentication Dial In User
`Service (RADIUS).” published by the Internet Society in
`April 1997.
`It will be understood by one of ordinary skill in the art
`that, although the description above is directed at using the
`Internet as the data network in the preferred embodiments,
`other data networks may be used as well. For data networks
`other than the Internet, one of ordinary skill in the art would
`know how to make the appropriate modifications to the
`example embodiments described below. Similarly, although
`the examples are described with reference to an Internet
`Service Provider (ISP), the concepts of the present invention
`apply to any entity that receives incoming calls and provides
`access to accounts having the capability to Store email or
`other Similar information.
`Class of Service Support
`In an illustrative embodiment of the invention, the RAS
`22 can differentiate network Services at the packet level by
`using the type-of-service (TOS) byte in the IP header (also
`known as the DS byte). Each IP packet includes an fPheader
`such shown in FIG. 3. As seen in FIG. 3, the TOS byte is the
`third field in the IP header. The format of the TOS byte is
`typically defined as follows:
`
`TABLE A
`
`Prior Art
`
`Precedence (3) Type of Service (4) MBZ (1)
`
`In the Table A, the 3-bit Precedence field uses the values
`000-111 to indicate the priority or the importance of the
`packet. In this example, higher values are more important,
`and should be given greater priority over lower precedence
`packets.
`Following the Precedence field, a 4-bit Type of Service
`field typically has five defined values that are utilized as
`follows:
`
`US 6,587,433 B1
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`US 6,587,433 B1
`
`9
`
`TABLE B
`
`Prior Art
`
`TOS Value
`
`Interpretation
`
`1OOO
`O1OO
`OO1O
`OOOO
`
`Minimize Delay
`Maximize Throughput
`Minimize Cost
`Normal
`
`10
`The us