Home > Articles > Networking > Wireless/High Speed/Optical

This chapter is from the book

This chapter is from the book

Metro Ethernet Services Concepts

The Metro Ethernet Forum is a nonprofit organization that has been active in defining the scope, concepts, and terminology for deploying Ethernet services in the metro. Other standards bodies, such as the Internet Engineering Task Force (IETF), have also defined ways of scaling Ethernet services through the use of MPLS. While the terminologies might differ slightly, the concepts and directions taken by these different bodies are converging.

For Ethernet services, the MEF defines a set of attributes and parameters that describe the service and SLA that are set between the metro carrier and its customer.

Ethernet Service Definition

The MEF defines a User-to-Network Interface (UNI) and Ethernet Virtual Connection (EVC). The UNI is a standard Ethernet interface that is the point of demarcation between the customer equipment and the service provider's metro Ethernet network.

The EVC is defined by the MEF as "an association of two or more UNIs." In other words, the EVC is a logical tunnel that connects two (P2P) or more (MP2MP) sites, enabling the transfer of Ethernet frames between them. The EVC also acts as a separation between the different customers and provides data privacy and security similar to Frame Relay or ATM permanent virtual circuits (PVCs).

The MEF has defined two Ethernet service types:

  • Ethernet Line Service (ELS)—This is basically a point-to-point (P2P) Ethernet service.

  • Ethernet LAN Service (E-LAN)—This is a multipoint-to-multipoint (MP2MP) Ethernet service.

The Ethernet Line Service provides a P2P EVC between two subscribers, similar to a Frame Relay or private leased-line service (see Figure 3-5).

Figure 5Figure 3-5 Ethernet Service Concepts

Figure 3-5 also illustrates the E-LAN, which provides multipoint connectivity between multiple subscribers in exactly the same manner as an Ethernet-switched network. An E-LAN service offers the most flexibility in providing a VPN service because one EVC touches all sites. If a new site is added to the VPN, the new site participates in the EVC and has automatic connectivity to all other sites.

Ethernet Service Attributes and Parameters

The MEF has developed an Ethernet services framework to help subscribers and service providers have a common nomenclature when talking about the different service types and their attributes. For each of the two service types, ELS and E-LAN, the MEF has defined the following service attributes and their corresponding parameters that define the capabilities of the service type:

  • Ethernet physical interface attribute

  • Traffic parameters

  • Performance parameters

  • Class of service parameters

  • Service frame delivery attribute

  • VLAN tag support attribute

  • Service multiplexing attribute

  • Bundling attribute

  • Security filters attribute

Ethernet Physical Interface Attribute

The Ethernet physical interface attribute has the following parameters:

  • Physical medium—Defines the physical medium per the IEEE 802.3 standard. Examples are 10BASE-T, 100BASE-T, and 1000BASE-X.

  • Speed—Defines the Ethernet speed: 10 Mbps, 100 Mbps, 1 Gbps, or 10 Gbps.

  • Mode—Indicates support for full duplex or half duplex and support for autospeed negotiation between Ethernet ports.

  • MAC layer—Specifies which MAC layer is supported as specified in the 802.3-2002 standard.

Traffic Parameters

The MEF has defined a set of bandwidth profiles that can be applied at the UNI or to an EVC. A bandwidth profile is a limit on the rate at which Ethernet frames can traverse the UNI or the EVC. Administering the bandwidth profiles can be a tricky business. For P2P connections where there is a single EVC between two sites, it is easy to calculate a bandwidth profile coming in and out of the pipe. However, for the cases where a multipoint service is delivered and there is the possibility of having multiple EVCs on the same physical interface, it becomes difficult to determine the bandwidth profile of an EVC. In such cases, limiting the bandwidth profile per UNI might be more practical.

The Bandwidth Profile service attributes are as follows:

  • Ingress and egress bandwidth profile per UNI

  • Ingress and egress bandwidth profile per EVC

  • Ingress and egress bandwidth profile per CoS identifier

  • Ingress bandwidth profile per destination UNI per EVC

  • Egress bandwidth profile per source UNI per EVC

