ethernet transport services – the current state of the art

Ethernet Transport Services – The Current State of the Art

Technology White Paper

Steve Gorshe Principal Engineer

Issue 1.0: May, 2003 PMC-2030897

© 2003 PMC-Sierra, Inc.

Ethernet Transport Services – The Current State of the Art Technology White Paper

PMC-2030897 (1.0) 1 © 2003 PMC-Sierra, Inc.

Abstract This PMC-Sierra white paper discusses the current state of Ethernet WAN transport. A review of various relevant standards activities is provided, showing that private leased line services are the only architecture ready for large scale tariffed deployment. Transport architectures supporting shared bandwidth and multi-site LAN connectivity are still in their infancy with a number of open issues to be resolved. The paper also discusses the key role for SONET/SDH as the transport medium for Ethernet within the carrier networks, using Virtual concatenation, GFP, and LCAS to enhance SONET’s data transport capability.

About the Author Steve Gorshe, Ph.D. is a Principal Engineer in the Product Research Group and oversees ICs for SONET, optical transmission and access systems.

Currently Steve is a senior member of the IEEE and co-editor for the IEEE Communications magazine’s Broadband Access Series. He is the chief editor for the ANSI T1X1 Subcommittee, which is responsible for SONET and optical network interface standards. He is a recent recipient of the Committee T1 Alvin Lai Outstanding Achievement Award for his standards work and has been a technical editor for T1.105, T1.105.01, T1.105.02, and T1.105.07 within the SONET standard series as well as the ITU-T G.7041 (GFP) recommendation and the draft G.eota Ethernet over Transport Architecture recommendation. He has 24 patents issued or pending and several published papers.

Revision History Issue No. Issue Date Details of Change

1 May, 2003 Document created



Contents Abstract.............................................................................................................................. 1 About the Author............................................................................................................... 1 Revision History................................................................................................................ 1 Contents............................................................................................................................. 2 List of Figures ................................................................................................................... 3 List of Tables ..................................................................................................................... 4 1 Introduction ............................................................................................................... 5 2 Overview of the Status of Related Standards Activities........................................ 6 3 Types of Transport Networks for Ethernet Transport............................................ 8

3.1 Ethernet Private Line (EPL)................................................................................ 8

3.2 Ethernet Virtual Private Line (EVPL) ................................................................ 10

3.3 Ethernet Private LAN (EPLAN)......................................................................... 11

3.4 Ethernet Virtual Private LAN (EVPLAN) ........................................................... 12

4 Importance of Virtual Concatenation (VCAT) ....................................................... 13 5 Conclusions............................................................................................................. 15 6 Glossary ................................................................................................................... 16 7 References ............................................................................................................... 17



List of Figures Figure 1 Ethernet Private Line ........................................................................................ 9

Figure 2 Example of a customer LAN comprised of EPL connections ........................... 9

Figure 3 EVPL example contrasted to EPL .................................................................. 10

Figure 4 Ethernet Private LAN ...................................................................................... 11



List of Tables Table 1 Standards activity relating to Ethernet transport............................................... 7



1 Introduction Private data services today are typically carried through the public telephone network as Frame Relay connections at rates of fractional DS1, full-rate DS1, fractional DS3, and full-rate DS3. In some cases, the data services use ATM instead of Frame Relay either for the customer connection or as a method of transporting the data through the core network. The Frame Relay based services suffer from a lack of scalability to high-speed connections. At the other end of the ‘spectrum,’ some customers use WDM or dark fiber for their WAN or MAN connections with native Gigabit Ethernet, 10Gbit Ethernet, or Fibre Channel. However, WDM equipment is expensive and not ubiquitously deployed, and dark fiber is not universally available, which limits the applications for these approaches. Another drawback of WDM and dark fiber applications is that unless they use the new G.709 Optical Transport Network standard, there is no embedded overhead for the carrier to monitor the quality of the connection or provide protection switching in order to guarantee their service level agreements (SLAs). Some larger customers use high-speed SONET OC-N / SDH STM-N connections which have typically encapsulated the data into PPP and use Packet over SONET/SDH (PoS) for transmission through the SONET/SDH pipe. Link Access Protocol - SONET/SDH (LAPS) - is another option that is very similar to PoS. The main advantages of SONET/SDH are its ubiquitous deployment and its extensive performance monitoring and protection capabilities. Generic Framing Procedure (GFP) has recently emerged as a standard technique for encapsulating native customer Layer 2 data frames (e.g., Ethernet MAC frames) for transmission through SONET/SDH or G.709 networks. GFP was developed to overcome some shortcomings of PoS. Specifically, GFP uses a very simple encapsulation technique that eliminates the need to terminate the customer’s Layer 2 frame and re-map it into PPP, and GFP uses a deterministic amount of bandwidth relative to the client signal bandwidth.

