United States Patent (19)
`Martin
`
`54) QUALITY OF SERVICE ALLOCATION ON A
`NETWORK
`
`75 Inventor: Jean-Christophe Martin, Varces,
`France
`
`73 Assignee: Sun Microsystems, Inc., Mountain
`View, Calif.
`
`21 Appl. No.: 09/045,546
`22 Filed:
`Mar 20, 1998
`51
`Int. Cl." ............................. G06F 13/38; G06F 15/17
`52 U.S. Cl. .......................... 709/226; 709/223; 709/224;
`709/235; 709/240; 370/390; 370/396
`58 Field of Search ..................................... 709/233,234,
`709/235, 240
`
`56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,674,003 10/1997 Andersen et al. ...................... 364/514
`5,884,301 3/1999 Takano ........................................ 707/3
`5,966.531. 10/1999 Skeen et al. ..
`... 395/683
`5,987,306 11/1999 Nilsen et al. .......................... 455/67.1
`OTHER PUBLICATIONS
`Ukiah Software, Inc.,"NetRoad Traffic Ware-Eliminates
`Anarchy at the internet Access Point and Improves Perfor
`mance' Data sheet, Dec., 1997, www.ukiahSoft.com/traf
`ficds.pdf.
`Theresa W. Carey, “Control Internet Bottlenecks”, Jan.
`1998, www.microsoft.com/mind/O198/stuff0198.htm.
`Erica Roberts, “Taking the Effort Out of Bandwidth Man
`agement”, Jan. 1998, www.data.com/hot products/ne
`troad.html.
`Bolot et al., “Evaluating Caching Schemes for the X.500
`Directory System”, Proceedings of the Int’l Conference on
`Distributed Computing Systems, IEEE, May 25, 1993.
`Michele Wright, “Using Policies for Effective Network
`Management,” International Journal of Network Manage
`ment, vol. 9, No. 2, Mar.-Apr. 1999.
`
`USOO6154776A
`Patent Number:
`11
`(45) Date of Patent:
`
`6,154,776
`Nov. 28, 2000
`
`“Remote Authentication Dial In User Service (RADIUS)”,
`Rigney etal., (RFC 2138), Standards Track, pp. 1-65, Apr.
`1997.
`“Dynamic Host Configuration Protocol”, R. Droms, (RFC
`2131) Standards Track, pp. 1-45, Mar. 1997.
`“Lightweight Directory Access Protocol, Yeong et al.,
`(RFC 1777) pp. 1–22(17 Pages) Mar. 1995.
`Internet Draft “draft-elesson-Sla-schema-oo.txt, Pgaes
`ii-XXV, Feb. 19, 1998.
`“Directory-enabled Networks-Information Model and
`Base Schema”, Version 2.0.2-2, pp. 1–57, Feb. 17, 1998.
`“ Application Class of Service Schemata”, Debasish Biswas,
`Berkeley Networks, Inc., p. 1-7, Feb. 19, 1998.
`“Policy Based Signaling QoS’, 6 Pages, Jan. 12, 1998.
`Microsoft Press Computer Dictionary Third edition, p. 72
`1997.
`
`Primary Examiner Zarni Maung
`ASSistant Examiner Mahmanzar Moezzi
`Attorney, Agent, or Firm Beyer Weaver & Thomas, LLP
`57
`ABSTRACT
`A Quality of Service (QoS) method and mechanism enable
`allocation of a QoS to a flow on a network in a dynamic
`environment in response to detection of a new instance of an
`entity associated with a flow on the network. A binding is
`determined between the flow and the entity which is based
`on at least one parameter of the flow. A QoS definition is
`maintained in a directory service of the network. The QoS
`definition includes at least one configuration rule for the
`flow. A QoS definition for the entity is accessed, which QoS
`definition binds the flow with a QoS. Configuration rules of
`the QoS definition are applied to the flow to configure the
`flow. The detection of a new instance of an entity could be
`in response to a flow event or in response to a directory event
`resulting, for example, from a login event.
`
`35 Claims, 6 Drawing Sheets
`
`16
`
`
`
`NEWORK
`ACCESS
`SERVER
`
`
`
`
`
`QoS
`SERVER
`
`2O
`
`
`
`
`
`22
`
`DIRECTORY
`SERVER
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 1 of 16
`
`

`

`U.S. Patent
`
`6,154,776
`
`W ] \/ -dSd
`
`
`
`XIXJOWA_LEN
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 2 of 16
`
`

`

