Ericsson CPP Platform

8/12/2019 Ericsson CPP Platform

http://slidepdf.com/reader/full/ericsson-cpp-platform 1/8

Why IP transport?The world of telecommunications is charac-terized by change. Yesterday’s dominanttraffic type—voice—is being superceded bydata traffic. In future telecommunicationsnetworks, voice will occupy only a small

portion of bandwidth. This will put new de-mands on the networks, which will have tobe packet-oriented and at the same time ableto handle delay-sensitive traffic, such asvoice and video (video conferencing). ATMtechnology has long been considered the so-lution to quality of service (QoS) in net-works, but several areas of concern have sincebeen identified in large and growing net-works. These are

• scalability—the cost of the extra ATMlayer makes it difficult for ATM vendorsand operators to increase the link speedabove 1 Gbit/s;

• administration and maintenance—inlarge ATM networks, the number of per-manent virtual circuits (PVC) for routerinterconnections increases significantly,and thus the administration and mainte-nance of these PVCs becomes a major issuewhen networks need to be upgraded. Asimilar problem exists in pure IP net-works, but the addition of ATM does notsimplify matters. In this sense, ATM is anextra layer that greatly increases com-plexity; and

• cost—for example, the cost of having tosupport and maintain two kinds of net-work equipment.

These issues have become a driving force forintroducing IP routing into telecommuni-cations networks.

The Internet boom has been accompaniedby increased investments in IP technology,and a lot of effort has gone into solvingquality-of-service and routing administra-

tion issues. Multiprotocol label switching(MPLS), differential services (DiffServ, BoxB), multiclass extension (MCE), and headercompression have made it possible to replaceATM with pure IP networks. And CPP iswell positioned to handle the new environ-ment (as well as the transition to it).DiffServ and MCE will be implemented inthe first IP release of CPP, and the archi-tecture is ready to make use of MPLS.

68 Ericsson Review No. 2, 2002

CPP—Cello packet platform

Lars-Örjan Kling, Åke Lindholm, Lars Marklund and Gunnar B. Nilsson

CPP is a carrier-class technology that has been positioned for access andtransport products in mobile and fixed networks. It is an execution andtransport platform with specified interfaces for application design. Theexecution part consists of support for the design of application hardwareand software. The transport part, which can be seen as an internal appli-cation on the execution platform, consists of several protocols for com-munication, signaling, and ET transmission. Typical applications on cur-rent versions of CPP include third-generation nodes—RBSs, RNCs, mediagateways, and packet-data service nodes/home agents. CPP was firstdeveloped for asynchronous transfer mode ATM and TDM transport . Now,support is being added for IP transport.

The authors describe the technical and customer benefits of adding IPsupport in CPP, walking the reader through the basic principles for IP ser-vices in CPP and the CPP IP architecture, which is very robust and scal-able.

API Application program interface ATM Asynchronous transfer modeBGP Border gateway protocolCPP Cello packet platformDiffServ Differential servicesE1/J1/T1 PDH transmission frame formats

for 2 Mbit/s (E1) or 1.5 Mbit/s(J1/T1) transmission rates

ET Exchange terminalFIB Forwarding information baseHA Home agentIP Internet protocol

IPv4, IPv6 IP version 4, IP version 6MCE Multiclass extensionMGW Media gatewayMPLS Multiprotocol label switchingO&M Operation and maintenanceOC3 Optical carrier 3 (155 Mbit/s)OSPF Open shortest path first

PBA Printed board assemblyPDSN Packet-data service nodePPP Point-to-point protocolPVC Permanent virtual circuitQoS Quality of serviceRBS Radio base stationRIP Routing information protocolRNC Radio network controllerRSVP-TE Resource reservation protocol –

traffic engineeringSCTP Stream control transmission

protocol

SIGTRAN Signaling transportSS7 Signaling system no. 7STM-1 SDH transmission frame format for

155 Mbit/sTCP Transmission control protocolTDM Time-divis ion multiplexingUDP User datagram protocol

BOX A, TERMS AND ABBREVIATIONS



Ericsson Review No. 2, 2002 69

Who are the customers?The introduction of IP in telecommunica-