The Bandwidth Profile service attributes consist of the following traffic parameters:

  • CIR (Committed Information Rate)—This is the minimum guaranteed throughput that the network must deliver for the service under normal operating conditions. A service can support a CIR per VLAN on the UNI interface; however, the sum of all CIRs should not exceed the physical port speed. The CIR has an additional parameter associated with it called the Committed Burst Size (CBS). The CBS is the size up to which subscriber traffic is allowed to burst in profile and not be discarded or shaped. The in-profile frames are those that meet the CIR and CBS parameters. The CBS may be specified in KB or MB. If, for example, a subscriber is allocated a 3-Mbps CIR and a 500-KB CBS, the subscriber is guaranteed a minimum of 3 Mbps and can burst up to 500 KB of traffic and still remain within the SLA limits. If the traffic bursts above 500 KB, the traffic may be dropped or delayed.

  • PIR (Peak Information Rate)—The PIR specifies the rate above the CIR at which traffic is allowed into the network and that may get delivered if the network is not congested. The PIR has an additional parameter associated with it called the Maximum Burst Size (MBS). The MBS is the size up to which the traffic is allowed to burst without being discarded. The MBS can be specified in KB or MB, similar to CBS. A sample service may provide a 3-Mbps CIR, 500-KB CBS, 10-Mbps PIR, and 1-MB MBS. In this case, the following behavior occurs:

    • Traffic is less than or equal to CIR (3 Mbps)—Traffic is in profile with a guaranteed delivery. Traffic is also in profile if it bursts to CBS (500 KB) and may be dropped or delayed if it bursts beyond 500 KB.

    • Traffic is more than CIR (3 Mbps) and less than PIR (10 Mbps)—Traffic is out of profile. It may get delivered if the network is not congested and the burst size is less than MBS (1 MB).

    • Traffic is more than PIR (10 Mbps)—Traffic is discarded.

Performance Parameters

The performance parameters indicate the service quality experienced by the subscriber. They consist of the following:

  • Availability

  • Delay

  • Jitter

  • Loss

Availability

Availability is specified by the following service attributes:

  • UNI Service Activation Time—Specifies the time from when the new or modified service order is placed to the time service is activated and usable. Remember that the main value proposition that an Ethernet service claims is the ability to cut down the service activation time to hours versus months with respect to the traditional telco model.

  • UNI Mean Time to Restore (MTTR)—Specifies the time it takes from when the UNI is unavailable to when it is restored. Unavailability can be caused by a failure such as a fiber cut.

  • EVC Service Activation Time—Specifies the time from when a new or modified service order is placed to when the service is activated and usable. The EVC service activation time begins when all UNIs are activated. For a multipoint EVC, for example, the service is considered active when all UNIs are active and operational.

  • EVC Availability—Specifies how often the subscriber's EVC meets or exceeds the delay, loss, and jitter service performance over the same measurement interval. If an EVC does not meet the performance criteria, it is considered unavailable.

  • EVC (MTTR)—Specifies the time from when the EVC is unavailable to when it becomes available again. Many restoration mechanisms can be used on the physical layer (L1), the MAC layer (L2), or the network layer (L3).

Delay

Delay is a critical parameter that significantly impacts the quality of service (QoS) for real-time applications. Delay has traditionally been specified in one direction as one-way delay or end-to-end delay. The delay between two sites in the metro is an accumulation of delays, starting from one UNI at one end, going through the metro network, and going through the UNI on the other end. The delay at the UNI is affected by the line rate at the UNI connection and the supported Ethernet frame size. For example, a UNI connection with 10 Mbps and 1518-byte frame size would cause 1.2 milliseconds (ms) of transmission delay (1518 * 8 / 106).

The metro network itself introduces additional delays based on the network backbone speed and level of congestion. The delay performance is defined by the 95th percentile (95 percent) of the delay of successfully delivered egress frames over a time interval. For example, a delay of 15 ms over 24 hours means that over a period of 24 hours, 95 percent of the "delivered" frames had a one-way delay of less than or equal to 15 ms.

The delay parameter is used in the following attributes:

  • Ingress and egress bandwidth profile per CoS identifier (UNI service attribute)

  • Class of service (EVC service attribute)