`U.S. Patent
`
`Nov. 28, 2000
`
`Sheet 2 of 6
`
`6,154,776
`
`16
`
`NETWORK
`ACCESS
`SERVER
`
`
`
`QoS
`SERVER
`
`2O
`
`
`
`
`
`DIRECTORY
`SERVER
`
`22
`FG. 2
`
`
`
`
`
`DIRECTORY
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 3 of 16
`
`

`

`U.S. Patent
`
`6,154,776
`
`
`
`
`
`SOO
`
`O}}VEISYHETTOYHLNO O
`
`-] / |
`
`
`
`WS?N\/HOEW SOÜ)
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 4 of 16
`
`

`

`U.S. Patent
`
`Nov.28, 2000
`
`Sheet 4 of 6
`
`6,154,776
`
`Ssgaoons
`
`—
`
`_
`
`|SSA9ONS
`
`Linvaad=$9dD
`
`OLNOILVYNDISANOD
`
`FHLalvadn
`
`AnySHLLoaidgay[--StS
`
`BHLLONYLSNOD
`
`sand
`
`V¥LONYLSNOD
`
`andLNvVsaaG
`
`G‘Sls
`
`
`
`—eeee_-——]ZS
`
`Daedalus EX2020
`Page 5 of 16
`
`AMIVASODSHLL309
`
`NOUINIS30
`
`SS3299Ns
`
`4/1WSINVHOAWS9D
`
`LS
`
`
`
`csMO1dLOVYULXS
`
`OLSLNSW374
`
`SHLLONYLSNOOS
`
`Lsanoay
`
`IPR2021-00831
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 5 of 16
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`
`
`4/1)AMOLOSHYIGELLS
`
`LLLS
`
`
`
`IN3AZLOVYLXA
`
`OLSLNSWa13
`
`3HLLONYLSNOO
`
`oTLsanoay
`
`Nov.28, 2000
`
`Sheet 5 of 6
`
`6,154,776
`
`OLNOLLVYNDISNOD
`
`SHLSLvdadn
`
`31ndSHL19471438O2-LS
`
`BHLLONYLSNOOD
`
`sand
`
`VYLONYLSNOD
`
`anyLInVvsaaa
`
`8LLS
`
`SsdoonsSA
`
`
`
`sa1nyasvaTsd
`
`SHLGNIS
`
`OLLS
`
`AHL313730
`
`sangGalva
`
`éAYLNA
`
`ALSTAG
`
`daislgow
`
`éAYXLNA
`
`ZbLS
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 6 of 16
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 6 of 16
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Nov. 28, 2000
`
`Sheet 6 of 6
`
`6,154,776
`
`
`
`ZZ ).AYJO LOB HICI
`
`/ “SO|-
`
`
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 7 of 16
`
`

