Which of the following attributes sets atm apart from ethernet and frame relay?

Publisher Summary

Carrier Ethernet and virtual leased-line (VLL) services refer to a group of technologies that allow the carriage of ISO Layer 2 protocols on a Layer 3 IP/MPLS network. These services are enabled by the encapsulation of Layer 2 frames in a standards-based manner: RFC-4619 for Frame Relay, RFC-4448 for Ethernet IEEE 802.3, and RFC-4717 for Asynchronous Transfer Mode. Apart from Ethernet, each of these services provides point-to-point service only, encapsulating frames between two logical interfaces. Carrier Ethernet, on the other hand, provides either a point-to-point or a point-to-multipoint service. VLL services are only point-to-point in nature and are considered alternatives to traditional leased-line circuits. VLL-based services are encapsulation specific and can be transparently hosted on an IP/MPLS infrastructure. The chapter also focuses on the aspects needed for building a Carrier Ethernet and VLL infrastructure and places more emphasis on the aspects that are relevant at the network edge, since this is the only difference between these services and MPLS L3VPN and other service types.

6.4 Chapter Summary

Selling carrier Ethernet (CE) services to off-net customers over peering carrier Ethernet networks (CENs) require service providing operators to purchase E-access service from access providing operators. This purchase order, known as access service request (ASR), constitutes a business-to-business (B2B) transaction. To ensure that there is no confusion about what is being requested, standardization of these request forms is required. This chapter provided brief descriptions of various access service request forms available from the Ordering and Billing Forum (OBF) which manages these forms and is part of an industry organization called the Alliance for Telecommunications Industry Solutions (ATIS). The chapter then identified those forms that are specifically used for E-access service with the caveat that operators have some deviations in implementing these forms. Details of fields in those E-access service-specific forms were then provided in this chapter. While describing these fields, the chapter identified some Common Language codes needed in these ASR forms. These Common Language codes are maintained by an industry organization called iConnective. Because MEF specifies attributes and parameters and ASR forms use Common Language codes to order required attributes and parameters, this chapter compared MEF-specified attributes and parameters with ASR required Common Language codes and identified areas where further clarification in mapping of attributes and parameters to Common Language codes would help in the implementation of this new and fast emerging E-access service for peering CENs. Because the access service request (ASR) is preceded by selling activities and leads to a long chain of activities that includes design, ordering, order management, installation coordination, preservice testing, service turn-up, maintenance, and billing and ongoing coordination of testing and trouble resolution for all operator-provided facilities, automation, or mechanization of these activities is highly desirable. Large and complex IT systems called operations and business support systems (OSS/BSS) provide automation or mechanization of these and some more activities. This chapter provided a transition to OSS/BSS systems which is the topic of our Chapter 7.

10.6 The packet-optical network

Combining OTN and carrier Ethernet with other modern packet switching and transport technologies results in a highly flexible and scalable infrastructure. As shown in Figure 10.4, these standards are part of a network evolution that now combines the older traditional telecom and datacom networks. This evolution has taken a long time, at least in technology terms, but the result takes the best of both: reliability of telecom and application diversity of datacom. The modernized packet optical network utilizes mesh topologies and G.8032 Ethernet shared protection rings to assure sub-50 ms restoration in the event of failures. The use of MEF-defined carrier Ethernet delivers a deep set of service flexibility, reliability, and operational efficiency to the network operator. Finally, the adoption of OTN at the photonic and switching layers allows an operator to deliver virtually any application to any user through a high bandwidth, highly agile infrastructure.

4.2.6 VLAN Tag Support Attribute (Service Delivery Related)

VLAN tag support provides a 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. CEN 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. In CENs support for different levels of VLANs and the ability to manipulate VLAN tags become very important.

Consider the example of a multitenant building in which the CE 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. Although identifying the customer itself is easy, isolating the traffic between different customers becomes an interesting issue and requires some attention on the provider’s part. Without special attention, traffic might get exchanged between different customers in the building through the basement switch. 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 which identify EVCs over which the customer’s traffic travels. In the case of Ethernet, the VLAN ID given by a carrier called S-tag becomes that identifier. The carrier needs to assign to each physical port a set of VLAN IDs that are representative of the services sold to each customer. For example, Customer 1 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’s internal VLANs and the CE–VLAN ID is called C-tag, and service provider assigned tag is called S-tag. For this schema of customer’s C-tag and service provider’s S-tag, there are two types of VLAN tag support. They are

VLAN tag preservation

VLAN tag translation/swapping