Jitter

Jitter is another parameter that affects the service quality. Jitter is also known as delay variation. Jitter has a very adverse effect on real-time applications such as IP telephony. The jitter parameter is used in the following service attributes:

  • Ingress and egress bandwidth profile per CoS identifier (UNI service attribute)

  • Class of service (EVC service attribute)

Loss

Loss indicates the percentage of Ethernet frames that are in-profile and that are not reliably delivered between UNIs over a time interval. On a P2P EVC, for example, if 100 frames have been sent from a UNI on one end and 90 frames that are in profile have been received on the other end, the loss would be (100 – 90) / 100 = 10%. Loss can have adverse effects, depending on the application. Applications such as e-mail and HTTP web browser requests can tolerate more loss than VoIP, for example. The loss parameter is used in the following attributes:

  • Ingress and egress bandwidth profile per CoS identifier (UNI service attribute)

  • Class of service (EVC service attribute)

Class of Service Parameters

Class of service (CoS) parameters can be defined for metro Ethernet subscribers based on various CoS identifiers, such as the following:

  • Physical port—This is the simplest form of QoS that applies to the physical port of the UNI connection. All traffic that enters and exits the port receives the same CoS.

  • Source/destination MAC addresses—This type of classification is used to give different types of service based on combinations of source and destination MAC addresses. While this model is very flexible, it is difficult to administer, depending on the service itself. If the customer premises equipment (CPE) at the ends of the connections are Layer 2 switches that are part of a LAN-to-LAN service, hundreds or thousands of MAC addresses might have to be monitored. On the other hand, if the CPEs are routers, the MAC addresses that are monitored are those of the router interfaces themselves. Hence, the MAC addresses are much more manageable.

  • VLAN ID—This is a very practical way of assigning CoS if the subscriber has different services on the physical port where a service is defined by a VLAN ID (these would be the carrier-assigned VLANs).

  • 802.1p value—The 802.1p field allows the carrier to assign up to eight different levels of priorities to the customer traffic. Ethernet switches use this field to specify some basic forwarding priorities, such as that frames with priority number 7 get forwarded ahead of frames with priority number 6, and so on. This is one method that can be used to differentiate between VoIP traffic and regular traffic or between high-priority and best-effort traffic. In all practicality, service providers are unlikely to exceed two or three levels of priority, for the sake of manageability.

  • Diffserv/IP ToS—The IP ToS field is a 3-bit field inside the IP packet that is used to provide eight different classes of service known as IP precedence. This field is similar to the 802.1p field if used for basic forwarding priorities; however, it is located inside the IP header rather than the Ethernet 802.1Q tag header. Diffserv has defined a more sophisticated CoS scheme than the simple forwarding priority scheme defined by ToS. Diffserv allows for 64 different CoS values, called Diffserv codepoints (DSCPs). Diffserv includes different per-hop behaviors (PHBs), such as Expedited Forwarding (EF) for a low delay, low-loss service, four classes of Assured Forwarding (AF) for bursty real-time and non-real-time services, Class Selector (CS) for some backward compatibility with IP ToS, and Default Forwarding (DF) for best-effort services.

Although Diffserv gives much more flexibility to configure CoS parameters, service providers are still constrained with the issue of manageability. This is similar to the airline QoS model. Although there are so many ways to arrange seats and who sits where and so many types of food service and luggage service to offer travelers, airlines can manage at most only three or four levels of service, such as economy, economy plus, business class, and first class. Beyond that, the overhead of maintaining these services and the SLAs associated with them becomes cost-prohibitive.

Service Frame Delivery Attribute

Because the metro network behaves like a switched LAN, you must understand which frames need to flow over the network and which do not. On a typical LAN, the frames traversing the network could be data frames or control frames. Some Ethernet services support delivery of all types of Ethernet protocol data units (PDUs); others may not. To ensure the full functionality of the subscriber network, it is important to have an agreement between the subscriber and the metro carriers on which frames get carried. The EVC service attribute can define whether a particular frame is discarded, delivered unconditionally, or delivered conditionally for each ordered UNI pair. The different possibilities of the Ethernet data frames are as follows:

  • Unicast frames—These are frames that have a specified destination MAC address. If the destination MAC address is known by the network, the frame gets delivered to the exact destination. If the MAC address is unknown, the LAN behavior is to flood the frame within the particular VLAN.

  • Multicast frames—These are frames that are transmitted to a select group of destinations. This would be any frame with the least significant bit (LSB) of the destination address set to 1, except for broadcast, where all bits of the MAC destination address are set to 1.

  • Broadcast frames—IEEE 802.3 defines the broadcast address as a destination MAC address, FF-FF-FF-FF-FF-FF.

