Next Generation Transmission- Wray Castle course.pdf

Next Generation Transmission Course Code: TY2702

Duration: 3 days

Technical Level: 3

Transport and Signalling coursesinclude: 

Broadband Access Technologies



SS7 Engineering

www.wraycastle.com

NEXT GENERATION TRANSMISSION

First published 2008 Last updated March 2012 WRAY CASTLE LIMITED BRIDGE MILLS STRAMONGATE KENDAL LA9 4UB UK

Yours to have and to hold but not to copy The manual you are reading is protected by copyright law. This means that Wray Castle Limited could take you and your employer to court and claim heavy legal damages. Apart from fair dealing for the purposes of research or private study, as permitted under the Copyright, Designs and Patents Act 1988, this manual may only be reproduced or transmitted in any form or by any means with the prior permission in writing of Wray Castle Limited. All of our paper is sourced from FSC (Forest Stewardship Council) approved suppliers.

© Wray Castle Limited

Next Generation Transmission

II

© Wray Castle Limited

NEXT GENERATION TRANSMISSION

CONTENTS Section 1

Introduction to Transmission Networks

Section 2

Options for Layer 2 Virtual Circuits

Section 3

Carrier Based Ethernet and Transmission Systems

Section 4

Synchronous Digital Hierarchy (SDH)

Section 5

Next Generation SDH

Section 6

Wavelength Division Multiplexing (WDM)

Section 7

Optical Transport Network (OTN)

Section 8

MPLS in Optical Networks

Section 9

Pseudo Wires

© Wray Castle Limited

III

Next Generation Transmission

IV

© Wray Castle Limited

Next Generation Transmission

SECTION 1

INTRODUCTION TO TRANSMISSION NETWORKS

© Wray Castle Limited

I

Next Generation Transmission

II

© Wray Castle Limited

Introduction to Transmission Networks

CONTENTS Modern Network Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.1 Transmission Networks

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.2

Early Transmission Systems

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.3

SDH (Synchronous Digital Hierarchy)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.4

SDH Line Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.5 Traditional Legacy Networks and Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.6 NGNs (Next Generation Networks) and Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.7 NGNs and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.8 Competing Core Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.9 Carrier-Based Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.10 Pseudo Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.11

© Wray Castle Limited

III

Next Generation Transmission

IV

© Wray Castle Limited

Introduction to Transmission Networks

OBJECTIVES At the end of this section you will be able to:



describe the evolution of digital transmission networks in support of modern services



identify the key transmission technologies available for use in modern core network design



describe where and when different transmission techniques could be used

© Wray Castle Limited

V

Next Generation Transmission

VI

© Wray Castle Limited

Introduction to Transmission Networks

Modern Network Evolution The modern telecommunications age began in the 1980s with the introduction of digital switching systems. These early systems supported a limited set of bearer services and teleservices – the primary service was 64 kbit/s voice. The bearer was centred on the 64 kbit/s timeslot, or primary multiplexer rates of 2.048 Mbit/s (E1). Although it was possible to support data using the telephony model, the line rates available were sub-64 kbit/s; realistically, around 20–36 kbit/s. Advances in the 1990s, in particular the V.90 series (56k Flex in the USA), promised speeds of up to 56 kbit/s. In 1991, the first GSM (Global System for Mobile Communications) telephony and data services became available in western Europe. GSM is now the predominant family of technologies supporting mobiletelephone users worldwide. GSM launched with voice, fax, emergency calls and a limited data service (up to 9,600 bit/s). During the late 1990s this was enhanced with the introduction of GPRS (General Packet Radio Service), which provided a suitable bearer service for access to IP (Internet Protocol)-based services. In the late 1990s and the early part of the new millennium, multi-megabit cable and DSL (Digital Subscriber Line) services have provided broadband services to business and residential users, offering multiple services down one medium, i.e. coaxial cable or twisted pair. This led to an explosionin terms of the internet/world wide web. Service demand has extended far beyond the initial voice-centric offerings and now adds such varied elements as VoD (Video on Demand), social networking, IPTV (IP Television), HDTV (High Definition Television), digital radio, online gaming, web services, e-mail, application sharing, mobile/portable services, home security and remote storage/backup. This all has to be carried around the network, providing access to customers worldwide. Transmission networks have traditionally provided the high bandwidth backhaul and long-haul pipes that can carry these services efficiently. However, these networks have to change to meet the new requirements, which do not match the old voice-centric, timeslot-based service model.

TY2702/v3.1

© Wray Castle Limited

1.1

Next Generation Transmission

Input User Data ‘A’

Output Data

Information Pipe

User ‘B’

Transmission Network

Tributary Interfaces

Multiplexing Equipment

Line Systems

Add/Drop Facility

Digital Transmission Networks 1. PDH 2. SDH 3. WDM 4. OTN

Transmission Networks Transmission systems are designed to transfer information over any distance from one point to another. To the user, the ideal transmission system would be error free and available at all times. From an operator’s perspective a modern transmission network should enable ease of circuit provisioning, be resilient to failures and reduce the cost per bit transmitted. Transmission systems can be said to provide a simple information pipe, or bit pipe, between two users. The size or capacity of the pipe will vary depending on the amount of data to be transferred between the input and the output. In general terms, transmission systems consist of tributary interfaces, multiplexers, add/drop facility (digital cross-connects) and line systems. Four main transmission networks are in use in modern systems. They are PDH (Plesiochronous Digital Hierarchy) and SDH (Synchronous Digital Hierarchy), which are digital systems; WDM (Wavelength Division Multiplexing), which provides optical multiplexing; and OTNs (Optical Transport Networks), hybrid networks providing digital switching capability over a WDM system. WDM is in fact analogue, as it deals with light waves, although it is still carrying a client digital signal. PDH systems have been around since their introduction into trunk systems in the USA in the early 1960s. SDH systems reflect the modern approach to digital transmission systems, having been in use since 1985; again starting in North America under the title of SONET (Synchronous Optical Network). Most if not all of the new transmission equipment rolled out over recent years tends towards SDH and OTN, although some in the industry are looking at pure optical systems, which will take tributary inputs and place them onto their own colour of light, i.e. WDM and optical switching. With the deregulation in the telecommunications market there are many new operators. These are likely to have networks consisting entirely of SDH/OTN equipment. Established operators have a mixture of legacy PDH and SDH equipment and new technologies such as OTNs, Carrier Ethernets and PBB (Provider Backbone Bridging), and PBT (PBB with Traffic Engineering). However, the percentage of PDH equipment in these networks is steadily decreasing, except in the access domain (for some mobile operators in particular), where 34/45 Mbit/s (E3) circuits are being deployed over microwave radio links to connect base stations back to exchange buildings.

1.2

© Wray Castle Limited

TY2702/v3.1

Introduction to Transmission Networks

CP – Central Processor GS – Group Switch

CP

CP E1 E1 E1 E1 E1 E1

GS

E1 E1 E1 E1 E1 E1

E1 E1 E1 E1 E1 E1

CP E1 E1 E1 E1 E1 E1

GS

GS

E1 E1 E1 E1 E1 E1

CP E1 E1 E1 E1 E1 E1

E1 E1 E1 E1 E1 E1

GS

E1 E1 E1 E1 E1 E1

PDH 565 Mbit/s E4 140 Mbit/s

E1 2.048 Mbit/s

Early Transmission Systems In the 1980s, the services supported by network operators were centred on the 64 kbit/s timeslot. These were usually multiplexed using primary rate multiplexers to form E1s (2.048 Mbit/s) or 30-channel PCM (Pulse Code Modulation). This was reflected by equipment manufacturers as it became the common interface type for their equipment, such as telephony switches, to connect to the outside world. For any service, local switches may need to connect to other users locally, nationally or even internationally. A solution has to be found to cover these distances. In the 1980s this was provided by PDH networks. PDH equipment had defined interfaces in accordance with ITU-T (International Telecommunication Union – Telecommunication Standardization Sector) recommendations such as G.702/G.703, and provided bit rates from E1 through to E4. These are standard interfaces that should provide a fully compatible interface for different vendors to connect to. There is also a proprietary stage operating at 565 Mbit/s. The problem with PDH systems was that they did not define the line system interface, i.e. optical or radio. PDH systems also had proprietary management systems. This meant that operators had to terminate transmission links using the same vendor’s equipment and if they wanted to reduce operating expenditure they had to replicate this across their whole network. This meant that once a vendor got into a major operator their future was pretty well guaranteed. This was undesirable as far as operators are concerned, and competition in the marketplace often suffered. To interconnect between different vendors, as with an international circuit, it was necessary to demultiplex down to the PDH tributary levels, i.e. E1 to E4, then manually cross connect at these levels before applying a management channel and a line code for the new system.

TY2702/v3.1

© Wray Castle Limited

1.3

Next Generation Transmission

SDH (Synchronous Digital Hierarchy) With the advent of the SDH standards in the late 1980s, a standard NNI (Network Node Interface) was created. This was a fundamental step forward as it allowed operators to interconnect different vendors’ equipment at the line signal without the need for expensive demultiplexing. SDH also provided higher bit rate line systems starting at a comparable 155 Mbit/s for STM-1 (Synchronous Transport Module 1) and working up in multiples of four to STM-64 (10 Gbit/s) and even STM-256 (40 Gbit/s). Another major advantage was the introduction of extensive management and protection mechanisms. With SDH it is possible to monitor the performance of an optical link or an individual circuit path down to level 1, i.e. 2.048 Mbit/s. SDH can also provide some FEC (Forward Error Correction) for signals of STM-16 and above which can improve the optical reach of a system by some 3–6 dBs. SDH has been further enhanced through Next Generation offerings such as GFP (Generic Framing Procedure), VCAT (Virtual Concatenation) and LCAS (Link Capacity Adjustment Scheme). GFP allows SDH to carry different payloads beyond the traditional switched circuit payloads and includes direct encapsulation of IP and Gigabit Ethernet frames. VCAT allows operators to assemble any of the SDH payloads in an STM-n signal and combine them as a group providing a combined group bandwidth to the client service. LCAS provides a dynamic means of adjusting the VCAT groups such that the effective bearer can be adjusted to meet the bandwidth requirements of the client service. SDH systems have been very successful and are carried on media as diverse as coaxial cable, microwave radio and optical fibre. SDH systems are the main technology used for submarine cable systems, which in turn represent a major portion of operators’ intercontinental interconnects.

1.4

© Wray Castle Limited

TY2702/v3.1

Introduction to Transmission Networks Capacity STM-1 STM-4 STM-16 STM-64 STM-256

155 Mbit/s 622 Mbit/s 2.5 Gbit/s 10 Gbit/s 40 Gbit/s

E1 x 63 E1 x 252 E1 x 1008 E1 x 4032 E1 x 16,128

SDH Hierachy STM-1 WDM

STM-4 STM-16

nx

STM-64 STM-256 n = 1, 8, 20, 40, 80, 120 ……

WDM Concept SDH Line Signals Since the late 1990s there has been a fall in the unit cost of network bandwidth, which in turn has allowed many different service providers to offer bandwidth-hungry applications such as streaming music and video as well as data transfers. At first it looked as though SDH systems were the solution. Although this considerably improves the effective bandwidth on offer, it is still effectively centred on voice type services. With NG-SDH GFP and VCAT can offer some interesting packet-based alternatives such as supporting Gigabit Ethernets. WDM (Wavelength Division Multiplexing) Concept An alternative plan to the STM-n progressive approach is where STM-n signals are seen as the tributary inputs. These tributary inputs are then transponded into individual ITU-T defined wavelengths, which are then bound to a single medium/optical fibre. This process is known as WDM (Wavelength Division Multiplexing) and hopes to offer an almost limitless capacity over modern optical fibres. Modern systems can offer up to 160 wavelengths on a single fibre, with bodies such as Bell Labs setting a 1000 wavelength target for future systems. With the advent of optically multiplexed systems comes the need to perform optical switching. The ITU has looked at WDM and includes this as part of its OTN solution, where an OTN sees STM-n as a digital client signal. However, OTN can also support other clients such as ATM (Asynchronous Transfer Mode), Ethernet and even MPEG (Motion Picture Experts Group) transport streams in support of IPTV. Thus, SDH is not the only tributary input to WDM systems; in some cases layer 2 protocols have been looking to expand their reach into the physical layer and thus would act as the tributary directly.

TY2702/v3.1

© Wray Castle Limited

1.5

Next Generation Transmission

Traditional Legacy Networks and Transmission Traditional networks concentrated on supporting circuit-switched networks. Even though packet-based solutions using ATM or FR (Frame Relay) were in use, they still used TDM (Time Division Multiplexing) architecture such as PDH and SDH as physical layer transmission technologies. The services on offer were voice centric, i.e. based on the 64 kbit/s timeslot or multiples thereof. Even if the service required was a data service, which was provided by a separate PDN (Public Data Network), this would probably still be supported by switches that switched at 64 kbit/s. Typically, management systems were deployed with different types of NEMs (Network Element Managers) used for each layer of the transport network. Even within the same layer it was common to find different types of NEMs. This approach makes it difficult to centrally manage networks.

1.6

© Wray Castle Limited

TY2702/v3.1

Introduction to Transmission Networks

NGNs (Next Generation Networks) and Transmission New networks do not see the architecture as a straight layer 1, 2 and 3 as per the OSI (Open Systems Interconnect) model; they see services being carried by a transport network. The transport layer includes such legacy technologies as PDH and SDH as well as OTN. It also enables protocols directly supporting services such as Ethernet to be carried natively over an optical signal or as part of a WDM solution. Another major factor is that equipment at the transport layer should be controlled and managed using the same solution. To this end, technologies such as GMPLS (Generalized Multi Protocol Label Switching) are being used to provide a common control plane for systems such as OTN. GMPLS, defined by the IETF (Internet Engineering Task Force), is seen as an extension of MPLS providing for packet and layer 2 switched networks, whereby it can also switch timeslots, wavelengths and whole fibres. The ITU-T started work on ASTN (Automatic Switched Transport Networks), which is now part of ASON (Automatic Switched Optical Networks), which uses GMPLS as its control layer for an OTN. The ITU-T has also been working on T-MPLS (Transport MPLS), which is seen as a connection oriented packetswitched service which would compete with carrier Ethernet solutions. Although most work has concentrated on improving transmission networks which are traditionally confined to the core network, there has been a drive towards providing these solutions in access networks. The first such solution, Access SDH, provided a versatile node which could be configured using different line cards in any slot to support a desired service. The internal interface would provide a common interface, and the backhaul link would be provided by SDH. Initially this was thought to be at sub STM-1 levels, although STM-1, 4, and 16 solutions may be coming into this area. The latest versions of these multi-service units are known as MSPPs (Multi Service Provisioning Platforms). These have been likened to the fabled ‘God Boxes’ and could provide a common interface point for any current access technology. This would be a useful feature in terms of dealing with legacy services, as everything to the left of the device could stay the same while the network to the right would become IP compatible. In fact, there would be an IP routing engine at the heart of these devices which would forward the information to the appropriate core network service node. The MSPP as a MSAN (Multi Service Access Node) reflects the fact that this node is usually the node terminating the customer’s line.

TY2702/v3.1

© Wray Castle Limited

1.7

Next Generation Transmission

Mobile Broadband Access Core Packet-Switched Network

Telephony

TV Leased Lines

Services

Logical Addressing

Virtual Circuits and Data Links and Physical Addressing

Physical Links

Layer 3 Network

Layer 2 Data Link

Layer 1 Physical OSI Model

NGNs and Services NGNs (Next Generation Networks) have seen the architecture change from a circuit-switched to a packet-switched network. So far, this has taken place in the core network, but it is intended that future solutions should be all packet or all-IP based. This would lead to all services being carried over packet based technologies such as IP, MPLS, FR and Ethernet. As such, services would be transported over a layer 3 technology such as IP, where logical addressing of the service end points is derived. IP provides for security and separation of user traffic through the use of layer 3 VPNs (Virtual Private Networks), although the VPN may be handled at lower layers. There may also be some limited support for QoS (Quality of Service), although QoS implementation is more likely to be conducted at the lower layers. The layer 3 packets will be carried over a suitable layer 2 switching architecture such as MPLS label switches or Ethernet bridges and switches. Ethernet has undergone a revolution in the access and metro, and even across the operator’s core. It has seen its line rate improve from hundreds of Megabits per second through to Gigabits, even tens of Gigabits and possibly more. Ethernet through PBB (Provider Backbone Bridging) networks can provide a layer 2 switched solution with local, national and international reach. However, Ethernet is no longer seen as just a LAN (Local Area Network) solution. Ethernet also supports the idea of separation for the user’s traffic, firstly through the advent of VLAN (Virtual LAN) tags and then by extending this to provide S-VLANs (Service VLANs) by the service provider and B-VLANs (Backbone VLANs) as broadband or backbone bridge VLANs through the core. All these higher layers still need to be carried over some form of physical media. The traditional approach was to use a transmission system such as PDH or SDH. However, this is changing, and technologies such as Ethernet can provide their own signal suitable for transmission over the physical media.

1.8

© Wray Castle Limited

TY2702/v3.1

Introduction to Transmission Networks

PBB-TE v

MPLS

v MPLS-TP

? Core Network

SDH GMPLS

OTN

WDM

Competing Core Technologies A common interface into modern networks is provided by the Ethernet family of standards. This includes media such as fibre copper and wireless. This is certainly true when considering the interconnection point for the user and for local transfer of information around an office or a campus. A suitable transmission solution is required when distance is a major factor. There is competition in this space. The middle ground is taken up by the evolution of traditional transmission solutions from the ITU, i.e. SDH and OTN, both of which could provide a single wavelength solution or use a multiple wavelength or WDM approach. Operators could adopt MPLS-TP (MPLS – Transport Profile; formerly T-MPLS), or take the Metro Ethernet solution of PBB-TE (PBB Traffic Engineering), otherwise known as PBT. Where network operators have already invested in an MPLS solution for their core network, they may look at PBB-TE within their Metro/Access domain. This would be beneficial in two ways. Firstly, the interface to the customer would be compatible with their current data closet solution, i.e. standards-based Ethernet, and secondly, the network operator would peer at layer 2, so would not need to maintain routing tables for each connected customer as is the case when peering in support of IP VPNs.

TY2702/v3.1

© Wray Castle Limited

1.9

Next Generation Transmission

LAN

LAN

Customer Bridge

PEB

PEB

Customer Bridge

WAN Carrier Ethernet Network

Normal Ethernet Frames

Normal Ethernet Frames

Carrier-Based Ethernet For as long as Ethernet has been used on customer premises, its reach has been local, with distances measured in hundreds of metres between stations using this technology. When it came to communicating over long distances, a WAN (Wide Area Network) solution had to be found. Part of the problem with Ethernets is that the address space available is limited to 48 bits for one station, which may be insufficient for a worldwide solution. Ethernet’s lack of QoS and OAM (Operation, Administration and Maintenance) also hinder its use in a WAN environment. All of these areas have been worked on by members of the Ethernet community including the IEEE, MEF and ITU-T SG 13. The aim is to be able to provide an end-to-end circuit using Ethernet-only bridges and switches in between; as such an EVC (Ethernet Virtual Circuit) would be described through the network. To support this, the Ethernet community introduced IEEE 802.1q VLAN (Virtual Bridged Local Area Network) tagging. Here, a tag was added to the header that could provide up to 4096 VLANs, where a VLAN would correspond to an IP subnet. This was expanded through IEEE 802.1ad, which introduced the concept of a stack of tags, whereby the outer tag value would correspond to a service provider’s EVC through their network whilst the inner tag would be left unchanged until it reached the egress of the service provider. Here, it is used to switch towards the appropriate customer. This is also known as QinQ. A further extension of this, known as Mac-in-Mac, was introduced through IEEE 802.1ah. This allows a double-tagged Ethernet frame to be encapsulated in another outer double-tagged Ethernet frame. This would increase the available address space for Ethernet, making it a viable option for an international carrier.

1.10

© Wray Castle Limited

TY2702/v3.1

Introduction to Transmission Networks

P

PE E1 BTS

PE

AC

AC

E1

AC

E1

BSC/ PCU

P FR/Gb PE

L2TP or MPLS

AC E1

S G S N

Pseudo Wires With the advent of NGNs, operators have been moving towards an all-packet-switched network. The first area to be migrated was the core. This was intended to reduce overall complexity and to minimize the impact on existing customers. The problem with this approach is that customers are still using legacy services and expect them to continue to work even if the network operator has changed its network. TDM private lines in the US in 2007 represented some $10.77 billion of revenue. In a typical example, a BTS (Base Transceiver Station) uses E1s to connect back to the BSC (Base Station Controller). Another example could be a corporate customer with a large PBX (Private Branch Exchange) which uses Primary Rate (E1) connections to connect to its local CP (Communications Provider). In each case, customers expect to get a native E1 service to support their connections. There are certain expectations from the E1 service that are well understood by the customer and may be important to the effective operation of the service. However, the CP cannot provide a switched circuit network through its core, as before; it needs to carry the service over a PSN (Packet Switched core Network). Here, PWs (Pseudo Wires) can provide a solution, where a suitable Attachment Circuit is used to connect the legacy service to the CP’s edge device such as an MPLS PE router. The CP would then need to provide a PW for the customer between the appropriate end points. A TDM PW can be used to connect the BTS to the BSC. A second PW is provided that uses a FR (Frame Relay) solution in order to support the Gb interface extending from the BSC to a SGSN (Serving GPRS Support Node), as needed for GPRS support. In either case, the PW is being carried over an IP or MPLS core network, which is essentially packet based. As with any network of this type, packet loss and delay variation can cause problems. If this is likely, time-sensitive PWs would fail unless there was appropriate engineering of the underlying resources.

TY2702/v3.1

© Wray Castle Limited

1.11

Next Generation Transmission

1.12

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission

SECTION 2

OPTIONS FOR LAYER 2 VIRTUAL CIRCUITS

© Wray Castle Limited

I

Next Generation Transmission

CONTENTS Leased Lines

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.1

Data VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2 IP VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.3 Overlay Model – Frame Relay or ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4 Peer-to Peer-Model – MPLS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.5

MPLS (Multi Protocol Label Switching)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.6