tions networks will commence in the corenetwork in response to demands for large,high-speed networks. Datacom vendors arecurrently trying to grab as many marketshares as they can. At present, these vendorscan solely offer pure IP router products.Therefore, network operators can either opt

to integrate telecommunications equip-ment and IP routers themselves or they canbuy complete site solutions from a telecom-

munications vendor. Over time, the IP mi-gration will extend further and further fromthe core network into the access network.

Ericsson knows that operators want vendorsto come up with solutions and migration sto-ries that are cost-effective and easy to main-tain (Figure 2). The introduction of IP in

Applicationsowninterfaces

IP links ATM linksTDM links

IP links betweenCello nodes and• Ethernet• PPP• IP• UDP• TCP• SCTP• M3UA • SCTP

Applications

Cello nodeCello node

Cello platform• Switching• Control system• O&M• Transport

Operator interface

Node hardwareand softwareinterfaces

Figure 1A network view of the Cello packet plat-form (CPP) including transport protocols.

GSM/UMTS/GPRScore network

BSC

GSM-BSS

UTRAN

RNC

PLMN

PSTN/ ŁISDN

Internet/ intranets

MGW

SGSN

MGW

GMSCserver

MSCserver

HLR

Telecomapplications

IP ATM

BB

GGSN

User trafficSignaling

Figure 2A telecommunications network with differ-ent types of backbone and access net-

works.




Traditional routers serve packets on a first-come-first-served basis. Since no differentia-tion is made with respect to the actualdemands put on the delivery times of packetflows, this is often called best-effort service. Ina best-effort network, packet flows that carrydelay-sensitive voice receive the same serviceas packet flows that carry, say, a file transfer.

Different approaches have been proposedto solve this shortcoming. According to oneapproach, called the IntServe model, a flowmust reserve resources in the routers on thepath before packets can be sent. If sufficientnetwork resources are not available, the flowis denied. An implication of IntServ is thatevery router in the network must store a per-flow state. This was seen as a major drawbackand led to the introduction of a lightweightmodel called differentiated services (DiffServ).The DiffServ model is based on the followingbasic principles:• A limited number of service classes is

defined for specific purposes. Theseclasses differ in terms of maximum delay ormaximum drop probability.

• At the edge of a network, packets aremarked in the header to reflect the serviceclass to which the packet flow belongs.

• The routers in the network serve thepackets according to its service class.

In principle, packet flows that belong to thesame service class are merged into a com-

mon aggregated flow. The routers see theseaggregated flows, but not individual packetflows.

A packet enters a classifier, where theservice class mark is inspected. Dependingon the mark, the packet is sent to one ofseveral queues via an enqueuer . Dependingon the filling in the queue, the packet mightbe discarded by the enqueuer according to abuffer management algorithm. Using ascheduling algorithm, a scheduler fetchespackets one-by-one from the queues.

The buffer management and schedulingalgorithms are configured to guarantee aspecific per-hop-behavior for each serviceclass, of which there are three standardclasses: One best-effort class (BE) and twoassured-forwarding classes (AF). Eachassured-forwarding class is guaranteed a cer-tain minimum bandwidth at which the queuesare served. Excess bandwidth is distributed toother classes. The best-effort class is servedonly if there are no packets in the otherqueues. If a queue is almost full, incomingpackets to that queue are discarded in a

pseudo-random fashion.In terms of resources, the DiffServ modelcauses the network to behave as if a few dif-ferent logical networks were separated fromeach other. For example, one logical networkcould be used for voice traffic and another forfile transfers.

BOX B, DIFFERENTIATED SERVICES

E T - F M b o a

r d

M P b o a

r d

M P b o

a r d

E T - F M b o

a r d S T M

- 1

S T M - 1

E 1 / J 1 /

T 1

E 1 / J 1 /

T 1

M P b o

a r d

D P b o a r d

S p a c e

s w i t c h

M S B b

o a r d

M S B b

o a r d

F M

F M

F M

F M

E T - F M

b o a r d

F M

F M

F M

Routing protocols

IP security control

IP security encryption

IP host

IP host

Media streamdevice

SIGTRAN

IP hostGigabitEthernet

Figure 3Embedded and distributed IP router.