Layer 2 Control Processing packets are the different L2 control-protocol packets needed for specific applications. For example, BPDU packets are needed for STP. The provider might decide to tunnel or discard these packets over the EVC, depending on the service. The following is a list of currently standardized L2 protocols that can flow over an EVC:

  • IEEE 802.3x MAC control frames—802.3.x is an XON/XOFF flow-control mechanism that lets an Ethernet interface send a PAUSE frame in case of traffic congestion on the egress of the Ethernet switch. The 802.3x MAC control frames have destination address 01-80-C2-00-00-01.

  • Link Aggregation Control Protocol (LACP)—This protocol allows the dynamic bundling of multiple Ethernet interfaces between two switches to form an aggregate bigger pipe. The destination MAC address for these control frames is 01-80-C2-00-00-02.

  • IEEE 802.1x port authentication—This protocol allows a user (an Ethernet port) to be authenticated into the network via a back-end server, such as a RADIUS server. The destination MAC address is 01-80-C2-00-00-03.

  • Generic Attribute Registration Protocol (GARP)—The destination MAC address is 01-80-C2-00-00-2X.

  • STP—The destination MAC address is 01-80-C2-00-00-00.

  • All-bridge multicast—The destination MAC address is 01-80-C2-00-00-10.

VLAN Tag Support Attribute

VLAN tag support provides another set of capabilities that are important for service frame delivery. Enterprise LANs are single-customer environments, meaning that the end users belong to a single organization. VLAN tags within an organization are indicative of different logical broadcast domains, such as different workgroups. Metro Ethernet creates a different environment in which the Ethernet network supports multiple enterprise networks that share the same infrastructure, and in which each enterprise network can still have its own segmentation. Support for different levels of VLANs and the ability to manipulate VLAN tags become very important.

Consider the example of an MTU building in which the metro provider installs a switch in the basement that offers multiple Ethernet connections to different small offices in the building. In this case, from a carrier perspective, each customer is identified by the physical Ethernet interface port that the customer connects to. This is shown in Figure 3-6.

Although identifying the customer itself is easy, isolating the traffic between the different customers becomes an interesting issue and requires some attention on the provider's part. Without special attention, traffic might get exchanged between the different customers in the

building through the basement switch. You have already seen in the section "L2 Switching Basics" that VLANs can be used to separate physical segments into many logical segments; however, this works in a single-customer environment, where the VLAN has a global meaning. In a multicustomer environment, each customer can have its own set of VLANs that overlap with VLANs from another customer. To work in this environment, carriers are adopting a model very similar to how Frame Relay and ATM services have been deployed. In essence, each customer is given service identifiers similar to Frame Relay data-link connection identifiers (DLCIs), which identify EVCs over which the customer's traffic travels. In the case of Ethernet, the VLAN ID given by a carrier becomes that identifier. This is illustrated in Figure 3-7.

Figure 6Figure 3-6 Ethernet in Multicustomer Environments

In this example, the carrier needs to assign to each physical port a set of VLAN IDs that are representative of the services sold to each customer. Customer 1, for example, is assigned VLAN 10, customer 2 is assigned VLAN 20, and customer 3 is assigned VLAN 30. VLANs 10, 20, and 30 are carrier-assigned VLANs that are independent of the customer's internal VLAN assignments. To make that distinction, the MEF has given the name CE-VLANs to the customer-internal VLANs. The customers themselves can have existing VLAN assignments (CE-VLANs) that overlap with each other and the carrier's VLAN. There are two types of VLAN tag support:

  • VLAN Tag Preservation/Stacking

  • VLAN Tag Translation/Swapping