MPLS Applications View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.7 MPLS and ATM Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.8 MPLS Shim Header and MPLS Packet Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.9 Architecture of MPLS-based IP-VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.10 Motivation for MPLS-based VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.11 MPLS VPLS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.12 What is MPLS Traffic Engineering? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.13 TE (Traffic Engineering) Label Distribution Protocols – CR-LDP . . . . . . . . . . . . . . . . . . . . . .2.14 Label Distribution Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.16 Label Advertisement Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.17 Label Retention Mode Routing

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.18

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.19

Appendix A Frame Relay – Frame Switching and Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A2.1 Frame Relay Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A2.2 QoS (Quality of Service)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A2.3

Frame Relay over TDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A2.4

II

© Wray Castle Limited

Options for Layer 2 Virtual Circuits

CONTENTS Appendix B ATM Terminology – VPs (Virtual Paths) and VC (Virtual Channel) Switches . . . . . . . . . . . .B2.1 ATM Interfaces and Adaptation Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B2.2 The ATM Layered Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B2.3 ATM Cell Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B2.4 ITU-T and ATM Forum Correlation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B2.5

Traffic Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B2.6 OAM Hierarchical Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B2.7 Mapping ATM Cells into SDH (Cell Delineation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .B2.8

© Wray Castle Limited

III

Next Generation Transmission

IV

© Wray Castle Limited

Options for Layer 2 Virtual Circuits

OBJECTIVES At the end of this section you will be able to:



identify the key packet switching attributes of Frame Relay



identify the types of circuits provided by Frame Relay



state how Frame Relay may support QoS (Quality of Service)



describe how Frame Relay may be transported over modern transmission systems



identify the key attributes of ATM (Asynchronous Transfer Mode)



describe how an ATM circuit can be created



state how ATM provides enhanced support for OAM (Operation Administration and Maintenance) and QoS



describe how ATM can be transported over modern transmission systems



identify the key attributes of MPLS (Multi Protocol Label Switching)



state the difference between LSPs (Label Switched Paths) and VPNs (Virtual Private Networks)



describe how MPLS can support IP (Internet Protocol) and Ethernet services

© Wray Castle Limited

V

Next Generation Transmission

VI

© Wray Castle Limited

Options for Layer 2 Virtual Circuits

Application Presentation Session Transport Kilmarnock

Network Data Link Physical

Leased Lines

Swansea

Leased Lines In telecommunications networks the main form of interconnection for corporate sites used to be some form of dedicated leased line. These are expensive resources, especially when extended over lengthy geographical distances. Typically, an incumbent operator such as BT in the UK would have the presence and the network infrastructure to provide this type of service on a local, national and international basis. Mobile-network operators used to rely on this when connecting to remote base stations, where they would need to lease a 2 Mbit/s E1 to provide connectivity back to the mobile telephone exchange. In terms of running costs the use of leased lines could be more than 60% of an operator’s expenditure. Obviously, on a cost basis, leased lines are undesirable. In some cases the other communications providers are installing their own networks to replace this need. Leased lines were typically dimensioned to support TDM services, voice in particular. In recent times the type of services being carried by operators has changed significantly and there has been a move away from TDM services to more packet-based bursty-type services. To support these, different types of leased line circuits are required. VPNs (Virtual Private Networks) are the solution. There are different VPN types of VPN; two types often encountered are Data VPNs and IP VPNs.

TY2702/v3.1

© Wray Castle Limited

2.1

Next Generation Transmission

Kilmarnock Data Centre

Application Presentation Session Transport Network Data Link Physical Swansea Data Centre

Data VPN Frame Relay or ATM

Data VPNs Data VPNs are the domain of technologies such as Frame Relay and ATM, which provide a meshed layer 2 switching architecture interconnecting customer sites. The circuits supported are no longer dedicated as they share the underlying resources; as such they are termed ‘virtual circuits’. With leased line circuits, the resources were dedicated. There was no need for addressing as the traffic routing was permanently (or semi-permanently) set. For virtual circuits some form of addressing is needed so that the switching devices can determine the correct path through the network for the traffic.

2.2

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

Kilmarnock Data Centre

Application Presentation Session Transport Network Data Link IP VPN

Physical

Swansea Data Centre

IP VPNs IP VPNs act at layer 3 and may be deployed using protocols such as MPLS (Multi Protocol Label Switching). Being IP-based, the information is routed through the network from source to destination based on IP addresses. However, if it is delivered over MPLS then MPLS is responsible for establishing a layer 2 switched path between the end points of the network and then rapidly packet-switching the traffic through the network. In essence, data movement around a modern network relies upon some form of layer 2 switching architecture. This still has to be carried by some underlying layer 1 (physical) technology such as SONET/SDH or WDM.

TY2702/v3.1

© Wray Castle Limited

2.3

Next Generation Transmission

Customer Site

Customer Site

Customer Site

Customer Site

Customer Site

Overlay Model – Frame Relay or ATM The diagram shows Frame Relay or ATM switches being used in an overlay model which employs layer 2 virtual circuits to interconnect the sites in a full mesh arrangement. This can provide significant scaling problems, such as when adding new sites. The benefit of this model is that the user traffic from different sites and customers can share the core resources on a statistical basis, being switched through the network based on addressing information contained in the frames or ATM cells. There are two principal forms of virtual circuit, PVCs (Permanent Virtual Circuits) and SVCs (Switched Virtual connections). In the case of PVCs the network operator configures the switches along the circuit path with all the necessary information in order to maintain the circuit. For SVCs, the service could be on demand. In this case the user equipment will request service from the network and the network will effectively have to build a circuit, automatically populating the switch nodes along the circuit route.

2.4

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

Customer Site

Customer Site

Customer Site

Customer Site

Customer Site

Peer-to Peer-Model – MPLS This diagram shows a peer-to-peer model where customers’ equipment peers with the CP (Communications Provider) network. This peering is done using standard routing or switching protocols such as OSPF (Open Shortest Path First) or straightforward Ethernet in the case of VPLS (Virtual Private LAN Service). The classic example of this model can be found in MPLS deployments, where the service provider’s network is aware of the customer’s chosen protocol and MPLS. In this model, the MPLS network creates virtual circuits between each POP (Point of Presence). Then the CP peers to its customers using standard interfaces and standard layer 2 and layer 3 protocols. In the case of IP VPNs, the MPLS peering provides a virtual instance of the customer’s router in the edge MPLS router. This virtual instance is known as a VRF (Virtual Routing and Forwarding) instance. The CP then moves information across its network using MPLS VPNs between the edge POPs.

TY2702/v3.1

© Wray Castle Limited

2.5

Next Generation Transmission Router

Switch

Sophisticated Routing Layer 3

Fast Switching Layer 2

V Connectionless

Connection-Oriented

MPLS

LSR Integration of Routing and Switching

MPLS (Multi Protocol Label Switching) Traditionally, switches have offered better performance than routers in terms of the speed at which data can be forwarded. However, routers can be configured to make sophisticated decisions about the processing of datagrams. As well as forwarding a packet based upon destination IP addresses, a router can classify packets based on other header fields, including source address and TCP (Transmission Control Protocol) port numbers. This leads to the question, why not build a device that combines fast forwarding across the core of a network based upon classification of packets carried out at the edge of the network? While this is essentially what an IP over ATM approach achieves, the key innovation of the MPLS approach was the use of traditional IP routing protocols to determine how these switched paths should be set up. In MPLS, a switching model closely coupled to the IP layer it was intended to support became available for the first time. This leads to the idea of LSRs (Label Switched Routers), devices that integrate the best of both routing and switching. Whereas traditional layer 2 switching was not integrated with the IP layer, MPLS is closely coupled to the routing and addressing schemes of the IP layer.

2.6

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

MPLS Applications

FEC

L3 Control

L2 Control

Simple Packet Forwarding

IP routing table

‘Any’ IP routing protocol

LDP

MPLS VPN

per-VPN routing table (VRF)

‘Any’ IP Routing CE-PE MP-BGP in core

MP-BGP

MPLS Traffic Engineering

MPLS tunnel definition

Combination of manual configuration and TE extensions to OSPF/IS-IS includes FRR

RSVP-TE or CR-LDP

VRF – Virtual Routing and Forwarding FRR – Fast Re-Routing

MPLS Applications View The underlying principles of MPLS have been tailored to several MPLS-based applications. These all have the same core components, but they are implemented in a different way. Simple Packet Forwarding Simple packet forwarding is the most general and basic of MPLS applications. It typically uses the LDP (Label Distribution Protocol) to carry label-binding information between LSRs. The layer 3 control protocol can be any conventional routing protocol. In this case the FEC (Forwarding Equivalence Class) table is simply the conventional routing table found in any router. Packet forwarding is widely used to build simple MPLS-based networks where no specialized traffic engineering is required. A common early deployment is to support MPLS VPNs, which require an MPLS core over which to operate. MPLS VPNs MPLS VPNs provide an alternative to traditional layer 2 VPN services, and are based upon running customer IP traffic across an MPLS core. In order to maintain separation between customer address spaces, separate routing tables must be maintained by the implementation, and the customer sites are modelled by extensions to the BGP (Border Gateway Protocol), so that all customers’ routing remains external to the internal routing of the service provider network. MPLS Traffic Engineering Traffic engineering using MPLS aims to improve the control and manageability of IP-based networks by adding explicit steering of traffic alongside the normal routing-based control methods. To propagate the correct layer 3 information between nodes, extensions have been defined to traditional routing protocols, and a signalling model is used to establish label bindings, using extensions to the RSVP (Resource Reservation Protocol), or to LDP.

TY2702/v3.1

© Wray Castle Limited

2.7

Next Generation Transmission LSR

edge-LSR

edge-LSR

Label Switched Path (LSP)

MPLS and ATM terminology compared MPLS

ATM

Function

edge-LSR

ATM edge switch

Operates at the boundary of the network. Maps input packets onto L2 network.

LSR

ATM switch

Operates in the core of the network, switches.

LSP

Virtual Circuit and Virtual Path

Logical connection between a pair of edge devices, across which L2 switching operates.

MPLS and ATM Terminology MPLS introduces some new terminology for layer 2 switching. An LSR is an MPLS layer 2 switch, which also has the appropriate control plane functions to participate in setting up and tearing down LSPs. This is similar to an ATM SVC switch in respect of the user plane, but very different in respect of the control plane. An LSP is an end-to-end MPLS virtual connection between a pair of edge-LSRs, and across a network of LSRs. This is similar to ATM VCs and VPs. An edge-LSR is an LSR that originates or terminates LSPs and can classify IP traffic for forwarding across the most appropriate LSP by placing the packet in a FEC (Forwarding Equivalence Class). This is similar to an ATM edge switch. An FEC is a collection of different packets that are treated identically by the MPLS network. So, for example, in a best-endeavour internet, all packets to the same aggregate network prefix would typically be within the same FEC.

2.8

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

edge-LSR

edge-LSR

LSR

2

1

MPLS Shim header

2

Label 20 bits

LFT FEC 5 6 . . .

3

1

TTL 8

LFT

Out Interface Label 2 2

EXP S

In Out Interface Label Interface Label

23 41

1 1 . . .

23 41 . . .

2 2 . . .

37 44 . . .

NHLFE

MPLS Shim Header and MPLS Packet Forwarding MPLS adds a shim header to the packet being switched through the network. It uses information in the header to switch packets through the network and for the purposes of managing per hop behaviour, i.e. QoS. The shim header contains the following fields:    

label – 20 bits EXP (Experimental) bits – 3 bits S (Stack) bit – 1 bit TTL (Time To Live) bits – 8 bits

The 20-bit label is used to identify a packet for label forwarding. The EXP bits are used for QoS and the S bit indicates if a label stack is in place, or that this is the last label in the stack (i.e. S=1). The TTL is effectively a hop count. Assuming for the moment that appropriate LSPs have been established, and the edge-LSR can determine the most appropriate FEC to use for any incoming packet, then the forwarding operation is straightforward and similar to that of virtual circuit technologies such as Frame Relay and ATM. The NHLFE (Next Hop Label Forwarding Entry) within an LSR LFT (Label Forwarding Table) maps an inbound label to the appropriate outbound label for the path, and writes the new label into the packet. At the ingress edge-LSR, inbound packets are mapped from their FEC to the appropriate initial label value. At the egress LSR, the MPLS label is removed from the packet and conventional layer 3 routing forwards it towards its final destination.

TY2702/v3.1

© Wray Castle Limited

2.9

Next Generation Transmission Customer router

Customer router CE router

PE router

PE router

Provider routers

LSR

LSR LSR

LSR LSR

IP

CE router

IP 1 2

LSR

IP 1 3

IP 1 4

IP packet within MPLS label stack

Conventional IP packet from customer

1 = VPN label 2, 3, 4 = MPLS trunk labels

IP

Conventional IP packet to customer

PE – Provider Edge CE – Customer Edge

Architecture of MPLS-based IP-VPNs MPLS VPNs operate from a service perspective at the IP layer and classify routers in the customer and service provider network into one of four types. CE and PE routers operate at the boundary of the customer and service provider networks respectively. Unlike the layer 2 VPN model, the CE and PE routers are peers from a routing perspective. The VPN functionality is centred on the PE router. The CE router typically requires no VPN-specific configuration, simply treating the PE router as the next hop router in a ‘private’ network. The P (Provider) routers in the service provider core are also ignorant of the VPN address and routing information, and simply provide transport across the core network. The C (Customer) routers are conventional enterprise routers, with no special relationship to the VPN service. MPLS VPNs assume that the service provider operates an MPLS core between PE routers to which customers attach, and that this core has mechanisms for the establishment of LSPs between these edge routers. The MPLS core LSPs may have been manually provisioned, or may have been established by another MPLS control plane mechanism. This is all independent of the MPLS VPN service, but this infrastructure is required for the MPLS VPN model of RFC 2457 to operate. This separation of the core routing from the VPN functionality achieved by MPLS VPNs is possible because the MPLS VPN architecture uses label stacking to tunnel a customer’s VPN traffic across the MPLS core. Decisions about how to switch the traffic are made at the originating PE router, which understands the customer VPN locations and the LSPs in place across the core. Therefore it can apply a pair of labels as traffic enters the network from customer sites. The inner label is a VPN label allowing the traffic to be routed to the correct customer site at the destination PE router. This label is not examined or changed by the core routers. The outer label is a conventional LSP label, which allows the packet to be switched across a trunk LSP through the network core joining the PE routers. This label is examined and modified at the core routers, and operates like a conventional virtual circuit identifier.

2.10

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

L2 PVC (e.g. Frame)

L3-VPN (IP-VPN)

L2-VLAN (VPLS)

Provisioning of new site requires multiple new PVCs

Provisioning of new site requires provisioning in single PE router

Provisioning of new site requires provisioning in single PE-router

No visibility of customer routing in SP core

Visibility of customer routing in SP core

No visibility of customer routing in SP core

Traditional serial interfaces

Traditional serial interfaces

10, 100, 1000, 10,000 Mbit/s low cost WAN interfaces

All routing issues responsibility of customer – SP has simple PVC network

Complex routing issues for fault/performance management by SP

All routing issues responsibility of customer – SP has simple VLAN network

Motivation for MPLS-based VPLS In addition to IP VPNs implemented using an MPLS core, there is increasing interest in a multipoint bridged service generally known as VPLS (Virtual Private LAN Service). This is the topic of current Internet drafts, including draft-ietf-l2vpn-vpls-ldp-09.txt, dated June 2006. Whereas in IP-VPN services the service provider participates in the routing of customer traffic, in a VPLS the service provider sees a flat layer 2 Ethernet network and all routing is carried out by the customer premises routers. Each approach has advantages and disadvantages.

TY2702/v3.1

© Wray Castle Limited

2.11

Next Generation Transmission

Full mesh of MPLS-LSPs between PE routers FIB instance for ‘blue’ VPLS instance CE

CE

Blue

Blue

Red

Red

FIB per VPLS service instance

FIB instance for ‘red’ VPLS instance PE router

P router

PE router

MPLS VPLS Architecture The architecture defined in the current VPLS drafts builds upon the approach taken to implementing IPVPNs using MPLS. PE routers connect customers to the service provider network and label stacking tunnels customer traffic with VPLS identifiers across an MPLS core LSP network, which fully meshes the PE routers. Where this solution differs from the IP-VPN service is in the implementation of a learning bridge between the PE routers, rather than the propagation of customer routes. When a customer is attached to a physical circuit, either the port is associated directly with their VPN service and its identifier, or (more usually) an 802.1q VPN_ID tag representing the customer VLAN is mapped internally to a separate instance of a FIB (Forwarding Information Base). This is the bridging equivalent of the VRF (Virtual Routing and Forwarding) used in IP-VPNs. Configuration of an instance of the VPLS service only requires that the physical port is mapped to the customer VPLS identifier in the PE router, or that the 802.1q tag is mapped to the VPLS identifier in the PE router.

2.12

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits Performance evaluation and optimization of operational networks Is the bandwidth utilization on these links within acceptable limits?

Measurement, characterization, modelling and control of Internet traffic Is this traffic meeting its Service Level Agreement (SLA) on delay, delay variation and loss? Usually supported by Differentiated Services (DiffServ)

What is MPLS Traffic Engineering? RFC 2702 defines Internet traffic engineering as ‘That aspect of network engineering dealing with the issue of performance evaluation and optimization of operational networks. Traffic engineering encompasses the application of technology and scientific principles to the measurement, characterization, modelling and control of Internet traffic.’ As this definition suggests, successful traffic engineering needs to address the performance of the network from two distinct perspectives. It seems that the CR-LDP (Constraint-based Routing Label Distribution Protocol) is used in optical networks, whereas the RSVP-TE (Resource Reservation Protocol – Traffic Engineering) is widely used elsewhere. Traffic-Oriented Performance Traffic-oriented performance optimization ensures that the QoS experienced on individual traffic streams is optimal in terms of delay, delay variation and packet loss. Resource-Oriented Performance Resource-oriented performance optimization ensures that the utilization of scarce resources in the network is optimized, including bandwidth, memory and processing power.

TY2702/v3.1

© Wray Castle Limited

2.13

Next Generation Transmission LDP Hello Packet Sent to 224.0.0.2 (Port 646) LDP Hello Packets

Establish LDP session between neighbour Label Switched Routers

TCP SYN (646) TCP SYN + ACK (646) TCP ACK (646)

Egress

Ingress Request Label to Network A

Request Label to Network A

+ Attributes Label Mapping 19

+ Attributes Label Mapping 21

P1

PE2

Database

OSPF v2 or IS-IS

Database

Network A PE1

OSPF v2 or IS-IS

Database

TE (Traffic Engineering) Label Distribution Protocols – CR-LDP TE is not QoS; it is used to manipulate traffic flows for that best fit the network topology. MPLS TE is the process of building links between nodes with an available bandwidth and then making allocations against that in support of circuits, reserving the bandwidth as required. For MPLS to support TE it needs to extend an existing IGP (Interior Gateway Protocol), such as OSPF and IS-IS (Intermediate System to Intermediate System), to include TE extensions. It also needs to extend the label distribution protocols used for the creation of label switched paths. These protocols are CR-LDP and RSVP-TE, both of which are supported in the ASON (Automatically Switched Optical Network) architecture. CR-LDP (Constraint-based Routed Label Distribution Protocol) LDP starts a discovery process by periodically sending hello packets over UDP using multicast address (224.0.0.2 using port 646). Once a neighbour has been detected, a TCP session (using port 646) is established between the pair. Once this has been completed the neighbours are free to start advertising labels. Notification messages are used to indicate the ongoing status of the neighbours and the labels. CR-LDP uses attributes as per RFC 3036 and RFC 3212, which provides extensions to the LDP model to support such things as bandwidth in order to support provision of links using traffic engineering.

2.14

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

RSVP-TE Egress

Ingress PATH to Network A

PATH to Network A

+ TE Attributes

+ TE Attributes

RESV Label 19

PE2

Network A

RESV Label 21

P1

PE1

TE (Traffic Engineering) Label Distribution Protocols – RSVP-TE RSVP-TE (Reservation Protocol – Traffic Engineering) RSVP-TE is an IETF-defined protocol as per RFC 2205 and is used to establish connections that may be subject to routing constraints in an MPLS network. RSVP-TE is an extended version of IP’s RSVP and includes additional fields to support parameters such as bandwidth. GMPLS extends both CR-LDP and RSVP-TE to support technologies beyond packet, frame and cellbased switching and now includes time division, lambda switching and fibre/physical switching. GMPLS is further extended to support the requirements of the GENERALISED_UNI object as per the OIF UNI-01.0. RSVP-TE and CR-LDP both allow for traffic engineering, but come from a datacoms background and have no knowledge of call control. To this end the OIF UNI provides extensions in support of the basic call model, i.e. call control. This also applies to the E-NNI, which is used in ASON between domains. This does not apply to the I-NNI as this is an intra-domain interface that may be more proprietary in nature. The types of circuits that can be established include SPCs (Soft Permanent Connections) and SCs (Switched Connections). Normally, SPCs are established by a management platform using a central circuit database, while SCs are more likely to be set up on demand when triggered by signalling from a user/client device over the UNI.

TY2702/v3.1

© Wray Castle Limited

2.15

Next Generation Transmission

PE2

P2

P1

PE1

Ingress

Egress

PE1

L3

PE1

L2

PE1

SWAP

L3

packet L3

L1

SWAP

L2

L2

packet L2

L1

packet L1

Data Flow

Downstream Nodes

Label Distribution Mode GMPLS prefers the use of ordered label distribution as opposed to independent control. With ordered control, the PE router acting as the egress initiates the LSP by assigning a label (L1), which corresponds to its loopback address. It then advertises this mapping to its peer router (P1). P1 checks its IGP routing table to ensure that PE1 is on the shortest path to the destination. If successful it will assign its label to reach PE1 and together with the label from PE1 enter this into its forwarding table. P1 then advertises to P2 a label (L2) to use to get to PE1. P2 repeats the checks and, if successful, assigns its label (L3) and then advertises this to PE2. PE2 performs the final check for this LSP and, if successful, enters the label (L3) into its forwarding table to reach PE1. Once the LSP is successfully established, traffic wishing to use this LSP will be mapped by the ingress LSR (PE2) through the forwarding table using the label (L3) provided by P2. Independent mode would assign labels for all egress PEs that it can see from its IGP and then advertise these to its neighbours. The neighbours work independently of each other and only when all have managed to determine a suitable label for the shortest path is the LSP in place. If one node en route fails to set up a mapping, other LSRs are likely to be unaware of this. Ordered LSP control mode would mean that the LSR would have to wait to receive bindings from its downstream neighbours before sending labels it has generated upstream. Independent mode allows LSRs to distribute label bindings freely to their neighbours either downstream or upstream. The terms ‘upstream’ and ‘downstream’ are used with reference to the direction of the data flow along an LSP, i.e. from the point of ingress to the point of egress, and not to the direction in which the labels are sent. In the example, labels are distributed from PE1, the egress point, to PE2, the ingress point. Data flow is from PE2 to PE1 along the LSP. Downstream nodes are P2, P1 and PE1.

2.16

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits Downstream on demand

PE2

P2

P1

PE1 192.168.10.0/24

Request Label to 192.168.10.0/24 Use Label 21 to 192.168.10.0/24

Unsolicited downstream used with independent control

PE2

P2

P1

PE1 192.168.10.0/24

Use Label 21 to 192.168.10.0/24

Label Advertisement Mode Labels in GMPLS should be using ‘downstream on demand’ mode, whereby an upstream LSR requests of its downstream neighbour a label mapping to a specific destination. The downstream LSR should then respond with a suitable label to use to support the LSP being built to the destination. One problem in any MPLS network is to make sure that all nodes are configured with the same method. If an LSR was configured to support downstream unsolicited operation whilst the others were all supporting downstream on demand, it would be providing unnecessary information and would not take part if a request for a label was received from an upstream device.

TY2702/v3.1

© Wray Castle Limited

2.17

Next Generation Transmission P4

P3 PE1

PE1

L4

L5

PE1

P2 PE1

PE1

L2

PE1

PE1

L2

PE2 PE1

L2

Conservative

PE1

L2

PE1

L5

PE1

L4

L2 PE1

L4

PE1

L2

L3

P5

P6

PE1

L3

Use this remember these

Liberal

Label Retention Mode GMPLS does not make any provision for the type of label retention; this may be left to implementers to decide. In either case, LSRs will receive label advertisements from downstream LSRs. They will check their internal routing functions, i.e. IGP, and determine which label is from a peer node on the shortest path to the destination. In the case of conservative label retention it will only store the entry representing the shortest path. For liberal label retention it will remember all (or a certain number of) labels pertaining to all paths towards the destination. The main problem with liberal retention would be that of the memory requirements needed to store all of these. However, in the case of a failure, liberal retention would already have an alternative label to use to the destination whilst conservative mode would need to signal and learn an alternative.

2.18

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits PE2

Explicit or Strict Source Routing P3

PE1

PE3 P2

P1

Loose Source Routing P3

PE1

PE3 P1

P2

Routing GMPLS supports both explicit and loose source routing in support of the establishment of LSPs. For explicit routing neighbour nodes will pass a request including the remainder of the path towards the destination. Then at each successive node they will remove their entry from the list and forward the request to wards the next destination on the list, until naturally all nodes in the explicit list have been contacted and labels have been assigned to support the ER-LSP. An explicit list will therefore initially contain a complete routing link by link between the two end points. Loose source routing allows for an intermediary node to use what it thinks is the best route towards the destination, as learned from its IGP. Loose source routing may contain a list of intermediary points; although this will not be the intended path, they will be points along its path. It is left to the nodes that appear in this list to select a route towards the next entry. Explicit or strict source routing is a valuable traffic engineering tool as it allows an operator to specify specific routes around its network for its customers’ traffic, which may differ from the IP preferred route.

TY2702/v3.1

© Wray Castle Limited

2.19

Next Generation Transmission

2.20

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission

APPENDIX A

FRAME RELAY

© Wray Castle Limited

AI

Next Generation Transmission

AII

© Wray Castle Limited

Options for Layer 2 Virtual Circuits Incoming

Outgoing

Incoming

Inter- DLCI Inter- DLCI face face

d

1

c

8

d

9

c

10

2

d

a d

c

3

d

1

c

4

d

10

2

d

a b

FRAD

Outgoing

Inter- DLCI Inter- DLCI face face

b d

c

FRAD

c c a

Incoming Fragment + Address (Data Link Connection Identifier (DLCI))

Outgoing

Inter- DLCI Inter- DLCI face face

a

8

c

3

b

9

c

4

2

c

Frame Relay – Frame Switching and Addressing A customer may use Frame Relay to interconnect several geographically disparate sites. Computer applications as well as VoIP (Voice over IP) services are typical of the services supported. The FRAD (Frame Relay Assembler/Dissembler) takes the information in from the customer equipment and encapsulates the traffic into a Frame Relay frame. The frames are then addressed using a DLCI (Data Link Connection Identifier). The DLCI is bound to a fragment. The fragment is usually a number of TDM timeslots; in the example shown, two timeslots have been combined to form the fragment. These timeslots in turn are usually carried in a TDM structure such as an E1/T1. The circuit path through the network may be either permanently set i.e. PVC, or dynamically established as an SVC. For SVCs a signalling protocol between the frame switches is required; this could be established using Q.933 and Q.922. The circuit path in this example is a PVC – it has been configured centrally. Each switch has a simple look-up table based on the interface and DLCI values. Thus if the FRAD associated with the laptop wishes to send information to the desktop PC, it will forward this into the network with a DLCI value of 1. This incoming value will be switched out of interface ‘c’ with a value of 8. The frames incoming at the second switch will have a incoming value of 8. The second switch will look up its table and forward the frames out of interface ‘c’ with a new value of 3. The final switch in the chain will see an incoming value of on its interface ‘c’, and as a result of its table settings it will forward the information towards the FRAD with a value of 1 on interface ‘d’.

TY2702/v3.1

© Wray Castle Limited

A2.1

Next Generation Transmission

F L A G

Header

Information

1598 octets

Address (6 bits) Address (4 bits)

C/R

EA (0)

DE

EA (1)

FCS

F L A G

2 octets 1 octet

Frame Relay over TDM The Frame Relay frame is usually carried in a TDM fragment, which in turn could be transported using a transmission technology such as SONET/SDH. This could be then transferred over fibre as a SONET/SDH frame or carried in an individual wavelength as part of a WDM network.

Frame Relay Frame Structure An example of the frame relay frame is shown with the following fields:    

Flag FCS (Frame Check Sequence) Information Field Header

Flags are used to delimit the Frame Relay frame set to 01111110. The FCS uses a 16-bit CRC (Cyclic Redundancy Check), which is computed across the frame to allow the receiver to check for transmission errors. The Information Field is the payload of the frame. It can be up to a maximum of 1598 octets. The header shown here is set to 2 octets, as indicated by the Extension bit (EA) set to 0 in the first octet and then 1 in the second, where the 1 indicates this is the end of the header, the header could be extended over 3 or 4 octets. The header could be extended further to carry a longer address field. Here, the DLCI is a 10-bit value over two octets. DE (Discard Eligible) is used in congestion control, as are the FECN (Forward Explicit Congestion Notification), which is used upstream to inform other devices that congestion has occurred, and the BECN (Backward Explicit Congestion Notification), which is used on any frames in the downstream direction to inform downstream switches of congestion. C/R (1 bit) is used to designate whether the frame is a command or response. Its use is not defined by frame relay and as such is left to implementors to decide on its use. Therefore this field may not be used.

A2.2

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

Discard on entry

EIR

CIR

Excess Information Rate (EIR) Attempt to deliver Mark 'Discard Eligible' Committed Information Rate (CIR) Deliver

Access Rate

QoS (Quality of Service) The CIR (Committed Information Rate) is the data rate at the ingress point that has been contracted with the customer. It must be supported by the network under normal conditions. The EIR (Excess Information Rate) is at a level above the CIR. The communications provider will attempt to deliver the frames that exceed the CIR but are below the EIR limit. However, it will mark these frames as ‘Discard Eligible’, and as they pass through the network they will be discarded by a subsequent switch through which they intend to pass which is currently suffering from congestion. Any frames at the ingress above the EIR will be discarded on entry.

TY2702/v3.1

© Wray Castle Limited

A2.3

Next Generation Transmission

Frame Relay

TDM

SONET/SDH

Frame Relay over TDM The Frame Relay frame is usually carried in a TDM fragment, which in turn could be transported using a transmission technology such as SONET/SDH. This could then be transferred over fibre as a SONET/SDH frame or carried in an individual wavelength as part of a WDM network.

A2.4

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission

APPENDIX B

ATM

© Wray Castle Limited

BI

Next Generation Transmission

BII

© Wray Castle Limited

Options for Layer 2 Virtual Circuits

VCC Endpoint 1

Virtual Path Switch 1

A

Virtual Channel Switch

Virtual Path Switch 2

B

C

Virtual Path Switch 3

D

VCC Endpoint 2

E

F

Virtual Channel Connection (VCC) VC Link 1

VC Link 2

VCI-7 VPI-1

VC Layer

VCI-8

VCI-7 VP Link

VP Link

VP Link

VP Link

VP link

VPI-1

VPI-2

VPI-3

VPI-4

VPI-5

Virtual Path Connection 1

VCI-8 VPI-5 VP Layer

Virtual Path Connection 2

ATM Terminology – VPs (Virtual Paths) and VC (Virtual Channel) Switches ATM is a connection-oriented switching technology within which the basic unit of transport is a fixed length packet known as a cell. Cells transport data flows over an ATM connection. An ATM connection is referred to as a VCC (Virtual Channel Connection). VCCs may be preconfigured, in which case they are known as PVCs (Permanent Virtual Connections), or they may be set up automatically using a suitable control protocol, in which case they are known as SVCs (Switched Virtual Connections). VCs are identified using a two-layer channel identifier consisting of a VPI (Virtual Path Identifier) and a VCI (Virtual Channel Identifier). This allows for switching at two levels. Individual circuits may be identified and switched using both the VPI and VCI; devices capable of this are generally known as VC switches. Groups of circuits may also be switched using just the VPI; devices capable of this are known as Virtual Path switches. VC switches must be able to terminate a VP, and by implication are also VP switches. In this example shown, an ATM VC has been established between VCC Endpoint 1 (A) and VCC Endpoint 2 (F) through several VP and VC switches. At A the VC is identified as VPI-1: VCI-7. This is transported over a physical connection (such as SDH) to Virtual Path Switch 1 (B). Virtual Path Switch 1 is not interested in the value of the VCI; it is simply configured to switch the traffic from VPI-1 to VPI-2. Virtual Path Switch 2 (C) is similarly configured to switch VPI-2 to VPI-3. Thus VCI-7 is transferred over VPI-1, then VPI-2, and finally it arrives on the Virtual Channel switch (D) on VPI-3. The Virtual Channel switch (D) is configured to switch cells arriving on VPI-3: VCI-7 to VPI-4: VCI-8. The path is completed to Endpoint 2 (F) via Virtual Path Switch 3 (E). Note that cells for this circuit arrive at Endpoint 2 (F) labelled as VPI-5: VCI-8. In the VP layer, cells have been transported over several VP links. A VP link exists between any pair of devices applying or swapping a VP label. There are two VP connections used in this example. A VP connection is simply a concatenation of VP links. A VP connection terminates at points where the VCI must be acted on. In the VC layer, two VC links have been used; A-D and D-F. A VC link exists between a pair of devices applying or swapping the VCI. The complete connection between endpoints is known as a VCC. A VCC is simply a concatenation of VC Links. The ability to switch groups of circuits under a single VP label ensures that size of switching tables at a VP switch is minimized.

TY2702/v3.1

© Wray Castle Limited

B2.1

Next Generation Transmission

Customer Site UNI Private – ATM-F (UNI+OSPF) Public – ITU-T B-ISUP

ITU-T: Q.2931 Q.2971 ATM-Forum UNI 3.0/3.1 UNI 4.0 (Q.2931)

Customer Site

9 Octets

UNI

NNI or PNNI

261 Octets

STM-1

UNI

VC-4 9

SOH

J1 B3 C2 G1

Customer Site ***

***

Incoming Outgoing Outgoing Incoming InterInterInter- DLCI InterVPI VCI DLCI VPI VCI face face face face

a

10

1

b

11

4

a

4

2

b

11

2

2

***

ATM cell VC-4 POH 53 Octets

ATM Interfaces and Adaptation Layers ATM allows operators/vendors to manage bandwidth across any interface, while providing services to both circuit- and packet-switched information. These valuable assets allow any application software to own dedicated bandwidth in order for the application to communicate. User data/traffic is no longer confined to 64 kbit/s timeslots on a physical layer transport system such as an E1 (PDH). Using ATM, greater or smaller bandwidths can be configurable, dependent on requirements. Bandwidth may be changed by different means, dependent on the type of ATM virtual circuit created. ATM switches fixed-length packets (cells) of information in the connection-oriented mode of operation, ensuring that all cells relating to a specific connection follow the same route through the network. Despite its name, the ATM cell stream is synchronous, and is ideally suited for delivery over synchronous transmission systems such as SDH. It is the way in which cells relating to a particular connection are transported that can be asynchronous rather than the operation of the complete cell stream. ATM has defined two interfaces, that of the UNI (User Network Interface), which connects customers to ATM networks, and the internal NNI (Network to Network Interface). The signalling protocol used across the UNI is usually based on Q.931 i.e. ITU-T Q.2931. Both the ITU-T and ATM Forum use these standards for their UNI. UNI signalling would be required specifically to support SVCs (Switched Virtual Channels). Most major deployments do not use SVCs and as such do not deploy UNI signalling. A positive exception to this could be seen in 3G networks where Q.2931 signalling is used to provide circuits for real time voice services i.e. Circuit Switched. The ATM Forum and ITU differ when it comes to the NNI. In the case of the ATM Forum this is PNNI (Private NNI) which is based on the UNI signalling with a dynamic routing protocol based on OSPF. The ATM Forum also extended some of OSPF's Link State Advertisements and renamed them as PTSEs (PNNI Topology State Elements). The PTSE LMI (Local Management Interface) uses VPI/VCI of 0/16. The ITU-T version of the NNI is their PNNI (Public NNI) where the signalling is based on the existing SS7, where the SS7 messages have been extended to include ATM parameters. This approach is consistent with their view of ATM as part of B-ISDN.

B2.2

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

Enterprise VoD

Internet

VoIP

Voice AAL Type 0

Q.2931 B-ISUP

Layer 2

SNMP CMIP

User

SAAL

AAL

Typical use Raw ATM cells containing unformatted data

1

CBR services

2

Real-time services

5

Packet data and Signalling

ATM Layer Physical e.g. SONET/SDH, PDH, Packet 1

The ATM Layered Reference Model The ATM layered reference model consists of three layers: physical, ATM, and AAL (ATM Adaptation Layer). The physical layer provides for the transport of cells between ATM cell switching interfaces. It performs functions such as cell delineation and the insertion of idle cells. Suitable physical layers include SONET/SDH. The ATM layer provides for the switching of cells between interfaces. The choice of output virtual link for any given input link is based on routing table information held within the ATM switches. The AAL provides for the support of multiple applications by adapting the higher-layer information for transfer across the ATM switching network. In effect, the AAL isolates the ATM layer from the complexity of functions associated with multiple applications. SAAL (Signalling AAL) is a specific implementation of AAL5 with two additional sublayers called SSCF (Service Specific Coordination Function) and SSCOP (Service Specific Connection Oriented Protocol). The higher layer may consist of functions required to exchange user data. Higher layers may also include access signalling, i.e. Q.2931; core network (PNNI) signalling using B-ISUP. The higher layers will also support management protocols such as CMIP (Common Management Information Protocol) or SNMP (Simple Network Management Protocol).

TY2702/v3.1

© Wray Castle Limited

B2.3

Next Generation Transmission a) User–Network Interface (UNI) Octets

