What are the differencess between virtual-circuit and virtual-switch?
Good Question. First, Let me add a picture, it's worth a thousand words. Then I'll add an additional comment.
In the above diagram: The Admin-user will need to provision traffic-profiles (TP) at each end of the EVC point-to-point circuit, or point-to-multipoint circuits (located between the UNI and the VS), scheduling is a uni-directional shaper only, so it'll need to be provisioned at voth ends of the Circuit.. On the Ingress-to-Egress flow, Qmapping, NTE RCOS MAP and Traffic-profiling are configured, prior to entering into the VC/VS. As I stated, in the above diagram, the TP shaping is between to UNI port and the VS depicted here.
An EVC (Ethernet Virtual Circuit) is built, which is comprised of a virtual-circuit (VC) with a virtual-switched (VS) attached to the VC; these handle the C-vlan and the S-vlan tagging through (ingress/egress) on the Ciena devices. One VC can have many VSes in it. Each RG is assigned a dedicated EVC service. Each EVC traverses the entire customer path. As described, these are virtual paths for all the customers traffic, through the network.
Hi Frederick Valcho!
I don`t think, that your statement is right: "One VC can have many VSes in it." You can assign only one Ethernet VC to a VS on Ciena devices. And an already assigned VC can not be assigned to another VS. So it is a 1:1 relation. From my point of view a MEF EVC is not the same as a VC used in Ciena Switch configuration. MEF EVC stands for a circuit between two endpoints (UNIs) end-to-end. Ciena uses VCs to encapsulate pakets. There are MPLS VC, Ethernet VC or PBT VC (PBT Services). Die Ethernet VC just stacks the S-VID to the Ethernet Header.Rüdiger
It is true that a 1:1 VC/VS ratio does exist, it makes no sense for MEF to have implemented such a strict restriction for EVC usage.
Remember, there are 3 logical typologies; P2P, MP2MP, and MP2P. Each translates to one of the MEF models for connectivity-based service types: E-Line, E-Lan, and E-Tree. Point to Multi-point (or MP2P) is the model I was referring. This is where a single CE UNI port can have up to 64 VLANs (Customer vlan traffic) configured per port. )This number differs between Ciena Models and software versions). If each VID is a customer (Virtual-switch), then all 64 VCs can be attached to a single Virtual-Circuit that can used to transport that CE ort traffic, to the far end, and vise-a-versa. In one example, IPTV cna broadcast (multicast) the same program from the CO and head-end, to many users at the far end. Each customer has its own Service Level Agreement (SLA) and SAP thru the Providers network/cloud that is used to tunnel his/her traffic. This is designed so that VIDs are separated and for security, as well as preventing bleeding over of unwanted or undesired traffic to an unwanted port/customer. In the same manner, each customer can use their Remote to add channels, change channels, and tag programs for recording, thru their SLA/SAP, without disrupting any other customer. Further, this same customer can connect to the Internet and surf via a laptop (one or more laptops) or cell phone, and get additional data delivered thru the EVC to them.
The service provider may have 64 tenents in a building that has requested HSIA and/or Wi-Fi service from this Internet Service Provider (SP), but the Ciena device has only 8 available ports, as a cost savings so that a hefty 48 port device is not an unnecessary expense. By adding multiple Customer EVCs to a single port, and attaching them all to a single VC, data is provided at a better cost-per-port for the SP, and hopefully to the end customer. The downside is the per-port bandwidth if the UNI port is a 1gig port. So Traffic-profiling per service is employed, with each SLA having its own QoS, etc. The NNI would then be Aggregated with 4x1gig ports for 4gigs, or perhaps 1 to 4x10 gig ports aggregated for 40G uplink.
The VS/VS ratio is determined by the users and the provider. One customer may wish to buy the whole 1 gig for his factory. 1:1. Sound like frame-relay?
Let me know if this helps. Maybe this is still not correct.
So many details in the explanation. Yes the Virtual switch has caused a lot of confusion for the customers that were introduced to the Ciena Ethernet portfolio. One simple explanation could be that it is actually a functional »entity« you use when you configure the services inside the Ciena Ethernet device. Something like an airport where at one side the cars, busses and trains arrive and on the other side the airplanes leave to other airports. Like Rüdiger Michl I also think that the VC should not be related to the MEF EVC. It is another functional » entity« used by Ciena for the creation of services inside the Ethernet device. Why has Ciena introduced the VS »entity« or concept? Ciena switches have many functionality you do not see in a »standard« L2 switch. They had to find a way to somehow configure these functionality so they needed an »entity« to »stick« the functionality to in the CLI configuration scripts. So, if the VS is the airport what is the VC?
Klaus Smardžić, my answer in comparison to the airport:
Let's understand the Ciena device as the airport.
Might this helps?
No comparison is 100%. However this »check in desk« fort he VS is excellent.
Perhaps a better explanation is the Truck/Train scenario. One truck can deliver goods between LA and NY, or many trucks can drive between the 2 cities, P2P. Or, a train can load each truck on the track as individual cargoes, and delivery them all to NT, saving time and expenses. Each truck would contain different cargo for different individual deliveries, but all would be transported via the train system across the country. MP2MP or MP2P.
Retrieving data ...