 In order to make sure that all the requirements which have been spelled out for Ethernet based NGN quality of service provisioning, a reference architecture has to be considered. This reference architecture shall form the basis for us to consider all the functional requirements and the network elements which would be then required to implement these. For that, in this module, we are going to look at the Ethernet connection as an end-to-end process and the boundaries between the access and the core side have to be addressed because that is where the QS mechanisms have to be particularly monitored and ensured. Then we are going to look at these interfaces and then we are going to look at the Ethernet based virtual connections which are carrying the user traffic between two endpoints. So once we say that we have Ethernet as a service, it is actually an end-to-end service which spans across multiple network and operators and service providers. So you can think about a concatenation of these operators and providers. Now since they each have different scopes, the access side, the core side, so we have to define some kind of interfaces, so Ethernet defines certain interfaces in the form of the user-to-network interface and the network-to-network interface. Now these interfaces have their own scopes with regards to the functionality they are supposed to provide. Naturally, when we talk about the access side, so the operation, administration and maintenance and the virtual private network service provisioning are not inherent to the UNI side. Likewise, the network-to-network interface is more concerned about encapsulated traffic which is handled by the routers. But in this case, since we are talking about Ethernet, so we have switches all across. So it means that the VLAN tags such as provided in 802.1Q standard have to be understood and incorporated at the network-to-network side as well. And then the user-to-network interface frame that leaves the customer premises, the access side enters into the core side has to, has now had to be incorporated as payload in the link layer frame at the network-to-network interface. Let's look at the reference architecture in a little more detail. We already know that we have the service stratum and the relevant entity with regards to the qualitative service is the service control function. Here for the sake of simplicity, we have two distinct SCFs A and B basically managing the QS aspects for the network A and network B. Here the point of concern is that we have the Ethernet at the transport stratum. So we have the customer premises equipment which speaks Ethernet-based IEEE 802.3 protocol. So we have between the customer premises equipment and the core, the access network side, we have the user-to-network interface. And then from the one network or one service provider or one network operator to another, we have the network-to-network interface. And then on the last mile that is on the other side of the connection, we have another user-to-network interface between the penultimate transport network, B in this case, and the customer premises equipment. So we are now looking at the network interfaces both on the user side and between these networks. Now the Ethernet virtual connections are basically the way to go or the mechanism for a carrier Ethernet provisioning. That is when a carrier Ethernet is talking to an access site Ethernet network, then Ethernet virtual connections have to be established. These virtual connections transcend or go beyond the user-to-network interface. These are actually established between two end-to-end UNIs. We've already discussed it and we know that the service types which can be provided by these virtual connections can be the E-line, E-lan and E-tree. Different formations or different connectivity or topological ways through which these services can be offered. Now we know that the tagging done for virtual LAN as in 802.1Q has QS support using three priority bits. So we steal three priority bits from the tag and we use it for up to eight different quality of service classes. So we can say that eight different QS mechanisms or QS differentiations can be provided for certain QS mechanisms. Depending upon the total combinations between the bandwidth profiling that is done on the basis of MAC addresses or IP addresses or even the flows at the transport layer, the bandwidth profile is the categorization of traffic falling into certain bandwidth requirements. This is one aspect of QS provisioning. Then we have the class of service that we've already seen. So if you combine the bandwidth profile and the class of service, four possible combinations can exist. For instance, it can be one-to-many, many-to-one or many-to-many. Let's look at these. So we can have a single class of service based virtual connections with one bandwidth profile. It means we are looking at multiple flows, each having its own bandwidth profile which is the same as others. So we don't have a problem. We have one bandwidth profile that is only a single bandwidth profile and we have single class of service. In this case, all the frames belonging to a single class of service with single bandwidth profile would be treated exactly in the same way in terms of how these packets are scheduled and in the wake of some competition or network congestion, how the traffic is shaped. Then we have the second type where we have single class of service and we have multiple bandwidth profiles. In that case, definitely the class of service based traffic behavior as in scheduling and traffic shaping is going to be consistent for all the flows, but since each have its own bandwidth profile, so the quality of service aspect based on bandwidth allotment is going to vary. Then we have multiple class of service virtual connections for a single bandwidth profile. It is self-explanatory where we are going to have multiple class of service flows, but the bandwidth requirements for all these are the same. And the most complex one is once we have multiple class of service based virtual connections, each having its own specific and different bandwidth profile. So these virtual connections would each dictate different resource availability and this is going to determine a changing behavior and different requirements for the RSEF. Let's talk a little more on the concept of interfacing and how these interfaces are implemented. A single UNI and a single NNI both can support more than one virtual connections because each virtual connection actually refers to a unique socket or a unique process between two endpoints. Another important aspect here is that the VPNs which are enabled between NNI's are actually the transport mechanisms for IP packets between distinct parties. So it means that some kind of translation mechanism is also needed to map the VPNs from the NNI to the UNI. Then another important and interesting dimension emerges because since we are talking about all switching paradigm and if the switched network, which is the Ethernet on the exercise and as well as on the carrier grade is now integrated or dovetailed with MPLS enabled networks, then the VLAN IDs are not needed because MPLS works on the basis of the labels. So it means some kind of mechanism has to be provisioned which translates the VLAN IDs into MPLS understandable labels. And likewise, once we are talking about all switched environment, up within a large LAN, we were using the spanning tree protocol to converge the switched network and to avoid any loops there. But once we are talking about quality of service, then spanning tree can be replaced with QS based routing protocols. So we are talking about switching mechanisms, all switching paradigm, but it is QS enabled switching elevated to routing because switching is done within a single IP domain or IP subnet. But when we are talking about the scope, which is enlarged, so the IP addresses may not be changing, but since we are talking about interfacing the access side as well as the core side, so some kind of routing kind of mechanism has to be implemented, which supports QS.