Method and nodes for aggregating data traffic through unicast messages over an access domain using service bindings

(54) Title: METHOD, ACCESS EDGE NODE AND ACCESS NODE TO PERFORM DATA TRAFFIC AGGREGATION THROUGH AN ACCESS DOMAIN USING SERVICE CONNECTIONS (30) Unionist Priority: 12/27/2005 us 11 / 316,740, 14 / 02/2005 US 60 / 651,971.25 / 04/2005 US 60 / 674,307, 12/27/2005 US 11 / 316,740 (73) Holder (s): telefonaktiebolaget lm ericsson (PUBL) (72) Inventor (s): benoittremblay, martin julien,

MATHIEU GIGUERE, SYLVAIN MONETTE (74) Attorney (s): Momsen, Leonardos & CIA.

(86) International Order: pct ib2006050311 de27 / 0i / 2006 (87) International Publication: wo 2006 / 085234de 17/08/2006 (57) Abstract: method, access edge node and ACCESS node TO PERFORM AGGREGATION OF TRAFFIC FROM DATA THROUGH AN ACCESS DOMAIN USING SERVICE LINKS. The present invention relates to a method and nodes for performing aggregation of data traffic across an access domain using service links. Upon receipt of a service request related message on an access edge node for a first device in a user domain, the service request related message identifying the first device in the user domain and one of the service provider domains , a service link is created at the access edge node. The service link governs data traffic between the first device in the user domain and the service provider domain by committing an access node serving the user domain and the access edge node in a way to manage data traffic between them through the access domain. An access node serving the user domain for which the service request related message is received is informed of the service link created. The service link created is required on the access node and access edge node for data traffic through the access domain between the first device in the user domain and the service provider domain by removing a MAC address from the user of Unidifusion messages exchanged between them through the access domain and replacing with a virtual MAC address recognized by the access node and the access edge node.

Device

DA = virtual EM MAC address

SA = user device MAC address bytes

<img file="BRPI0607337A2_D0001.tif" />

VLAN Tag = service ID bytes ^ -750

User data

46-1500 bytes

Access node

DA = virtual EM MAC address

SA = virtual access node MAC address

Type

VLAN Tag ~ Service Agent

User data

700b

Access edge node

DA = virtual EM MAC address

SA = user device MAC address

Type

VLAN

Tag = service identification id.

Service provider domain

J “METHOD, ACCESS EDGE NODE AND ACCESS NODE TO PERFORM DATA TRAFFIC AGGREGATION THROUGH AN ACCESS DOMAIN USING SERVICE CONNECTIONS”

Priority declaration under 35 USCS119 (e) and 37 CFR 5 S.1.78

This non-provisional patent application claims priority based on previous US provisional patent applications entitled 'Poly project' and 'Access node-edge node complex protocol (AEP)', having respective application number 60 / 651,971, filed on February 14, 2005, in the 10 names of Sylvain Monette, Mathieu Giguere, Martin Julien and Benoit Tremblay, and Order number 60 / 674,307, filed on April 25, 2005, in the names of Sylvain Monette, Mathieu Giguere, Martin Julien and Benoit Tremblay.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to a method and nodes for performing data traffic aggregation relying on Unidiffusion messages in an environment using service connections through an access domain.

Description of Related Art

Recent years have seen the explosion of Internet Protocol (IP) networks. Initially developed to allow universities and researchers to communicate and cooperate in research projects, it has grown into networks offered at a mass market level. Nowadays, it is normal for 25 households to have a connection to an IP network to surf the wide worldwide network, play interactive games, take Voice over IP, upload documents and software, make electronic business transactions, etc.

Reference is now made to Figure 1, which represents an example of the prior art of an IP 100 network. Typically, an IP network is composed of an access domain 115, network service provider domains 140 and service provider domains. application service 150. Access domain 115 includes Access Nodes (AN) 120 and an access network 130, such as an IP network. ANs 120 are network providers that can provide access to the IP network 130 for user domains 110. User domains 110 include for example User Devices (UDs) (such as computers, mobile phones, personal digital assistants, etc.), Local Area Networks (LANs) and wireless LANs (W-LANs). User domains communicate with ANs through several possible technologies. Among these technologies, dial-up connections and Asymmetric Distribution Subscriber connections can be found over telephone lines, cable modem connecting via cable television networks, or wireless communications. Access network 130 is composed of a group of independent routers, which task is to route incoming data traffic based on a destination address embedded in it. As for the network service provider domains 140, they can correspond for example to Voice services over IP, while the application service provider domains 150 can correspond to electronic banking and electronic business transactions.

Although Figure 1 describes three user domains, two Access Nodes, two service provider domains and two application service domains, IP 100 networks typically include several thousand user domains, dozens of Access Nodes, hundreds of service provider domains and application service provider domains. As for access network 130, it is common to find networks including hundreds of routers. It is thus understood that Figure 1 describes a highly simplified IP 100 network for the sake of clarity.