Network providers and system vendors see Ethernet as the most appropriate technology for evolving data services to higher bandwidth and more flexible connectivity. There are currently projects underway in multiple standards bodies and industry forums to address various aspects of MAN and WAN Ethernet transport. These activities are summarized in Section 2. The transport network WAN architectures for carrying Ethernet can be categorized into Ethernet private line (EPL), Ethernet virtual private line (EVPL), Ethernet private LAN (EPLAN), and Ethernet virtual private LAN (EVPLAN). Of these, EPL is the only transport network architecture option that will be standardized in the near future. This is discussed in Section 3.

One key technology that has already been added to the SONET/SDH standards is known as virtual concatenation (VCAT). VCAT allows multiple individual SONET/SDH channels to be combined into a larger channel of appropriate size for a given payload. One of the virtues of VCAT is that only the endpoints of the VCAT channel need to be aware of its existence. The individual constituent channels (members) can even take different routes through the network, with the VCAT sink node accommodating the differential delay between the members. VCAT can be performed at either high order, where the concatenated members are STS-1 or STS-Nc for SONET and VC-4 or VC-4-Nc for SDH, or low order where the concatenated members are VTs for SONET and VC-1/2 or VC-3 for SDH.1 Both higher order VCAT and low order VCAT have important roles, as is discussed further in Section 4.

1 The VC-3 can be a high order container in SDH, where it is essentially equivalent to the SONET STS-1. It is more typical, however, to treat VC-3 as low order container mapped into a TU-3.



2 Overview of the Status of Related Standards Activities The current amount of standards activity is a good indication of how many companies and organizations see Ethernet WAN as the next key step both for Ethernet and for the public transport network providers (i.e., carriers). The major standards activities are summarized in Table 1.

Each standards organization has its own areas of expertise. The majority of the standards that will be required for the public transport network are being developed in the Q12 and Q11 groups of ITU-T SG15. This work has been partitioned not only logically by topic, but also in a manner that will allow the earliest possible approval of useful standards/recommendations (i.e., in October 2003). Those recommendations that will require more study and debate prior to consensus are targeted for May 2004. ITU-T SG15 has established liaison contact with the other standards organizations and forums where their input is required or desired. For example, the G.ethsrv work is expected to use a considerable amount of input from the MEF regarding the definition of services. Multiple organizations are working on operations, administration, and maintenance (OAM) aspects of Ethernet MANs/WANs. OAM is critical once Ethernet is extended beyond the customer premises, especially when multiple transport service providers carry the traffic. In a multiple carrier environment, for example, the OAM is crucial for determining the locations of problems and degradations when they occur. It is not clear how the different OAM proposals in the different bodies will be resolved. From a transport network provider standpoint, this OAM requirement is an area where SONET/SDH really shines. The OAM capabilities inherent in the SONET/SDH backbone allow full monitoring and protection of the transmission facilities and transport path through the SONET/SDH network.



Table 1 Standards activity relating to Ethernet transport

Organization Activities Status IEEE 802.3ae 10 Gbit Ethernet, which included a WAN PHY

interface to simplify interfacing to a SONET/SDH or G.709 OTN network