telecommunications networks adds yet an-other transport protocol. Today operators arestruggling with the migration from TDM toATM. Later, when operators introduce IP,they will have to consider even more complexnetworks. Ericsson can offer telecommunica-tions nodes with built-in transport capabili-ties for TDM, ATM and IP. Operators canthus capitalize on their installed base, espe-cially in mobile networks. Likewise, Ericssonknows that network operators want a compactand cost-effective solution that has a consis-tent network-management interface. Ericssonwill thus make pure IP routers obsolete in op-erator networks. CPP is the ideal choice of car-rier-class technology for all telecommunica-tions nodes in the access network, includingthe edge nodes to the core backbone.

Basic principlesSix basic principles for the IP services in CPPadd value:• embedded and distributed IP router by

means of routing protocols in the mainprocessor cluster and distributed for-

warding on all device boards (Figure 3);• fully distributed forwarding of IPv4 or

IPv6 modules can be implemented inhardware or software. A hardware imple-mentation can handle wire-speed trans-port (Figure 4);

• internal IP hosts can be located on a sin-gle printed board assembly (PBA) andconnected to the IP router via the localforwarding module on the PBA (Figure5). The IP host provides the applicationprogram interface (API);

• the internal hosts are IP end-systems thatare visible and addressable from the ex-ternal network and from within the node(Figure 5);

• a CPP node can house multiple virtualrouters. In this case, each IP interface inthe node is configured to belong to onespecific virtual router; and

• CPP has built-in support for signalingsystem no. 7 (SS7) signaling gatewayfunctionality by means of a complete SS7stack for SIGTRAN, IP, ATM and TDM(Figure 6).

ArchitectureThe CPP IP architecture is composed of sev-eral subsystems that interwork with eachother through well-defined interfaces (Fig-ure 7). The IP forwarding subsystem pro-vides fully distributed forwarding of IPv4

GPB

MPhost FM

FM

FM

FM

Support for wire-speed user databy means of hardware support inthe forwarding modules

Host 1

Host n

CPP node

ET-board

Application board

UDP/IP termination support

ET-board

Figure 4Fully distributed IP forwarding.

SCCP

NIF

MTP3bSAAL AAL5 ATMLayer 1

MTP3MTP2

TDMLayer 1

M3UA SCTPIPLayer 2Layer 1

Figure 6Built-in support for signaling gateway.

BP

FM

All hosts communicate viathe local forwarding module

Host 1

Host 2

Host 3

Host 4

Host x

CPP node

Application board

All hosts have their own IP

address and are visible inthe IP network

Figure 5Multiple internal IP hosts.



and IPv6 packets. Forwarding modules(Box C) implemented in software or in ded-icated hardware circuits can be put on anyboard in the CPP system and are intercon-nected by the CPP space switch. Hardware-

based forwarding modules can achieve wire-speed forwarding. The IP forwarding sub-system also includes packet classificationand filtering, including DiffServ queuing.

To forward an IP packet, the forwardingmodules need a forwarding table that is cal-culated in the IP routing subsystem usingstatic (configured) routes and dynamic rout-ing protocols, such as the open shortest pathfirst (OSPF), routing information protocol(RIP), and border gateway protocol (BGP).The routing protocol handlers monitor thenetwork topology, and the routing tablemanager calculates a forwarding table atstart-up and when the network topologychanges. Forwarding information from theIP routing subsystem (Box D) is communi-cated to all forwarding modules in the CPPnode using the dedicated forwarding infor-mation base (FIB) interface.

Telecommunications applications thatuse CPP IP transport services need to ter-minate and originate large amounts of IPtraffic that comes from or is sent to the IPnetwork. The IP access subsystem enablesapplications to use IP hosts in CPP. A user

can access multiple IP hosts on every proces-sor board in the system: each host is identi-fied by a unique IP address. The hosts canhandle IPv4 and IPv6, user datagram pro-tocol (UDP), transmission control protocol(TCP), and stream control transmission pro-tocol (SCTP) termination. If necessary, thehosts can be made robust by means of themoveable host concept (see also section onRobustness).

An automatic configuration mechanismsimplifies host configuration. The IP accesssubsystem uses the IP forwarding subsystemto send and receive packets. For low-speedapplications, CPP provides a distributedhost mechanism whereby one IP host withone IP address can be distributed and usedon multiple processor boards.