To ensure a coordinated exchange of data and message traffic across such IP networks, the IP protocol was developed in the early 1970s. IP version 4 (IPv4) is used by a majority of IP networks deployed today. IPv4 provides an addressing scheme using 32 bits, which results in some 4,294,967,296 possible addresses, where each address is unique, and directly identifies a device. In the case of IP 100 networks such as the one shown in Figure 1, it is commonly known that such a network relies on data connection based on Ethemet to provide fast and simple transfer and traffic of data and messages across the IP 100 network.

But with the growing number of devices communicating over IP networks, and some inherent limitations of IPv4, the IP community saw the need for a new IP revision: IP version 6 (IPv6). This new version relies on an addressing scheme using 128 bits, which provides a much wider number of possible addresses.

Although IPv6 allows for a much larger number of IP addresses, and also addresses some shortcomings found in IPv4, both IPv4 and IPv6 are 'best effort' protocols. 'Best effort' means that a network delivers data traffic without making a particular effort to satisfy higher or particular demands on the quality of service required for these types of data traffic. This could be sufficient for some network service providers 140 and application service providers 150, but unfortunately it proves to be insufficient for others. Thus, some network service providers 140 and application service providers 150 cannot easily and expediently offer their services over IP 100 networks.

To overcome this problem, Multiprotocol Tag Switching (MPLS) is being used over IP networks. MPLS relies on protocols such as the Reservation Protocol (RSVP) to reserve a path, with a specific quality of service, through the IP 100 network. RSVP initially creates a path through a series of routers. To create the path, each router adds an entry to its MPLS table. This input indicates data traffic arriving at a specific input port and having a predetermined tag, a corresponding output port and a tag to be used. By creating such reserved paths on the IP 100 network, it makes it possible to carry data traffic to a wider spectrum of network service providers 140 and application service providers 150.

However, with the growing number of network service providers 140 and application service providers 150 requiring higher quality of service than 'best effort', along with an expansion in the number of User Domains 110 and Access Nodes 120 required for allowing these User Domains 110 the possibility to use access network 130, MPLS does not prove to be a good option.

The initial principle at the base of IP networks is to rely on routers that perform as few and small operations as possible before routing incoming data traffic to its final destination. It is also a widely recognized concept that 'best effort' networks are a compromise between quality of service and amount of data traffic. An increased quality of service for the same number of routers results in a lower amount of data traffic being carried on those routers. IP networks were not designed with a higher level of quality of service in mind. Thus, by creating reserved paths for higher quality of service data traffic over IP networks, a direct consequence is a reduced amount of data traffic through these IP networks. In addition, such reserved paths needed for MPLS result in consuming more routing effort on each router in the reserved paths. Such routing effort is not significant when only a few reserved paths are opened simultaneously, but with the current development of service applications requiring more than 'best effort' quality of service, it is possible to sense that thousands of reserved paths will be required simultaneously through the IP networks. Maintaining and routing data traffic with so many reserved paths will become more of a hassle for routers, thus also resulting in delayed routing capabilities of the affected routers. Therefore, the current use of MPLS over IP networks to improve quality of service is resulting in less data traffic being exchanged, and slower data traffic. Such impacts are not acceptable, as they directly affect all data traffic that is not part of the reserved paths.

There is currently no known solution to the problems associated with the explosion in the number of user devices and service providers offering services over IP networks. In addition, no long-term solution has been identified to allow for a tangible and non-destructive solution to the increased QoS need for certain services and applications.

Therefore, it should be readily appreciated that in order to overcome the shortcomings and disadvantages of existing solutions, it would be advantageous to have a method and nodes to efficiently aggregate data traffic using service connections across access domains, and more particularly a method and nodes. to aggregate data traffic using Broadcast messages, it is needed. The present invention provides such a method and we.

Summary of the Invention

The present invention efficiently allows thousands of network service provider domains and application service provider domains to communicate through an access domain efficiently using service calls. The method and nodes of the present invention perform aggregation of data traffic across the access domain using service calls and modifying Broadcast messages.

To do so, the method of the present invention performs aggregation of data traffic across an access domain using service links, by receiving a service request related message on an access edge node for a first device on a user domain by creating a service link on the access edge node. The service request related message identifies the first device in the user domain and one of the service provider domains. The service link governs data traffic between the first device in the user domain and the service provider domain by committing an access node serving the user domain and the access edge node in a way to manage data traffic between them through the access domain. The method also informs the access node serving the user domain for which the service request related message is received from the created service call. Then, the method forces the service link created on the access node and the access edge node for data traffic through the access domain between the first device in the user domain and the service provider domain by removing a MAC address user device of Unidifusion messages exchanged between them through the access domain and replacing with a virtual MAC address recognized by the access node and the access edge node.