Approved

802.17 Resilient Packet Rings: Working on a ring-based network for access and metro applications

In progress

802.1ah (EFM)

Ethernet Last Mile, where work includes OAM aspects for Ethernet Links, specially access links

In progress

ITU-T SG15 (With input from ANSI T1X1) G.eota (Q12)

Ethernet over Transport Network Architecture, which deals with requirements for a transport network carrying Ethernet traffic.

The initial version will cover EPL, with approval targeted for Oct. 2003. EVPL, EPLAN, and EVPLAN approval is targeted for 2004.

G.ethna (Q12)

Ethernet Layer Network Architecture, which is largely to translate the IEEE 802 network material into ITU-T transport network terminology and models

Approval targeted for Oct. 2003

G.ethsrv (Q12)

Ethernet over Transport – Ethernet Service Characteristics

Approval targeted for Oct. 2003

G.esm (Q12)

Ethernet over Transport – Ethernet Service Multiplexing, which will cover the multiplexing protocol(s) required to implement EVPL and EVPLAN

Approval targeted for. 2004

G.smc (Q12)

Service Management Channel – private line Approval targeted for. 2004

G.uni (Q11)

Ethernet User Network Interface, which is largely to capture aspects of Ethernet interfaces that are required for interface to a transport network

Approval targeted for May 2004

G.nni (Q11)

Ethernet over transport Network Node Interface, which will capture those aspects required for the interface between transport NEs that carry Ethernet

Approval targeted for May 2004

Q2 Studying Ethernet OAM aspects relating to access In progress ITU-T SG13 Q3 is working on end-to-end and edge-to-edge

aspects of Ethernet OAM In progress

Metropolitan Ethernet Forum (MEF)

MEF is studying various aspects of Ethernet MANs, including service definition and OAM. MEF work is covering all possible OAM flows, such as end-to-end, edge-to-edge, access, inter-provider, intra-provider, etc.

In progress

IETF PWE3 WG

Working on defining an Ethernet transport over IP/MPLS using Martini drafts. This is mainly EVPL service using UDP, L2TP or MPLS as multiplexing layer

In progress

IETF PPVPN WG

Working on defining EVPLAN service using IP/MPLS.

In progress



3 Types of Transport Networks for Ethernet Transport As noted in the introduction, there are four types of Ethernet transport architectures. These types are discussed in this section. Of these architectures, only Ethernet Private Line will be covered in the first phase of the ITU-T G.eota recommendation. Since reaching consensus on some of the aspects of Ethernet Virtual Private Line, Ethernet Private LAN, and especially Ethernet Virtual Private LAN which requires additional work, these architectures will be added to G.eota in a later phase. Some of the issues are listed in the discussions of these three architectures. PMC-Sierra’s ARROW 2xGE and ARROW 24xFE devices were developed and optimized for the EPL and EPLAN architectures.

3.1 Ethernet Private Line (EPL)

EPL, as illustrated in Figure 1, consists of point-to-point Ethernet connections using reserved, dedicated bandwidth. With EPL, the transport network effectively looks like a “piece of wire” from the Ethernet client perspective. From the transport network provider standpoint, however, it also provides the performance monitoring capabilities required for guaranteeing the service level agreement with the customer. The most typical customer to carrier interface is expected to be a native Ethernet signal between the CPE and the carrier’s CLE. The CLE will typically be a MSPP. There are three general methods for providing EPL transport service.

1. Encapsulate the Ethernet client data frames and carry them through the transport network.

2. Re-encode the client’s Layer 1 signal for more efficient transport while maintaining Layer 1 transparency.

3. Carry the client’s Layer 1 signal as a native entity (possibly mapped into a transport protocol channel).

The third method is only really defined for the 10 Gbit/s Ethernet WAN-PHY signal (10GBASE-W). The 10GBASE-W signal was designed to have the same frame structure and nominal bit rate as a SONET OC-192 (SDH STM-64) signal. Due to differences in the clock accuracy specifications between 10GBASE-W and SONET/SDH, it is not typically possible to carry the 10GBASE-W signal through a SONET/SDH network unless the 10GBASE-W clock is upgraded to SONET/SDH accuracy. It is possible, however, to carry a 10GBASE-W signal through a G.709 OTN as an ODU2 payload.