VLAN Tag Preservation/Stacking

With VLAN Tag Preservation, all Ethernet frames received from the subscriber need to be carried untouched within the provider's network across the EVC. This means that the VLAN ID at the ingress of the EVC is equal to the VLAN ID on the egress. This is typical of services such as LAN extension, where the same LAN is extended between two different locations and the enterprise-internal VLAN assignments need to be preserved. Because the carrier's Ethernet switch supports multiple customers with overlapping CE-VLANs, the carrier's switch needs to be able to stack its own VLAN assignment on top of the customer's VLAN assignment to keep the separation between the traffic of different customers. This concept is called 802.1Q-in-802.1Q or Q-in-Q stacking, as explained earlier in the section "VLAN Tagging." With Q-in-Q, the carrier VLAN ID becomes indicative of the EVC, while the customer VLAN ID (CE-VLAN) is indicative of the internals of the customer network and is hidden from the carrier's network.

Figure 7Figure 3-7 Logical Separation of Traffic and Services

WARNING

The Q-in-Q function is not standardized, and many vendors have their own variations. For the service to work, the Q-in-Q function must work on a "per-port" basis, meaning that each customer can be tagged with a different carrier VLAN tag. Some enterprise switches on the market can perform a double-tagging function; however, these switches can assign only a single VLAN-ID as a carrier ID for the whole switch. These types of switches work only if a single customer is serviced and the carrier wants to be able to carry the customer VLANs transparently within its network. These switches do not work when the carrier switch is servicing multiple customers, because it is impossible to differentiate between these customers using a single carrier VLAN tag.

VLAN Tag Translation/Swapping

VLAN Tag Translation or Swapping occurs when the VLAN tags are local to the UNI, meaning that the VLAN tag value, if it exists on one side of the EVC, is independent of the VLAN tag values on the other side. In the case where one side of the EVC supports VLAN tagging and the other side doesn't, the carrier removes the VLAN tag from the Ethernet frames before they are delivered to the destination.

Another case is two organizations that have merged and want to tie their LANs together, but the internal VLAN assignments of each organization do not match. The provider can offer a service where the VLANs are removed from one side of the EVC and are translated to the correct VLANs on the other side of the EVC. Without this service, the only way to join the two organizations is via IP routing, which ignores the VLAN assignments and delivers the traffic based on IP addresses.

Another example of tag translation is a scenario where different customers are given Internet connectivity to an ISP. The carrier gives each customer a separate EVC. The carrier assigns its own VLAN-ID to the EVC and strips the VLAN tag before handing off the traffic to the ISP. This is illustrated in Figure 3-8.

Figure 8Figure 3-8 VLAN Translation

Figure 3-8 shows the metro carrier delivering Internet connectivity to three customers. The carrier is receiving untagged frames from the CPE routers located at each customer premises. The carrier inserts a VLAN tag 10 for all of customer 1's traffic, VLAN 20 for customer 2's traffic, and VLAN 30 for customer 3's traffic. The carrier uses the VLAN tags to separate the three customers' traffic within its own network. At the point of presence (POP), the VLAN tags are removed from all EVCs and handed off to an ISP router, which is offering the Internet IP service.

Service Multiplexing Attribute

Service multiplexing is used to support multiple instances of EVCs on the same physical connection. This allows the same customer to have different services with the same Ethernet wire.

Bundling Attribute

The Bundling service attribute enables two or more VLAN IDs to be mapped to a single EVC at a UNI. With bundling, the provider and subscriber must agree on the VLAN IDs used at the UNI and the mapping between each VLAN ID and a specific EVC. A special case of bundling is where every VLAN ID at the UNI interface maps to a single EVC. This service attribute is called all-to-one bundling.

Security Filters Attribute

Security filters are MAC access lists that the carrier uses to block certain addresses from flowing over the EVC. This could be an additional service the carrier can offer at the request of the subscriber who would like a level of protection against certain MAC addresses. MAC addresses that match a certain access list could be dropped or allowed.

Tables 3-1 and 3-2 summarize the Ethernet service attributes and their associated parameters for UNI and EVCs.

Table 3-1 UNI Service Attributes