VLAN tag preservation—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 Q-in-Q stacking. With Q-in-Q, the carrier VLAN ID becomes indicative of the EVC, whereas the customer VLAN ID (CE-VLAN) is indicative of the internals of the customer network and is hidden from the carrier’s network. 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. This was called Q-in-Q for a while before there was a standard. After the IEEE 802.1ad standard was published, it is now known as provider bridging. Some nonstandard enterprise switches on the market can perform a double-tagging function; however, these switches can only assign same VLAN ID as a carrier ID for all ports in the 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. Because of this reason, it is important that Ethernet switch support dual tagging on a per-port basis.

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 does not, the carrier removes the VLAN tag from the Ethernet frames before they are delivered to the destination. Another case is where 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 of course is at layer 3, 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 Internet service provider (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. In an example where a carrier-delivering Internet connectivity to three customers, the carrier is receiving untagged frames from the customer edge devices 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, the VLAN tags are removed from all EVCs and handed off to an ISP router, which is offering the Internet IP service.

Publisher Summary

This chapter focuses on the possible options available for offering Multicast in a carrier Ethernet environment, with Virtual Private LAN Service (VPLS) as the carrier infrastructure used to offer various services to end customers. It reviews the various models for building VPLS infrastructures and the mechanisms for delivering multicast. The building blocks of a broadband wholesale network and some widely deployed architecture for delivering multi-play services are detailed. MPLS Layer 2 VPNs, also referred to as Point-Point services, is briefly discussed. A point-to-point L2VPN circuit is a provider service that offers a point-to-point service infrastructure over an IP/MPLS packet switched network. Virtual Private LAN Services (VPLS), also known as multipoint-to-multipoint Ethernet L2VPN, which is a provider service that emulates the full functionality of a traditional Local Area Network (LAN). A VPLS makes it possible to interconnect several LAN segments over a PSN and makes the remote LAN segments behave as one single LAN. The same PSN is able to offer separate VPLS services to different customers. Like in all PE-based VPNs, with VPLS the CE devices are unaffected by the service: a VPLS CE can be a standard router, Ethernet bridge, or host. It is the PE device that implements VPLS specific functions. The VPLS control plane has two primary functions: autodiscovery and signaling.

5.9 Chapter Summary

This chapter described how growth in Ethernet technology is leading to the expansion of Carrier Ethernet (CE) services beyond one operator’s CEN. This expansion is also coupled with the fact that today subscribers, particularly business subscribers, have many locations that are not all in one operator’s footprint. These are the reasons that are making peering of CENs necessary. To address this necessity of expanding CE services over peering CENs, MEF defined an E-Access service type which was the topic of this Chapter. In order to understand this E-Access service type, it was essential to revisit bridging techniques and tags, particularly S-tags because of the critical role S-tags play in peering CENs. This chapter explained bridging techniques and tags. The chapter then covered terminology, architecture, attributes, and parameters associated with E-Access service type to explain terms like ENNI, OVC, O EP, service provider, access provider, subscriber’s point of view, service provider’s point of view, and access provider’s point of view. The chapter also provided reference to all IEEE, ITU-T, and MEF specifications relevant to peering CENs.

The chapter then described Access-EPL and Access-EVPL services that belong to E-Access service type and provided some examples of subscriber’s services on peering CENs that use these access services. The chapter expanded on the description of delivering QoS given in Chapter 4 and described how QoS is delivered on peering CENs by coordination of CoS, performance parameters, bandwidth profile, and policing by two-rate three-color model. Description in this chapter also included SOAM over peering CENs, so that QoS is in compliance with the SLA between subscriber and service provider.

The peering of CENs requires B2B transactions between service providing operator and access providing operator. This B2B transaction, in communication industry, is called ASR, and this chapter provided a transition to ASR which is the topic of our Chapter 6.

Carrier ethernet

With Ethernet emerging as the dominant networking technology within the enterprise, and telecom service providers being driven to provide more features and bandwidth without increasing costs to the end users, Ethernet has made significant inroads into carrier networks. This started with the metro networks that connect enterprise networks within a metropolitan area.

The Metro Ethernet Forum (MEF) was founded in 2001 to clarify and standardize several Carrier Ethernet services with the idea of extending enterprise LANs across the wide area network (WAN). These services include:

E-line: This is a direct connection between two enterprise locations across the WAN.

E-LAN: This can be used to extend a customer’s enterprise LAN to multiple physical locations across the WAN.

E-tree: This can connect multiple leaf locations to a single root location while preventing interleaf communication.

This movement of Ethernet out of the LAN has progressed further into the carrier space using several connection oriented transport technologies including Ethernet over SONET/SDH and Ethernet over MPLS. This allows a transition of Ethernet communication, first over legacy transport technologies, and, ultimately, to Ethernet over Carrier Ethernet Transport, which includes some of the following technologies.

Carrier Ethernet networks consist of Provider Bridge (PB) networks and a Provider Backbone Bridge (PBB) network as shown in Figure 2.14. Provider bridging utilizes an additional VLAN tag (Q-in-Q) to tunnel packets between customers using several types of interfaces. Customer Edge Ports (CEP) connect to customer equipment while Customer Network Ports (CNP) connect to customer networks. Provider equipment can be interconnected directly using an I-NNI interface, or tunneled through another provider network using an S-PORT CNP interface. Two service providers can be interconnected through an S-NNI interface. A fundamental limitation of Provider Bridging is that only 4096 special VLAN tags are available, limiting the scalability of the solution.

In the carrier PBB network, an additional 48-bit MAC address header is used (MAC-in-MAC) to tunnel packets between service providers, supporting a much larger address space. The I-component Backbone Edge Bridge (I-BEB) adds a service identifier tag and new MAC addresses based on information in the PB header. The B-component Backbone Edge Bridge (B-BEB) verifies the service ID and forwards the packet into the network core using a backbone VLAN tag. The Backbone Core Bridge (BCB) forwards packets through the network core.

As carrier networks migrate from circuit switching to packet switching technologies, they must provide Operation Administration and Maintenance (OAM) features that are required for robust operation and high availability. In addition, timing synchronization must be maintained across these networks. As Carrier Ethernet technology replaces legacy SONET/SDH networks, several new standards have been developed such as Ethernet OAM (EOAM) and Precision Time Protocol (PTP) for network time synchronization.

While Carrier Ethernet standards such as PB, PBB, and EOAM have been in development by the IEEE for some time, other groups have been developing a carrier class version of MPLS called MPLS-TE for Traffic Engineering or T-MPLS for Transport MPLS. The idea is that MPLS has many of the features needed for carrier class service already in place, so why develop a new Carrier Ethernet technology from scratch? The tradeoff is that Carrier Ethernet should use lower cost switches versus MPLS routers, but MPLS has been around much longer and should provide an easier adoption within carrier networks. In the end, it looks like Carrier networks will take a hybrid approach, using the best features of each depending on the application.

Data centers are connected to the outside world and to other data centers through technology such as Carrier Ethernet or MPLS-TE. But within the data center specialized data center networks are used. The rest of this book will focus on Ethernet technology used within the cloud data center networks.

6.7 Conclusion

IPTV is an application that involves multiple technologies. ITU-T, DSL Forum, IETF, and ETSI are among the organizations contributing actively to the IPTV evolution. A combination of Carrier Ethernet in the core and aggregation and DSL in the access is a common transport architecture for IPTV delivery. SSM and IGMPv3 are protocols that together provide the necessary support for users to Join and Leave multicast groups. Quality of service and quality of experience are important parameters in the area of IPTV. Unlike in the data world, the end-user sensitivity to video is quite high so it is necessary for the network to be optimized for video delivery. All of these topics have been discussed in this chapter in varying degrees of detail.

Abstract

Packet-optical transport has been a major trend in optical networking over the past 18 months. New products have emerged that combine WDM transport, ROADMs, Sonet/SDH ADMs, and centralized carrier Ethernet switching in a single converged device. These products are known packet-optical transport systems (P-OTS).

To date, the P-OTS evolution has been all about the metro, but we're now seeing P-OTS move into the core of the network. Part of the reason core P-OTS is emerging now is that the core transport network has largely been ignored for a couple of years while the industry has focused on rebuilding access, metro, and aggregation networks for packets and IP. In reality, growth in Ethernet and IP, Internet data and video, and mobile data and video affect core as well as metro access networks. The migration from Sonet/SDH circuits to packets is not just a metro issue. In this chapter we look at some of the emerging trends that are being developed to bridge the back between the Packet and Optical Layers.

8.5 Process for Converting Application and Topology Information into a Design

Description in this section leverages all the learnings from all the chapters in this book particularly, Chapters 4–8Chapter 4Chapter 5Chapter 6Chapter 7 and multitude of standards and specifications related to CEN, peering CENs, ASR, OSS/BSS, and customer-specific applications. In view of this, the process of design encompasses areas that are quite diverse and vast requiring large number of people with specialization in different fields. The design process is always a collaborative effort between various teams. The process starts with an examination of customer applications and topology of sites from connectivity perspective. From application, one can determine PT and CPOs as described in this chapter. From site topology one can determine if there is any off-net location; if yes, peering of CENs will be needed. Next, in discussion with the customer, the service provider determines bandwidth, CIR, and type of CE service including, EPL, EVPL, EP-LAN, EVP-LAN, EP-Tree, or EVP-Tree CE that will do the job. In case peering CENs are needed, then Ethernet-access service will be required, and as part of the design, service provider has to determine if Access E-Line or Access E-LAN type of Ethernet-access service is needed and then determine if the Ethernet-access service is going to be port based or VLAN based. For VLAN-based CE services, it is important to examine if UNI-based, EVC-based, or CoS-based bandwidth profile is needed. It should be noted that MEF 6.2 requires use of CoS-based bandwidth profile only. It is important to use S-tags in External Network Network Interface (ENNI) since it is defined as an S-tagged interface and to use Provider Backbone Bridge Traffic Engineering (PBB-TE)-based connection–oriented approach in the MAN/RAN/WAN. It is interesting to note that currently far more carriers use MPLS/MPLS-TP (Multiprotocol Label Switching - Transport Profile). It may change in future with the wider acceptance of PBB-TE due to reasons that we discussed in Chapter 5. It is also important to base the design, as much as possible, on “switch many route once” approach to get improved performance.

Next section provides a transition to steps that are needed to further enhance and accelerate the implementation of peering CENs.