The second method uses a GFP option known as transparent GFP (GFP-T). Of the Ethernet signals, it is only applicable to Gigabit Ethernet, which uses an 8B/10B Layer 1 line code. GFP-T mappings also exist for other signals including Fibre Channel, ESCON, and FICON. GFP-T translates the 8B/10B line code characters into more efficient 64B/65B block codes, with groups of these 64B/65B codes sent in each GFP-T frame. The code translation is done such that control commands that are encoded as special 8B/10B characters are preserved.

The first method is the most general method and may be used with Ethernet signals of any rate (as long as line code-based control code transparency is not required). Although X.86 could also be used in this application, the preferred encapsulation protocol is frame-mapped GFP (GFP-F).



GFP-F is the only encapsulation method described in G.eota. With this method, each Ethernet MAC frame (minus its preamble and start of frame delimiter) is encapsulated into a GFP-F frame.

After encapsulation, the stream of GFP-F frames is then inserted into a SONET/SDH (or OTN) channel.2 This SONET/SDH channel will typically use VCAT to match the transport channel size as close as possible to the client signal information rate. (See Section 4.) This channel is dedicated to that client, at the rate agreed to for the service.

Figure 1 Ethernet Private Line

SONET/SDH or OTN

Carrier NetworkCustomerEquipment

EthernetPHY

CarrierEquipment

CarrierEquipment

CustomerEquipment

EthernetPHY

As illustrated in Figure 2, a customer can implement a LAN with EPL connections if the CPE provides the bridging/switching functions and just uses the carrier network for connectivity.

Figure 2 Example of a customer LAN comprised of EPL connections

SONET/SDH or OTNCarrier Network

CustomerEquipment

CustomerEquipment

CustomerEquipment

EthernetPHY

EthernetPHYs

EthernetPHYs

a) Mesh example


CustomerEquipment

CustomerEquipment

CustomerEquipment

EthernetPHY

EthernetPHY

EthernetPHY

b) Hub-and-spoke example

2 There has been a recent agreement to define a GFP-F mapping for DS3 and DS1 signals. See [4] for the initial DS3/DS1 mapping proposal.



3.2 Ethernet Virtual Private Line (EVPL)

EVPL is essentially an EPL service where the data streams from multiple customers share a common transport network resource. The shared resource is typically the bandwidth of a transport channel where the sharing allows an increase in transport network bandwidth efficiency through statistical multiplexing of the client data frames. The resource can similarly include the switch fabric bandwidth of switches/routers in the transport network. An example of EVPL with shared bandwidth is shown in Figure 3, in contrast to an EPL configuration in which TDM is used to give each customer its own dedicated bandwidth.

Figure 3 EVPL example contrasted to EPL

SONET/SDH or OTN

Carrier Network

Customer AEquipment

EthernetPHY

CarrierEquipment

CarrierEquipment

Customer AEquipment

EthernetPHY

Customer BEquipment

Customer BEquipment

a) EPL for two customers, each with their own TDM channel

SONET/SDH or OTN

Carrier Network

Customer AEquipment

EthernetPHY

CarrierEquipment

CarrierEquipment

Customer AEquipment

EthernetPHY

Customer BEquipment

Customer BEquipment

b) EVPL for two customers where they share a TDM channel for increased efficiency

Although the potential exists for increase bandwidth efficiency and for reducing the number interface ports on transport network switches, there are a number of issues that complicate EVPL. Issues to be resolved with the EVPL portion of the G.eota standard include:

�� How are the different customer data streams tagged to identify and logically separate the different customer data flows?

�� Is the bandwidth specified on the basis of peak information rate (PIR), or a committed information rate (CIR) that allows the customers to potentially burst up to some PIR? (If CIR=PIR, then there is no opportunity for statistical multiplexing gain.)