UNI Service Attribute

Parameter Values or Range of Values

Physical medium

A standard Ethernet physical interface.

Speed

10 Mbps, 100 Mbps, 1 Gbps, or 10 Gbps.

Mode

Full-duplex or autospeed negotiation.

MAC layer

Ethernet and/or IEEE 802.3-2002.

Service multiplexing

Yes or no. If yes, all-to-one bundling must be no.

Bundling

Yes or no. Must be no if all-to-one bundling is yes and yes if all-to-one bundling is no.

All-to-one bundling

Yes or no. If yes, service multiplexing and bundling must be no. Must be no if bundling is yes.

Ingress and egress bandwidth profile per UNI

No or one of the following parameters: CIR, CBS, PIR, MBS.

If no, no bandwidth profile per UNI is set; otherwise, the traffic parameters CIR, CBS, PIR, and MBS need to be set.

Ingress and egress bandwidth profile per EVC

No or one of the following parameters: CIR, CBS, PIR, MBS.

Ingress and egress bandwidth profile per CoS identifier

No or one of the following parameters: CIR, CBS, PIR, MBS.

If one of the parameters is chosen, specify the CoS identifier, Delay value, Jitter value, Loss value.

If no, no bandwidth profile per CoS identifier is set; otherwise, the traffic parameters CIR, CBS, PIR, and MBS need to be set.

Ingress and egress bandwidth profile per destination UNI per EVC

No or one of the following parameters: CIR, CBS, PIR, MBS.

Egress bandwidth profile per source UNI per EVC

No or one of the following parameters: CIR, CBS, PIR, MBS.

Layer 2 Control Protocol processing

Process, discard, or pass to EVC the following control protocol frames:

 

IEEE 802.3x MAC control

 

Link Aggregation Control Protocol (LACP)

 

IEEE 802.1x port authentication

 

Generic Attribute Registration Protocol (GARP)

 

STP

 

Protocols multicast to all bridges in a bridged LAN

UNI service activation time

Time value


Table 3-2 EVC Service Attributes

EVC Service Attribute

Type of Parameter Value

EVC Type

P2P or MP2MP

CE-VLAN ID preservation

Yes or no

CE-VLAN CoS preservation

Yes or no

Unicast frame delivery

Discard, deliver unconditionally, or deliver conditionally for each ordered UNI pair

Multicast frame delivery

Discard, deliver unconditionally, or deliver conditionally for each ordered UNI pair

Broadcast frame delivery

Discard, deliver unconditionally, or deliver conditionally for each ordered UNI pair

Layer 2 Control Protocol processing

Discard or tunnel the following control frames:

 

IEEE 802.3x MAC control

 

Link Aggregation Control Protocol (LACP)

 

IEEE 802.1x port authentication

 

Generic Attribute Registration Protocol (GARP)

 

STP

 

Protocols multicast to all bridges in a bridged LAN

EVC service activation time

Time value

EVC availability

Time value

EVC mean time to restore

Time value

Class of service

CoS identifier, Delay value, Jitter value, Loss value

This assigns the Class of Service Identifier to the EVC


Example of an L2 Metro Ethernet Service

This section gives an example of an L2 metro Ethernet service and how all the parameters defined by the MEF are applied. The example attempts to highlight many of the definitions and concepts discussed in this chapter.

If you have noticed, the concept of VPNs is inherent in L2 Ethernet switching. The carrier VLAN is actually a VPN, and all customer sites within the same carrier VLAN form their own user group and exchange traffic independent of other customers on separate VLANs.

The issue of security arises in dealing with VLAN isolation between customers; however, because the metro network is owned by a central entity (such as the metro carrier), security is enforced. First of all, the access switches in the customer basement are owned and administered by the carrier, so physical access is prevented. Second, the VLANs that are switched in the network are assigned by the carrier, so VLAN isolation is guaranteed. Of course, misconfiguration of switches and VLAN IDs could cause traffic to be mixed, but this problem can occur with any technology used, not just Ethernet. Issues of security always arise in public networks whether they are Ethernet, IP, MPLS, or Frame Relay networks. The only definite measure to ensure security is to have the customer-to-customer traffic encrypted at the customer sites and to have the customers administer that encryption.