Another aspect of the present invention relates to an access edge node for performing aggregation of data traffic across an access domain using service links. More particularly, the access edge node is located in the access domain between user domains and service provider domains. The access edge node includes an input / output unit, a service agent unit and a controller unit. The input / output unit receives a service request related message for a first device from a user domain to a service provider domain, and receives and forwards Unidiusion messages. The service agent unit creates a service connection. The service link governs data traffic between the first device in the user domain and the service provider domain through the access domain. The service link commits an access node serving the user domain and the access edge node representing the service provider domain in operation of data traffic between them through the access domain. The controlling unit informs the access node serving the user domain for which the service request related message is received from the creation of the service link by the input / output unit, and enforces the service link created on the access edge node for data traffic between the first device in the user domain and the service provider domain through the access domain by removing a MAC address from the Unified Messaging user device and replacing with a virtual MAC address recognized by the access node and the access edge node.

In another aspect, the present invention is directed to an access node to perform aggregation of data traffic across an access domain using service links. The access node is located between user domains and the access domain. The access node includes an input / output unit, an aggregation unit and a controller unit. The input / output unit routes data traffic from user domains through the access domain and receives messages related to the service call. The aggregation unit stores and manages service calls. The controlling unit evaluates the service call messages received at the input / output unit and updates the stored service calls accordingly. The controller unit, in turn, controls data traffic and enforces stored service calls by removing a user device MAC address from Unicast messages received from the user domain and replacing it with a virtual MAC address from a user. access edge node.

Brief Description of Drawings

For a more detailed understanding of the invention, for additional purposes and advantages, reference can now be made to the following description, taken together with the accompanying drawings, in which:

Figure 1 is an example of the prior art of an IP network;

Figure 2 is a schematic illustrating a network in which the present invention has been incorporated;

Figure 3 is a simplified flow chart of a method for administering service calls in accordance with the present invention;

Figure 4 is a schematic representation of an access edge node in accordance with the teachings of the present invention;

Figure 5a is an exemplary tabular representation of the contents of a service agent administration and control unit according to the present invention;

Figure 5b is an exemplary tabular representation of the content of a service link host unit in accordance with the teachings of the present invention;

Figure 6 is a schematic representation of an access node in accordance with the teachings of the present invention;

Figure 7a is a diagram representing the modifications performed on the network for Unidifusion messages upstream of data traffic; and

Figure 7b is a diagram representing the modifications performed on the network for Unidifusion messages downstream of data traffic.

Detailed Description of Preferred Embodiments

The innovative teachings of the present invention will be described with particular reference to the various exemplary embodiments. However, it should be understood that this class of embodiments provides only a few examples of the many beneficial uses of the innovative teachings of the invention. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed aspects of the present invention. In addition, some statements may apply to some inventive features, but not others. In the drawings, the same or similar elements are designated with identical reference numerals across the various views.

The present invention provides a method and nodes for efficiently aggregating data traffic across an access domain using service links. To do so, an access edge node is introduced within the access domain, between user domains and service provider domains. The access edge node includes a service agent unit, which manages and controls service agents. Each of the service agents corresponds, on the one hand, to one of the service provider's domain, and on the other hand, manages and controls for this purpose a Virtual Local Area Network (VLAN) through the access domain. Whenever a user domain wants to communicate with a selected one of the service provider domains, a service request related message is sent to the access edge node. The service request-related message includes information identifying one from the service provider domain and one from the user domain. The access edge node determines whether one of the service agents matches the service provider domain identified in the service request related message, in which case it creates a service link for the service request related message received. The service link identifies one of the service agents, user domain information, and access domain transport primitives. Then, an access node serving the requesting user domain is informed of the creation of the service link, and execution of the service link is performed on the access node and access edge node thus to aggregate data traffic between them according to the service link created. The following paragraphs will provide a more detailed explanation of how service agents, service calls, and the access edge node and access node are woven together to manage service calls.

The term 'data traffic' is used throughout this specification and relates to messages and information transferred over a data network.

To understand the present invention and its inventive mechanisms, reference is now made to Figure 2, which is a schematic example of a network 200, in which the present invention has been incorporated. The schematic representation of network 200 has been simplified for the sake of clarity, and the various elements described have been grouped by similar functions instead of graphically representing geographic network entities. However, each group of similar functions would typically correspond to a multitude of physical network entities performing these specific functions, geographically spread across network 200. The schematic representation of network 200 includes user domains 110, an access domain 115 (including: access nodes 120, an access network 130, an access edge node 160 and a regional network 135), network service providers 140, and application servers 150. An exhaustive description and examples for each of these elements will be provided in the following paragraphs, with continued reference to Figure 2.

Network 200 corresponds to one or multiple data networks communicating together. Thus, network 200 could be operated by one or multiple operators. As data networks are usually supported by several different operational entities and / or organizations, it is necessary to define how these entities and organizations can communicate successfully. For this reason, data networks are usually explained and detailed using the Open System Interconnection (OSI) model. The OSI model defines a network connection structure to implement protocols in seven layers. These seven layers are in the respective order: 1) Physical layer; 2) Data Link Layer; 3) Network layer; 4) Transport layer; 5) Session layer; 6) Presentation layer and 7) Application layer. Each layer corresponds to an aspect to be considered and actions to be taken when executing the data transmission through a data network. Using the OSI model to describe the network 200 of the present invention, it is possible to layer some of the various protocols used and / or supported by the network 200 of the present invention as follows:

Layer 2: Ethemet, Asynchronous Transfer Mode; Layer 3: Internet Protocol (IP) versions 4 and 6;

Layers 4 and 5: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP); and

Layers 6 and 7: various presentations and application protocols currently existing and to come.

It should be understood that the foregoing list of protocols is provided for exemplary purposes, rather than to limit the protocols supported by the present invention.

Returning now to access domain 115, it is possible to summarize its function as a means to provide point-to-point access between user domains 110 and network service providers 140 and application service providers 150. The access domain includes access nodes 120, access network 130, regional network 135 and access edge node 160. Thus, access domain 115 is not an entity per se; it is instead an aggregation of components, which when interconnected together both directly and indirectly, acts as a domain to provide access, hence its name 'access domain'. It should also be clear that the current representation of access domain 115 including only an access node 120, an access network 130, an edge access node 160 and a regional network 135 does not mean that such entities are found unique in the domain of access, but instead for the sake of clarity only one such entity is represented. The following paragraphs explain in greater detail the various components of the access domain.

Access nodes 120, which also include access portals (not shown), represent the first component of access domain 115. Access nodes 120 typically refer to access providers, which allow user domains 110 access to the network access 130, for example, on a subscription basis or pay per use. Such access can be made using several possible means and technologies. Possible means include cable, landline phone, and cordless phone. Regarding possible technologies, Digital Integrated Services Network (ISDN) and Asymmetric Digital Subscriber Line (ADSL), Worldwide Interoperability for Microwave Access (WiMax) are examples of possible technologies. However, it should be noted that the present invention is not limited to those means or technologies. Also, although only three access nodes have been described, it should be noted that network 200 potentially includes hundreds or thousands of access nodes.

The access domain also includes access network 130 and regional network 135 which will be discussed together. The primary function of access network 130 and regional network 135 is to provide point-to-point, independent transport between access nodes 120 and network service providers 140 and application service providers 150. The access network 130 and regional network 135 are networks capable of tasks such as: aggregation, switching and routing of downstream and upstream data traffic. Access network 130 is preferably capable of using Ethemet, or other similar protocols, which correspond to Layer 2 of the OSI model, but is not limited to this. It could be advantageously capable of supporting IPv4 and / or IPv6. Regional network 135 preferably supports Ethemet and / or IP and MPLS, and possibly other Layer 3 capable protocols. In addition, it should be noted that access network 130 and regional network 135 could be operated and / or administered by a single operator or by many different operators.

It is by tightly coupling their traffic engineering capabilities through access edge node 160 that access network 130 and regional network 135 can provide point-to-point Quality of Service (QoS). The role of the access edge node 160 is the creation, administration and hosting of service agents 170 and service calls (not shown in Figure 2, but described in Figure 4). Each of the service agents 170 corresponds to one of the service provider domains (140 or 150) and manages and controls for this purpose a VLAN through access network 130. The term 'service connection' refers to a connection between user domain 110 and one from network service provider domain 140 or one from service provider domain 150. The access edge node and the concepts of service agents and service connections will be described in further detail in the description with reference to Figures 4, 5a and 5b.

Returning now to user domains 110, the former relies on access domain 115 to operate peer-to-peer communication with network service providers 140 and application service providers 150. It should be noted that in this description, use of The word 'domain' refers to one or multiple elements sharing similar functional characteristics. Thus in the context of the present invention, the term 'user domains' can refer to independent computers, local computer networks connected by a router either physically or wirelessly, cordless phones, Assistants

Personal Digital Devices (PDAs), and all other devices that are capable of communicating data over a data network such as the 200 network. In addition, the term 'user domain' is also intended to include multiple simultaneous data traffic sessions executed with a multitude of devices, through a single user port. For example, a user could simultaneously access different network applications and services such as Internet access, video conferencing, and television programs with one or multiple devices via a VLAN located in the user domain, or a single user port referred to here as' user domain '.

Network service providers 140 refer for example to entities that use access domain 115 to provide IP addressing and connectivity to another IP network, and to offer and deliver a specific application. In the context of data traffic with user domains 110, network service providers 140 typically own and assign IP addresses to user domains 110, using identification based on for example Remote Authentication Dialed User Service (RADIUS). Network service providers 140 can perform user-level authentication and authorization plus forwards if desired and / or necessary.

Application service providers 150 use access domain 115 to offer and deliver applications to end users in user domains 110. Examples of such applications include games, video on demand, video conferencing, and many other possible applications. It is, however, access domain 115 that names IP addresses on behalf of application service providers for user domains 110. If desired, application service providers 150 can also perform user-level authentication and authorization if necessary. It should be noted that in the preceding description, the expression 'service providers' and' service provider domains' will be used alternatively to simultaneously represent both network service providers 140 and application service providers 150, and the expression 'provider Service Provider 'represents one of the network service providers 140 or application service providers 150.