�� If statistical multiplexing is performed for increased bandwidth efficiency, how will frame discard be handled during congestion (e.g., discard eligibility and policy)?



�� How is the service rate specified if the customer Ethernet interfaces on different ends of the transport network use different native rates (e.g., 10BASE on one end and 100BASE on the other)?

�� How is security guaranteed such that errors or faults won’t lead to one customer’s data in the shared channel being accidentally sent to another customer? (This security is guaranteed with EPL due to each customer having its own dedicated channel.)

3.3 Ethernet Private LAN (EPLAN)

An EPLAN provides LAN-type connectivity between multiple customer sites through dedicated channels. Figure 4 illustrates some of the different basic transport network topologies that can support this service. From the customer viewpoint, these topologies are equivalent (i.e., the carrier network architecture is transparent to the customer). In Options 1 and 3, the carrier does the switching at the edge of the network. Option 3 does the switching at one end of the network rather than at each end. In Option 2, the traffic is brought to a centralized switch (or a number of centralized switch points) in a star connection. Since the switching is performed at Layer2 in these examples, an MSPP can be used to implement Options 1 and 3.

Open issues to be resolved for the EPLAN portion of G.eota include:

�� How do the customer and carrier specify the bandwidth requirements? For example, if the traffic was evenly distributed among the different customer nodes, the bandwidth between nodes could be specified on the basis of CIR. The more realistic scenario, however, is that multiple customer nodes will want to simultaneously communicate with a single node (e.g., remote sites communicating with a headquarters office). A safe policy would be to reserve enough bandwidth for each node to simultaneously receive data at full rate from each other node; however, this would too inefficient to be practical.

�� Closely related to the above issue, how much buffering must the carrier provide to handle congestion, and what will the discard policy be?

�� Is protection handled at Layer 1 (e.g., SONET APS) or Layer 2?

Figure 4 Ethernet Private LAN


CustomerEquipment

CustomerEquipment

CustomerEquipment

EthernetPHY

EthernetPHY

EthernetPHY

a) Option 1 – mesh connectivity



SONET/SDHor OTN

CarrierNetwork

CustomerEquipment

CustomerEquipment

CustomerEquipment

EthernetPHY

EthernetPHY

EthernetPHY

b) Option 2 – traffic hauled to a centralized switching point(s)


CustomerEquipment

CustomerEquipment

CustomerEquipment

EthernetPHY

EthernetPHY

EthernetPHY

- Carrier Equipment

c) Option 3 – edge node serves as a bridge

3.4 Ethernet Virtual Private LAN (EVPLAN)

EVPLAN is a combination of EVPL and EPLAN. The channel bandwidth is shared among different customers (as in Figure 3b), as are switches and/or routers in the carrier network. Ultimately, the sharing of bandwidth in the transmission channels and switch fabrics give EVPLAN the potential for very cost-effective carrier network resource use. Clearly, however, EVPLAN is the most complicate network architecture to administer. The open issues for G.eota regarding EVPLAN architectures include all of those already discussed for EVPL and EPLAN; although, the magnitude of some of these issues is greatly increased for EVPLAN, which in turn restricts some of the potential solution space. For example, the tagging mechanism to differentiate the data from different customers and the different data flows within each customer data stream must have an adequately large address space. (E.g., the 4K address space of VLAN tags, and their applicability to only Ethernet frames, makes them impractical for EVPLANs.)



4 Importance of Virtual Concatenation (VCAT) SONET/SDH channel sizes were originally defined to support legacy TDM telephony signals (e.g., DS1, DS3, E1, E3, and E4). None of these rates is a good match, however, for standard LAN data rates (e.g., 10BASE and 100BASE Ethernet). In addition, many WAN applications would like to make use of sub-rate connections in which the customer bases its WAN channel bandwidth on its anticipated throughput requirements rather than on the full rate of the LAN. Ideally, a customer could specify its WAN channel size with some reasonable bandwidth increments. In the case of EVPL and EVPLAN, the bandwidth increments can be handled as part of the statistical multiplexing (i.e., as logical increments rather than physical channel size changes). For EPL and EPLAN, however, the bandwidth increases must be handled by changing the size of the TDM channel that the customer’s data occupies. Virtual concatenation is the key to efficiently carrying both full-rate and sub-rate WAN connections.

