Interactions with MTO module

One of the biggest advantages of this architecture is to perform the distribution of multiparty data with QoS. Hence, it is necessary to implement interactions between the NUM element, which performs the intelligent context-aware network selection, and other modules that work in the network physical layer in order to eectively reserve or release resources in the utilized paths. In this way is guaranteed the quality of the delivery trac.

Regarding the scalability of the approach proposed by C-CAST architecture, the MTO module is used as intermediate between the NUM block and the lower levels of the network. In this sense, the exchange of messages between dierent network layers is reduced, being optimized its overall performance and achieving a scalable model.

Therefore, it is necessary to implement the interactions with MTO so the reserva- tions and releases can be made. Due to lower level requirements, more precisely MIRA

module specications, the reservation or release of an entire path has to be divided into Sub-AMTs reservations or releases. This fact also implies that the required parameters exchanged with MTO while reserving one Sub-AMT are dierent to the parameters needed to communicate a reserve in a dierent Sub-AMT. Thus, in order to inform MTO of these parameters so the reservations and releases can be executed, NUM lls a packet header with the information and passes it as argument to an MTOAgent function which eectively performs the desired operations.

Therefore, it can be said that this MTO module works as a proxy, changing the source and the destination of the packets when necessary. For example, when dierent users that wish to receive the same multiparty content are connected in dierent access points, it must be created a multicast tree along the network to serve all of them. So, in order to have the same multicast group, all the branches of the tree should have the same destination according to the multicast group.

In Table 11 are described the packet header elds and their importance to the execution of these functions.

hdr_rsv – Packet header used iteraction with MTO to reserve a path path

src dst bw CoS

Vector containing the interior nodes of the path Source of the reservation

Destination of the reservation Bandwidth reserved Class of Service of the flow flag_Mult Flag indicating either unicast or multicast

flag_IPv Flag indicating if it is a IPv4 or IPv6 reservation grp

fid

Group to be reserved Flow identifier

pxy_src Proxy Source

pxy_dst Proxy Destination

Table 11: Packet header structure used reserve a path.

In order to better understand the parameters elds, and their importance, the Figure 18 shows an example of a reservation made between the session source node and the user T1. The table in this gure describes the values of the elds in the packet header that are used to communicate a reservation of each Sub-AMT. In case of release a path, the parameters passed are exactly the same as in the reservation.

Wi-Fi T1 NUM ION2 IPT _IPT IPT IPT IPT IPT IPT IPT IPT IPT IPT _IPT ION1 ION3 CN1 CN2 CN3 CON1 CN4 CN5 EON3 EON2 EON1 ON-enabled routers ON-disabled routers Session Source 4 3 2 1 Reservation Request 1 Reservation Request 2 Reservation Request 3

Reservation Request 4 -> T1 join-group 1

src dst fid grp bw CoS flag_M flag_I pxy_src pxy_dst path

Session Source ION1 1 1 100 40 1 0 Session Source Session Source [ ION1 ]

ION1 CON1 1 2 100 40 1 0 ION1 2 [ CN1 CON1 ]

CON1 EON2 1 3 100 40 1 0 CON1 3 [ CN5 EON2 ]

fid = 1 group = 1 rate = 100Kb CoS = 4

Figure 18: Path reservation example.

As it is mandatory to interact with MTO to reserve and release paths, it is also crucial to communicate with it in order to collect some useful information. For instance, as was previously referred in order to do multicast grouping is necessary to know what group is used in the previous reservations so this group can be associated to the current reservation. Nevertheless, it is also required to know which the parameters of a certain reservation are, so it can be released. Hence, every time that multicast group is required to perform a reservation or a release, a request is sent to MTO so this information can be acquired.

To reserve a path that embraces several Sub-AMTs, there is one parameter that should be carefully handled, as can be observed in the Figure 18. After dividing the whole path into dierent Sub-AMTs, the reservation is communicated to MTO. Still, when reserving the Sub-AMT that includes the source of trac, i.e. the rst Sub-AMT of the path, the variable pxy_dst refers to the source node address. On the other hand, if the reservation is being done for another Sub-AMT, this variable should be stated as the multicast group to be reserved in this Sub-AMT. The code implemented to reserve a path is described in the Figure 19 that refers to the function treat_MTOreserve.

Treat_reserveMTO Path_to_Reserve CoS Source_mGroup Fid Bandwidth Flag_Mult Source_Address AP_Address User_address

Start analizing the path since the last element, that represents the AP Yes No

The

Path_to_Reserve

variable is empty? Will be established the

connection between the AP and the user

The user supports multicast (Flag_Mult = 1 ) ? The proxy already exists? Ask MTO if this AP has

already a proxy made for the Source_mGroup

Inform MTO about the parameters to implement the proxy to

the multicast group

Join the user to the multicast group especificated in Source_mGroup Update userPosition structure End

Inform MTO about the parameters to implement the proxy to the unicast connection

Search backwards in the path for another ON, to form a Sub-AMT

to reserve

Is this Sub-AMT the closest to source of traffic?

State pxy_src parameter equal to the

first element of the Sub-AMT

This Sub-AMT embraces any unicast node?

Allocate an unused multicast group and store it in pxy_dst and

in group

pxy_dst – Source_Address

src - initial element of

Sub-AMT

dst - last element of Sub-

AMT

Inform MTO of the parameters to reserve

this Sub-AMT

Is this Sub-AMT the closest to source of traffic?

Erase this Sub-AMT from the

Path_to_Reserve

variable Consider the last

element of Path_to_Reserve pxy_src – Source_Address pxy_dst – Source_Address group – Source_mGroup Yes Yes Yes Yes Yes No No No No No

Figure 19: Reservation process of an entire path.