`

`1
`QUALITY OF SERVICE ALLOCATION ON A
`NETWORK
`
`6,154,776
`
`2
`The period between the transmission of a message and the
`receipt of an acknowledgement is termed the Round-Trip
`Time (RTT). The RTT varies over time depending upon
`many factorS Such as, for example, network loading (e.g.,
`delays at intermediate nodes in the System) and loading on
`the receiver. An important factor in determining the RTT is
`the available bandwidth. Thus, where multiple clients have
`access to a common Server, for example, in order to balance
`the Quality of Service between clients, it is desirable to
`control factors such as the bandwidth allocated to the
`individual clients, packet delay, and So on. The control of
`Such factorS is typically referred to as the control of a
`Quality of Service (QoS).
`Currently, a QoS for specific information flows is allo
`cated Statically based on information contained in the traffic
`itself, such as IP source address, IP destination address,
`protocol and ports. The QoS is defined in terms of one or
`more configuration rules, each of which defines one or more
`factors, such as the bandwidth for an information flow,
`buffer Sizes, firewall characteristics, etc.
`The QoS allocation to an information flow is based on a
`unique identifier, which is usually constructed from param
`eterS Such as the Source/destination IP address protocol,
`Source/destination ports and/or any other relevant elements
`from the data flow. However, the QoS allocation to an
`information flow belonging to an entity is possible only if
`these parameters are tightly, and permanently bound to that
`entity.
`Traditional QoS is essentially applied in a Static manner.
`AS well as providing limited flexibility, a Static configuration
`has the effect that rules for the QoS may not be used if a user
`is not logged on to the network.
`The Internet and Similar intranets have been typically
`been based on a best effort, first-in-first-out basis. However,
`a trend to the provision instead of differentiated Services
`over a network leads to a need for a more flexible approach
`to the allocation of a QoS.
`However, there is the problem of how to achieve this. To
`create a configuration rule based simply on an IP address or
`a port as in the prior art is not effective where an entity to
`IP address or entity to port allocation can vary due to
`dynamic IP and/or port allocation. More generally, where
`there is dynamic allocation of a flow parameter (e.g., an IP
`address) to an entity, there is no tight link between the entity
`and the flow. It should be noted herein that the “entity” could
`be a user, or more generally could be an application, a piece
`of equipment or other network entity, and need not be a
`unitary entity, but could be a compound entity Such as a
`group of users, a set of equipment, etc. Also, a dynamic flow
`parameter could be an IP address, a port, or any other
`dynamically allocatable flow parameter.
`Particular reference is made hereinafter to dynamic
`address allocation, although it should be understood that the
`invention is not limited to environments with dynamic
`allocation of IP addresses, but also to other environments
`with, for example, dynamic allocation of ports. Dynamic
`address allocation is provided under a number of different
`environments. Examples of Such environments are the
`Remote Authentication Dial in User Service (RADIUS) and
`the Dynamic Host Configuration Protocol (DHCP). A
`description of RADIUS is to be found in C Rigney, A
`Rubens, W Simpson, and S Willens, “Remote Authentica
`tion Dial in User Service (RADIUS), RFC 2138, April
`1997. A description of DHCP can be found in R. Droms
`“Dynamic Host Configuration Protocol, RFC-2131, March
`1997.
`
`15
`
`35
`
`40
`
`25
`
`BACKGROUND OF THE INVENTION
`This invention relates to Quality of Service allocation on
`a network, for example on the Internet, or an intranet.
`Conceptually, the Internet provides three Sets of Services.
`At the lowest level, a connectionless delivery System pro
`vides a foundation on which everything rests. At the next
`level, a reliable transport Service provides a high level
`platform. At the third level, application Services are provided
`which rely on the reliable transport service.
`A fundamental Internet Service consists of an unreliable,
`connectionless, best-effort, packet delivery System. The Ser
`vice is described as being “unreliable” because delivery is
`not guaranteed. A packet may be lost, duplicated, or deliv
`ered out of order, but the Internet will not detect Such
`conditions, nor will it inform the Sender or receiver. The
`Service is described as being “connectionless' because each
`packet is treated independently from all others. A sequence
`of packets Sent from one machine to another may travel over
`different paths, or Some may be lost while others are
`delivered. The service may be described as “best-effort”
`because the Internet aims to deliver packets but does not
`guarantee delivery.
`The protocol that defines the unreliable, connectionless,
`delivery mechanism is called the “Internet Protocol', and is
`usually referred to by its initials IP IP defines the formal
`Specification of data formats, including a basic unit of data
`transfer and the exact format of all data passing across the
`Internet. IP also includes rules which specify how packets
`should be processed and how errors should be handled. In
`particular, IP embodies the idea of unreliable delivery and
`packet routing.
`Above the IP layer of the Internet protocol structure one
`Service which is provided is a reliable transport Service
`which is typically called the “reliable stream transport
`service', defined by the Transmission Control Protocol
`(TCP). The combination of the TCP protocol and the under
`lying Internet Protocol (IP) is often referred to as TCP/IP.
`The reliable stream delivery service provided by the TCP
`can be contrasted with the unreliable datagram protocol
`(UDP) which is also provided over the Internet. The UDP
`45
`provides an unreliable delivery Service because delivery is
`not guaranteed. For example, packets may be lost or
`destroyed when transmission errors interfere with data,
`when network hardware fails, or when networks become too
`heavily loaded to accommodate the load presented.
`The TCP on the other hand has a complex structure
`providing delivery by means of a stream of bits, divided into
`eight-bit bytes. The TCP specifies the format of the data and
`acknowledgements that two computers are to exchange to
`achieve reliable transfer, as well as the procedure to ensure
`that data arrives correctly.
`AS mentioned above, given that the underlying Internet
`protocol is unreliable, TCP transmissions operate in accor
`dance with a technique known as positive acknowledgement
`with retransmission. The technique requires a recipient to
`communicate with the Source, Sending back an acknowl
`edgement message every time it receives data. The Sender
`keeps a record of each packet that it sends and waits for an
`acknowledgement before Sending the next packet. The
`Sender also Starts a timer when it sends its packet and
`retransmits a packet if the timer expires before the acknowl
`edgement arrives.
`
`50
`
`55
`
`60
`
`65
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 8 of 16
`
`