Figure 3-9 shows an example of an L2 metro Ethernet VPN. This example attempts to show in a practical way how many of the parameters and the concepts that are discussed in this chapter are used.

Figure 9Figure 3-9 All-Ethernet L2 Metro Service Example

Figure 3-9 shows a metro carrier offering an L2 MP2MP VPN service to customer A and a packet leased-line service (comparable to a traditional T1 leased line) to an ISP. In turn, the ISP is offering Internet service to customers B and C. It is assumed that customer A connects to the carrier via L2 Ethernet switches and customers B and C connect via IP routers. Notice the difference between access ports and trunk ports on the Ethernet switches. The ports connecting the customer's Ethernet switch to the carrier's Ethernet switch are trunk ports, because these ports are carrying multiple VLANs between the two switches. When the carrier's switch port is configured for Q-in-Q, it encapsulates the customers' CE-VLAN tags VLAN 10 and VLAN 20 inside the carrier VLAN 100. On the other hand, the ports connecting the customer router with the carrier switch are access ports and are carrying untagged traffic from the router. Tables 3-3 and 3-4 describe the UNI and EVC service attributes for customers A, B, and C as defined by the MEF.

Table 3-3 Customer A E-LAN UNI Service Attributes

Customer A E-LAN UNI Service Attribute

Parameter Values or Range of Values

Physical medium

Standard Ethernet physical interfaces

Speed

100 Mbps site 1, 10 Mbps sites 2 and 3

Mode

Full duplex all sites

MAC layer

IEEE 802.3-2002

Service multiplexing

No

Bundling

No

All-to-one bundling

Yes

Ingress and egress bandwidth profile per CoS identifier

All sites CoS 1:

CIR = 1 Mbps, CBS = 100 KB, PIR = 2 Mbps, MBS = 100 KB

CoS ID = 802.1p 6–7

Delay < 10 ms, Loss < 1%

All sites CoS 0:

CIR = 1 Mbps, CBS = 100 KB, PIR = 10 Mbps, MBS = 100 KB

CoS ID = 802.1p 0–5, Delay < 35 ms, Loss < 2%

Layer 2 Control Protocol processing

Process IEEE 802.3x MAC control

 

Process Link Aggregation Control Protocol (LACP)

 

Process IEEE 802.1x port authentication

 

Pass Generic Attribute Registration Protocol (GARP)

 

Pass STP

 

Pass protocols multicast to all bridges in a bridged LAN

UNI service activation time

One hour after equipment is installed


Note in Table 3-3 that customer A is given only one MP2P EVC; hence, there is no service multiplexing. All customer VLANs 10 and 20 are mapped to the MP2MP EVC in the form of carrier VLAN 100. Customer A is given two Class of Service profiles—CoS 1 and CoS 0. Each profile has its set of performance attributes. Profile 1, for example, is applied to high-priority traffic, as indicated by 802.1p priority levels 6 and 7. Profile 0 is lower priority, with less-stringent performance parameters. For customer A, the metro carrier processes the 802.3x and LACP frames on the UNI connection and passes other L2 control traffic that belongs to the customer. Passing the STP control packets, for example, prevents any potential loops within the customer network, in case the customer has any L2 backdoor direct connection between its different sites.

Table 3-4 Customer A E-LAN EVC Service Attributes

Customer A E-LAN

EVC Service Attribute

Type of Parameter Value

EVC type

MP2MP

CE-VLAN ID preservation

Yes

CE-VLAN CoS preservation

Yes

Unicast frame delivery

Deliver unconditionally for each UNI pair

Multicast frame delivery

Deliver unconditionally for each UNI pair

Broadcast frame delivery

Deliver unconditionally for each UNI pair

Layer 2 Control Protocol processing

Tunnel the following control frames:

 

IEEE 802.3x MAC control

 

Link Aggregation Control Protocol (LACP)

 

IEEE 802.1x port authentication

 

Generic Attribute Registration Protocol (GARP)

 

STP

 

Protocols multicast to all bridges in a bridged LAN

EVC service activation time

Twenty minutes after UNI is operational