48

Information Bits

5

HEC 8

C L PT P 1

VCI

3

16

VPI

G F C

8

4

b) Network–Network Interface (NNI) Octets

48

Information Bits

5

HEC 8

C L PT P 1

3

VCI 16

VPI 12

ATM Cell Fields The five-octet header contains the following fields:      

GFC (Generic Flow Control) VPI (Virtual Path Identifier) VCI (Virtual Channel Identifier) PT (Payload Type) CLP (Cell Loss Priority) HEC (Header Error Control)

The 4-bit GFC is used to control traffic between the user and ATM network, thus it is only seen in the UNI, not the NNI. It provides local functions only. The VPI identifies a virtual path link between two nodes. The VPI allows a VP switch to route cells based on information held within the node’s switching table. The VCI identifies a VCL between two adjacent nodes. The VCI (along with the VPI) allows a VC switch to route cells based on information held within the node’s switching table. The 3-bit PT indicates the nature of the payload information. It distinguishes between user data and management data. Cells with their CLP set to 1 are deemed eligible for discard by the network in the event that congestion is encountered within the network. Thus it provides a method for prioritizing cells. HEC is used to carry out a CRC of the header. The HEC does not report on the payload of the cell, only the header. If an error is found, the cell is discarded. Though this field is provided by the ATM layer, it is populated and used by the physical layer.

B2.4

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits ATM Service Category

≡

ATM Transfer Capability

ITU-T ‘ATM Transfer Capability’

Typical Use

Constant Bit Rate (CBR)

Deterministic Bit Rate (DBR)

Real-time, QoS guarantees

real-time Variable Bit Rate (rt-VBR)

(For further study)

Statistical mux, real-time

non-real-time Variable Bit Rate (nrt-VBR)

Statistical Bit Rate (SBR)

Statistical mux

Available Bit Rate (ABR)

Available Bit Rate (ABR)

Resource exploitation feedback control

Unspecified Bit Rate (UBR)

No equivalent

Best effort, no guarantees

No equivalent

ATM Block Transfer (ABT)

Burst level feedback control

ATM Forum ‘ATM Service Category’

ITU-T and ATM Forum Correlation An ATC (ATM Transfer Capability) is intended to represent a class of ATM connections that have homogeneous characteristics in terms of traffic pattern, QoS requirements and possible use of control mechanisms, making it suitable for a given type of resource allocation. ATC is an ITU-T definition; the ATMF (ATM Forum) equivalent definition is termed an ATM Service Category. A comparison of the two definitions are shown. Referring principally to the ITU-T definitions, the transfer capabilities are defined as follows and summarized below:    

DBR (Deterministic Bit Rate) SBR (Statistical Bit Rate) ABR (Available Bit Rate) ABT (ATM Block Transfer)

The DBR is based on a constant (maximum) bandwidth allocation. It is termed CBR (Constant Bit Rate) by ATMF. The SBR is based on an average bandwidth allocation. This is termed VBR (Variable Bit Rate) by ATMF. The ABR is based on dynamic bandwidth allocation, where the allocated resources vary with time depending on network availability. The ABT is based on block or burst allocation, and is specific to ITU-T. In addition, the ATMF has split the VBR category into rt-VBR (real-time Variable Bit Rate) and nrt-VBR (non-real-time Variable Bit Rate) and has introduced the ATM Service Category known as UBR (Unspecified Bit Rate), which is considered only by ATMF. Here, no explicit resource allocation is performed; neither bandwidth nor QoS objectives are specified.

TY2702/v3.1

© Wray Castle Limited

B2.5

Next Generation Transmission Traffic Contract ATM Transfer Capability Connection Traffic Descriptor Source Traffic Descriptor Peak Cell Rate (PCR) Sustainable Cell Rate (SCR) Minimum Cell Rate (MCR) QoS Class QoS Parameters (i.e. CLR, CTD, CDV)

" +RVW $70&HOOV &$& 81,

1HWZRUN

83&

Traffic Contract A traffic contract specifies the negotiated characteristics of the ATM layer connection at the UNI. The network must only accept a new connection if the traffic contract can be honoured and must ensure that the user adheres to this contract during the connection by policing the connection traffic flow. The traffic contract identifies an ATC (ATM Transfer Capability). The ATC is realized by a source traffic descriptor (e.g. peak cell rate, mean cell rate), associated CDV (Cell Delay Variation) tolerances and requested QoS class. All are declared by the user at connection set-up by means of signalling (SVC) or subscription (PVC). Once the connection has been accepted, the value of the CAC (Connection Admission Control) and UPC/NPC (Usage Parameter and Network Parameter Control) parameters are set by the network at the UNI and the NNI respectively. CAC represents a set of actions taken by the network at call set-up in order to accept or reject an ATM connection. UPC/NPC represent a set of actions taken by the network to police ATM connection usage, e.g traffic volume and cell routing. In other words UPC/NPC enforce compliance of ATM connection usage with the traffic contract.

B2.6

© Wray Castle Limited

TY2702/v3.1

Options for Layer 2 Virtual Circuits

Typically provided by SDH

OAM Hierarchical Levels OAM functions are performed on five OAM hierarchical levels associated with the ATM and physical layers of the ATM reference model. These functions, identified by the ITU-T, result in five bidirectional information flows, referred to as OAM flows. Not all of these flows need to be present, as OAM functions of a missing level are performed at the next higher layer. The levels are as follows: Virtual Channel Level (F5) This extends between network elements performing VCI termination functions, such as VC switches and CEQ (Customer Equipment). This level encompasses one or more VCLs (Virtual Channel Links) and may span a complete VCC (Virtual Channel Connection). Note that a virtual channel link is transported over a VPC and that a VCC is a concatenation of VCLs. Payload Type indicates the presence of OAM cells at this level. Virtual Path Level (F4) This extends between network elements performing VPI termination functions, such as VP crossconnects and CEQ. This level encompasses one or more VPLs (Virtual Path Links) and may span a complete VPC (Virtual Path Connection). A reserved VCI value is used to indicate presence of OAM cells. Transmission Path Level (F3) This extends between network elements assembling/disassembling the payload of a transmission system and associating it with its OAM functions. Cell delineation and HEC functions are required at each endpoint. The transmission path is connected through one or more digital sections. Digital Section Level (F2) This extends between section endpoints and comprises a maintenance entity. Regenerator Section Level (F1) A regenerator section is a portion of a digital section and as such is a maintenance sub-entity (such as a repeater). It should be borne in mind that the Physical Layer within the ATM model may be realized by technologies such as SDH or a cell-based technology. SDH will exchange its OAM F1 to F3 information within its own synchronous overhead channels, while a cell-based technology will need to identify cells specifically marked as OAM. TY2702/v3.1