`

`3
`In such an environment with dynamic allocation of IP
`parameters (e.g., dynamic IP address allocation), an entity
`will Seek a presence on the network to establish an infor
`mation flow, typically referred to simply as a “flow”.
`A conventional, Static, approach to the allocation of QoS,
`with configuration rules (or policies) defining the QoS being
`established apriori, does not work efficiently, or at all in Such
`an environment. At best, apriori allocation of QoS will result
`in inefficient use of network resources as the apriori alloca
`tion may not be applicable for a particular instance of an
`information flow. For example, due to bandwidth limitations
`of a predetermined QoS, a particular instance of an infor
`mation flow may not be able to make full use of an available
`bandwidth. Also, in a network with a potentially huge
`number of entities, apriori installation of QoS will result in
`erroneous combinations of configuration rules with unused,
`or overloaded, resources. At Worst, the apriori allocation will
`not work where there is no permanent link between a flow
`and an entity.
`Accordingly, the invention seeks to provide a Solution to
`the provision of a QoS definition for an environment in
`which dynamic allocation of flow parameters is practised.
`SUMMARY OF THE INVENTION
`Particular and preferred aspects of the invention are Set
`out in the accompanying independent and dependent claims.
`Combinations of features from the dependent claims may be
`combined with features of the independent claims as appro
`priate and not merely as explicitly Set out in the claims.
`In accordance with an aspect of the invention, there is
`provided a computer-implemented method of allocating a
`Quality of Service (QoS) to a flow on a network. The method
`comprises:
`i) detecting a new instance of an entity associated with the
`flow on the network;
`ii) determining a binding between the flow and the entity
`based on at least one parameter of the flow;
`iii) using the binding to access a QoS definition for the
`entity, the QoS definition being maintained in a direc
`tory Service of the network and including at least one
`configuration rule for the flow, whereby the QoS defi
`nition binds the flow with the QoS, and
`iv) dynamically applying to the flow at least one configu
`ration rule identified by the QoS definition.
`AS opposed to conventional apriori allocation of QoS
`configuration rules, an embodiment of the invention pro
`vides an allocation of a QoS in response to detection of a
`new instance of an entity associated with a flow. In this
`manner the QoS can be allocated dynamically as activity for
`an entity Starts. As a result, the configuration rules are only
`created when the flows to which they apply are present. Thus
`they can be allocated dynamically. They can even be based
`on a flow parameter (e.g., a network address or a port)
`allocated dynamically. A flexible mapping of a flow to entity
`binding to the configuration rules is thereby possible.
`The detection of a new instance of an entity associated
`with a flow on the network can be achieved in different
`ways.
`For example, this can be achieved by responding to a flow
`event in respect of the entity, for example by detecting a flow
`which does not already have a correct QoS allocated to it.
`Thus, in one embodiment of the invention the protocol
`headers (eg. the headers of packets) for a flow are examined
`and flow parameters are extracted therefrom. A comparison
`with established rules (policies) can be used to identify flows
`having a specific configuration rule which is representative
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6,154,776
`
`4
`of a new instance of an entity associated with a flow. The
`detection of a flow which does not have any Specific rules
`assigned to it can be Subjected to a default rule and also be
`interpreted as a new instance of an entity associated with that
`flow.
`Alternatively, or in addition, the detection of a new
`instance of an entity associated with a flow can be achieved
`in response to a directory event. For instance this can be
`achieved by responding to changes in a directory of a
`directory Service resulting from, for example, events Such as
`a DHCP dynamic allocation phase or a RADIUS authenti
`cation phase.
`One or more flow parameters for a flow associated with
`each new instance of an entity can be used as a key to
`establish a flow to entity binding. The flow parameters can
`include dynamically applicable, or allocatable parameters
`(e.g. an allocated IP address or port number). A QoS
`identification can be accessed from the directory Service by
`looking for an entry for an entity having this key. The QoS
`identification forms an identifier representing the flow to
`entity binding. The QoS identification can then be used in a
`further Stage to retrieve a QoS definition including one or
`more configuration rules for the flow. The QoS definition
`thereby binds the flow to the QoS. As a consequence, the
`QoS definition can then be bound to the entity. In other
`words, therefore, an embodiment of the invention can pro
`vide a method of associating a QoS to a flow belonging to
`an entity.
`The rules (or policies) which form, or are included in, the
`QoS definition can then be applied to, or installed in, a piece
`of network equipment to allocate the QoS to the flow for the
`entity.
`In a preferred implementation of the invention, the net
`work equipment detecting a new instance of a new flow for
`an entity and for allocating the QoS is the same. However,
`these functions could be separated.
`The “entity could be a user, an application, a piece of
`equipment, or other network entity, and need not be a unitary
`entity, but could be a compound entity Such as a group of
`users, a Set of equipment, etc.
`The dynamically applicable flow parameters can be
`extracted from a protocol header and can include one or
`more of, for example, an IP address (either Source or
`destination address depending on the direction of the flow),
`the protocol under which the information flow is operable,
`and Source and/or destination ports. Although the invention
`is particularly directed to Such a dynamic environment, it
`can also be used in an environment where IP allocation is
`Static.
`In accordance with another aspect of the invention there
`is provided a QoS mechanism for allocating a QoS definition
`to a flow on a network. The QoS mechanism includes a
`controller configured to be responsive to detection of a new
`instance of an entity associated with a flow on the network
`to determine a binding between the flow and the entity based
`on at least one parameter of the flow. A directory interface
`is configured to access a QoS definition. The QoS definition
`is maintained in a directory Service of the network and
`includes at least one configuration rule for the flow, whereby
`the QoS definition binds the flow with the QoS. The con
`troller is further configured to be operable to apply at least
`one configuration rule identified by the QoS definition to the
`flow on the network.
`The directory Service maintains a mapping between a flow
`and an entity, a mapping between the QoS identification and
`the entity and a mapping between the QoS identification and
`the QoS definition.
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 9 of 16
`
`

`

`S
`The detection of a new instance of an entity associated
`with a flow on the network could be determined by the QoS
`mechanism itself. Alternatively, this could be determined by
`a separate network element.
`Preferably the mechanism includes cache Storage for at
`least one QoS identification and/or for at least one QoS
`definition and/or for at least one configuration rule. The
`directory interface is then operable initially to access the
`cache for retrieving a QoS identification, QoS definition or
`configuration rule, if present, and if not present to retrieve
`the QoS identification, QoS definition or configuration rule,
`as applicable, from the directory Service.
`The invention also provides a network element compris
`ing a QoS mechanism as described above.
`The invention further provides a QoS Server comprising a
`QoS mechanism as described above.
`The invention can be implemented by means of a QoS
`Software product on a Storage medium.
`BRIEF DESCRIPTION OF THE DRAWINGS
`Exemplary embodiments of the present invention will be
`described hereinafter, by way of example only, with refer
`ence to the accompanying drawings in which like reference
`Signs relate to like elements and in which:
`FIG. 1 is a Schematic representation of a telecommuni
`cations environment including a plurality of Stations inter
`connected via a network;
`FIG. 2 is a Schematic block representation of an inter
`change of information between Servers in the environment
`of FIG. 1;
`FIG. 3 is a Schematic block diagram giving an overview
`of elements of an example of a QoS mechanism;
`FIG. 4 is a Schematic block diagram Showing a directory
`interface of the QoS mechanism of FIG. 3;
`FIG. 5 is a Schematic flow diagram illustrating the opera
`tion of the QoS mechanism interface and a QoS controller of
`the QoS mechanism of FIG. 3 when triggered by a flow
`event,
`FIG. 6 is a Schematic flow diagram illustrating the opera
`tion of a directory interface and a QoS controller when
`triggered by a directory event; and
`FIG. 7 is a Schematic representation of an environment
`with either dynamic or Static address allocation.
`DESCRIPTION OF THE PREFERRED
`EMBODIMENTS
`FIG. 1 is a Schematic diagram illustrating an environment
`forming part of a telecommunications network, in particular
`part of the Internet, in which an embodiment of the invention
`is implemented. Although embodiments of the present
`invention are described in the context of the Internet, it
`should be appreciated the invention is not limited to these
`Specific embodiments, and that it may be implemented in
`other environments.
`In FIG. 1, users 12 communicate via a telecommunica
`tions network, for example a packet Switched telecommu
`nications network (PSTN) 10, for example the Internet,
`operable under a packet Switched protocol, with a server Site
`14, where a number of Servers are connected via a local
`network 18, for example an ethernet network. A network
`access server 16 can provide access to the PSTN 10 from the
`server site. A Quality of Service (QoS) enforcement unit
`controls the allocation and maintenance of QoS to individual
`information flows. A directory Server 22 Supports a directory
`Structure for the network. A router 24 enables routing over,
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6,154,776
`
`6
`for example, an X.25 connection under, for example an
`Asynchronous Transfer Mode (ATM) protocol 26. The
`operation of the whole system illustrated in FIG. 1 is based
`on the Internet Protocol (IP).
`In the system shown in FIG. 1, the QoS enforcement unit
`20 could implement the invention, although alternatively the
`QoS functionality could form an integral part of the network
`acceSS Server 16, or of another element of the network.
`However, in the following description, it is assumed that a
`separate QoS enforcement unit (or QoS server) 20 is pro
`vided.
`Communication between the QoS server 20 and the
`directory Server 22 is achieved using the Lightweight Direc
`tory Access Protocol (LDAP). Details of LDAP may be
`found, for example, in W Yeong, T Howes, and S. Kille,
`“Lightweight Directory Access Protocol", RFC 1777, March
`1995.
`LDAP is a protocol which enables access to an X.500 type
`directory without the resource requirements of the Directory
`Access Protocol (DAP). LDAP enables clients to perform
`protocol operations against Servers by transmitting a proto
`col request describing the operation to be performed to a
`server. The server is then responsible for performing the
`required operations on the directory. After completing the
`required operations, the Server returns a response containing
`any results or reporting any errors to the client which Sent
`the request.
`LDAP needs to operate over a reliable transport service,
`such as, for example the Transmission Control Protocol
`(TCP). LDAP message packets can be mapped directly onto
`the TCP bytestream. The function of the LDAPMessage is to
`provide an envelope containing common fields required in
`all protocol eXchanges. LDAP provides a common message
`field, the message ID. The message ID of any request has a
`value different from the values of any other requests out
`Standing in an LDAP Session of which this message forms
`a part. The same message ID value is provided in each
`LDAPMessage containing a response as that of an LDAP
`Message which contained a request to which the response
`relates.
`LDAP thus provides an environment within which a QoS
`mechanism can acceSS and modify a directory in order to
`acceSS and maintain user parameters for a QoS on a user
`basis for controlling information flow.
`FIG. 2 is a Schematic representation of an interchange of
`information between the network access server 16, the QoS
`server 20 and the directory server 22. It should be noted that
`this relates to the transfer of control information and not to
`the information flows for which it is intended to define a
`OOS.
`The exchange of information represented in FIG. 2 is
`necessary because the network environment is dynamic. For
`example, IP addresses are typically allocated dynamically,
`as a result of which the IP address may not uniquely identify
`a SC.
`In one embodiment the network access server 16 forms a
`network element in the form of a RADIUS client for a
`RADIUS server. The RADIUS client is implemented by a
`directory Server 22 in the present example. It should be
`noted, however, that this is but one embodiment of the
`invention. For example, the network access Server 16 could
`provide the combined functionality of a RADIUS client and
`a RADIUS Server. Indeed, more generally, a network access
`Server need not be provided. For example, in another
`embodiment the network acceSS Server could be replaced by
`a DHCP Server.
`
`IPR2021-00831
`
`Daedalus EX2020
`Page 10 of 16
`
`

`

`15
`
`7
`In the present embodiment, the network acceSS Server 16
`as well as the QoS server 20 and the directory server 22 are
`configured to be operable under the LDAP protocol for the
`eXchange of messages as represented by the pathways 30, 32
`and 34.
`The network access server 16 is thus able to access the
`directory Server for user parameters and also to modify
`information in the directory server. Likewise the QoS server
`20 is able to access both the network access server 16 and
`the directory Server 22 for information. In use, for example,
`from user Session to user Session, the user may be dynami
`cally allocated an available IP address by the network access
`server 16. The network access server 16 is then able to
`access the directory Server 22 to inform the latter and to
`update the latter with the current information about the user.
`Under LDAP, it is possible to retrieve user profiles using
`fields of IP packet headers and to change the QoS of the
`information flow(s) from the retrieved information.
`The QoS server 20 is able to obtain user parameters from
`the directory server 22 (and/or the network access server 16)
`and to use this to define QoS factors for the user. However,
`the QoS server 20 cannot rely on user parameters directly
`(e.g. a user IP address) to allocate a QoS, as the user's IP
`address may change. Consequently, the direct use of user
`parameters would not guarantee a consistent and reliable
`application of a QoS for that user. In addition, it may be
`desired to allocate a different QoS for different instances of
`the user being active on the network. For example, a
`different QoS may be required between first and second
`addresses as between first and third addresses.
`Accordingly, the QoS Server 20 associates an identifier to
`the user for an information flow (i.e. a flow to user binding),
`which can be constant from Session to Session for that flow,
`even if the parameters associated with the flow for the user,
`for example the IP address, change.
`FIG. 3 is a schematic overview of aspects a QoS mecha
`nism 42. The QoS mechanism may be part of the QoS server
`20, although it could be implemented at another location, for
`example in a network access server. A QoS controller 40 is
`responsive to events which are indicative of a new instance
`of an entity associated with an information flow Selectively
`to access the directory of a directory Service by means of a
`directory interface 44. The controller 40 may make a deter
`mination of Such an event itself in response to information
`received via the QoS mechanism interface 43.
`For example, the QoS mechanism interface 43 can Sample
`packets relating to information flow and extract from the
`packet headers (the protocol headers) at least Selected
`parameters representative of the flow. Such parameters can,
`for example, relate to a user (e.g., IP source or destination
`addresses), a Service (e.g., a protocol and/or a Source or
`destination port), a type of Service value and/or the header
`of a URL (Universal Resource Locator). The controller 40
`can be arranged to make a comparison of the Selected
`parameters to established rules (policies) and, in accordance
`with a logical or deterministic algorithm, to determine
`whether the flow represents a new instance of an entity
`associated with the flow.
`Alternatively, it may receive a report of Such an event
`60
`from the directory service via the directory interface 44. A
`report from the directory Service can be generated automati
`cally in response to, for example, a directory entry being
`updated by RADIUS server or a DHCP server (not shown).
`Such a directory entry update can occur as a result of, for
`example, the dynamic allocation of a flow parameter (e.g. an
`IP address or port) to an entity, a record of the allocation then
`
`45
`
`50
`
`55
`
`65
`
`6,154,776
`
`25
`
`35
`
`40
`
`8
`being made by the RADIUS or DHCP server in the entry for
`the entity in a directory of the directory service. The auto
`matic reporting of the update can be pushed to the directory
`interface by means of a conventional filter arrangement and,
`for example, a replication or other conventional automatic
`reporting mechanism. The directory interface could be
`arranged to poll the directory Service, although this would be
`less efficient.
`The QoS controller 40 and the QoS interface 43 can be
`thought of as Separate components, or their functions could
`be combined. The QoS mechanism 42 can be implemented
`as a Software mechanism on conventional computing hard
`ware (e.g. a computer including conventional components
`Such as memory, processor, display, user input devices, etc.).
`Thus the QoS controller 40 and the interfaces can be
`implemented by code Stored in an execution memory and
`executed on a processor. The memory can thus form a carrier
`medium for the QoS mechanism 42. The QoS mechanism 42
`can also be Supplied as a computer program product on a
`disc, over a network communication line or any other carrier
`medium. Alternatively, the QoS mechanism can be imple
`mented at least in part by Special purpose hardware, for
`example one or more ASICS.
`FIG. 4 is a Schematic block diagram showing the directory
`interface in more detail. In this particular embodiment, the
`directory is based on the X.500 model, implementing the
`Lightweight Directory AcceSS Protocol. In a preferred
`example the directory Server provides an event notification
`service as illustrated in FIG. 4, for example by means of a
`replication or other automatic reporting mechanism.
`The directory 54 maintained by the directory service
`(which could be a distributed directory) comprises a hier
`archical arrangement of entries 56 including entries for
`entities. The entry for an entity can contain, for example, the
`identification of that entity and also the current value of one
`or more parameters allocated to it, Such as, for example, an
`IP address or port allocated to it. The entity entry can thus
`define a mapping, or binding between an entity and one or
`more, possibly dynamically allocatable, flow parameters.
`The entity entry is updated to take account of the allocation
`of the dynamically allocatable flow parameters, whereby it
`is always possible to derive the current b