IP transport is also used for highly confi-dential traffic, such as control signaling andoperation and maintenance (O&M) traffic.To guarantee the integrity of this traffic, theIP security subsystem provides tunnel- andtransport-mode encryption and decryptionof IP packets. The IP security encryp-tion/decryption engines can be distributedon multiple processors or dedicated hard-

ware circuits to yield greater capacity.The CPP architecture has been prepared

for the introduction of MPLS—CPP canserve as a label edge router or label switchrouter. However, modifications will need tobe made to the forwarding modules, and ad-


Forwarding modules implement the function-ality needed to forward or terminate an IPpacket. They also provide the functionality forresolving dependencies on connected routers(the data part) and hosts (the control part).

Figure 8 shows the data part of a wire-speed forwarding module. Most of the func-tionality is implemented in dedicated hard-ware or network processors. In addition, anexception handler executes on a standardprocessor. The exception handler provides thefunctionality needed for dealing with someinfrequent packet types. If, during any step inthe forwarding process, an exception is identi-fied, the packet is handed over to the excep-tion handler.

Packets enter the forwarding module froman incoming link. Each packet is classifiedaccording to the type of service it requires.

This classification might involve meteringactual load. The type-of-service field in thepacket might be changed as a result of theclassification. The classification also serves asa sort of firewall, and might result in havingthe packet dropped.

The packet is next analyzed to find out if it

should be terminated in the node. If so, apoint of termination in the node is determinedand the packet is put into one of severalqueues to the switch. Otherwise, the packet isfurther analyzed to determine• the best next hop in the network; and• various related parameters. One parameter

contains the outgoing link and the point inthe node where the forwarding moduleresponsible for this link is located.

The packet is then put into one of the switchqueues. After having passed the switch, thepacket arrives at the forwarding module ofthe appointed outgoing link where it enters asecond classification step, which might resultin the packet being assigned a differentclass.

Finally, the packet enters the queuing sys-tem to the outgoing link. The queuing system

has several queues served by a configurable,weighted, fair-queuing scheduler. The systemalso has advanced dropping mechanisms tohandle overload situations on the link. Thetreatment a packet receives in the queuingsystem is determined by the class to whichthe packet has been assigned.

BOX C, FORWARDING MODULES

O A M

O A M

O A M

O A M

O A M O A M

O A M

O A M

I P r o u t i n g

I P f o r w a r d i n g

I P a c c e s s

I P a p p l i c a t i o n s

A T M a p p l i c a t i o n s

I P s e c u r i t y

M P L S I P l i n k l a y e r

P h y s i c a l l i n k

A T M

t r a n s p o r t s e r v i c e s

C P P p la t form

Figure 7The CPP IP architecture.




ditional signaling protocols will be intro-duced, including the

• resource reservation protocol – traffic en-gineering (RSVP-TE); and

• CR-LDP.Likewise, interworking will be introducedbetween IP routing and MPLS.

Together with the physical layer sub-system, the IP link layer subsystem providesaccess to the external network. For example,the IP link layer subsystem supports10/100 Mbit Ethernet, Gigabit Ethernet,point-to-point protocol (PPP), IP overATM, and frame relay. Likewise, the phys-ical layer supports STM-1/OC3, E1/J1/T1and Ethernet. The IP link layer functional-ity is connected to the IP forwarding sub-system using the generic link interface.

ScalabilityCPP is uniquely scalable. It can be used insmall applications (such as a small RBS) aswell as large RNC and media gateway nodes.Indeed, virtually every aspect of scalabilityis covered by CPP: high-end and low-endnodes, payload capacity, processing capaci-ty, number of routes, route updating capac-ity, number of physical links, link capacity,

and cost.In general, the IP functionality of CPP is

composed of central functions and localfunctions. A central function solely exists inone instance for each virtual IP router,whereas a local function might exist in sev-

eral instances. With few exceptions, thescaling of local functions is quite straight-

forward. By contrast, the scaling of a centralfunction is an intricate matter since centralfunctions have a single, consistent informa-tion base. Distribution is not precluded butmust be accomplished without incurringexcessive costs in terms of memory and ca-pacity.

Payload handling capacity