© Wray Castle Limited

B2.7

Next Generation Transmission

VC-4 Payload (260 columns) J1 B3 C2 G1 F2 H4 F3 K3 N1

ATM Cell

VC-4 Path Overhead H4 byte used as a pointer to indicate the first occurrence of an ATM cell header in the same row as the H4 byte.

Mapping ATM Cells into SDH (Cell Delineation) The mapping of ATM cells is performed by aligning the byte structure of every cell with the byte structure of the VC used. According to the ITU-T, there are several ways in which ATM cells can be mapped into an SDH frame, including VC-4 use. Considering the VC-4 option, the diagram shows how ATM cells containing 53 octets could be mapped into the Virtual Container payload. The VC-4 is a standard 261-column payload, with the first column reserved for the VC-4 POH (Path Overhead); the remaining 260 columns are designated as the payload. The ATM cells are transported as a stream in the payload area, where each cell has the characteristic 53 octets, i.e. 5-octet header and 48octet data. The ATM cell header can be thought of as the cell’s FAW (Frame Alignment Word), which facilitates cell delineation. The H4 byte in the VC-4 POH is identified in G.707 as being ‘a generalized position indicator for payloads, which is payload dependent’. Thus the H4 byte is used as the pointer, indicating the first occurrence of an ATM cell header, which is found in the same row as the H4 byte. The 48 bytes of the ATM cell for data are scrambled prior to transmission to prevent the ATM signal from replicating the SDH frame sequence. The 5-byte header is not scrambled, however, as this would affect ATM cell delineation. The H4 byte indicates the start of an ATM cell to the scrambler/descrambler.

B2.8

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission

SECTION 3

CARRIER BASED ETHERNET AND TRANSMISSION SYSTEMS

© Wray Castle Limited

I

Next Generation Transmission

CONTENTS Transport Network Evolution

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.1

Carrier Ethernet Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.2 Motivation for Carrier Ethernet Services – Mobile Operator Perspective . . . . . . . . . . . . . . . . .3.3 Advantages and Disadvantages of Traditional Ethernet/GE . . . . . . . . . . . . . . . . . . . . . . . . . .3.4 Metro Ethernet Forum (MEF) Carrier Ethernet Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.5 MEF Terminology for Ethernet Services

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.6

E-Line Services – Ethernet Private Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.7 Ethernet Line Services – Ethernet Virtual Private Line (EVPL) . . . . . . . . . . . . . . . . . . . . . . . .3.8 Ethernet Private LAN (EP-LAN) Service

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.9

E-Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.10 MEF Service Definition Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.11 MEF Metro Ethernet Network Model

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.12

The 802.1 Standards for Bridged Networks

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.13