Reference is now made to Figure 3, which represents a simplified flow chart of a method for administering service connection according to the present invention. The present method performs service connection management through access domain 115, which carries data traffic between a plurality of network service providers 140 and application service providers 150, and user domains 110. The method can optionally start with a step 300 to establish a plurality of service agents at the access edge node 160. However, it should be noted that the step 300 of establishing a plurality of service agents will not be performed each time, but instead when an access edge node 160 is introduced in access domain 115. Thereafter, the method begins at step 310 with the receipt of a service request related message at access edge node 160. The service request related message identifies one of the service providers and one of the user domains. The service request-related message may have been generated, for example, by access by the identified user domain from a web page of the identified service provider. The method proceeds with a step 320 to identify whether one of the established service agents matches the identified 140 or 150 service providers. The method then has a step 330 to determine whether a new service call is needed. If determination step 330 is positive, the method proceeds with step 340 of creating a service link for the service request related message received. The method then proceeds with step 350 of informing an access node 120 responsible for providing access to the user domain identified in the service request related message, of the creation of the service link. The access node 120 is thus informed that data traffic received from the user domain identified in the service request related message and addressed to the identified service provider is to be aggregated through the access domain according to the created service link. The method continues with step 360, which consists of forcing the service link created so to aggregate data traffic to be transported through access domain 115, received at the access node or at the access edge node for the user domain and identified service provider, according to the service link created. In the event in step 330 that it is determined that a new service call is not needed, the method furthermore proceeds with a step 370 to determine whether a service call already exists for the message related to the service request received and requires modification. In the event that the result of determination step 370 is that a service call already exists, but does not require modification, the method then continues back to step 310 and waiting for another service request message to be received in step 310. However, in the event that the result of determination step 370 is that a service link already exists and requires modification, the method continues with step 380 to verify that the corresponding existing service link requires to be removed at step 380. If the service link needs to be removed, the method continues at step 390 with removing the service link from the access edge node, and information step 350 from the service link access node to be removed and the force 360 ​​to remove the service link. In the event that it is determined that the service link does not need to be removed at step 380, the method then continues at step 395, where the modifications indicated in the service request message received are performed, and the method continues from that point to step 350 Examples of modifications to the service link including adding or removing a device from the user domain, modifying quality of service requirement, and many other examples, as further described.

As previously mentioned, a service connection relates to a transport relationship. This transport relationship is established between one of the user domains and one of the service providers, and directly influences the service access node 120 and one of the service agents 170 of the access edge node 160. Conceptually speaking, the creation of a service connection corresponds to adding the identified user domain to the VLAN corresponding to the service provider domain through the access domain. Thus, each service call represents a negotiable business entity, which guarantees the delivery of the corresponding service, with the right integrity and QoS, between a specific user domain user port and a specific service provider provider port. Service bindings are created, administered and hosted on the access edge node, and exist in combination with service agents 170.

Since service agents and service calls are created, managed and hosted at the access edge node, reference is now made simultaneously to Figures 2 and 4, where Figure 4 is a schematic representation of an access edge node accordingly with the teachings of the present invention. To be able to perform the tasks of creating, administering and hosting service agents and service calls, the access edge node is made up of multiple elements. Because of its location in access domain 115, the access edge node includes an input / output unit including an access domain input / output unit 410 to communicate with access network 130 of access domain 115 and with access nodes 120. It is also the access domain entry / exit unit 410 that receives the messages related to service request 420. The inbound / outbound unit of access edge node 160 also includes an inbound / outbound unit of network service provider / application domains 430 to communicate with network service providers 140 and application service providers 150 through the regional network 135. In addition, access edge node 160 includes a service agent unit 440, a controller unit 450, and may furthermore include a translation table 460, a shipping unit 470 and a regulatory unit 480.

Service agent unit 440 is comprised of a service agent administration and control unit 442 and a service link host unit 444. Service agent unit 440 maintains information for existing service agents 170 in the service unit administration and control of service agents 442. The unit of administration and control of service agents 442 is in turn responsible for the creation and administration of service calls 446. To do so, the service agent administration and control unit 442 determines when service new service calls 446 are required or can be removed, and proceeds to create / remove service calls 446. The service administration and control unit 442 service agents are also responsible for adding / removing user devices for existing service calls. In addition, the service agent administration and control unit 442 is responsible for ensuring synchronization of information related to service calls 446 with access nodes with which it is interacting. The service agent administration and control unit 442 is also responsible for creating reserved MultiProtocol Label Switching (MPLS) paths on access network 130, when such a reserved path is required. Figures 7 and 8 of the accompanying description will provide an exhaustive explanation of the various messages used by the 442 service agent administration and control unit to perform its various responsibilities.