The nomenclature for VCAT is as follows.

�� VTn-Xv is the LO virtual concatenation of X SONET VTns (e.g., VT1.5-6v),

�� VC-n-Xv is the LO virtual concatenation of X SDH VCs for n = 11,12, 2, and 3 (e.g., VC-12-5v),

�� STS-1-Xv or STS-Nc-Xv are the HO virtual concatenation of SONET STS-1s or STS-Ncs (e.g., STS-1-2v),

�� VC-4-Xv is the HO virtual concatenation for SDH VC-4s (e.g., VC-4-7v).

HO virtual concatenation is a good fit for most high speed, full-rate LAN connections. For example, SONET STS-1-2v provides a channel of nearly 100 Mbit/s that can be used with GFP for 100BASE Ethernet connections. Also, STS-3c-7v (VC-4-7v) provides a very efficient fit for Gigabit Ethernet (GE). The large increments (≈50 Mbit/s for STS-1 and ≈150 Mbit/s for SDH) limit the usefulness of HO virtual concatenation for incremental bandwidth adjustment.

The PMC-Sierra ARROW 2xGE maps two GE interfaces into SONET/SDH HO virtual concatenation channels at either full- or sub-rate. With its integrated GE MAC and its GFP and PoS mapping options, it is ideally suited for high speed EPL and EPLAN applications.

LO virtual concatenation is ideally suited for 10BASE Ethernet and sub-rate WAN connections from a 100BASE Ethernet. (Also, at 100.8 Mbit/s, a VT1.5-63v is the most efficient VCAT channel that is guaranteed to carry the full rate of 100BASE Ethernet. The STS-1-2v has a bandwidth of 96.768 Mbit/s, which can only accommodate a 100BASE connection if a sufficient number if inter-packet Idle bits can be removed when the data is mapped into the STS-1-2v channel.) VT1.5-7v (which provides an 11.2 Mbit/s channel) is the most efficient full-rate mapping for 10BASE Ethernet. Sub-rate mappings from 1.6 Mbit/s through 102.4 Mbit/s at 1.6 Mbit/s increments are possible by virtually concatenating VT1.5s.

Applications that use HO virtual concatenation will often be full-rate services. For 100BASE, and especially for GE, the WAN connection is typically between customer routers or switches that have already performed a substantial degree of traffic aggregation. As a result, the WAN



connection will typically be mostly filled. For 10BASE customer interfaces, however, the customer-side Ethernet will typically only connect to one or two computers. With so few computers generating traffic, the WAN link utilization will be much lower and tend to be bursty. For this reason, there will typically be more opportunity and reason to use sub-rate channels for 10BASE and some 100BASE connections. LO virtual concatenation allows creating sub-rate WAN channels with the fine, 1.6 Mbit/s channel size increment granularity. LCAS (Link Capacity Adjustment Scheme) provides an ideal mechanism for adjusting the bandwidth of such a VCAT channel. In response to a provisioning change, LCAS controls the actual bandwidth change of the VCAT channel without corrupting any customer data packets during the adjustment. Thus, LO virtual concatenation combined with LCAS will allow a carrier to provide the customer with a cost-effective, efficient channel that can be easily increased or decreased in size, as the customer needs change.

The PMC-Sierra ARROW 24xFE has been developed to address the lower speed access applications. It provides integrated Ethernet MACs for up to 24 10BASE and/or 100BASE interfaces and maps the Ethernet into SONET/SDH channels using either GFP or PoS. LO virtual concatenation and HO virtual concatenation are both supported, with LCAS available to handle the type of sub-rate bandwidth adjustments just described.