EVC availability

Three hours

EVC mean time to restore

One hour

Class of service

All sites CoS 1:

CoS ID = 802.1p 6–7

Delay < 10 ms, Loss < 1%, Jitter (value)

All sites CoS 0:

CoS ID = 802.1p 0–5, Delay < 35 ms, Loss < 2%, Jitter (value)


The EVC service parameters for customer A indicate that the EVC is an MP2MP connection and the carrier transparently moves the customer VLANs between sites. The carrier does this using Q-in-Q tag stacking with a carrier VLAN ID of 100. The carrier also makes sure that the 802.1p priority fields that the customer sends are still carried within the network. Note that the carrier allocates priority within its network whichever way it wants as long as the carrier delivers the SLA agreed upon with the customer as described in the CoS profiles. For customer A, the carrier passes all unicast, multicast, and broadcast traffic and also tunnels all L2 protocols between the different sites.

Tables 3-5 and 3-6 describe customers B and C and ISP POP service profile for the Internet connectivity service. These are the service attributes and associated parameters for customers B and C as well as the service attributes and associated parameters for the ISP POP offering Internet connectivity to these customers.

Table 3-5 Customers B and C and ISP POP UNI Service Attributes

Customers B and C and ISP POP Internet Access UNI Service Attribute

Parameter Values or Range of Values

Physical medium

Standard Ethernet physical interfaces

Speed

10 Mbps for customers B and C, 100 Mbps for the ISP POP

Mode

Full duplex all sites

MAC layer

IEEE 802.3-2002

Service multiplexing

Yes, only at ISP POP UNI

Bundling

No

All-to-one bundling

No

Ingress and egress bandwidth profile per EVC

Customers B and C

CIR = 1 Mbps, CBS = 100 KB, PIR = 2 Mbps, MBS = 100 KB

ISP POP

CIR = 10 Mbps, CBS = 1 MB, PIR = 100 Mbps, MBS = 1 MB

Layer 2 Control Protocol processing

Discard the following control frames:

 

IEEE 802.3x MAC control

 

Link Aggregation Control Protocol (LACP)

 

IEEE 802.1x port authentication

 

Generic Attribute Registration Protocol (GARP)

 

STP

 

Protocols multicast to all bridges in a bridged LAN

UNI service activation time

One hour after equipment is installed


For customers B and C and ISP POP UNI service parameters, because two different P2P EVCs (carrier VLANs 200 and 300) are configured between the customers and the ISP POP, service multiplexing occurs at the ISP UNI connection where two EVCs are multiplexed on the same physical connection. For this Internet access scenario, routers are the customer premises equipment, so it is unlikely that the customer will send any L2 control-protocol packets to the carrier. In any case, all L2 control-protocol packets are discarded if any occur.

Table 3-6 Customers B and C and ISP POP EVC Service Attributes

Customers B and C and ISP POP Internet Access EVC Service Attribute

Type of Parameter Value

EVC type

P2P

CE-VLAN ID preservation

No; mapped VLAN ID for provider use

CE-VLAN CoS preservation

No

Unicast frame delivery

Deliver unconditionally for each UNI pair

Multicast frame delivery

Deliver unconditionally for each UNI pair

Broadcast frame delivery

Deliver unconditionally for each UNI pair

Layer 2 Control Protocol processing

Discard the following control frames:

 

IEEE 802.3x MAC control

 

Link Aggregation Control Protocol (LACP)

 

IEEE 802.1x port authentication

 

Generic Attribute Registration Protocol (GARP)

 

STP

 

Protocols multicast to all bridges in a bridged LAN

EVC service activation time

Twenty minutes after UNI is operational

EVC availability

Three hours

EVC mean time to restore

One hour

Class of service

One CoS service is supported:

Delay < 30 ms, Loss < 1%, Jitter (value)


The EVC parameters indicate that the carrier is not preserving any customer VLANs or CoS info. Also, because this is an Internet access service, normally the provider receives untagged frames from the CPE router. The provider can map those frames to carrier VLANs 200 and 300 if it needs to separate the traffic in its network. The VLAN IDs are normally stripped off before given to the ISP router.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020