CPP forwarding is based on interacting for-warding modules. Each forwarding moduleis a local function that handles a number of links and interfaces. Each processing entity(processor) and printed board assembly hasits own forwarding and link module, whichmeans that forwarding and link capacity arenot adversely affected when new hardwareis added. The only potential bottleneck isthe intercommunication capacity of the for-warding module, which is based on the CPPspace switch. At present, the capacity with-in the subrack is 16 Gbit/s, which is suffi-cient to support some 400,000 IP-bornevoice calls. Moreover, multiple subracks canbe interconnected to form very large nodesthat constitute a single coherent system. Aswith forwarding, IP access mainly consists

of local functions and scales smoothly whennew hardware is added.

Forwarding information base

The number of routes to be handled direct-ly affects the size of the forwarding infor-

C l a s s i f i c a t i o

n

m e t e r i n g

F o r w a r d i n g m

o d u l e

C l a s s i f i c a t i o n

m e t e r i n g

C l a s s i f i c a t i o n

m e t e r i n g

T e r m i n a t i o n

a n a l y s i s

T e r m i n a t i o n

a n a l y s i s

F o r w a r d i n g

F o r w a r d i n g

S w i t c h

q u e u e

E x c e p t i o n

h a n d l e r

S w i t c h

L i n k q u e u e

L i n k

Figure 8Internal architecture of the forwardingmodule.



mation base (FIB). A very large FIB makesit unfeasible to house the entire forwardingtable in fast path-forwarding logic. There-fore, CPP provides a caching scheme whichforwards packets that fall outside the scopeof the cache. At present, the fast path-forwarding path supports up to 64,000routes.

Routing protocols

The central functions that demand the mostprocessing power in CPP are the routingprotocol handlers (OSPF, BGP and so on).A shortage of processing power for routingresults in unacceptably long convergencetime—that is, the time it takes to regener-ate a routing table when the topology haschanged.

Certain measures affecting network layerconfiguration can significantly reduce theprocessing load on the individual routers.These measures are hierarchical networktopology, appropriate address allocation,route summarization, and area subdivision.CPP supports these measures as well as scal-ability at the node level.

Allocation of routing protocol handlers

Different routing protocol handlers (RPH)can be allocated to different processors.Every RPH is mastered by a single routingtable manager. However, other scaling so-lutions are necessary when a single RPH re-quires more capacity than can be providedby one processor.

Adding a virtual router

Where the network is concerned, the addi-tion of a virtual router is no different fromthe addition of a physical router. In eithercase, the network becomes more complexand the RPHs must work harder to keeptrack of the network topology. The advan-tages in the local node are that the interfacescan be partitioned between virtual routers,and functions that belong to different vir-tual routers can be allocated to differentprocessors. In addition, costs can be avoid-ed provided that the virtual-router inter-connecting link is implemented efficiently.

Distributing a single RPH

A single RPH can be distributed to someextent by allocating certain sub-functions todifferent processors. The exact allocation of sub-functions varies according to the typesof routing protocol in use. For OSPF, theshortest path calculation must be executedin one processor, whereas the handling of in-terfaces can be distributed.

Low- end scalability

For CPP to meet the requirements of radiobase stations it must support low-end scal-ability. As a consequence, the CPP IP ar-chitecture has been designed to accommo-date IP functionality on a single PBA andto eliminate the switch. Another feature isthe FIB caching mechanism mentionedabove. These features keep the cost of fastforwarding-path logic to a minimum evenin relatively complex networks with multi-ple routes.

RobustnessThe fully distributed IP-forwarding and IP-termination mechanisms in CPP are very ro-bust. The failure of a board solely affects theforwarding and termination of IP packets onthat board. All other boards continue for-warding and terminating as if nothing hadhappened, except that packets are not for-warded to the failed board. Should a net-work interface board or link fail, the rout-ing protocols initiate link protectionswitching or automatic rerouting.

The robustness principles applied in CPPmake it possible to define reliable programs

that execute in the main processor cluster.These programs can be run on a standbyprocessor should the main processor fail. TheCPP IP functionality employs this fail-overconcept for all central functions, such as therouting protocols, the central parts of IP ac-


The Internet is made up of severalautonomous systems (AS), each of which isoperated by an Internet service provider(ISP) or an organization (Figure 9). Intelecommunications, each IP-based radioaccess network or core network can be seenas an autonomous system. Interior gatewayrouting protocols, such as RIP, OSPF or IS-IS, are used inside autonomous systems toautomatically create forwarding tables to beused by the routers.