Reference to Figure 5 a, which represents an exemplary tabular representation of the content of the 442 service agent administration and control unit, is now made simultaneously with Figure 4. Each of the rows in Figure 5 a, with the exception of the first row, which is a header row, represents exemplary content from one of the service agents 170 administered and controlled by the service agent administration and control unit 442. Each of the columns in Figure 5a corresponds to the specific information, maintained by the service agent administration and control unit 442, for each of the service agents 170. The first column represents an identification of the service agent 170. This identification is typically a numeric identifier acting as a service agent identifier. According to a preferred embodiment of the invention, each service agent at the access edge node has a unique service agent identifier and corresponds to a specific service provider domain 140 or 150. The second column refers to an a specific type of service for the corresponding service agent. For example, in cases where a 140 or 150 service provider domain offers multiple services, each of the services offered is associated with a different type of service so to differentiate between the various services of a service provider domain. The third column identifies the preferred or necessary Quality of Service (QoS) required to correctly transport data traffic to that service provider domain and the type of service related. Exemplary criteria for QoS may include delay, bit error rate, bandwidth, and preferred protocol. The fourth column indicates a port to be used on the regional network to communicate with the corresponding service provider domain. In addition to this content, the service agent administration and control unit 442 includes enough logical software and hardware to create additional service agents and remove unnecessary service agents. It should also be noted that although the content of the service agents' administration and control unit has been represented in Figure 5a in the form of a table, such content is not limited to this. The unit of administration and control of service agents could be composed of a relational database, physical coded components, microprocessors, programming library, etc.

Reference is now made to Figure 5b, which represents an exemplary tabular representation of the content of the service link host unit 444, simultaneously with Figure 4. Each of the rows in Figure 5b, with the exception of the header row, represents exemplary content of any of the service calls 446 hosted on the service call host unit 444. Each of the columns in Figure 5b corresponds to specific information, hosted on the service host connection unit 444, for each of the service connections 446. The first column represents an identification of a corresponding service agent, using for example the service identifier. service agent service agent. The second column identifies the type of service, as described in relation to Figure 5a. The other columns represent the transport primitives for data traffic related to the service link. More specifically, the third column identifies a user domain's Media Access Control (MAC) address. The fourth column consists of an identification of a port used by the user domain on the service access node. The fifth column corresponds to the arbitrary LAN identifier used by the user domain, and can include, for example, implicit or explicit VLAN information. The sixth column refers to a virtual MAC address of the access node serving the user domain. Consequently, each service link 446 links together one of the service agents, one of the user domains and one of the access nodes to provide data traffic between a user domain and a 140 or 150 service provider domain. It should be noted that although the content of the service link host unit 444 has been represented in Figure 5b in the form of a table, such content is not limited to that. The service link host unit could consist of a relational database, physical coded components, microprocessors, a programming library, etc.

In addition, the service link host unit may furthermore contain a seventh column, which includes an IP address uniquely identifying the user's domain or a user's device. This unique IP address could be provided to the user domain or user device by the access edge node using a protocol such as the Dynamic Host Configuration Protocol (DHCP), using for example a broadcasting mechanism that could be performed before the service request message. The combination of the service agent identifier and the unique IP address of the user domain or user device thus represents a simple and secure way to quickly connect incoming messages to the right service link. Typically, once the service link has been created, the access node has been informed of this, and data traffic is being aggregated across the access domain according to the service link, the aggregate data traffic received at the node access edge is disaggregated prior to its referral to the corresponding service provider domain using the information provided in the service links host unit. More particularly, in the case where the access domain is an Ethemet network, the service agent identifier is provided, for example, in the field known as the VLAN Unified Broadcast Tag, Multicast and Broadcast messages, while the IP address user domain or user device is provided in IP messages embedded in Ethemet's messages. Based on the service agent identifier provided in the Ethemet message VLAN Tag field, and the IP address provided in the embedded IP message, service agent unit 440 can unbundle data traffic and secure its delivery to the domain corresponding service provider, and inclusion of necessary information in the sender's user domain, such as MAC user information and its local network context.

Returning now to the description of Figure 4, the controller unit 450 of the access edge node is responsible for determining, upon receipt of the message related to service request 420, if it corresponds to one of the service agents. To do so, the controlling unit 450 consults the service agent administration and control unit 442 to determine whether one of the service agents 170 matches the service provider domain identified in the service request related message 420. In the event that one of the service agents 170 corresponds to this, the controller unit 450 instructs the service agent administration and control unit 442 to create a service link 446 for the message related to the service request received. Creating a service link 446 for the received service request message 420 includes adding an entry in the service link host unit 444, where:

the agent service ID (first column) corresponds to the service agent identifier for the service agent corresponding to the requested service provider domain;

the user MAC information is the user device MAC address;

the user port on the access node is an identification of the port on the service access node to which the user device is connected;