5 Conclusions With Ethernet’s dominance as a LAN technology, it seems logical to also base WAN services through the public transport network on Ethernet. The flurry of standards activity indicate that this conclusion is shared by carriers and equipment vendors, who see considerable new revenue potential in Ethernet WAN connectivity. Due to the complexity of providing virtual connections through transport networks, leased-line EPL and EPLAN services will provide the starting point for Ethernet transport services. EVPL and EVPLAN services will come along as the necessary standards are defined and mature. Carriers, who are not in a position to build massive new overlay networks, will need to utilize their existing SONET/SDH networks for data transport. Virtual concatenation with LCAS (especially for LO virtual concatenation) and the GFP encapsulation method are the key technologies that enable efficient use of the SONET/SDH backbone networks.



6 Glossary CIR Committed Information Rate – the guaranteed bandwidth for a customer connection

CLE Customer Located Equipment – equipment owned by the carrier or service provider that is physically located on the customer premise

EPL Ethernet Private Line

EPLAN Ethernet Private LAN

EVPL Ethernet Virtual Private Line

EVPLAN Ethernet Virtual Private LAN

GE Gigabit Ethernet (1000BASE)

GFP Generic Framing Procedure – ITU-T G.7041 technique for the encapsulation of native client data (including Ethernet MAC frames) for transport through a SONET/SDH or OTN network

HO High Order–SONET STS-1s/STS-Ncs or SDH VC-4s (and VC-3 in some cases).

LAPS Link Access Procedure –SDH – A byte-stuffed HDLC-based mapping technique for mapping Ethernet frames into SDH

LCAS Link Capacity Adjustment Scheme – A mechanism for controlling a bandwidth provisioning change to a VCAT channel such that no customer data corruption (hits) occur during the bandwidth change.

LO Low Order–SONET VTs or SDH VC-1/2 (and VC-3s in some cases).

MSPP Multi-Service Provisioning Platform – The terminal multiplexer (or ADM) typically used to map the customer data into the SONET/SDH or OTN channel

PHY Physical layer interface

PIR Peak Information Rate – the peak bandwidth allowed for a customer connection

PoS Packet over SONET/SDH – A data mapping technique that uses PPP for Layer 2 and byte-stuffed HDLC for mapping the data into SONET/SDH channels.

SLA Service Level Agreement – The quality of service type of agreement between the carrier and the customer

TDM Time Division Multiplexed

VCAT Virtual Concatenation

VCG Virtually Concatenated Group


7 References [1] ITU-T Recommendation G.7041/Y.1303 Generic Framing Procedure (GFP), (S. Gorshe - technical

editor).

[2] ITU-T Recommendation G.707/Y.1322 Network node interface for the Synchronous Digital Hierarchy (SDH)

[3] T1.105 Synchronous Optical Network (SONET) -Basic Description including Multiplex Structure, Rates and Formats

[4] draft ITU-T Recommendation G.eota Ethernet over Transport Network Architecture, (S. Gorshe technical editor)

[5] ITU-T Recommendation G.7042/Y.1305 Link Capacity Adjustment Scheme (LCAS) for virtually concatenated signals

[6] T1X1.5/2003-036, A Proposed Mapping for GFP into DS3 and DS1 signals, standards contribution by S. Gorshe, PMC-Sierra, June 2003

17

Head Office: PMC-Sierra, Inc. #105 - 8555 Baxter Place

To order documentation, send email to: [email protected]

All product documentation is available on our web site at: http://www.pmc-sierra.com/

© Copyright PMC-Sierra, Inc. 2003.

Burnaby, B.C. V5A 4V7 Canada Tel: 604.415.6000 Fax: 604.415.6200

or contact the head office, Attn: Document Coordinator

http://www.pmc-sierra.com/processors/http://www.pmc-sierra.com/serdes/ For corporate information, send email to: mailto:[email protected]

PMC-2030897 (1.0)

All rights reserved.

ethernet transport services – the current state of the art

Documents