OSPF is one of the most popular interiorgateway protocols. This link state routing pro-tocol discovers its neighboring routers and

learns their network addresses by sending out‘Hello’ packets on all its interfaces. The infor-mation it receives is stored in a topology data-base. OSPF then sends out a link state adver-tisement (LSA) packet indicating the status ofits own links. The LSAs are ‘flooded’ by theother routers in order to reach every router in

the AS. Based on this input, OSPF calculatesthe shortest path to all routers and builds anoptimal forwarding table. Whenever a changein network topology takes place—that is, if alink or a router goes down—new LSAs areflooded through the autonomous system.OSPF in each router updates the topologydatabase and recalculates the forwardingtable.

Some autonomous systems can be verylarge and difficult to manage. Likewise, theLSA flooding can generate a heavy load in alarge autonomous system. To reduce load andsimplify management, OSPF allows

autonomous systems to be divided into OSPFareas. Routers connected to one area needonly have detailed knowledge about the topol-ogy of that area. All areas in an autonomoussystem are interconnected by the backbonearea. The routers connected to more than onearea are called area border routers.

BOX D, IP ROUTING




cess, IP security, IP forwarding, and allO&M functions. Should the processor onwhich the routing protocols execute fail,then the routing protocols are simply trans-ferred to the standby processor. In the in-terim, while the protocols are being trans-ferred and a new forwarding table is beingbuilt, the forwarding of packets on all otherboards continues uninterrupted using themost recent forwarding table.

In coming releases of CPP, the standbyrouting protocol will operate in a listeningmode and maintain an updated standbyrouting table.

The internal hosts in CPP, which appli-cations use for terminating and originat-ing IP traffic, can be distributed on anyprocessor board in a CPP node. Each hostis identified by a unique IP address. Shoulda board fail, CPP automatically transfersthe host (and IP address) to another board.At the same time, the forwarding table isrecalculated and traffic destined for thehost is forwarded to the new location.

If an application requires it to do so, CPPcan configure a robust Ethernet IP interface

that uses a primary and secondary physicalport. Should the primary port fail, the sec-ondary port is activated using the IP addressthat the primary port had.

ConclusionEricsson knows that operators want vendorsto offer solutions and migration stories thatare cost-effective and easy to maintain. Con-sequently, Ericsson offers telecommunica-tions nodes with built-in transport capabil-ities for TDM, ATM and now, IP. Ericssonalso knows that network operators want acompact and cost-effective solution that hasa consistent network-management inter-face. Accordingly, Ericsson will make pureIP routers obsolete in operator networks.

The CPP IP architecture is composed of several subsystems that interwork with eachother through well-defined interfaces:• The IP forwarding subsystem provides

fully distributed forwarding of IPv4 andIPv6 packets.

• The IP routing subsystem calculates a for-warding table, which forwarding modulesuse to forward IP packets.

• The IP access subsystem enables applica-tions to use IP hosts in CPP.

• An automatic configuration mechanismsimplifies host configuration.

• The IP security subsystem guarantees theintegrity of sensitive traffic.

The CPP architecture has been prepared forthe introduction of MPLS—CPP can serveas a label edge router or label switch router.Interworking will be introduced between IProuting and MPLS. Together with the phys-ical layer subsystem, the IP link layer sub-system provides access to the external net-work.

CPP is uniquely scalable. It can be usedin small applications and large RNC andmedia gateway nodes. Virtually every aspectof scalability is covered by CPP: high-endand low-end nodes, pay-load capacity, pro-cessing capacity, number of routes, routeupdating capacity, number of physicallinks, link capacity, and cost.

The fully distributed IP-forwarding andIP-termination mechanisms in CPP are veryrobust. The robustness principles applied inCPP make it possible to define reliable pro-grams that execute in the main processorcluster.

Backbone area

Backbone area

Area 1

AS

RR

R

R

RR

R

R R

R

R

R

AS

BGP

Area 2

Figure 9Example of section of the Internet consisting of two autonomous systems (AS), where oneAS is divided into three OSPF areas. The border gateway protocol (BGP) is used to convey

routing information between the two autonomous systems.

Documents

Ericsson CPP Platform