the LAN context corresponds to an arbitrary identifier provided in a field labeled 'VLAN tag' of messages from Ethemet to be received from the user device and corresponding to a local user domain identifier; and the access node MAC is a virtual MAC address for the access node serving the user device for which the service request related message was received.

Then, the control unit 450 informs the access node serving the user domain identified in the service request related message, by a service connection message 490 sent by the access domain entry / exit unit 410, of the creation of the access domain. service link 446. In the event that a service link already exists for service request-related message 420, controller unit 450 informs the service access node of the existing service link by a message related to service link 490.

Controller unit 450 also interacts with translation table 460. Since each service agent 170 of the service agent administration and control unit is uniquely identified by a service agent identifier, it is necessary to maintain a mapping in the translation table between the service agent identifier corresponding to 170 service agents and corresponding service provider domains (140 or 150). Thus, on receiving data traffic on the access domain input / output unit 410 having a destination address corresponding to a virtual MAC address for access edge node 160 and a VLAN tag corresponding to one of the access identifier. service agent, controller unit 450 queries translation table 460 for a quick translation of the virtual MAC address of the access edge node to the destination service provider's domain address (140 or 150) corresponding to the service agent identifier provided in the VLAN tag.

The controller unit 450 furthermore consults the shipping unit 470 to determine whether data traffic received at the access domain input / output unit 410 is to be forwarded directly to the service provider's domain input / output unit without any modification. .

Finally, the controller unit 450 can also interact with a regulatory unit 480, which can run on data traffic received both at the access domain input / output unit 410 and at the domain service provider input / output unit. network / application 430, policing and marking downstream / upstream traffic, rescheduling traffic, as indicated and / or required by 170 corresponding service agents.

Reference is now made to Figure 6, which is a schematic representation of one of the access nodes according to the teachings of the present invention. Because of its location in access domain 115, access node 120 includes an access domain input / output unit 610 to communicate with access network 130 of access domain 115 and the access edge node 160. Access node 120 also includes a user domain input / output unit 620 to communicate with user domains 110. One type of message received at access domain input / output unit 610 is the message related to the connection service 490. Messages related to service link 490 are generated by access edge node 160, and sent through access network 130. Examples of service connection messages 490 will be provided in the description of Figures 7 and 8.

Access node 120 is capable of receiving and operating multiple messages related to service connection 490. Messages related to service connection 490 are received on access node 120 of access network 130, by the domain entry / exit unit of access 610. Upon receipt of a message related to service link 490, the access domain input / output unit forwards the message related to received service link 490 to controller unit 630. The control unit 630 extracts the contact from the message related to the service call 490, and determines if there are actions to be taken. An example of a message related to the 490 service link is information about creating a new service link. As previously described, when the access edge node 160 determines that a new service link is required, it proceeds with its creation and informs the access node serving the requesting user domain of the creation of the service link. The 490 service call related message used in this particular example is called ADD_SB (add service call). The ADD_SB message is sent from access edge node 160 to access node 120, and contains information about the created service link. The information contained in the ADD_SB message must then be incorporated into an aggregation unit 680 of access node 120.

One of the various responsibilities of the 680 aggregation unit is hosting information related to service calls. Service link related information contains specific service link information (in the form of service agent identity and service type), identification on a port of the access node that received the service request related message, and network context user domain location.

Access node 120 furthermore handles incoming data traffic originating from / destined for user domains to which it provides access service to access network 130. To do so, access node 120 furthermore contains a translation table 650, a shipping unit 660, regulatory unit 670 and aggregation unit 680. To do so, data traffic received at access node 120 either by user domain input / output unit 620 or access domain input / output unit 610 is forwarded to controller unit 630. Controller unit 630 interacts with the 650 translation table. Since each service call stored in the service call host unit 444 of the service agent unit 440 is identified by a combination of parameters (service agent identity, service type, user device MAC address and address virtual MAC access node), it is necessary to maintain in the translation table 650 a mapping between the service agent identity corresponding to service agents 170 and corresponding service provider domains (140 or 150). Thus, on receiving data traffic on the access domain input / output unit 610 having a destination address corresponding to the virtual MAC address of the access node 120, the controller unit 630 queries translation table 650 for a translation destination address and VLAN tag so to match the user domain MAC address and local identifier respectively. Such a translation is required, because the user domain information is not carried through the access domain between the access edge node 160 and the access node 120.

Controller unit 630 also consults shipping unit 660 to determine whether data traffic received at access domain input / output unit 610 or user domain input / output unit 620 is to be forwarded directly to the corresponding user 110 or access network 130 without any modification.

Finally, controller unit 630 can also interact with a regulatory unit 670. Interaction with regulatory unit 670 is required, for example, when policing and marking downstream / upstream traffic, rescheduling of traffic is required, as indicated in the properties service connection.

