Hechos ocurridos después del período sobre el que se informa

VSDN provides end-to-end quality of service for real-time video applications. VSDN uses the network-wide view to provision and select path that supports video application QoS requirements including bandwidth, delay, and jitter. VSDN sup- ports three types—CIF, ED, and HD [200]. VSDN uses a variation of the A*prune algorithm to find Constrained Shortest Path First (CSPF) [307, 319].

VSDN simplifies application programmable interface (API) for video applica- tion developer, requiring minimal input to request service. VSDN has four mes- sage types, request—requests QoS from network, the video application generates a request message, accept—starts session, the receiver generates an accept message, re- move—explicitly removes session from the network, the sender or receiver can generate a remove message, and error—indicates an error condition, the sender, receiver, con- troller, or switch can generate an error message. The sessions are implicitly removed by the network devices if flow timeout occurs [70].

VSDN operates on a single network domain. Although VSDN finds optimum path within a single network domain, it may not find optimum multi-domain path—paths across independent network domains that are stitched together to create an end-to- end path.

For example, in Figure 6.1, the best path for video application with respect to bandwidth, delay, and jitter is path Domain2-Domain3-Domain1 from sender A to receiver B. The VSDN controllers in Domain1, Domain2, and Domain 3 configure their paths independent of one other.

To initial session with receiver B, sender A sends a request message to R1, R1 forwards the request message to VSDN controller1. The controller determines sender A can reserve network resources within Domain1 and receiver B is unreachable from Domain1. The controller returns request message to R1 which forwards the request message over default path to R2. R2 forwards request message to R4—highest weight, local preference, or shortest path, in Figure 6.1. R4 forwards request message to

VSDN controller2. The controller in Domain2 determines receiver B is reachable from Domain2. The VSDN controller returns request message to R4 that forwards the request message through the default path to R6. R6 forwards request message to receiver B.

Upon receiving request, receiver B accepts the request from sender A by generating an accept message. The accept message is sent to R6. R6 forwards accept message to VSDN controller2. The controller performs admission control and policy control on request from receiver B. The controller in Domain2 calculates end-to-end path and installs flow rules and queues in receiver B, R6, and R4—path receiver B-R6- R4. After installing flow rules and queues, the controller returns accept message

to R6. R6 forwards accept message to R4. R4 forwards accept message to R2.

R2 forwards accept message to VSDN controller1. The controller receives accept message from R2 and performs admission control and policy control. The controller that manages Domain1 installs path sender A-R1-R3-R2 and returns accept message to R2. R2 forwards accept message to R3 and R3 forwards the accept message to R1 and R1 forwards accept message to sender A. The VSDN network has finished installing the multi-domain path between sender A and receiver B—path Domain1- Domain2; however, the best path for video application using bandwidth, delay, and jitter constraints is path Domain1-Domain3-Domain2.

The VSDN network is unable to select the best path for real-time video application across multi-domains because it lacks multi-domain flow management. The VSDN networks independently select the multi-domain path using local domain routing in- formation. The multi-domain paths when stitched together may not be best path for real-time video applications.

One can attempt to solve this issue by having one VSDN controller program Domain1, Domain2 and Domain3 using slices [164]. Slices allow a single physical network to be used by multiple programs without harmful interference [164]. The network slices are static and are unable to be programmed dynamically [164].

Although VSDN networks select optimum path of a single domain, relying on VSDN networks to select feasible multi-domain path result in worst-case multi-domain path being selected. Selecting a feasible multi-domain paths requires two issues to be addressed.

Issue 1: Develop a network service layer that supports optimum multi- domain path selection among independent network domains. Selecting a multi-domain path across domains is feasible using a multi-domain network service layer that provides traffic engineering service. Selecting paths independently across domains, in Figure 6.1 may result in worst-case path being selected for real-time interactive video applications. A multi-domain network service layer with end-to-end visibility across domains needs to be developed.

Issue 2: Develop a control protocol that allows independent VSDN controllers to communicate with the network service layer and inform the network service layer of internal network state changes. A protocol that allows the controllers to request traffic engineering service from network service layer needs to be developed. The protocol should allow the controllers to inform the network service layer about internal state changes such as bandwidth, delay, and jitter [279, 328].