Service Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.14 EVC Bandwidth Profiles (BWP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.15 IEEE 802.1ad Provider Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.16 Provider Bridge Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.17 Ethernet Label Switching (ELS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.18 Scalability of Provider Bridge (PB) Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.19 Provider Backbone Bridging (PBB) Networks PBB Basic Network Architecture

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.20

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.21

MAC Learning in PBB Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.22 Multiplexing Service Instances through a B-VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.23 More on Service Multiplexing in a PBB Network

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.24

Simple Provider Bridged Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.25 II

© Wray Castle Limited

Carrier Based Ethernet and Transmission Systems

CONTENTS Hierarchical PBB Networks

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.26

Benefits and Limitations of PBB Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.27 Provider Backbone Bridging Traffic Engineering (PBB-TE) . . . . . . . . . . . . . . . . . . . . . . . . . .3.28 Transport Profile (MPLS-TP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.29 MPLS-TP Transport Profile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.30 Carrier Ethernet Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.31 Ethernet OAM Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.32 802.3ah – EFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.33 CFM and Performance Management (PM)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.34

End-to-End Ethernet Service OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.35 MEP and MIP Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.36 Ethernet Service OAM Service Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.37 CFM Continuity Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.38 CFM Fault Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.39 Link Trace Message – MIP Address Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.40 Loopback Procedures – CFM Fault Verification/Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.41 CFM AIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.42 Performance Monitoring Y.1731 Frame Loss Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.43 Performance Monitoring Y.1731 Delay and Delay Variation

. . . . . . . . . . . . . . . . . . . . . . . . .3.44

OAM Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.45 Ethernet Physical Layer Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.46 LAN PHY and WAN PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.47 LAN PHY and WAN PHY in WANs and MANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.48 Ethernet Physical Layer Options

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3.49

© Wray Castle Limited

III

Next Generation Transmission

IV

© Wray Castle Limited

Carrier Based Ethernet and Transmission Systems

OBJECTIVES At the end of this section you will be able to:



briefly discuss the evolution of transport networks



list the advantages and disadvantages of LAN-based Ethernet



identify and discuss the five attributes used by the MEF to define Carrier Ethernet (CE)



discuss the terms UNI and Ethernet Virtual Connection



identify and discuss the range of CE services defined by the MEF



discuss Service Profiles, their relationship to BandWidth Profiles (BWP) and how BWPs may be assigned at a UNI



discuss the structure of 802.1Q and 802.1ad VLAN tags and how they may be used in a Provider Bridge network



identify tags associated with Provider Backbone Bridging (PBB) networks



discuss the operation of simple and hierarchical PBB networks



discuss the roles of Ethernet Label switching, PBB-TE and MPLS-TP as transport options for Carrier Ethernet services



list and discuss the functions associated with Ethernet OAM with particular reference to EFM, Connection Fault Management (CFM) and Performance Management (PM)



identify the roles associated with different OAM maintenance levels



discuss the roles of MEPs and MIPs in Ethernet OAM



with the aid of suitable diagrams explain the use of various messages used in CFM and PM operations

© Wray Castle Limited

V

Next Generation Transmission

VI

© Wray Castle Limited

Carrier Based Ethernet and Transmission Systems

ETH Client Services

MPLS IP-POS

PDH

ATM PBB-TE

Transport Networks G.805 Layered networks

MPLS-TP Characteristics: Connection oriented

SDH

Fast recovery

NG-SDH

Deterministic Sophisticated OAM

OTN Fibre

Static Provisioning

WDM

Optical Technology 1990 Transport eras

1995 1. Circuit

2000 2. Optical

2005 3. Packet

Transport Network Evolution Transport networks provide links between service platforms that are reliant on stable and reliable links between their various nodes and elements. In the early 1990s, the first era of transport networks based on a G.805, which describes a generic functional architecture of transport networks, were based on SDH and SONET to provide transport quality links between switching elements. SDH/SONET were designed against a TDM and ATM background to ‘efficiently’ manage sharing of the physical media. The characteristics generally associated with carrier transport system are shown in the diagram. WDM systems emerged to address the increasing demand for capacity. This led to the development of the OTN set of standards, also designed following G.805 principles, and in parallel to this the NG-SDH standards were produced. Both OTN and NG-SDH provided more efficient ways of dealing with packet transport. The requirement to further increase the efficiency of transporting packet data, using layer two aggregation, saw the introduction of carrier class layer two technologies including MPLS Transport Profile (MPLS-TP) and Provider Backbone Bridging Traffic Engineering (PBB-TE). These technologies provide a mechanism for the static provisioning of end-to-end connections, configured with the appropriate CoS and QoS, with options for building working and standby paths for resilience. They also provide a rich set of OAM functions. Modern transport networks aim to provide carrier class transport of Ethernet service frames. Carrier Ethernet Transport is not a single technology but a multilayer network using a range of the technologies shown above.

TY2702/v3.1

© Wray Castle Limited

3.1

Next Generation Transmission

Reliable Transport Network implemented using layer 1 and layer 2 technologies

LAN

Customer Bridge

Carrier Edge Bridge

MAN/WAN

Carrier Edge Bridge

LAN

Customer Bridge

Carrier Ethernet Network Normal Ethernet Frames

Carrier Ethernet Transport

Normal Ethernet Frames

Carrier Ethernet Services A carrier-based Ethernet service provides Ethernet connectivity between customer sites, over a MAN or WAN. This service is provided using a Carrier Ethernet Network that is assumed to provide reliable transport services. The transport service itself may be Ethernet based or could rely upon pseudo wire technologies or classic transmission techniques such as SDH using Packet over SONET (RFC 2615) or Generic Framing Procedure (GFP). The Ethernet layer 2 model of a service allows point-to-point and bridged networks and aims to compete with/replace traditional PVC services provided by ATM and Frame Relay.

3.2

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems Subscriber base growing strongly PDA

iPhone

Cost curve for TDM transport closely linked to traffic .

Blackberry

Meet me there at 5:00

Home

E-mail

Voice dominant

Web

Traffic TDM costs

Mobile Broadband EDGE (100 kbit/s) WCDMA (384 kbit/s)

Traffic/Revenue disconnect

1000’s Radio sites

HSDPA (7.2 Mbit/s)

Revenue

HSPA+ (24 Mbit/s) LTE (30-40 Mbit/s) Services: Downloads Interactive Games Video TV

Data dominant Mobile Backhaul Traditionally implemented using NxE1 TDM

Ethernet transport flattens the cost curve. Graph: source Light Reading

Motivation for Carrier Ethernet Services – Mobile Operator Perspective The mobile subscriber base continues to grow strongly. With the introduction of mobile broadband access, the proliferation of devices such as the Android, iPhone, PDAs and BlackBerry, and the popularity of high-bandwidth packet-based services such as downloads, interactive games, video and TV, the amount of traffic used by each subscriber is growing as well. Larger operators have thousands of cell sites and continuing traffic growth means they have to cope with massive amounts of capacity in the backhaul network. Capacity requirements are set to increase further with the deployment of HSPA+ and LTE technologies; initial deployments of LTE, a purely packet based technology, is likely to increase cell site traffic by 30–40 Mbit/s. With packet-based traffic likely to become dominant in the years to come, CAPEX considerations for transport systems are becoming critical. Continuing down the traditional route of building backhaul solutions based on an NxE1 TDM model is too costly. As the graph shows, there is a direct link between traffic growth and transport costs in the TDM model. If revenue grew in step with traffic, this might not be a problem. However, in a data-dominant world, where flat-rate charges are the norm, then Average Revenue Per User (ARPU) will not increase in line with traffic growth. It is imperative that operators deploy new transport technologies in order to reduce the cost per bit and break the linear relationship between traffic growth and transport costs. Ethernet is a technology that can bend the cost curve downwards. Ethernet connectivity is near enough ubiquitous; port costs are relatively cheap; it is well known and understood, and is the main connection of choice for most customers; it is naturally suited to carry packet-based technologies, and the physical interface scales well in terms of capacity. Implementing carrier Ethernet services will mean added investment now, but the incremental costs to meet future capacity demands will be relatively small. Installing a 100 Mbit/s interface at a cell site now is likely to meet demands for years to come, assuming appropriate access to the site such as fibre or Ethernet microwave radio.

TY2702/v3.1

© Wray Castle Limited

3.3

Next Generation Transmission Ethernet/GigE versus other approaches ease of use – plug and play low cost/port scalability at the physical layer inherently broadcast widely deployed combines data link layer and switching layer Disadvantages of LAN Ethernet/GigE best effort – no end-to-end QoS lack of OAM - no standardized service points to check for service health - Performance monitoring, if any, is far less than provided in optical systems lack of resilience - not designed as for 5 or 6 nines reliabilty - failure recovery in seconds, not 50 ms non-deterministic scalability issues - MAC address learning - Spanning Tree Protocol - designed for 100s or 1000s, not millions timing/synchronization security – unknown traffic flooded to all ports

Advantages and Disadvantages of Traditional Ethernet/GE The advantages of using traditional Ethernet and GigE characteristics can be summarized as being best effort, ease of use, low cost/port, bandwidth availability and equipment availability. Additionally, Ethernet is inherently a broadcast mechanism, which in some cases is an advantage, although it can also unnecessarily consume network resources. The disadvantages of traditional Ethernet/GigE in carrier-grade transport networks are that it lacks management functionality and resilience, and there is no inherent synchronization information. There are also scaling issues arising from the use of the Spanning Tree Protocol and MAC address learning. Maintaining synchronization between sites across a packet-based network is not a trivial matter. For example, if a mobile operator chooses to backhaul radio site traffic using a packet-based service, maintaining frequency synchronisation becomes important to maintain the accuracy targets set in the appropriate standards documents. There are two solutions currently under development: Synchronous Ethernet (ITU-T G.8261) and IEEE 1588v2.

3.4

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems MEF-Carrier Ethernet – Service Providers A set of certified network elements that connect to transport Carrier Ethernet services for all users, locally and worldwide

MEF Carrier Ethernet for Business Users Five Attributes

E-Line: point-to-point E-LAN: multipoint-to-multipoint E-Tree: rooted multipoint Standardized Services Traffic and QoS descriptors enabling SLAs matching the needs of voice, video and data.

Quality of Service

Service Management

Scalability

Scalable granular bandwidth 1–10 Gbit/s and beyond. Millions of users.

Reliability

OAM with the ability to monitor, diagnose and centrally manage Ethernet services.

Detect and recover from incidents in as little as 50 ms.

Carrier Ethernet services are carried over physical Ethernet networks and other legacy transport technologies

Metro Ethernet Forum (MEF) Carrier Ethernet Defined The MEF has defined Carrier Ethernet for business users as ‘A ubiquitous, standardized, carrier class Service and Network defined by five attributes that distinguish it from familiar LAN based Ethernet’. The five attributes are: standardized services, scalability, service manageability, quality of service and reliability. For service providers MEF has defined a set of certified network elements that connect to transport Carrier Ethernet services for all users; locally and worldwide Carrier Ethernet services are carried over physical Ethernet networks and other legacy transport technologies. The E-Line, E-LAN and E-Tree are well defined, globally recognizable, services provided via MEF certified equipment and require no change to the customer LAN or existing connectivity. Ethernet has traditionally been known as a best-effort technology, but in a carrier-class environment reliability is a key component. Today’s Carrier Ethernet should be capable of detecting and recovering rapidly from network faults; the recovery time should be as low as 50 ms to meet the most demanding quality and availability needs for critical business applications. Scalabilty is another important attribute for carrier networks. Traditional Ethernet uses MAC addresses to transfer data between devices, and this works well at the LAN level. However, address space is limited, and in the WAN space such addresses would be used up very quickly. Carrier Ethernet transport networks based on Ethernet technology use a variety of techniques to expand address space including tag stacking and MAC-in-MAC encapsulation. Additionally, Ethernet provides scalable, granular bandwidth from 1to 10 Gbit/s and beyond at the physical layer. The MEF defines a range of QoS options that set exacting standards for traffic characteristics such as CIR, frame loss, delay and delay variation, leading to Service Level Agreements (SLAs) that match the needs of voice, video and data over converged business and residential networks. Service management defines carrier class OAM capability with the ability to monitor, diagnose, test and centrally manage Ethernet services including rapid service provisioning. MEF service and terminology definitions have provided a common language for the industry so that customers and service providers can communicate effectively. The MEF have also defined standards for mobile backhaul (MEF 22) and Circuit Emulation Services (MEF 8). TY2702/v3.1

© Wray Castle Limited

3.5

Next Generation Transmission EVC attributes include EVC Type (Point-to-Point or Multipoint-to-Multipoint), UNI list CoS identification EVC related Performance - delay, delay variation, frame loss, availabilty

Ethernet Virtual Circuit: end-to-end service instance supporting E-Line or E-LAN services (SP responsibility)

Subscriber Site

OVC

OVC

Operator 1 Domain Carrier Ethernet network

Operator 2 Domain Carrier Ethernet network

MEN

CE UNI

ETH UNI-C

Subscriber Site

MEN

I-NNI

E-NNI

ETH UNI-N

ETH E-NNI

CE

I-NNI

ETH E-NNI

UNI

ETH UNI-N

ETH UNI-C

Ethernet Services Layer Terminology

UNI attributes include: UNI Identifier, Physical Layer (speed, mode, and physical medium), Service Multiplexing

E-NNI Interface Details 802.3 PHY, 1GE or 10GE Protection – Link Aggregation Support frame that are: untagged, single S-tagged, single S-tagged plus single C-tagged MTU size: at least 1526,octets , recommended 2000 octets

Metro Ethernet Network

MEF Terminology for Ethernet Services The terms MEN and Carrier Ethernet Network (CEN) are used interchangeably to describe Provider or Operator owned networks that provide connectivity services to customers. The MEF specifies the services provided by the MEN, interfaces to the MEN and the attributes that characterize these services and interfaces. The MEF does not specify the technology used in the MEN to implement services. If the MEN is implemented using 802.1 technologies then the MEN will be a Provider Bridge (PB) or Provider Backbone Bridge (PBB) network. In the MEF model a Service Provider (SP) is responsible for the end-to-end service offered to the customer. The SP may contract one or more operators , each responsible for a MEN, to implement the service. The SP may or may not be the same business as one of the operators. The User-to-Network Interface (UNI) is defined in MEF 11 as the physical interface/demarcation point between the service provider and subscriber. The interface is described in terms of the functionality supported at the customer side, UNI-C, and the service provider’s side, UNI-N, of the UNI. The UNI must support at least one of the 802.3 PHY interfaces in full duplex mode using either fibre or twisted pair at rates ranging from 10 Mbit/s to 10 Gbit/s. An EVC is defined as an association between two or more UNIs and is an end-to-end service instance. Customer frames received over a UNI are mapped to an EVC and may be delivered to any or all other UNIs mapped to the same EVC. The EVC is used to implement transparent private-line services including point-topoint and multipoint-to-multipoint LAN services. There are three types of EVC: E-Line, E-LAN and E-Tree. Two sets of attributes may be used to describe the EVC as shown in the diagram. One set of attributes describe the characteristics of the EVC at a UNI, the other set describe the characteristics of the EVC within the MEN. The UNI service multiplexing parameter identifies whether multiple EVC services may be supported at a particular UNI. For example the UNI may carry service frames belonging to different VLANs and it may be required to map different VLANs to different EVCs. The EVC UNI list for an EVC is a list of UNI pairs. The list must have exactly one such pair for each UNI in the EVC. In a carrier Ethernet network, data is transported across the EVC according to the attributes of the E-line or E-LAN service. The Network Node Interface (NNI) is a demarcation or peering point between different operator MENs, E-NNI, or between a service provider’s internal networks, I-NNI. The E-NNI includes definition of the following: support of at least one 1GE or 10GE 802.3 Physical Interface (PHY), Protection using Link Aggregation, support of untagged framed, single S-tagged frames, single S-tagged followed by single C-tagged frame, MTU size of at least 1526 octets (but 2000 octets is recommend). The E-NNI specification also includes the definition of an Operator Virtual Connection (OVC) which is similar in concept to an EVC. An OVC is an association of UNIs which constrains the exchange of frames between the external interfaces of a single operator MEN, i.e. frames sent on a particular OVC may transferred from UNI to E-NNI, E-NNI to UNI, UNI to UNI, E-NNI to E-NNI where each UNI or E-NNI are on the same MEN domain. If an EVC exists within one MEN domain then there is a one -to-one mapping between an EVC and OVC. Further Reading: MEF 6.1 Service definitions: MEF 10 Service Attributes, MEF 11 – UNI, MEF 26 E-NNI.

3.6

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems Head Quarters

Ethernet Private Line (EPL) Replaces a TDM private line Port-based service with single service (EVC) across dedicated UNIs providing site-to-site connectivity Typically delivered over SDH (Ethernet over SDH) Most popular Ethernet service due to its simplicity

CE

UNI

Remote Site

Metro Ethernet Network CE UNI UNI

Point-to-Point EVCs

UNI

ISP POP

Internet

CE

E-Line Services – Ethernet Private Line The E-Line service provides a point-to-point connection between customer sites using an Ethernet service interface. This is similar to a point-to-point PVC service based on FR or ATM. The service delivers Ethernet frames across the VLAN connection between the source and destination MAC addresses of the CE devices, without overwriting or changing the MAC addresses. An Ethernet Private Line (EPL) is essentially a port-based service that could be used to replace a traditional TDM Private Wire/Line. The EPL uses a port-based service where traffic from a single port is mapped to a point-to-point EVC providing site-to-site connectivity between a single pair of UNIs.

TY2702/v3.1

© Wray Castle Limited

3.7

Next Generation Transmission

CE

Remote Site 1 (Spoke)

Service Multiplexing SP’s Edge

Head Quarters (Hub)

UNI

CE

UNI

Metro Ethernet Network

Point-to-Point EVCs

UNI

CE

Remote Site 2 (Spoke)

Ethernet Line Services – Ethernet Virtual Private Line (EVPL) The EVPL service employs service multiplexing at the SP’s Edge device to enable multiple services (EVCs) to be delivered over a single physical connection (UNI) to a customer premises. In the example above, a single physical UNI carries multiple service flows, e.g. traffic belonging to multiple VLANs, where each service flow is mapped to a different EVC. The EVCs may terminate at different end points on the Carrier Ethernet Network. The EVPL may be used to replace Frame Relay or ATM L2 VPN services to deliver higher bandwidth, end-to-end services, and it supports ‘hub and spoke’ connectivity via the Service Multiplexed UNI at the hub site. This is similar to Frame Relay or Private Line hub-and-spoke arrangements.

3.8

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

1. EP-LAN – Port based service: all traffic on UNI is mapped to a single EVC - or 2. EVP-LAN – Service multiplexing: different service flows mapped to different EVCs CE

Remote Site 1 (Spoke)

Headquarters (Hub) UNI

CE

UNI

Metro Ethernet Network

Multipoint-to-Multipoint EVCs

UNI CE

Remote Site 2 (Spoke)

Ethernet Private LAN (EP-LAN) Service The EP-LAN service supports dedicated UNIs to provide transparent multipoint-to-multipoint connectivity between a customer’s CE equipment within a particular LAN. In functional terms, the Carrier Ethernet Network (CEN) appears as a dedicated multiport learning bridge to the customer. Broadcast and multicast frames should be handled by the service in the same way as a multiport bridge would handle them. In this case the EP-LAN service is implemented as a port-based service where all traffic flows are mapped to the same EVC providing the EP-LAN service. Alternatively, service multiplexing at the service provider’s edge device enables different service flows on a common UNI to be mapped to different EVCs. In this case the service is referred to as an Ethernet Virtual Private LAN (EVP-LAN) service. .

TY2702/v3.1

© Wray Castle Limited

3.9

Next Generation Transmission

Communications Directions Root to Leaf

CE

Remote Site 1

CE

Remote Site 2

Leaf to Root Headquarters (Hub) Metro Ethernet Network

CE

UNI

Root

Leaf

UNI

Leaf UNI Leaf

Rooted-Multipoint EVC

UNI CE

Remote Site 3

E-Tree The E-tree service is aimed at applications requiring point-to-multipoint services including video on demand, IPTV and mobile backhaul from cell sites. E-tree is implemented as a rooted multipoint EVC where a Root UNI can transmit to any leaf and any leaf can transmit to any root, but a leaf is not allowed to transmit to another leaf. At the configuration stage a UNI must be declared as a root type or leaf type. The root provides a well-defined source address, which would be useful in multicast services such as business multicast and IPTV. These services are usually deployed asymmetrically. It is envisioned that there will be less provisioning for point-to-multipoint services using an E-tree implementation as opposed to multiple EVPLs in a large hub-and-spoke environment. Service multiplexing may be employed at the UNI to provide an Ethernet Virtual Private Tree (EVP-Tree) service (not shown here).

3.10

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Port-Based

VLAN-Based

(All-to-One Bundling)

(Service Multiplexed)

E-Line

Ethernet Private Line

Ethernet Virtual Private Line

(Point-to-Point EVC)

(EPL)

(EVPL)

Ethernet Private LAN

Ethernet Virtual Private LAN

(EP-LAN)

(EVP-LAN)

E-Tree

Ethernet Private Tree

Ethernet Virtual Private Tree

(rooted multipoint EVC)

(EP-Tree)

(EVP-Tree)

Service Type

E-LAN (multipoint-to-multipoint EVC)

MEF Services are classified into two categories: Port-based-Single Service Instance per UNI (dedicated network resource) VLAN-based-Multiple Service Instances per UNI (shared network resource)

MEF Service Definition Summary The table above summarizes the MEF services definitions.

TY2702/v3.1

© Wray Castle Limited

3.11

Next Generation Transmission Application Services Layer

Applications carried on the basic Ethernet services across the MEN

APP Layer

(e.g. IP, MPLS, PDH, etc

Ethernet Services Layer

Ethernet connection services between UNIs, ETH OAM

ETH Layer (MEF Focus)

(Ethernet Service PDU)

Metro Ethernet Network

TRAN Layer

Transport Services Layer CE

CE UNI

UNI

TRAN Layer candidates include: ATM VP/VC

SONET/SDH Fibre

802.1 Bridged Network Family (PBB-TE) OTN Copper

MPLS-TP

PDH

802.3 PHY

Coax

Wireless

MEF Metro Ethernet Network Model The MEN layer network model defines the MEN in terms of three layer network components: the Application Services Layer (optional), the Ethernet Services Layer (ETH Layer) and the Transport Services Layer (TRAN). The Ethernet Services Layer supports basic Layer 2 Ethernet data communication services and is responsible for Ethernet connectivity services and the delivery of Ethernet service frames across MEN interfaces, UNI and NNI. The ETH layer is also responsible for ETH operations, administration and maintenance. The service frame presented by the ETH layer external interfaces is an Ethernet unicast, multicast or broadcast frame conforming to the IEEE 802.3-2002 frame format. The Transport Layer is a set of one or more supporting Transport Services Layer(s). The TRAN layer supports connectivity among ETH layer functional elements in a service independent manner. Various technologies may be used to support the transport requirements for the Ethernet services including those identified in the diagram above. This allows Carrier Ethernet traffic to be agnostic to the transport services it traverses. The optional Application Services Layer supports applications carried on the basic L2 Ethernet services the MEN. Various application services may be supported over the basic Ethernet services; a sample of which are identified above.

Further Reading: MEF 4

3.12

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Carrier Ethernet 802.1D Bridging

Foundations

802.1Q VLAN Tagging and priority field – 4096 VLAN Ids 802.1P

Scaling Further scaling Quality Predictability Ethernet in the First Mile (EFM)

Details use of the priority field for CoS/QoS

802.1ad also called Q-in-Q VLAN Tag Stacking 802.1ah PBB also called MAC-in-MAC 802.1ag Y.1731, MEF–OAM/Performance 802.1Qay PBB-TE – connection-oriented Ethernet 802.3ah Point-to-point link monitoring

The 802.1 Standards for Bridged Networks The table above identifies the specifications that have enabled the evolution of Ethernet to a call class transport technology. The 802.1D/Q/P standards are the foundations and are commonly found in LAN deployments. The 802.1Q standard introduced the concept of VLAN tagging to create multiple logical or virtual LANs into Ethernet switched architectures up to a limit of 4096 VLANs. The 802.1ad standards adds another layer of 802.1Q to expand the VLAN space by tagging tagged frames, i.e. it introduces tag stacking. The expanded address space allows the service provider to provide specific services on specific VLANs, e.g. Internet access on one VLAN, voice services on another. Provider Backbone Bridging (PBB), 802.1ah, provides a highly scalable technology using MAC-in-MAC encapsulation. However, it lacks carrier-grade protection and traffic engineering functions, it is not a deterministic model. PBB with Traffic Engineering (PBB-TE) provides a connection-oriented, deterministic operation Ethernet service by introducing traffic engineering capabilities. OAM and functions are provided at Ethernet layer 2 with 802.1ag, Connectivity Fault Management (CFM) for Ethernet services, and Y.1731. CFM provides basic Ethernet service testing functions such as continuity, loopback and trace functions. While Y1731 includes performance monitoring and alarm signals in addition to CFM. 802.3ah is also called Ethernet in the First Mile (EFM) and provides a point-to-point link monitoring function between two adjacent devices.

TY2702/v3.1

© Wray Castle Limited

3.13

Next Generation Transmission BW Profile Token Bucket Algorithm – Coupled* yellow rate bounded by CIR+EIR burst size bounded by EBS

Bandwidth Profile Compliance Colours Green Tokens - CIR Traffic > EIR

CBS

None

C-Bucket Overflow Green Tokens

EIR Traffic > CIR Mark DEI

Yellow Tokens - EIR

CIR Traffic

CIR

Guaranteed

EBS

Discard

E-Bucket

If service frame length is less than C-Bucket tokens - declare green and remove tokens from C-Bucket else if service frame is less than E-Bucket tokens - declare yellow and remove tokens from E-Bucket else - declare red

Best Effort: deliver to egress UNI SLA performance objectives do not apply Assured: deliver to egress UNI SLA performance objectives do apply

CIR/EIR long term average rates CBS and EBS short term burst rates within the CIR/EIR limits

* BW Profile Token Bucket Algorithm - decoupled yellow rate bounded by EIR only no green overflow tokens burst size bounded by EBS

Service Profiles Ethernet services, EVCs, are described by attributes and profiles that can be used to implement and police SLAs. Many attributes are conventional Ethernet attributes, such as physical port speed, addressing, etc. In addition to this the MEF define a number of Bandwidth Profile (BWP) parameters, discussed below, to allow the equivalents of the FR service descriptors to be applied and for traffic policing to take place at the service provider’s side of the UNI for a given service flow. Committed Information Rate (CIR) is the long-term average rate in bits/s up to which service frames, i.e. Ethernet frames transmitted on the UNI, are delivered across the UNI and then the network. Frames within the CIR are fully compliant ‘green’ frames and are delivered at the performance objectives determined by CoS markings, i.e. CIR defines the assured bandwidth. Committed Burst Size (CBS), expressed in bytes, limits the maximum number of bytes available for a burst of Service Frames sent at the UNI speed to remain CIR-conformant. Higher burst sizes improve performance. The Excess Information Rate (EIR) is the long-term average rate in bits/s up to which the network may deliver Service Frames but without any performance objectives. Service frames transmitted as ‘excess frames’ are partially compliant ‘yellow’ frames and marked as eligible for discard in congestion conditions. EIR provides additional throughput, network conditions permitting. Excess Burst Size (EBS), expressed in bytes, limits the maximum number of bytes available for a burst of Service Frames sent at the UNI speed to remain EIR-conformant. Higher burst sizes improve performance. CBS and EBS are often considered to be parameters defining a bucket size in bytes. Tokens representing bytes are dripped into the buckets at the CIR/EIR rate respectively. The size of any frame arriving at the UNI is initially compared to the amount of tokens in the CBS bucket. If there are enough tokens then the service frame is compliant with CIR, declared green and transmitted; if not the frame is not compliant with CIR, in which case it is marked yellow and compared with the amount of tokens in EBS bucket. If there are sufficient tokens in the EBS bucket the frames are EIR-compliant, declared yellow, and transmitted as best-effort frames, eligible for discard. If they are not compliant they are declared red and discarded. The long-term yellow rate may be bounded just by EIR, decoupled from CIR, or bounded by CIR and EIR, coupled. In the latter case tokens may overflow from the CBS bucket into the EBS bucket. EBS limits the burst size in either case. 3.14

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems 1. BW Profile per UNI CIR=10 Mbit/s

2. BW Profile per EVC

EVC1

Service Frames

Service Frames

UNI

UNI EVC2

EVC2

Service multiplexing: Multiple services per EVC

UNI

EVC1

CIR= 6 Mbit/s

CIR= 4 Mbit/s

Service multiplexing: Multiple EVCs per port

3. BW Profile per CoS Instance

Service Frames

EVC1

Ingress BW Profile per CoS Identifier

CE-VLAN 1 PCP 0,1,2,3, untagged

3 Mbit/s CIR CoS Id 1 – Gold

CE-VLAN 1 PCP 4,5

4 Mbit/s CIR CoS Id 2 – Silver

CE-VLAN 1 PCP 6,7

1 Mbit/s CIR CoS Id 3 – Bronze

EVC2

2 Mbit/s for Internet Access

Determining the CoS Id: 1. All service frame mapped to an EVC have the same CoS Id 2. CoS Id is determined from PCP 3. CoS Id is determined from DSCP 4. CoS Id is determined from VLAN Id

EVC Bandwidth Profiles (BWP) A BWP is a method of characterizing service frames with respect to their length and arrival time, for the purpose of rate enforcement or policing and may be considered as equivalent to traffic policing in Frame Relay. BWPs are associated with a single UNI of an EVC allowing each UNI to be configured independently with its own BWP. A BWP defines the set of traffic parameters applicable to a sequence of service frames, these include CIR, CBS, EIR, EBS. The BWP may be per UNI, per EVC or per Class of Service Identifier (CoS Id). In a per UNI model a single BWP is applied to all service frames regardless of the EVC they may be mapped to. In this case service frames will be handled non-discriminately by the BWP one EVC may get more bandwidth than the other. In the per EVC model a BWP may be applied to each EVC at the UNI. Service frames are mapped to either EVC1 or EVC2. The BPW for EVC1 polices the traffic flow of service frames mapped to EVC1, while the BWP for EVC2 polices the traffic flow for service frames mapped to EVC2. In the per CoS Id model a single BWP must be applied to all service frames with a specific CoS identifier. There are three ways to determine the CoS Identifier from the contents of a service frames on the UNI. Firstly all service frames mapped to the same EVC shall have the same CoS Id; secondly the CoS Id may determined from the priority code point (PCP) in a tagged frames, if the frame is untagged then PCP is assumed to be 0. The third mechanism uses the DiffServ Code Point in an incoming IP packet to determine the CoS Id. As an example consider EVC1 in case three above. The service provider offers three services classes, gold, silver and bronze. Service frames for CE-VLAN 1 are mapped to EVC1. Tagged service frames with a PCP=0, 1,2 or 3 or untagged frames are mapped to COS Id 1 and receive the gold service. Tagged frames with a PCP=4 or 5 are mapped to CoS Id 2 and receive the silver service while tagged frames with a PCP=6 or 7 are mapped to CoS Id 3 and receive the Bronze service. Multiple models may be supported at a UNI as long as only a single BWP is applied to a given ingress service frame. The CoS marking enable the network to determine the QoS to apply. CoS is usually defined by three performance parameters, frame delay, frame delay variation (jitter) and frame loss. Further Reading: MEF 10 sections 6 and 7 TY2702/v3.1

© Wray Castle Limited

3.15

Next Generation Transmission S-TAG: Gold/Silver/Bronze C-TAG: Customer Service Provider (S-TAG)

E-TYPE

D E I

SP CoS

Customer (C-TAG)

VI

TPI

P

C

VI

1 bit Service Provider's Ethernet Virtual Circuit (EVC) ID

Port Config

No. Classes of Service types

8P0D

8

7P1D

7

6P2D

6

5P3D

5

No. of applicable DEs

EType=88-a8 802.1ad S-TAG

0 1 in class 4 2 1 in class 4 1 in class 2 3 1 in class 4 1 in class 2 1 in class 0

IEEE 802.1ad Provider Bridge One of the issues facing the Ethernet community was the lack of address space either at the MAC level or with the introduction of IEEE 802.1q tags. With IEEE 802.1q Tags, provide the potential to differentiate up to 4096 VLANs. Service Providers (SP) wanting to offer connectivity over 802.1q networks between corporate sites faced address space issues arising from the fact that enterprises commonly use 802.1q tagging within their own networks. This often means that an enterprise customer presents the SP with an already dot1q tagged frame, thus eating into the available VLAN address space available to the SP. The concept of 802.1ad is simply to add another layer of tagging on top of the 802.1q tag. This expands the address space by tagging tagged frames. IEEE 802.1ad adds a second, outer Tag referred as the Service-provider’s Tag (S-Tag), identified using Ethernet Type (ETYPE) value 88-A8. The inner Customer Tag (C-Tag) is the IEEE 802.1q Tag seen before, i.e. TPI=81-00. In theory the double-tagged frame gives a theoretical address space of 16 million VLANs, not all to the SP because the C-Tag is often applied by the user as described above. The Tag format for the S-Tag is:    

ETYPE – 2 bytes set to 88-A8 Service Provider Class of Service – will conform to the IEEE 802.1p standards. Discard Eligibility Indicator (DEI) – will be used to provide an enhanced CoS function VLAN Identifier (VI) – 12 bits, which can describe 4096 service instances

The expanded VLAN space makes it possible for the service provider to switch VLAN traffic from a customer over their network using the S-Tag to discriminate the different customer flows, leaving the customer to manage the C-Tag portion. For example, Internet access may be provided on specific VLANs for specific customers, while another VLAN might be used for VoIP traffic.

3.16

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Customer Bridge

PEB

PEB

Customer Bridge

Provider Bridges

Normal Ethernet Frames

C-Tag

S-Tag

C-Tag

Normal Ethernet Frames

Provider Bridge Network A simple provider bridge network is depicted above. Here, the customers’ networks are using simple Ethernet frames, so can be thought of as using legacy Ethernet equipment. At the edge of the customer’s network is a customer bridge. This may be IEEE 802.1q aware, so would manage the first Tag or C-Tag. This is not important as the customer bridge may only support normal Ethernet frames; in this case the Provider Edge Bridge (PEB) would have to provide both a C-Tag and an S-Tag. The PEB will add an S-Tag to discriminate this customer traffic from other traffic carried by the service provider. For an E-LAN service the S-Tag defines the extent of the broadcast domain on the service provider’s network. Broadcast addresses and unknown unicast addresses will be flooded across the broadcast domain, as is the case with standard VLANs. Over time the Provider Bridges (PB) and PEBs learn customer MAC Addresses and will forward unicast frames in a targeted manner towards a destination MAC on the service provider’s VLAN. MAC address learning means that the customers’ MACs are exposed on the provider network. This is in contrast to IP VPNs where the layer 3 routing table information would be exposed and therefore is seen by security experts as more acceptable for MACs rather than for IP to be known. Another problem with this approach is the fact that the Tags are being added to the Ethernet frame structure, which has a maximum length as depicted by the Maximum Transmission Unit (MTU). This means that the information portion of the frame would have to reduce in size. This is exacerbated by the fact that the Ethernet community is working on IEEE 802.1ah, which will see MAC frames with S- and C-Tags encapsulated in other MAC frames, which again will be double tagged. The Ethernet community has therefore been working on enlarging the Ethernet frame size. Although this work is continuing, some manufacturers are already supporting increased frame sizes up to 9 Kilobytes or more. However, this may be proprietary.

TY2702/v3.1

© Wray Castle Limited

3.17

Next Generation Transmission Normal Ethernet Frames

C-Tag

S-Tag

PEB

Customer Bridge

VID=10 MAC learning and Flooding replaced by configuration

Normal Ethernet Frames

C-Tag

PEB

Cross Connect

Customer Bridge

VID=20

VID=20

VID=10 VID=20

VID=10

VID=20

Switching based on Port No. and VID (not MAC)

Ethernet Label Switching (ELS) The concept of ELS, aka Q-in-Q tunnelling mode, is to use the same 802.1ad Ethernet frame format but to forward based on the ingress port number VLAN-Id but not the MAC address. Tag stacking may still be used and there is potential for basing switching decisions on double tags as well as single tags. MAC learning and flooding are replaced with VLAN switch configuration, which is used to preconfigure a point-to-point Ethernet Virtual Connection across the network. Note that tags may be added, swapped or removed by the Ethernet ‘cross connect’ switch. Additionally, bridged connections can be made from a single port to multiple ports.

3.18

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Benefits

Limitations

Transparency of 4K C-VIDs

Only 4K services

Ability to determine CoS and discard eligibilty

Topology constrained by the number of connected devices. PEB and PB devices learn customer MAC addresses STP and RSTP

Native support of E-LAN services (S-VLAN determines the extent of the broadcast domain)

Customer MAC addresses exposed in the core

Scalability of Provider Bridge (PB) Networks PB networks may support up to 4096 separate service VLANs with a large number of customer VLANs traversing these. The PB networks have to run separate STPs for each VLAN as well as having to record all the MAC addresses of the PB switches as well as customer MAC addresses per VLAN. As such, the PB equipment needs to have significantly more processing and memory capability than the customer bridging equipment. PB networks cope well whilst the number of VLANs and aggregate MAC addresses are relatively low, but once these numbers start to grow significantly then the PB networks may start to exhibit problems. A solution to this would be to move to a traffic engineering solution.

TY2702/v3.1

© Wray Castle Limited

3.19

Next Generation Transmission

802.1D

802.1Q

802.1ad

802.1ah

Payload

Payload

Payload

Payload

SA

VLAN Tag

C-Tag

C-Tag

Inner VLAN ID

DA

SA

S-Tag

S-Tag

Outer VLAN ID

DA

SA

SA

DA

DA

Customer MAC E-Type I-PCP 88e7 (3) Same type of Tag as S-TAG

DEI (1)

Res (2)

Res (2)

I-SID (24)

E-Type B-PCP B-DEI 88a8 (3) (1)

B-VID (12)

I-Tag

Service Instance Tag

B-Tag

Backbone Provider Tag

B-SA Backbone MAC Address B-DA

S-Tag (Service VLAN Tag) E-Type SP-PCP B-DEI 88a8 (3) (1)

B-VID (12)

C-Tag (Customer VLAN Tag) E-Type 8100

PCP (3)

C (1)

VID (12)

B - Backbone DEI - Discard eligibility PCP - Priority Code Point VID - VLAN Id I-SID - Service Instance Id

Provider Backbone Bridging (PBB) Networks MAC-in-MAC provides a hierarchical structure to carrier Ethernet networks, whereby the service provider’s frames may be totally encapsulated in a backbone provider’s frame, hence the term ‘MAC-in-MAC’. The service provider’s frames may well be already double tagged as per IEEE802.1ad i.e. S- and C tagged. Where each S-tag provides a block of 4000 separate VLANs, these S-VLANs could be mapped to one of 16 million separate service instances using the 24-bit I-SID contained in the I-Tag. I-Tagged frames would be associated with one of 4096 possible backbone VLANs (B-VLANs). The B-VLAN is identified by a combination of Backbone-Destination MAC address (B-DA) and B-Tag’s B-VLAN ID (B-VID).

3.20

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems PBB:

PB

802.1ad

standard 802.1ad Bridge learns B-MAC addresses per B-VLAN does not learn customer MAC addresses

PB

PBEB 3

PBEB 1

802.1ad

PBB S-Tagged frames

S-Tagged frames 802.1ad

PB

PB

802.1ah Encapsulation Layer PBEB 2

PBEB 4

802.1ad

802.1ad

PBEB: maps S-Tag to I-Tag assigns I-Tag to BVLAN-Id BVLAN-Id defines extent of the broadcast domain learns B-MAC addresses per B-VLAN learns customer MAC addresses per B-VLAN per B MAC address

802.1ah Encapsulation layer unknown destination B-MAC unicast addresses and broadcast frames are flooded to all BVLAN endpoints known destination B-MAC address are tunnelled to the B-DA endpoint

PBB Basic Network Architecture PBB was introduced to address MAC Address and service scalability issues. PBB introduces extensions to native Ethernet technology. The number of 802.1ad Q-in-Q service instances per metro is limited to 4094 by the 12 bit S-VLAN tag. PBB, 802.1ah, solves the scaling issue by adding a hierarchical structure using MAC-in-MAC encapsulation and the ability to identify millions of service instances using a service instance tag, I-Tag. There are two types of bridges defined in the 802.1ah architecture: Provider Backbone Edge Bridge (PBEB) and PBB in the core. PBEBs contain the ‘intelligence’ to map S-tagged frames from a service provider’s PB to a service instance, identified by an I-Tag’s I-SID. The I-Tag is mapped to a Backbone VLAN (B-VLAN) and an associated B-VLAN tag. S to I to B-VLAN mapping is a configuration function. The B-VLAN defines the extent of the broadcast domain, actually a multicast domain, on the PBB network. Additionally, the PBEB adds the appropriate B-MAC source and destination address and encapsulates the service provider’s S-tagged frame. The PBEB learns backbone addresses per B-VLAN. Furthermore, a PBEB learns customer MAC addresses per S-Tag per B-DA per B-VLAN. An egress PBEB uses the I-SID as a filter to decide whether or not to forward frames to a service provider’s PB network. Should a PBEB device receive a frame where there is no mapping between the I-Tag and an STag, the frame is silently discarded. PBB devices in the core do not learn customer MAC addresses; they are only required to learn B-MAC addresses per B-VLAN. The diagram shows only one PBB, for simplicity. In practice, the core may contain many PBBs. PBBs forward frames based on the B-VLAN and B-DA. As the B-Tag is the same type of tag as an S-Tag and the B-DA is a standard MAC address, then the PBB need only be 802.1ad. The PBB floods unknown unicast B-DAs and broadcast B-MAC addresses across the B-VLAN identified by the B-Tag in the frame. By monitoring traffic passing through it a PBB learns the MAC addresses of PBEBs per B-VLAN.

TY2702/v3.1

© Wray Castle Limited

3.21

Next Generation Transmission SP1 PB2

P C S SA DA I-Tag B-Tag B-SA B-DA SP1 PB1

PBB

PBEB 1 S-Tag 1

802.1ad

B-MAC 1B-1B-15-1F-10-1F

P1

2C-2C-28-24-21-00

B-MAC 2B-2B-25-2F-20-2F

802.1ad

2C-2C-28-24-21-01

PBEB 2 S-Tag 1

P2 P3

802.1ad

C-MAC Address

PBEB 3

802.1ah

SP1 PB3

C-MAC Address 3C-3C-38-34-31-00

B-MAC 3B-3B-35-3F-30-3F

Provisioned S-Tag

I-Tag BVLAN

Learned

Learned

B-MAC Address

C-MAC Address

001

0001

0001

2B-2B-25-2F-20-2F

2C-2C-28-24-21-00

002

0002

0001

3B-3B-35-3F-30-3F

2C-2C-28-24-21-01

802.1ad

3C-3C-38-34-31-01

C-MAC Address 3C-3C-38-34-31-00 3C-3C-38-34-31-01

MAC Learning in PBB Networks The diagram above shows three PBEBs in a single B-VLAN within a PBB domain together with their BMAC addresses. The PBB network is used to provide a B-VLAN service to a Service Provider, SP1. SP1’s domain contains three provider bridges: PB1, PB2 and PB3. A number of C-MAC addresses are connected via PB1 and PB2. The PBB provider provisions service instances at each PBEB. In this example this is accomplished by mapping a particular S-tag to an I-Tag identifying the service instance and then by mapping the I-Tag to a B-VLAN that connects the appropriate service Provider Bridges (PB). As traffic is encapsulated and passed through the B-VLAN, PBEB devices learn customer MAC addresses per S-Tag, per B-VLAN per B-MAC address as illustrated. PBB devices simply learn on a per B-VLAN basis which port a particular PBEB is available on; for example, PBB learns that PBEB 3, whose B-MAC address is 3B-3B-35-3F-30-3F, is available via P3.

3.22

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems SP1 PB2

S-Tag 1

PBEB 2

802.1ad

I-SID1 SP1

SP1 PB1 802.1ad

PBEB 3

PBEB 1 S-Tag 1

S-Tag 1

S-Tag 2

S-Tag 2

PB3 802.1ad

I-SID2

B-DA B-SA B-Tag I-Tag Note: When I-SID2 frames are broadcast towards PBEB 2 they will be filtered and not sent on to the SP bridge as ISID2 has no mapping at this interface

I-SID 1 Port

BVLAN 1

S-Tag 1

Tunnel I-SID 2

S-Tag 2

DA SA S-Tag C-Tag P

Multiplexing Service Instances through a B-VLAN In this example an SP presents service frames to the PBB provider tagged as either S-Tag 1 or S-Tag 2. These are mapped to service instances I-SID 1 and 2 respectively, both are mapped to B-VLAN 1. Service instance one is configured at PBEB 1, 2 and 3, while service instance two is only configured at PBEB 1 and 2. Although this example shows the value of the S-Tag being preserved across the network this is not necessary if a single S-Tag is mapped to a particular service instance, for example for service instance two, S-Tag 2 arriving at PBEB 1 may be mapped to S-Tag 3 at PBEB 3. Prior to C-MAC and B-MAC learning it is possible that unknown unicast addresses sent on the B-VLAN for service instance 2 arrive at PBEB 2. PBEB 2 will not forward these to PB2 as I-SID2 has no mapping to a service at this edge. Note that it is possible to map multiple S-Tags to the same service instance using a port-based service, i.e. all service frames are mapped to the same service instance, where an S-Tagged bundled service is requested. In both these cases it is important to preserve S-Tags end-to-end. The ‘tunnel’ illustration provides a conceptual view of PBB operation. The B-VLAN tag determines the extent of a multicast domain PBB network; the B-DA identifies a tunnel endpoint on the B-VLAN and the I-SID identifies particular service instance.

TY2702/v3.1

© Wray Castle Limited

3.23

Next Generation Transmission SP1 PB2 S-Tag 1

802.1ad SP1

SP1

PBEB 2

PB1

PB3 I-SID1

802.1ad S-Tag 1

802.1ad

PBEB 1

S-Tag 1

SP2 PB1

S-Tag 1

PBEB 3

S-Tag 1

SP2 PB2

I-SID2 802.1ad

802.1ad

Note: When I-SID2 frames are broadcast towards PBEB 2 they will be filtered and not sent on to the SP bridge as I-SID2 has no mapping at this interface

More on Service Multiplexing in a PBB Network This example illustrates how different SPs may have their traffic tunnelled through the same B-VLAN. Here SP1 and SP2 present service frames tagged with the same S-Tag value. They are mapped to different I-SIDs but to the same B-VLAN. Since PBB devices are not I-SID aware then any unknown unicast frames sent from any of the SPs, regardless of the service instance they are mapped to, are sent to all endpoints on the B-VLAN. In which case SP2’s traffic may be presented to PBEB 2, PBEB 2 filters traffic based on the I-SID 2 and finds no mapping for this service and silently discards the frame. PBEB 3 uses the I-SID to discriminate between traffic meant for SP1 and SP2.

3.24

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Provider Backbone Bridge (IEEE 802.1ah) P CSA

CDA C S I B BSA BDA

PBEB

PBB

PBB

PBEB

B-SA

B-DA 3

Site A Customer LAN

Site D Customer LAN

6 P CDA

1

POP C

POP B

CSA C S

P CDA

CSA C S

7

2

CSA

PEB PB PEB Provider Bridge (IEEE 802.1ad)

2 1 P CDA

5

4

PEB

S-Tag

CDA

PB PEB Provider Bridge (IEEE 802.1ad)

6

S-VLAN CSA C

8

S-Tag

7

8

S-VLAN P CDA

3 B-SA

4

B-Tag/I-Tag B-VLAN

CSA C

5 B-DA

Simple Provider Bridged Networks The diagram illustrates a simple PBB network where the Customer LAN is situated at two remote locations, A and D. The local service provider perhaps provides a metro Ethernet solution using PB network IEEE 802.1ad technology. The service provider has two regional POPs at B and C. The interconnect between B and C is provided by a PBB Network using IEEE802.1ah technology. The S-VLANs are controlled by the Service Provider, at B and C these frames are encapsulated by the PBB network provider edge equipment. The S- and C- tags together with the customer MAC addresses are used to help with correctly switching the customer's frames between their LANs. At 3 the S-VLAN service frame is mapped to one of 16 million I-SID values. The PBEB at 3 will also add the B-VLAN information: the B-Tag containing the BVID, the destination B-MAC address of the PBEB at 5 and its own source B-MAC address. The PBB devices forward the MAC-in-MAC frame based on the B-VID and B-DA to specific ports, assuming that they have learned the B-DA address, toward the egress PBEB. The egress PBEB at 5 processes the frame identifies the I-SID and recovers the S-Tagged service frame and forwards to the Service Provider’s network at POP C. The Service Provider delivers the frame on the S-VLAN path towards the customer site. The PBB devices tunnel service frames through the PBB network, i.e. they are transparent to encapsulated PB frames and do not learn customer MAC addresses.

TY2702/v3.1

© Wray Castle Limited

3.25

Next Generation Transmission PBB-Layer 2 802.1ah MAC-in-MAC-in-MAC P CSA

CDA C S I B BSA BDA I2 B2 BSA BDA

BVLAN 2

PBB-Layer 1

802.1ah MAC-inMAC (B-VLAN 1)

B-VLAN 1

P CSA

B-VLAN 1

CDA C S I B BSA BDA

End-to-End I-Tag

Provider Bridge Layer

S-VLAN

S-VLAN P CDA

CSA C S

End-to-End S-Tag P CDA

CSA

P

CSA

CSA C

CDA

CE

P

CE

CSA

CDA

CDA 802.1Q

802.1Q

Hierarchical PBB Networks Supporting B-VLANs with a large number of bridges is challenging as multicast frames delivered to large number endpoints restrict performance. For this reason 802.1ah supports the deployment of hierarchical networks. The hierarchical approach reduces the size of individual multicast domains by reducing the number of bridges in each domain. This in turn reduces the number of multipoint tunnels and the number of frame replications required. The diagram above illustrates how a hierarchical 802.1ah network may be implemented. PBEB edge devices at PBB layer two map the service frame from PBB layer 1 to a layer 2 service instance and B-VLAN, B-VLAN 2 in this example. The PBB layer 1 frame is totally encapsulated in a layer 2 frame, MAC-in-MAC-in-MAC, and tunnelled through the layer 2 network. An egress PBEB node at layer two identifies the service instance and forwards the service frame back to the PBB layer 1 network. In some peer-to-peer relationships, rather than use complete MAC-in-MAC-in-MAC encapsulation, an 802.1ah peer network receiving an 802.1ah frame removes the B-MAC headers, swaps the B-VID label based on the I-SID of the incoming frame, and adds its own B-MAC addresses. The I-SID is the same throughout peer networks. A hierarchical PBB network can have as many layers as required.

3.26

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Benefits

Limitations

Highly scalable architecture

Customer MAC address learning required on PBEB switches

Supports 802.1ag OAM

Complex to optimize when using multiple spanning trees

Clear separation between customer and service provider networks, transparent transport of S-VLANs

Restoration/convergence/ time following faults is limited to seconds by RSTP and MSTP, whereas requirements for carrier transport network recovery is 50 ms.

Customer MAC addresses tunnelled on the PBB network increasing security and scalability

Lack of effective traffic engineering, this a flat switching hierarchy based on flooding if the destination MAC is unknown

PBB switches only need to learn B-MAC addresses

Still non-deterministic.

Benefits and Limitations of PBB Networks The table above summarizes the main benefits and limitations of PBB networking.

TY2702/v3.1

© Wray Castle Limited

3.27

Next Generation Transmission Service and Network Management Provisioning system

C

B

Customer A

Customer B

PBEB

Provider Bridge Network

A

D

Provider Bridge Network

F

E

Provider Backbone Bridge B-VID=4000 B-DA =d

B

B-VID=4000 B-DA =d

C

B-VID=4000 B-DA =d

D

A MAC=a B-VID=4000 MAC=b B-DA =a B-VID=4001 B-DA =d

E

MAC=c

MAC=d

F D

A MAC=a B-VID=4001 MAC=e B-DA =a

Primary Tunnel

MAC=f

Back-up Tunnel

PBB-TE connection oriented traffic engineered tunnels - point-to-point - reserved bandwidth - hard QoS 50ms restoration time uses 802.1ag and Y.1731 for management and recovery

MAC=d

Provider Backbone Bridging Traffic Engineering (PBB-TE) PBB-TE, which is also further abbreviated to PBT, has been developed in accordance with IEEE802.1Qay specifically to address the major problems of carrier Ethernet such as scalability and reliability. PBB-TE may be run in isolation or in parallel with PBB. PBB-TE removes the need for core devices to engage in MAC address learning and flooding and does not use any variant of STP as with PBB. PBB-TE replaces these with connection-oriented, trafficengineered point-to-point tunnels. Tunnels have reserved bandwidth and a specified QoS, which are used to transport client S-VLANs frames with deterministic performance and hard QoS across the PBBTE network. The PBT tunnels require a sophisticated provisioning platform to be utilized which can engage with the network equipment. IEEE802.1Qay utilizes the IEEE802.1ah frame structure, where the B-DA MAC address and B-Tag BVID are used as the Tunnel Identifiers. The PBEBs seen in the diagram at A and D map the Provider Bridge frames onto an I-Tag I-SID and then adds the PBEB Destination MAC Address (B-DA) and B-VLAN ID ( B-VID). MAC learning, flooding and spanning tree processes are turned off across the PBB –TE network. Instead, the PBB devices are configured with forwarding tables where each B-DA/B-VID couple received on a given ingress port identifies a unique PBB-TE circuit and tunnel, and a specific egress forwarding port. PBB-TE also provides for provisioning of backup tunnels. The same I-Tag would be used for both the primary and backup tunnels, with a different B-VID used to discriminate between the two tunnels. Switching time targets between the tunnels is specified as 50 ms. IEEE 802.1ag Connection Fault Management (CFM) and ITU-T Y.1731 Performance Management (PM) are used to provide management and recovery for the PBB-TE tunnel Connection-oriented operation, rapid recovery times, and deterministic performance and QoS makes PBB-TE a good candidate for carrier Ethernet transport.

3.28

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems IP/MPLS

NMS

Control Plane

Control Plane embedded in LSRs signalling protocols e.g. • RSVP-TE • OSPF-TE unidirectional LSPs

Data Plane Forwarding based on MPLS shim header(s)

MPLS-TP

Control Plane implemented in NMS automatic or manual path configuration support bidirectional LSP set up over the same path

NMS Control Plane

Data Plane

Forwarding based on MPLS shim header(s)

Transport Attributes: - Connection Oriented, Reliability, QoS, E2E OAM, protection switching

Transport Profile (MPLS-TP) Acknowledging the increasing importance of packet transport MPLS-TP is a joint effort between the ITUT and the IETF to define a profile of MPLS that adapts it to support the capabilities of a packet transport network that includes transport characteristics such as connection-oriented operation, reliability, simplicity, protection switching, deterministic behaviour and OAM at a price point that makes it suitable for deployment in metro networks as well as core networks. MPLS-TP removes the need for a complex and expensive IP control plane to be embedded in the MPLS LSRs. This is expected to lead to equipment implementations that support carrier requirements but at a lower cost. In the standard MPLS model LSPs are established uni directionally via complex signalling procedures, using protocols such as OSPF-TE and RSVP-TE, together with path computation. The signalling and path computation procedures are carried out in the control plane elements of the LSRs. The LSRs also act as forwarding elements in the data plane. Bidirectional connectivity requires two paths to be established between edge LSRs which may or may not follow the same path through the network. In the MPLS-TP model, control plane complexity is shifted from the LSRs to a NMS. The NMS is used to preconfigure traffic engineered end-to-end paths through the MPLS nodes in the network. These nodes operate as forwarding devices in the data plane but do not take part in control plane functions. MPLS-TP allows for bidirectional point-to-point LSPs to be set up such that both directions follow the same path through the network. Provisioning via the NMS may be automated or manual.

TY2702/v3.1

© Wray Castle Limited

3.29

Next Generation Transmission

Service and Network Management Provisioning system

MPLS-TP Domain NE1

NE2

NE3

NE4

NE5

Ethernet

Ethernet

S-Tag

Tunnel 1

S-Tag

Tunnel 2

C-Tag P

Tunnel and PW Labels: • pushed on ingress • popped on egress

C-Tag TL1.1

TL1.2

TL2.1

TL2.2

PW1.1

PW1.1

PW1.2

PW1.2

S-Tag

S-Tag

S-Tag

S-Tag

C-Tag

C-Tag

C-Tag

C-Tag

P

P

P

P

Tunnel 1 label swap

Tunnel 1 and PW 1 Label swap

P

Tunnel and PW Labels: • pushed on ingress • popped on egress

Tunnel 2 label swap

MPLS-TP Transport Profile Example The example above shows how MPLS-TP may be used to provide an EVC across an MPLS-TP domain using a pseudo wire service. The edge devices are preconfigured by the management system to multiplex/demultiplex tagged Ethernet frames into and out of MPLS-TP tunnels and to apply the appropriate labels. The outer MPLS label is the tunnel label; the inner label is the PW label which is used to identify a particular Ethernet service flow. The core devices are configured to swap outer labels and inner labels as required to build the end-to-end path through the MPLS-TP domain. NE2 performs a label swap for tunnel 1. NE3 terminates tunnel layer, performs a label swap at the PW layer and pushes a new tunnel label, tunnel label 2.1, onto the label stack and forwards the data to NE4. NE4 performs a tunnel swap for tunnel 2. Finally, NE5 terminates tunnel 2 and the PW and forwards the tagged Ethernet frame to the customer.

3.30

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems Carrier Ethernet Attributes Service

Port-Based

VLAN-Based

Standardized Services

Type

(All-to-One Bundling)

(Service Multiplexed)

Scalability

E-Line

Ethernet Private Line

Ethernet Virtual Private Line

E-LAN

Ethernet Private LAN

Ethernet Virtual Private LAN

E-Tree

Ethernet Private Tree

Ethernet Virtual Private Tree

Reliability Service Management Quality of Service

Metro Ethernet Network EVC

CE UNI

CE UNI

Transport Technologies for Carrier Ethernet Services 802.1Qay -PBB-TE SONET/SDH

ITU-T and IETF MPLS-TP OTN

ETH Label Switching (ELS) 802.3 PHY

Transport Attributes connection-oriented, reliability, simplicity, deterministic behaviour, fast restoration protection switching – 50 ms, QoS, OAM

Carrier Ethernet Summary This section has discussed the evolution of transport networks from being voice centric to becoming data centric and the importance, going forward, of building transport networks that are optimized for packet transfer. Ethernet connectivity is becoming, if it is not already, the connectivity option of choice. Transporting Ethernet on an end-to-end basis is vitally important to customers and service providers alike. As Ethernet services become business critical it becomes equally critical that the technologies used to transport it are reliable. The term ‘carrier Ethernet’ is often thought to describe a technology, but in practice it is a reference to providing the reliable end-to-end transfer of Ethernet service flows. The MEF has provided an industry-accepted definition of carrier Ethernet: ‘A ubiquitous, standardized, carrier class Service and Network defined by five attributes that distinguish it from familiar LAN based Ethernet’. Additionally, the MEF have defined a standard set of Ethernet services, traffic shaping parameters and CoS marking scheme so that QoS can be applied in the transport network. Transport attributes have been identified together with a number transport technologies that provide these attributes. Carrier Ethernet Transport is not a single technology but a multilayer network architecture that combines a flexible packet layer with an efficient optical layer, SDH/NG-SDH/OTN, allowing end-to-end QoS, resilience and deterministic performance. The main forwarding technologies emerging for packet transport solutions are MPLS-TP, PBB-TE and Ethernet Label switching. One of the major requirements of transport networks is OAM, which includes fault management and performance management.

TY2702/v3.1

© Wray Castle Limited

3.31

Next Generation Transmission

Customer Site

Customer Site UNI

NID

Access

UNI Core Transport Network

10/100/GE NID

Access

Demarcation Point

OAM Layers MEF and ITU-T Y.1731

Reflected in customer SLAs

Service Layer

802.1ag, Y.1731 and MEF

EVC: CFM and PM

Connectivity layer

802.3ah

EFM

EFM

Link layer

Ethernet OAM Standards As Ethernet has evolved as a carrier transport service, a number of standards have emerged to provide OAM support, namely 802.3ah, Y.1731 and 802.1ag. Collectively, these standards provide performance management, connection fault management and troubleshooting functions. IEEE 802.3ah, otherwise known as EFM provides management at the port level for a single link, fibre or copper; it does not support end-to-end service monitoring functions. It has been designed to provide OAM across the access interface between CPE devices, such as a Network Interface Device (NID) providing the demarcation point between the service provider and the customer. MEF services such as E-Line and E-LAN provide connectivity at the EVC level. OAM functions for endto-end EVCs are defined in MEF 17. MEF 17 does not specify OAM physical link layer functions but with the connectivity layer, i.e. the EVC, and the service layer. The MEF standards specify edge-to-edge monitoring of an EVC provided across a single operator domain or across multiple operator domains. 802.1ag and Y.1731 provide functions allowing end-to-end service monitoring at the Ethernet connectivity layer and the service layer. However, rather than just providing an edge-to-edge view of an operator domain, 802.1ag and Y.1731 802.1ag provide the capability to monitor points within a domain. 802.1ag defines CFM (Connection Fault Management) functions, while Y.1731, in addition to CFM functions, also defines Performance Management (PM) functions. CFM functions include fault verification and isolation, while PM functions include monitoring frame loss ratio, delay, delay variation and jitter.

3.32

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Main Functions discovery unidirectional fault signalling link Monitoring loopback extensions container Customer Site Customer owned equipment

Customer Site

Loopbacks 802.3ah-EFM NID

NID Access UNI

Core Transport Network

OAM PDUs: relevant to a single link – therefore not forwarded service discovery – check OAM support loopback PDUs continuity PDUs event notification PDUs

Access UNI

Performance stats: % frame errors coding symbol errors Alarms – also trigger RDIs power, dying gasp loss of signal critical events – CPE failure

802.3ah – EFM EFM is a link layer OAM protocol which is applied specifically to a single physical link between an endpoint and a directly connected peer device. OAM PDUs are not forwarded by a receiving device. IEEE 802.3ah (EFM) uses OAM PDUs to implement service discovery, check link continuity and provide loopback capabilities. EFM functionality includes auto discovery, fault detection, link performance monitoring and loopback. The auto discovery mechanism is the first phase of the OAM protocol that peers use to determine each other’s OAM capabilities and configuration, e.g. support of loopback functions. On a normal link, OAM PDUs and data frames are sent in both directions. If a link fails in one direction then only OAM PDUs are sent in the opposite direction to the failure. This is often referred to as unidirectional fault signalling and is used to provide remote fault detection indications such as loss of signal to the far end, i.e. remote failure indication, dying gasp or a critical event such as a CPE failure. A ‘dying gasp’ condition occurs when there is a break in an end-point’s power supply. Prior to complete power failure a dying gasp alert is sent to the network operator’s management system. Remote monitoring capabilities enable devices to provide performance statistics. An event OAM PDU is used to notify a peer when a threshold has been exceeded. Monitored events include errored symbol periods and the number of errored frames. An 802.3ah capable device can put its peer into a remote loopback condition using a loopback control OAM PDU. This is useful for testing at the installation phase and troubleshooting. 802.3ah allows ‘organizational specific extensions’ to be written into the protocol. These enable vendors to incorporate proprietary management functions into their EFM implementation. This might include additional monitoring and discovery information, configuration details and trap notifications. For example, Omnitron NIDs include traps for customer-facing port faults, temperature and power deterioration and security and intrusion detection alarms. They are also able to monitor optical port parameters such as temperature power and voltage.

TY2702/v3.1

© Wray Castle Limited

3.33

Next Generation Transmission OAM Function CFM

PM

802.1ag

Y.1731

Fault detection

yes

yes

Continuity Check Message (CCM)

Fault/verification/ loopback

yes

yes

Fault isolation

yes

yes

MIP Discovery

yes

yes

Loop Back Message (LBM) Loop Back Response (LBR) Link Trace Message (LTM) Link Trace Response (LTR) Link Trace Message (LTM) Link Trace Response (LTR)

Fault Notification

no

yes

AIS/RDI

Maintenance

no

yes

ETH-LCK and ETH-Test

Frame Loss

no

yes

CCM Loss Measurment Message (LMM) Loss Measurement Response (LMR)

Frame Delay (one-way)

no

yes

Delay Message (one-way) (DM)

no

yes

Frame Delay Message (one-way) (DM)

no

yes

Delay Message (DMM) Delay Message Response (DMR)

Delay Variation (one-way) Frame Delay (RTT) Delay Variation

Method

DMM/DMR

Main standards: IEEE 802.1ag, ITU-T Y.1731 and MEF 6, 10 & 17

CFM and Performance Management (PM) IEEE 802.1 and ITU SG 13 and MEF have worked together to ensure that the set of Ethernet OAM standards are compatible. The IEEE has defined the protocol element and Opcodes for a specific set of CFM functions. The ITU-T and MEF reference these baseline standards and also provide additional CFM functionality together with PM capability. IEEE 802.1ag CFM functions focus on fault detection, fault localization using loopbacks capability, fault isolation and Maintenance Intermediate Point (MIP) discovery. ITU-T and MEF include fault notification such as RDI and AIS and maintenance and test signals, namely Ethernet Lock (ETH-LCK)and Ethernet Test (ETH-Test). The ETH-LCK signal is a maintenance option and is transmitted by a Maintenance End Point (MEP) to communicate intentional maintenance activity on that MEP. It is sent to all other MEPs in the same OAM level to suppress alarms and to provide a means for MEPs to distinguish between maintenance activity that disrupts data traffic and fault conditions. ETH-Test uses a OAM Test Signal message that is sent between MEPs and may be used to test throughput, measure bit errors, or detect frames delivered out of sequence. The ETH-Test may be used either in service or out of service. In-service testing must be at a rate that is not disruptive to traffic. Outof-service testing will cause MEPs to send LCK messages in addition to the test messages. Test messages include sequence number, transaction identifiers and a pseudo-random test pattern. There are used to test throughput, measure bit errors or detect frames delivered out of sequence. The PM functions are frame loss detection, frame delay (both one way and round trip time) and delay variation. The table above summarizes CFM and PM functions together with the OAM PDUs methods that are used to implement them.

3.34

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Operator A

Operator B

UNI

UNI

Customer OAM Level (Domain) – levels 5-7

Service provider OAM Level (Domain) – levels 3-4 ETH Service Layers

Layer 2 data flow Operator A OAM Level (Domain) levels 0-2

Operator B OAM Level (Domain) levels 0-2

Server/ Transport

MEP – Maintenance Endpoint manage OAM session, e.g. initiate a loopback MIP – Maintenance Intermediate Point- react and respond to OAM PDUs.

For a particular Maintenance Entity:

same domain same level same vlan

End-to-End Ethernet Service OAM The IEEE, ITU and MEF have adopted a common multi-domain OAM model. The Ethernet service layer sits on top of an underlying transport layer. The transport layer provides packet transport links between Ethernet devices in an operator’s/service provider’s network. The transport layer may be implemented over a single Ethernet link or multi-hop MPLS pseudo-wire or SONET/SDH or OTN paths each with their own OAM functions. The Ethernet OAM model is split into three distinct levels called maintenance domains: customer, service provider and operator. The customer OAM level has visibility of the end-to-end service between CE devices connected to the UNI. The service provider has end-to-end responsibility so has visibility of the end-to-end Ethernet path across the network. An end-to-end link is typically provided by a number of partner carriers, each with responsibility for their own network. The operator domain OAM level allows them to monitor tandem connections across their own networks. Notice that any given maintenance domain is bounded by Maintenance Endpoints (MEPs). Each domain may also have Maintenance Intermediate Points (MIPs). In practice, the Multi-domain model is implemented by network elements and CE equipment that act as OAM MEPs or MIPs. In the diagram, the data flow in Ethernet Layer is shown by the dashed line passing through the MEP and MIPs of various OAM levels configured in the network equipment. This data flow includes customer traffic and Ethernet OAM PDUs. OAM PDUs may be ‘addressed’ to a particular MEP/MIP at a particular OAM level. MEPs are functional entities that manage OAM sessions and generate/receive OAM PDUs, e.g. CCMs or LBMs. MIPs are intermediate functional entities on the end to-to-end path that react and respond to OAM PDUs, i.e. they forward them towards a MEP or provide troubleshooting information for fault isolation. Multiple MIPs and MEPs may be associated with a port on a device. However, a particular MEP and MIP must belong to a particular OAM level within a particular VLAN within a single domain. OAM levels are identified in the diagram. One of the goals of the OAM model is to contain alarms within predetermined levels. This goal is achieved by only allowing alarms detected in one level to be reported within that level and the level above. For example, a fault detected in the operator level is reported to the service provider level allowing the SP to reroute around the fault, while fault reporting in the detecting layer provides the operator with a rich set of information to allow them to localise and repair the fault. Although alarms may be reported into the next higher level, they are not reported between operator domains. TY2702/v3.1

© Wray Castle Limited

3.35

Next Generation Transmission MEP

interface FastEthernet1/0/1 switchport trunk encapsulation dot1q switchport mode trunk ethernet cfm mip level 7 ethernet cfm mep level 4 mpid 2110 vlan 110 ethernet cfm mep level 4 mpid 2101 vlan 101

MIP

ethernet cfm domain CUSTOMER_DOMAIN level 7 ethernet cfm domain Provider_DOMAIN level 4 mep archive-hold-time 60 service customer_101_provider vlan 101 service customer_110_provider vlan 110 ethernet cfm enable ethernet cfm traceroute cache

Site C

Gi0/1

Site A

Fa1/0/1

4 7 Gi0/1

POP 2

!

4

interface FastEthernet1/0/1 switchport trunk encapsulation dot1q switchport mode trunk ethernet cfm mip level 7 ethernet cfm mep level 4 mpid 1110 vlan 110 ethernet cfm mep level 4 mpid 1101 vlan 101

Fa1/0/24 Fa1/0/1

4

Gi3/24

7

4 4 Fa1/0/23

4

Gi3/23

!

4

POP 1

interface FastEthernet1/0/23* switchport trunk encapsulation dot1q switchport trunk mode ethernet cfm mip level 4

Gi3/48 Gi3/48

Site B 4

!

Fa0/1

ethernet cfm cc enable level 0-7 vlan 1-4095

4

Gi3/32

7 POP 3

mpid – MEP Identifier

MEP and MIP Assignments An EVC is provided via a number of service providers switches, as shown above, to a customer at three remote sites, A, B and C. To facilitate ETH OAM, the service provider has configured MEPS and MIPS at either OAM level 4 (service provider level) or 7 (customer level) on appropriate ports as shown. MEPs at level 4 are configured at the edges of the service provider domain, while each intermediate port is configured as a MIP at level 4. The service provider is able to initiate, via the MEPS, CFM and Performance Management (PM) functions end-to-end across their domain. The service provider has configured MIPS at the OAM level 7, but only at the edges of his domain. The MEPs for this level would either be configured on the customer routers or at demarcation devices at the customer sites. This gives the customer end-to-end visibility of their service. The configuration detail shows that there are two VLANs configured for this EVC on interface Fa1/0/1 on the switch at POP 1, VLAN 101 and VLAN 110. Each VLAN is assigned a MEP at level 4 with an associated MEP Id. Interface Fa1/0/1 is also configured with a MIP at level 7. A MIP at level 4 is configured on interface Fa1/0/23. The configuration data for all the MIP at level 4 and 7 will be similar to that shown in the diagram for the MIP on interface Fa1/0/23. The configuration data for the MEPs at POP 2 and 3 will be similar to that at POP 1 except the MEP Ids will differ per VLAN to those declared at POP 1, as shown at POP 2. This example is based on an extract from the following: ethernet-oam-tutorial_srinath-beldona cisco.

3.36

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems Service Provider ME S

S

S

S

CE A CE

A A

A

Operator A

A

Operator B B

A A

A

B

B

B B B

A

A

B

B

B

Operator A ME Operator A MEG

A

CE

MEP MIP

MEP

Maintenance Endpoint

MIP

Maintenance Intermediate Point

ME

Maintenance Entity

MEG

Maintenance Entity Group (ITU-T Y.1731)

MA

Maintenance Association (IEEE 802.1ag) (same definition as MEG)

CE

Ethernet Service OAM Service Terminology The ITU-T and MEF use the following terminology to define entities in the OAM architecture. A Maintenance Endpoint (MEP) is a functional entity that manages OAM sessions. For example, a MEP may generate messages to check continuity between a pair of MEPs. A Maintenance Entity (ME) is an entity that requires management. It may be considered to be an association between Maintenance endpoints, as indicated in the diagram. An ME is bounded by a pair of MEPs. A Maintenance Endpoint Group (MEG) includes a set of MEs that satisfy the following condition. MEs in a MEG must be in the same administrative domain and at the same OAM level, operator, service provider; MEs in a MEG belong to the same service provider S-VLAN, i.e. a point-to-point or multipoint EVC. IEEE 802.1ag uses the term Maintenance Association rather than MEG. It follows that MEPs and MIPS, which are part of an ME, must also be in the same domain, at the same OAM level, and on the same S-VLAN.

TY2702/v3.1

© Wray Castle Limited

3.37

Next Generation Transmission

CE A CE

A

A

Operator A

A

Operator B

B

B B

A A

B

B

B Operator B ME

ETH (CCM)

(CCM) ETH S

S ETH (CCM)

NE 1

(CCM) ETH S

ETH (CCM)

S ETH (CCM)

Fault free

NE 2

CCM intervals: 3.3 ms, 10 ms, 100 ms, 1 min or 10 mins Service Provider ME

MEPs pre configured with a list of all other MEPs (MEP Id list) in the domain

MEP MIP

ETH (CCM) – Ethernet frame with encapsulated) CCM – contains senders MEP Id Ethernet frame: SMAC – Unicast, DMAC Multicast

CCMs detection capabilities include:  Link and Fabric Failures  Duplicate MEPs  Missing MEPs  Data Loss

CFM Continuity Check Continuity Check Messages (CCM) are used to detect one way connectivity between a pair MEPs in an ME or between multiple pairs of MEPS in a MEG. CCMs may be sent at configured intervals ranging from 3.3ms to 10 seconds. MEPs and MIPs do not send responses to CCMs. The example above considers the case where there are no fault conditions on the network. MEPs at NE1 and NE2 send CCM messages to each other at a pre defined interval. This enables the MEPs to ‘continuously’ monitor connectivity. This example shows CCM messages being sent in the SP domain only. However, CCM messages may also be sent in the operator domains, i.e. along the ME between MEPs in Operator domain A and along the ME between MEPs in Operator domain B. When defining a service domain for a VLAN, MEPs are configured with a list of the MEP Ids for all other MEPS in that domain. CCM messages are sent using a DMAC multicast address to all other MEPs in the domain encapsulated in an Ethernet frame. The Ethernet frame contains the unicast SMAC address of the sender while the CCM messages include the MEPs identity. MEPs receiving CCM messages learn the senders MAC address and its MEP Id. Furthermore MEPs can identify which MEPS are active and can confirm, by comparing the MEP Id in the CCM to its pre configured list of MEP Ids, that the MEP is a valid member of the domain. CCMs may be used to determine a range of conditions included those listed in the diagram.

3.38

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Service Provider ME NE 1

CCM/RDI

CCM/RDI S S CCM CCM

S CCM

NMC

NE 2

CCM/RDI

NMC

S

uni directional fault

Alarm CE

Alarm A CE

A A

A

Operator A

Operator B

B

B

B

A A

B

B

B

uni directional fault

B

CCM

CCM/RDI

B

MEP MIP Operator B ME

CFM Fault Detection Consider a unidirectional fault at the point shown. In the SPs domain NE2 will not receive CCM messages. Following three consecutive lost CCM PDUs, NE2 sets the Remote Defect Indicator (RDI) flag in the CCM frame it sends to NE1 indicating that there is a loss of service. Both NE1 and NE2 report alarms to their NMCs. Similarly, in Operator B’s domain, NE2 will, following three consecutive lost CCM PDUs, set the RDI flag in the CCM messages sent to its peer at the other edge of the domain indicating that there is a loss of service.

TY2702/v3.1

© Wray Castle Limited

3.39

Next Generation Transmission

Service Provider ME

NE 1

LTM

LTM

S

NE 2

LTM

S

S

S

LTR

LTR

CE LTR A CE

A A

A

Operator A

Operator B

B

B

B

A A

B

B

B Operator B ME

MEP MIP LTR – Contains the MIPs MAC address

Link Trace Message – MIP Address Learning The link trace function, similar to IP trace route, may be used to discover the address of MIPs across an ME. LTM messages are sent using a DMAC multicast address to all other MEPs in the domain encapsulated in an Ethernet frame, alternatively the initiating MEP could use the unicast MAC address of a target MEP learned from the CCM procedures. The Ethernet frame contains the unicast SMAC address of the sending MEP. Any MIP receiving an LTM sends a response, LTR, to the initiating MEP’s unicast address. This is encapsulated in an Ethernet frame where the SMAC is the MIP’s unicast address. The MIP then forwards the LTR onto the next hop. The MEP at the distant end of the ME also responds to the LTM with an LTR indicating that the final destination, i.e. the MEP, has been reached. Following this procedure the initiating MEP learns the unicast MAC addresses of all the MIPs along a path to a given MEP.

3.40

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

LBM to NE2 Service Provider ME

LBM NE 1

NE 2

LBM

S

S

S

LBR

S

LBR

CE A CE

A A

A

Operator A

Operator B

B

B

B

A A

B

B

B Operator B ME

MEP MIP

Loopback Procedures – CFM Fault Verification/Isolation If a fault is detected on the network the loopback function, similar to IP ping request/response, may be used to verify and isolate the fault. A network manager can initiate a loopback procedure across the Service Provider ‘s (SP’s) ME by sending a LoopBack Message (LBM) from the MEP at NE1, for example. The LBM is addressed to a specific MIP or MEP in the ME using the MIP’s/MEP’s unicast MAC address learned during the LTM and CCM procedures respectively . The addressed MIP/MEP responds with a LBR. In the example above NE1 receives successful responses from the two MIPs but this would not be the case for LBM sent to the MEP at NE2. Operator B could use the LBM procedure to isolate the fault within their network. The loopback method provides two way connectivity verification. It may also be used to provide a degree of performance monitoring, for example it can be used to measure delay and delay variation.

TY2702/v3.1

© Wray Castle Limited

3.41

Next Generation Transmission

Operator A

Operator B

UNI

UNI

RDI

Customer OAM levels 5-7

RDI SP OAM levels 3-4

AIS sent downstream In next higher layer

Operator OAM levels 0-2 Transport MEP MIP

Connectivity Failure detected here

Note that defect information is now transferred between operators

CFM AIS When a MEP detects a connectivity failure OAM Level N it injects AIS in the downstream direction away from the fault in the next higher OAM layer on each VLAN affected by the failure. A MEP receiving an AIS in a particular maintenance layer injects it into the next higher layer and sends RDI to its peer MEP in the same maintenance layer as itself. The AIS condition is sent periodically until the service is restored. The AIS interval range is 3.3 ms to 10 seconds; an interval of one second is recommended. When a MEP receives an ETH-AIS from a lower layer it detects AIS and suppresses alarms associated with all its peer MEPs. Note that RDI and AIS indication are supported by Y.1731 but not 802.1ag.

3.42

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

Operator A

Operator B

UNI

UNI

EVC

TX/RX Counters

Frame Loss Measurement (CCM or LMM and LMR) (can be single ended or dual ended)

2 3 0 9 9

TX/RX Counters 2 2 9 5 6

Dual ended CCM both MEPs calculate near and far end frame loss

Single ended LMM/LMR LMR sender calculates near and far end frame loss

MEP

Performance Monitoring Y.1731 Frame Loss Ratio As well as Connection Fault Monitoring, Y.1731 adds Performance Monitoring to the Ethernet OAM functionality. Y.1731 and MEF 10 use the same parameter definitions for PM functions. These include frame loss ratio, service availability, frame delay and frame delay variation. Frame loss ratio is the difference between the number of frames transmitted by a MEP at one end of an EVC and those received at the other end of an EVC. There are two types of loss measurement, single ended and dual ended. Single-ended frame loss is calculated on demand between two MEPs using Loss Measurement Messages (LMM) and Loss Measurement Responses (LMR). The MEPs include TX and RX frame counters to determine the frame loss ratio at both the near end and the far end. Only the end that initiated the LMR message is able to calculate frame loss. Dual-ended frame loss is achieved using CCM messages and appropriate counters which enable MEPs at both ends to calculate near end and far end frame loss. Service availability can be assessed from the frame loss ratio over a period over time. If the loss ratio exceeds a threshold the service is considered to be unavailable.

TY2702/v3.1

© Wray Castle Limited

3.43

Next Generation Transmission

Operator A

Operator B

UNI

UNI

EVC One Way Delay (1DM) (clocks need to be time of day synchronized) 1DM Delay and Delay Variation

Two Way Delay (DMM/DMR) (does not need time of day clocks to be synchronized)

NE1

DMM DMR

MEP

1DM

DMR

NE2 DMR Proc time

RTT=(Time_DMR_RX)-(Time_DMM_TX)-(Processing time) Processing time=Time_DMR-TX -Time-DMM-RX

Performance Monitoring Y.1731 Delay and Delay Variation There are two types of Frame Delay measurement: One Way and Two Way. One-way measurement requires accurately synchronized time-of-day clocks at both MEPs. An initiating MEP sends periodic 1DM messages containing a transmit timestamp. The receiving MEP creates a receive timestamp at the instant the 1DM frame arrives and calculates the time delay as the difference between the two clocks. Two-way frame delay measurements allow an initiating MEP to calculate the Round Trip Time (RTT). This method does not require time-of-day synchronization. MEPs exchange Delay Measurement Messages (DMM) and Delay Measurement Responses (DMR), each of which contains a transmit timestamp and may include a receive timestamp and a return transmit timestamp. A MEP can approximate the RTT using just the transmit time stamp by comparing the time difference between a transmitted DMM and the DMR response. The additional timestamp information enables the DMR processing time to be compensated when calculating RTT. In the diagram:    

Time_DMR_RX is the time the DMR message is received by NE1, as seen by NE1 clock Time_DMM_TX is the time the DMR message is sent by NE1, as seen by NE1 clock Time_DMR_TX is the time NE2 sends the DMR, as seen by NE2 clock Time_DMM-RX is the time NE2 receives the DMM, as seen by NE2 clock

Frame delay variation is calculated by monitoring the variation in delay between two delay measurements.

3.44

© Wray Castle Limited

TY2702/v3.1

Carrier Based Ethernet and Transmission Systems

S-Tag DA 6 Octets

SA 6 Octets

C-Tag

OAM Type 0x8902

T-PID S-VID T-PID C-VID

OAM E-Type

ITU-T

FCS

0

802.1ag

Codes

Y.1731

0-31

yes

yes

32-63

yes

no

64-255

no

yes

4 Octets

Octets

Op Code – OAM message type Op

Data

2 2 2 2 2 Octets Octets Octets Octets Octets

Octets

0

MA Level

Version

1

2

3

Op Code

Flags

TLV Offset

4 8 12 Last

End TLV

MA 0–2 Network operator level OAM MA 3+4 Provider level OAM MA 5–7 Customer level OAM

OAM Frame The IEEE 802.1 and ITU study group 13 have been working on a common frame format. The work is in progress, so some of the parameters are still to be defined. The OAM frames will be addressed using the same Tag values as the traffic to which they refer. A new OAM ETYPE 0x8902 has been defined to identify that this is not normal traffic but carrying OAM. The OpCode will be used to identify the OAM operation and the FLAGS will have specific meanings dependent upon the leading OpCode. For example, in a CCM message the flags are used to encode the CCM sending interval; they also contain the RDI. The TLV offset records the position of the first information element within the OAM payload. The MA levels are: MA 5–7 Customer Level; MA 3+4 Provider Level; and MA 0–2 Network Level.

TY2702/v3.1

© Wray Castle Limited

3.45

Next Generation Transmission LAN PHY Ether Type

WAN PHY Ether Type

Transmission Rate

Cable Type

? nm

IEEE

Distance

Duplex

100Base2

NA

10 Mbit/s

Coax (thick or thin)

NA

802.3

64 octets

Flags 0000

0000

Sequence number ATM specific Optional (16) (8)

– ATM N-to-one cell mode – AAL5 SDU Frame Mode RFC 4446 N-to-one mode. Either one or more VCCs or one or more VPCs may be mapped to one PW. The VPI/VCI is always present. Cells from one or more VCCs (or one or more VPCs) may be concatenated.

0000

Flags 0000

RES (2)

LEN (000000)

SEQ NO. (16)

Flags/length not used

Three deployment models: 1. Single ATM connection. A PW carries the cells of only one VCC or VPC. Supports transport of multiservice ATM for all AAL types. 2. Multiple ATM connections. A PW carries the cells of multiple VCCs or VPCs. Supports transport of multiservice ATM for all AAL types. 3. AAL5. A PW carries the cells of only one VCC . Supports transport of multiservice ATM. The AAL SDU is the upper layer PDU – i.e. If the upper layer is IP then the AAL SDU i s the IP datagram.

ATM Pseudo Wire General

TY2702/v3.1

© Wray Castle Limited

A9.1

Next Generation Transmission

ATM Packed Cell Relay (One-to-One) Mode One VCC per PW – with multiple cells (VPI/VCI not included) Tunnel Label PW Label 0000

Control Word

RSV (4)

SEQ NO. (Optional) (16)

M

V

RES (2)

PTI (3)

C

ATM Payload 48 bytes M

Control Word ATM Payload 48 bytes

V

RES (2)

PTI (3)

C

M=0 : packet contains ATM cells M=1: packet contains AAL5 payload V=0: no VCI field present, i.e. Payload is a VCC V=1: VCI present, payload is a VPI PTI: Payload Type Indicator mapped from the ATM header C: CLP bit mapped from ATM Header field

Control Word

M

V

RES (2)

PTI (3)

C

ATM Payload 48 bytes

ATM Cell Relay VCC: one-to-one

ATM Packed Cell Relay (One-to-One) Mode One VPC per PW – with multiple cells (Only the VCI is included) Tunnel Label PW Label Control Word

0000

RSV (4)

SEQ NO. (Optional) (16)

M

V

RES (2)

PTI (3)

C

VCI ATM Payload 48 bytes Control Word

M

VCI

RES (2)

PTI (3)

C

M=0 : packet contains ATM cells M=1: packet contains AAL5 payload V=0: no VCI field present, i.e. Payload is a VCC V=1: VCI present, payload is a VPI PTI: Payload Type Indicator mapped from the ATM header C: CLP bit mapped from ATM Header field

ATM Payload 48 bytes

Control Word

V

M

V

RES (2)

PTI (3)

C

VCI ATM Payload 48 bytes

ATM Cell Relay VPC: one-to-one

A9.2

© Wray Castle Limited

TY2702/v3.1

Pseudo Wires ATM AAL5 CPCS - PDU Mode AAL5 flows mapped to a PW

Tunnel Label PW Label Control Word Payload AAL5 CPCS - PDU N*48 bytes

CPCS Common Part Convergence Sublayer RSV SEQ NO. (Optional) RES Control 0000 M V (4) (16) (3) Word

U

E

C

M=0 : packet contains ATM cells M=1: packet contains AAL5 payload V=0: no VCI field present, i.e. Payload is a VCC V=1: VCI present, payload is a VPI U: used when interworking with Frame Relay . The FR C/R bit is copied here E : EFCI [1if the EFCI bit of the final AAL5 cell is set to 1 C: CLP bit mapped from ATM Header field

ATM AAL5 Pseudo Wire

ATM Packed Cell Relay (N-to-One) Mode. Where multiple VCC or VPCs are transferred on one PW the VPI/VCIs must be unique Tunnel Label PW Label

Optional 0000

Control Word VPI

VCI

PTI

Flags 0000

CLP

RES (2)

LEN (000000)

SEQ NO. (16)

Flags/length not used 1

ATM Payload 48 bytes VPI

VCI

PTI

CLP 2

ATM Payload 48 bytes

VPI

VCI

PTI

CLP

28 max

ATM Payload 48 bytes

ATM N-to-One Pseudo Wire

TY2702/v3.1

© Wray Castle Limited

A9.3

Next Generation Transmission

Structure Agnostic TDM over Packet E1/T1 and E3/T3 emulation SATOP RFC 4553

SATOP RFC 4553

SATOP RFC 4553

TDM Payload

TDM Payload

TDM Payload

CW (Man)

RTP (Opt)

RTP (Opt)

RTP (Opt)

CW (Man)

CW (Man)

UDP (Demux )

L2TPv3 (Demux )

PW Label (Demux )

IP

IP

MPLS Tunnel Label

0000

L R

RSV FRG (2) (2)

LEN (6)

SEQ NO. (16)

Mandatory payload support : – E1 – 256 bytes (8 frame s worth) – T1 – 192 bytes (8 frames worth) – E3/T3 – 1024 bytes

Structure Agnostic TDM over Packet E1/T1 adn E3/T3 emulation

Structure Aware Circuit Emulation over Packet Nx64 kbit/s

CESoPSN RFC 5086

CESoPSN RFC 5086

CESoPSN RFC 5086

TDM Payload

TDM Payload

TDM Payload

CW (Man)

RTP (Opt)

RTP (Opt)

RTP (Opt)

CW (Man)

CW (Man)

UDP Dest Port (Demux )

L2TPv3 (Demux )

PW Label (Demux )

IP

IP

MPLS Tunnel Label

0000

L R M)

FRG 2

LEN (6)

SEQ NO. (16)

Typical payload consists of m frames, where a frame is N timeslots

Structure Aware Circuit Emulation over Packet Nx 64 kbit/s

A9.4

© Wray Castle Limited

TY2702/v3.1

Pseudo Wires TDM over IP Structure Aware and Structure Agnostic TDMoIP RFC 5087

TDMoIP RFC 5087

TDMoIP RFC 5087

TDMoIP RFC 5087

TDM Payload

TDM Payload

TDM Payload

FCS

CW (Man)

RTP (Opt)

RTP (Opt)

TDM Payload

RTP (Opt)

CW (Man)

CW (Man)

RTP (Opt)

UDP Source or Dest Port (Demux)

L2TPv3 Session Id (Demux)

PW Label

MPLS PW Label

Tunnel Label

CW (Man)

IP

IP

Eth Type 88D8 or 8847 (8847 is the MPLS Eth Type) VLAN ID (OPT)

0000 L R

M

RES

LEN (6)

SEQ NO. (16)

Supports real time streams: – constant – rate real time traffic – AAL1 adaptation –

VLAN Eth Type 8100 (OPT) Source MAC Destination MAC

unstructured or structured unchannelized, or structured channelized all channels active all the time

–

AAL1 must be used where high timing accuracy is required

–

variable - rate real time traffic – AAL2 adaptation for example a channelized circuit where all channels are not active all the time – called loop emulation

TDM over IP Structure Aware and Structure Agnostic

TY2702/v3.1

© Wray Castle Limited

A9.5

Next Generation Transmission

A9.6

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission

NEXT GENERATION TRANSMISSION

GLOSSARY OF TERMS

© Wray Castle Limited

I

Next Generation Transmission

II

© Wray Castle Limited

Next Generation Transmission A AAL AAL5 ABR ABT AC AD ADM ADSL2+ AIS AIS ANPS AP APM APS ARPU AS ASE ASON ASTN ATC ATM ATMF AToM AUG AUI AW AWDM AWG

Adaptation ATM Adaptation Layer ATM Adaptation Layer 5 Available Bit Rate ATM Block Transfer Attachment Circuit Automatic Discovery Add and Drop Multiplexer Asynchronous Digital Subscriber Line 2+ Alarm Indication Signal Alarm Inhibit Signal Automatic Network Protection System Access Point Aggregator/Parser Multiplexer Automatic Protection Switching Average Revenue Per User Administrative System Amplified Spontaneous Emission Automatic Switched Optical Network Automatic Switched Transport Network ATM Transfer Capability Asynchronous Transfer Mode ATM Forum Any Transport over MPLS Administration Unit Group Attachment Unit Interface Administration Weight Access WDM Arrayed Waveguide Grating

B-DA BDI BDI-O BDI-P BECN BEI BGP BIAE BIP BIP8 B-ISUP BSC B-SHR BTS B-VID B-VLAN BWP

B MAC Destination Address Backward Defect Indication Backward Defect Indication – Overhead Backward Defect Indication – Payload Backward Explicit Congestion Notification Backward Error Indication Border Gateway Protocol Backward Incoming Alignment Error Bit Interleaved Parity Bit Interleaved Parity – 8 bits Broadband ISDN User Part Base Station Controller Bidirectional Self Healing Ring Base Transceiver Station B-VLAN ID Backbone VLAN Bandwidth Profiles

C C C CAC CBR CBS CC CC CC CCAMP CCC CCID CCM CCM CD CDV CE CEN

Customer Canonical Control Word Bit Connection Admission Control Constant Bit Rate Committed Burst Size Control Channel Connection Controller Connection Controller Common Control and Management Plane Calling or Called-party Call Controller Control Channel ID Continuity Check Message Council Channel Management Collision Detection Cell Delay Variation Customer Edge Carrier Ethernet Network

TY2702/v3.1

© Wray Castle Limited

G.1

Next Generation Transmission CEQ CESoPSN CFM cHEC CI CID CII CIR CLP CLR CMI CMIP CONC CoS CP CP CP CPE CPM CRC CRC8 CR-LDP CSPF CSPF C-Tag CTP CTRL CV CWDM

Customer Equipment Circuit Emulation Service over PSN Connectivity Fault Management core Header Error Code Characteristic Information Channel Identifier Common Interworking Indicator Committed Information Rate Cell Loss Priority Cell Loss Ratio Code Mark Inversion Common Management Information Protocol Concentrator Class of Service Central Processor Communications Provider Connection Point Customer Premises Equipment Control/Parser Multiplexer Cyclic Redundancy Check Cyclic Redundancy Check – 8 bits Constraint-based Routed Label Distribution Protocol Constrained Shortest Path First Constraint-based Shortest Path First Customer Tag Connection Termination Point LCAS Control Connectivity Verification Coarse Wavelength Division Multiplexing

DA DA DACCS DAPI DBR DCM DCM DCN DCSC DE DEI DiffServ DLCI DM DMAC DMM DMR DSL DWDM DXC

Destination Address Discovery Agent Digital Access Cross Connect System Destination Access Point Identifier Deterministic Bit Rate Dispersion Compensation Module Distributed Call and Connection Management Data Communication Network Data Channel Switch Capable Discard Eligible Discard Eligibility Indicator Differentiated Services Data Link Connection Identifier Delay Message (1-way) Destination MAC Delay Message Delay Message Response Digital Subscriber Line Dense Wavelength Division Multiplexing Digital Cross-Connect

EA ECMP EDFA EFM EIR E-LAN E-Line ELS EMS E-NNI EOS EOW EPL EP-LAN ERO

Extension bit Equal Cost Multi Path Erbium-Doped Fibre Amplifier Ethernet in the First Mile Excess Information Rate Ethernet LAN Ethernet-Line Ethernet Label Switching Element Management System NNI inter-domain End Of Sequence Engineering Order Wire Ethernet Private Line Ethernet Private LAN Explicit Route Object

G.2

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission ESCON ETSI EVC EVPL EVP-Tree EXI EXI EXP

Enterprise Systems Connection European Telecommunications Standards Institute Ethernet Virtual Circuit Ethernet Virtual Private Line Ethernet Virtual Private Tree Extension Identifier Extension Indicator Experimental

FAS FAW FCS FDDI FDI-O FDI-P FEBE FEC FEC FECN FEND FERF FIB FM FP FR FRAD FRP FRR FRWD FSC FTFL

Frame Alignment Signal Frame Alignment Word Frame Check Sequence Fibre Distributed Data Interface Forward Defect Indicator – Overhead Forward Defect Indicator – Payload Far End Block Error Forward Error Correction Forwarding Equivalence Class Forward Explicit Congestion Notification Far End Far End Receive Failure Forwarding Information Base Fault Management Functional Process Frame Relay Frame Relay Assembler/Dissembler Fast Reroute Protection Fast Re-Route Forwarder Fibre Switch Capable Fault Type and Fault Location

GCC0 GFC GFP GFP-F GFP-T GID GMPLS GPRS GPS GS GSM GSMP

General Communication Channel-0 Generic Flow Control Generic Framing Procedure Frame Mapped Generic Framing Procedure Transparent Generic Framing Procedure VCG Group Identification Generalized Multi Protocol Label Switching General Packet Radio Service Global Positioning System Group Switch Global System for Mobile Communications General Switch Management Protocol

HDLC HDTV HEC H-LSP HOP HPA HPC HPOH HPT HVC

High-level Data Link Control High Definition Television Header Error Control Hierarchical Label Switched Path High Order Path High Order Path Adaptation HOP Connection Higher-order Path Over Head High Order Path Termination High Order Virtual Container

IaDI IAE iBGP IETF IGP ILA I-NNI IP IPCC IPTV

Intra-Domain Interface Incoming Alignment Error Internal Border Gateway Protocol Internet Engineering Task Force Interior Gateway Protocol In Line Amplifier NNI intra-domain Internet Protocol IP Control Channel IP Television

TY2702/v3.1

© Wray Castle Limited

G.3

Next Generation Transmission IPv4 IPv6 IrDI ISC IS-IS ISIS-TE ITU-T

Internet Protocol version 4 Internet Protocol version 6 Inter-Domain Interface Interface Switching Capabilities Intermediate System to Intermediate System ISIS Traffic Engineering International Telecommunication Union – Telecommunication Standardization Sector

L L2TP LACP LAG LAN LAS LBM LBR LC LCAS LCV LDP LDP LFT LLC LMM LMP LMR LOP LOS LPA LPC LPC LPOH LPT LRM LSA LSC LSP LSR LTM LTR LVC

Local Failure Layer 2 Tunnelling Protocol Link Aggregation Control Protocol Link Aggregation Group Local Area Network Link Aggregation Sublayer Loop Back Message Loop Back Response Link Connection Link Capacity Adjustment Scheme Link Connectivity and Verification Label Description Protocol Label Distribution Protocol Label Forwarding Table Logical Link Control Loss Measurement Message Link Management Protocol Loss Measurement Response Low Order Path Loss Of Signal Low Order Path Adaptation LOP Connection Link Property Correlation Lower-order Path Over Head Low Order Path Termination Link Resource Manager Link State Attribute Lambda Switch Capable Label Switched Path Label Switched Router Link Trace Message Link Trace Response Low Order Virtual Container

M MA MAC MAN MAU MCp ME MEF MEG MEN MEP MFI MH-PW MIB MII MIP MMI MoE MoP MoR MoS MP-BGP MPEG MPLS

Defect Modifier Maintenance Association Medium Access Control Metropolitan Area Network Medium Attachment Unit Matrix Connection protection Maintenance Entity Metro Ethernet Forum Maintenance Entity Group Metro Ethernet Network Maintenance End Point Multiframe Indicator Multi Hop Pseudo Wires Managed Information Base Media Independent Interface Maintenance Intermediate Point Man–Machine Interface T-MPLS over Ethernet T-MPLS over PDH T-MPLS over Resilient Packet Ring T-MPLS over SDH Multi Protocol BGP Motion Picture Experts Group Multi Protocol Label Switching

G.4

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission MPLS-TE MPLS-TP MS-AIS MSAN MSC MSOH MSP MSPP MST MST MSTP MTU

MPLS – Traffic Engineering MPLS – Transport Profile Multiplexer Section Alarm Indication Signal Indication Multi Service Access Node Mobile-services Switching Centre Multiplexer Section Overhead Multiplex Section Protection Multi Service Provisioning Platform Multiplexer Section Termination Member Status Multiple Spanning Tree Protocol Maximum Transmission Unit

NAT NC NCC NCCMAC nD-ROADM NE NEM NEND NGN NHLFE NHOP NID NLPID NMC NMS NNHOP NNI NPC nrt-VBR NSP NSP

Network Address Translation Network Connection Network party Call Controller NCC at the MAC layer nDimentions-Reconfigurable Optical Add Drop Multiplier Network Element Network Element Manager Near End Next Generation Network Next Hop Label Forwarding Entry Next Hop Network Interface Device Network Layer Protocol Identifier Network Management Centre Network Management System Next-next Hop Network Node Interface Network Parameter Control non-real-time Variable Bit Rate Network Service Processor Native Service Processing

OADM OAM OCC OCG OCh OChr OCI ODF ODTUG2 ODU ODUk OIF OLA OLT OLTE OMS OMSP ONNI OOS OPS OPU OPUk OSA OSC OSI OSPF OSPF-TE OSTN OTM OTM-n OTN

Optical Add-Drop Multiplexer Operations Administration and Maintenance Optical Channel Carrier Optical Carrier Group Optical Channel – full functionality Optical Channel – reduced functionality Open Connection Indicator Optical Distribution Frame Optical Channel Data Tributary Unit Group 2 Optical-channel Data Unit Optical-channel Data Unit – k Optical Internetworking Forum Optical Line Amplifier Optical Line Terminal Optical Line Terminating Equipment Optical Multiplex Section Optical Multiplex Section Protection Optical Network Node Interface OTM Overhead Signal Optical Physical Section Optical-channel Payload Unit Optical-channel Payload Unit – k Optical Spectrum Analyser Optical Supervisory Channel Open Systems Interconnect Open Shortest Path First OSPF Traffic Engineering Automatic Switched Optical Network Optical Transport Modules Optical Transport Module – n Optical Transport Network

TY2702/v3.1

© Wray Castle Limited

G.5

Next Generation Transmission OTS OTU OTUk OVC OXC

Optical Transmission Section Optical Transport Unit Optical Channel Transport Unit Operator Virtual Connection Optical Cross-Connect

P P PB PBB PBB-TE PBT PBX PC PCC PCM PCP PCS PDA PDH PDN PE PEB pFCS PFI PHB PHP PHY PLS PM PMA PMD PMI PNNI POH PON POP PoS POS POTS PPP PPPoA PPPoE PPS PRBS PRC PREP PSC PSF PSI PSN PT PTI PVC PW PWE3

Priority Provider Provider Bridges Provider Backbone Bridging PBB with Traffic Engineering Provider Backbone Transport Private Branch Exchange Protocol Controller Protection Communication Channel Pulse Code Modulation Priority Code Point Physical Coding Sublayer Personal Digital Assistant Plesiochronous Digital Hierarchy Private Data Network Provider Edge Provider Edge Bridge payload Frame Check Sequence Payload FFCS Indication Per Hop Behaviour Penultimate Hop Popping Physical Interface Physical Layer Signalling Performance Monitoring Physical Medium Attachment Physical Medium Dependent Payload Missing Indicator Private Network to Network Interface Path Overhead Passive Optical Network Point of Presence Packet over SDH Packet Over SONET Plain Old Telephone Service Point-to-Point Protocol Point-to-Point over ATM Point-to-Point over Ethernet Path Protection System Pseudo Random Binary Signal Primary Reference Clock Pre-Processing Packet Switch Capable Pseudo Wire Stitching Function Payload Structure Identifier Packet Switched Network Payload Type Payload Type Identifier Permanent Virtual Circuits Pseudo Wire Pseudo Wire Emulation Edge to Edge

QoS

Quality of Service

R RC RCOH RDI REI RF RFC

Remote Failure Routing Controller Radio Complementary Overhead Remote Defect Indication Remote Error Indication Radio Frequency Request For Comments

G.6

© Wray Castle Limited

TY2702/v3.1

Next Generation Transmission RR-STM RS RSA RS-ack RSOH RST RSTP RSVP RSVP-TE RTP rt-VBR

STM-1 radio-relay Regenerator Section Re-Sequence Acknowledge Re-Sequence Acknowledgement Regenerator Section Overhead Regenerator Section Termination Rapid Spanning Tree Protocol Resource Reservation Protocol Resource Reservation Protocol – Traffic Engineering Real-time Transport Protocol real-time Variable Bit Rate

S SA SA SA SAAL SAg SAN SAPI SBR SCs SDH SDH-DRRS SDU SE SGSN SLA SM SM SMAC SNC SNCP SNMP SNP SNPP SNR SOH SONET SPC SPF SPI SQ SRLG SSCF SSCOP SSF SSMB S-Tag STM SVC S-VLAN

Stack Section Adaptation Source Address Structure Aware Signalling AAL Structure Agnostic Storage Area Network Source Access Point Identifier Statistical Bit Rate Switched Connection Synchronous Digital Hierarchy SDH Digital Radio-Relay System Service Data Unit Shared Explicit Serving GPRS Support Node Service Level Agreements Section Monitoring Synchronous Multiplexer Source MAC Sub Network Connection SNC Protection Simple Network Management Protocol Sub Network Point Sub Network Point Pool Signal-to-Noise Ratio Section Overhead Synchronous Optical Network Soft Permanent Connection Shortest Path First Synchronous Physical Interface Sequence Indicator Shared Risk Link Group Service Specific Coordination Function Service Specific Connection Oriented Protocol Server Signal Fall Synchronization Status Message Byte Service-provider’s Tag Synchronous Transport Module Switched Virtual Circuit Service VLAN

TAP TCM TCP TCP TDM TDMoIP TE TE TED TIM TLV TM TMH

Termination and Adaptation Performer Tandem Connection Monitoring Termination Connection Point Transmission Control Protocol Time Division Multiplexing TDM over IP Thermo Electric Traffic Engineering Traffic Engineering Database Trace ID Mismatch Type Length Value Terminal Multiplexers T-MPLS Hierarchy

TY2702/v3.1

© Wray Castle Limited

G.7

Next Generation Transmission T-MPLS TNA TPI TRAN TT TTI TTL TTp TTP TTPid TTu TU TUG

Transport MPLS Transport Network Address Tag Protocol Identifier Transport Services Layer Trail Termination Trail Trace Identifier Time To Live protected Trail Termination Trail Termination Point Trail Termination Part identifier unprotected trail termination Tributary Unit Tributary Unit Group

UBR UDP UNI UPC UPE UPI U-SHR

Unspecified Bit Rate User Datagram Protocol User Network Interface Usage Parameter Control Ultimate PE User Payload Identifier Unidirectional Self Healing Ring

VBR VC VC VCAT VCC VCCV VCG VCI VCI vcPT VDSL2 VFI VI VLAN VoD VoIP VP VPC VPI VPL VPLS VPN VRF

Variable Bit Rate Virtual Circuit Virtual Container Virtual Concatenation Virtual Channel Connection Virtual Circuit Connectivity Verification Virtual Concatenation Group Virtual Circuit Identifier Virtual Channel Identifier Virtual Concatenation Payload Type Very-high-speed Digital Subscriber Line 2 Virtual Forwarding Instance VLAN Identifier Virtual Bridged LAN Video on Demand Voice over IP Virtual Path Virtual Path Connection Virtual Path Identifier Virtual Path Link Virtual Private LAN Service Virtual Private Network Virtual Routing and Forwarding

WAN WDM WDM WSS WTR WXC

Wide Area Network Wavelength Division Multiplexing Wave Division Multiplexer Wavelength Selection Switch Wait To Restore Wavelength Cross Connect

XC XGMII

Cross Connect 10 Gigabit Media Independent Interface

G.8

© Wray Castle Limited

TY2702/v3.1