Now that access node 120 and access edge node 160 have been described in detail, the background more fully describes how data traffic is aggregated across the access domain. In typical Ethemet networks, three types of messages are used to exchange data traffic between two entities: Broadcast messages, Multicast messages and Broadcast messages. Unidiffusion messages are used to exchange data traffic between a sender and a recipient. Multicast messages are used to efficiently send data traffic from one sender to multiple recipients. About Broadcast messages, they are used to send messages from one sender to all nodes on the network. The present invention focuses on using service calls in conjunction with Unidiffusion messages to aggregate data traffic across the access domain.

Reference is now made to Figures 7a and 7b. Figure 7a describes modifications performed on the network for Unidiffusion messages in the upstream data traffic, in accordance with the present invention. Figure 7b is a diagram representing the modifications performed on the network for Unidiffusion messages in the downstream data traffic. In this application, upstream data traffic refers to data traffic sent from user domain 110 to one of service provider domain 140 or 150, while downstream data traffic refers to data traffic sent from the provider domain service 140 or 150 for one of user domains 110. Figures 7a and 7b describe Ethemet Unidiffusion messages for exemplary purposes, as described in International Electrical and Electronic Engineering (IEEE) 802.3ac. Unicast messages typically include the following fields: a Destination Address (DA) 710, a Source Address (SA) 720, a Type 730, a VLAN Tag 740 and User Data 750. Destination Address 710 refers to an address to which the Unidifusion message is intended, and consists of 6 bytes. The Source Address 720 indicates from which address the Unicast message originates, and contains 6 bytes. The Type 730 field is 2 bytes long. The VLAN Tag 740 is 4 bytes long, and usually refers to a VLAN identifier that is only known and significant for the destination address and the source address. Finally, user data 750 varies between 46 1500 bytes, and contains data traffic being sent from source address 720 to destination address 710.

Now returning more specifically to Figure 7a, a broadcast message originating from User Device 110 is represented by its various modifications over the network in accordance with the present invention. The User Device generates a Unifiedcast message 700a, in which: Destination Address 710 corresponds to a virtual MAC address for access edge node 160, Source Address 720 is the MAC address of the user device and the VLAN Tag 740 corresponds to a local service identifier for the user device. The Unicast message 700a generated by the user device is sent and received by the access node 120, where some modifications are performed by the controller unit 630 before forwarding the Unicast message through the access network 130. More particularly, the source address 720 is replaced with a virtual MAC address for the access node, and the VLAN Tag is changed to match the service agent ID. The access node identifies the service agent identification of the service calls stored in the aggregation unit. By replacing the MAC address of the user device, the access node improves the performance of the access network 130 by reducing the learning and switching table of all routers and switches within the access network 130. The modified Broadcast 700b message is sent from the access node through access network 130 to the access edge node. The access edge node receives the modified Broadcast message 700b, and changes back the source address 720 and the VLAN Tag 740 to match the source address and the VLAN Tag provided initially by the User Device in the Unidiusion message. 700c. To do so, the access edge node relies on the service link information stored in the service link host unit 444. The Unity message 700c is sent from the access edge node 160 to the destination service provider domain 140 or 150.

Referring more specifically to Figure 7b, a description of the modifications to the Uni-Fusion message in downstream data traffic is now provided. The Unity message 700d is generated in the service provider domain 140 or 150. The 700d Unity message has a destination address corresponding to the user device MAC address, a source address equivalent to the service provider MAC address, and a VEAN tag corresponding to the local service identification known to the user domain . Access edge node 160 receives the Unidiíusion 700d message and intercepts it to modify its content before sending it on access network 130. Access edge node 160 changes the destination address to match a virtual MAC address of the service access node, modifies the source address to be the virtual MAC address of the access edge node, and replaces the label of VLAN by service agent identification, to get the Unity message 700e. These modifications are performed by the service link based access edge node existing on access edge node 160 for data traffic between the receiving user device of the sending service provider domain. Unity message 700e is sent from access edge node 160 to service access node 120 through access network 130. Upon receiving the Unidiíusão 700e message on access node 120, the former relies on its controller unit 630 and its aggregation unit 680 to identify which service link it relates to, and to modify the Unidiíusion message

700e to bring it up in a way that will be recognizable by the user device 110. To do so, access node 120 changes the destination address to match the user device's MAC address, and modifies the user field. VLAN tag to match the local service ID, known to user device 110.

As can be seen, the modifications to the Unidiffusion message are only visible to access node 120, access network 130 and access edge node 160. The modifications to the Unidiffusion message are transparent to user device 110 and the service provider domain 140 or 150. Modifications are possible because of the service link created by access edge node 160, and bound to both access node 120 and access edge node 160. The service link stored in the access node and the access edge node store the information required to carry out the modifications to the broadcast messages. The results of the modifications include the aggregation of data traffic to various service provider domains 140 or 150 by the access edge node 160, and better management of the access network resources 130, without influencing user domains 110 and service provider domains 140 and 150.

Although several preferred embodiments of the method and nodes of the present invention have been illustrated in the accompanying drawings and described in the preceding Detailed Description, it will be understood that the invention is not limited to the exposed embodiments, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as published and defined by the following claims.