Internet protocol cisco

8/7/2019 Internet protocol cisco

1/40

December 2010 Volume 13, Number 4

A Quarterly Technical Publication orInternet and Intranet Proessionals

In This Issue

From the Editor ...................... 1

Emergency Services ................. 2

Integrating CoreBGP/MPLS Networks .......... 18

Letter to the Editor ............... 32

Book Review......................... 33

Fragments ............................. 37

F r o m T h e E d i t o r

I have recently started using both a smartphone and a tablet deviceor Internet access. Like millions o other Internet users, I have dis-covered the wonders o mobile applications that provide everythingrom the traditional Internet services (e-mail and web browsing) tospecialized sotware that can pinpoint my location on a map, pro-vide live currency-exchange calculations, give weather orecasts, andmy avorite: play radio stations rom all over the world. I am oldenough to remember the orange glow rom pre-transistor vacuum-tube radios, so having a customizable world radio in the orm o an

app on a smartphone seems almost like science ction.

But radio is not the only traditional service that is now availableover the Internet. Another prominent example is telephony or Voiceover IP (VoIP). Not only is VoIP replacing traditional land lines inmany places, the original circuit-switched telephone network is itselincreasingly using VoIP technology in place o an inrastructure oland lines and dedicated switching equipment. An important aspecto traditional phone service is the notion o special numbers or emer-

gency services. Such systems rely on a database o phone numbers andaddresses that allow emergency personnel to dispatch responders tothe correct location. This location identication becomes a lot more

complicated i the caller is using an Internet-based calling service ratherthan a hard-wired telephone. The IETF has been tackling this prob-lem in the Emergency Context Resolution with Internet Technology(ECRIT) working group. Our rst article, by Hannes Tschoenig andHenning Schulzrinne, is an overview o the architecture this workinggroup is developing.

According to the ITU-T, a Next Generation Network (NGN) is...a packet-based network which can provide services includingTelecommunication Services and is able to make use o multiple broad-band, Quality o Service-enabled transport technologies in whichservice-related unctions are independent rom underlying transport-

related technologies. Paul Veitch, Paul Hitchen, and Martin Mitchelldescribe the integration o a standalone core BGP/MPLS VPN net-work into an NGN architecture.

Please check your subscription expiration date and renew online iyou wish to continue receiving this journal. Click the SubscriberServices link atwww.cisco.com/ipj to get to the login page. I youneed any assitance just send e-mail to [email protected] and we willmake the necessary changes or you.

Ole J. Jacobsen, Editor and [email protected]

You can download IPJback issues and nd

subscription inormation at:www.cisco.com/ipj

ISSN 1944-1134


2/40

The Internet Protocol Journal

2

Emergency Services for Internet Multimediaby Hannes Tschoenig, Nokia Siemens Networks and Henning Schulzrinne, Columbia University

Summoning the police, the re department, or an ambulancein emergencies is one o the most important unctions thetelephone enables. As telephone unctions move rom circuit-

switched to Internet telephony, telephone users rightully expect that

this core eature will continue to be available and work as well as ithas in the past. Users also expect to be able to reach emergency assis-tance using new communication devices and applications, such asinstant messaging or Short Message Service (SMS), and new media,such as video. In all cases, the basic objective is the same: The personseeking help needs to be connected with the most appropriate PublicSaety Answering Point(PSAP), where call takers dispatch assistanceto the callers location. PSAPs are responsible or a particular geo-graphic region, which can be as small as a single university campusor as large as a country.

The transition to Internet-based emergency services introduces two

major structural challenges. First, whereas traditional emergencycalling imposed no requirements on end systems and was regulatedat the national level, Internet-based emergency calling needs globalstandards, particularly or end systems. In the old Public SwitchedTelephone Network (PSTN), each caller used a single entity, the lan-dline or mobile carrier, to obtain services. For Internet multimediaservices, network-level transport and applications can be separated,with the Internet Service Provider (ISP) providing IP connectivity ser-vice, and a Voice Service Provider (VSP) adding call routing and PSTNtermination services. We ignore the potential separation between theInternet access provider, that is, a carrier that provides physical anddata link layer network connectivity to its customers, and the ISPthat provides network layer services. We use the term VSP or sim-plicity, instead o the more generic term Application Server Provider(ASP).

The documents that the IETF Emergency Context Resolution withInternet Technology (ECRIT) working group is developing supportmultimedia-based emergency services, and not just voice. As isexplained in more detail later in this article, emergency calls need tobe identied or special call routing and handling services, and theyneed to carry the location o the caller or routing and dispatch. Onlythe calling device can reliably recognize emergency calls, while onlythe ISP typically has access to the current geographical location othe calling device based on its point o attachment to the network.The reliable handling o emergency calls is urther complicated bythe wide variety o access technologies in use, such as Virtual PrivateNetworks (VPNs), other orms o tunneling, rewalls, and NetworkAddress Translators (NATs).


3/40


3

This article describes the architecture o emergency services as de-ned by the IETF and some o the intermediate steps as end systemsand the call-handling inrastructure transition rom the current cir-cuit-switched and emergency-calling-unaware Voice-over-IP (VoIP)systems to a true any-media, any-device emergency calling system.

IETF Emergency Services Architecture

The emergency services architecture developed by the IETF ECRITworking group is described in [1] and can be summarized as ollows:Emergency calls are generally handled like regular multimedia calls,except or call routing. The ECRIT architecture assumes that PSAPsare connected to an IP network and support the Session InitiationProtocol(SIP)[2] or call setup and messaging. However, the callinguser agent may use any call signaling or instant messaging protocol,which the VSP then translates into SIP.

Nonemergency calls are routed by a VSP, either to another subscribero the VSP, typically through some SIP session border controller orproxy, or to a PSTN gateway. For emergency calls, the VSP keepsits call routing role, routing calls to the emergency service system toreach a PSAP instead. However, we also want to allow callers that donot subscribe to a VSP to reach a PSAP, using nothing but a standardSIP[2] user agent (see [3] and [4] or a discussion about this topic);the same mechanisms described here apply. Because the Internet isglobal, it is possible that a callers VSP resides in a regulatory juris-diction other than where the caller and the PSAP are located. In suchcircumstances it may be desirable to exclude the VSP and provide adirect signaling path between the caller and the emergency network.This setup has the advantage o ensuring that all parties included inthe call delivery process reside in the same regulatory jurisdiction.

As noted in the introduction, the architecture neither orces norassumes any type o trust or business relationship between the ISPand the VSP carrying the emergency call. In particular, this designassumption aects how location is derived and transported.

Providing emergency services requires three crucial steps, which wedescribe in the ollowing sections: recognizing an emergency call,determining the callers location, and routing the call and locationinormation to the appropriate emergency service system operatinga PSAP.

Recognizing an Emergency Call

In the early days o PSTN-based emergency calling, callers would diala local number or the re or police department. It was recognizedin the 1960s that trying to nd this number in an emergency causedunacceptable delays; thus, most countries have been introducing singlenationwide emergency numbers, such as 911 in North America, 999in The United Kingdom, and 112 in all European Union countries.


4/40


4

This standardization became even more important as mobile devicesstarted to supplant landline phones. In some countries, dierenttypes o emergency services, such as police or mountain rescue, areidentied by separate numbers. Unortunately, more than 60 di-erent emergency numbers are used worldwide, many o which alsohave nonemergency uses in other countries, so simply storing thelist o numbers in all devices is not easible. In addition, hotels anduniversity campuses oten use dial prexes, so an emergency caller insome European universities may actually have to dial 0112 to reachthe re department.

Because o this diversity, the ECRIT architecture decided to separatethe concept o an emergency dial string, which remains the amiliarand regionally dened emergency number, and a protocol identierthat is used or identiying emergency calls within the signaling system.The calling end system has to recognize the emergency (service) dialstring and translate it into an emergency service identier, which isan extensible set o Uniorm Resource Names (URNs) dened inRFC 5031[5]. A common example or such a URN, dened to reachthe generic emergency service, is urn:service.sos. The emergencyservice URN is included in the signaling request as the destinationand is used to identiy the call as an emergency call. I the end systemails to recognize the emergency dial string, the VSP may also perormthis service.

Because mobile devices may be sold and used worldwide, we wantto avoid manually conguring emergency dial strings. In general, adevice should recognize the emergency dial string amiliar to the userand the dial strings customarily used in the currently visited country.The Location-to-Service Translation Protocol(LoST)[6], described inmore detail later, also delivers this inormation.

Some devices, such as smartphones, can dene dedicated user inter-ace elements that dial emergency services. However, such mechanismsmust be careully designed so that they are not accidentally triggered,or example, when the device is in a pocket.

Emergency Call Routing

When an emergency call is recognized, the call needs to be routed tothe appropriate PSAP. Each PSAP is responsible or only a limitedgeographic region, its service region, and some set o emergency ser-vices. For example, even in countries with a single general emergencynumber such as the United States, poison-control services maintain

their own set o call centers. Because VSPs and end devices cannotkeep a complete up-to-date mapping o all the service regions, a map-ping protocol, LoST[6], maps a location and service URN to a specicPSAP Uniorm Resource Identifer (URI) and a service region.

Emergency Services: continued


5/40


5

LoST, illustrated in Figure 1, is a Hypertext Transer Protocol(HTTP)-based query/response protocol where a client sends a requestcontaining the location inormation and service URN to a server andreceives a response containing the service URL, typically a SIP URL,the service region where the same inormation would be returned, andan indication o how long the inormation is valid. Both request andresponse are ormatted as Extensible Markup Language (XML). Foreciency, responses are cached, because otherwise every small move-ment would trigger a new LoST request. As long as the client remainsin the same service region, it does not need to consult the server againuntil the response returned reaches its expiration date. The responsemay also indicate that only a more generic emergency service isoered or this region. For example, a request or urn:service:sos.marine in Austria may be replaced by urn:service:sos. Finally, theresponse also indicates the emergency number and dial string or therespective service.

The number o PSAPs serving a country varies signicantly. Sweden,or example, has 18 PSAPs, and the United States has approximately6,200. Thereore, there is roughly one PSAP per 500,000 inhabit-ants in Sweden and one per 50,000 in the United States. As all-IPinrastructure is rolled out, smaller PSAPs may be consolidated intoregional PSAPs. Routing may also take place in multiple stages,with the call being directed to an Emergency Services Routing Proxy(ESRP), which in turn routes the call to a PSAP, accounting or actorssuch as the number o available call takers or the language capabili-ties o the call takers.

Figure 1: High-Level Functions

of Location-to-Service Translation

(LoST) Protocol

Location Information+

Service URN

Emergency Number+

Service URN+

(PSAP) URI+

Service Boundary

L o S T

Location Inormation

Emergency services need location inormation or three reasons:

routing the call to the right PSAP, dispatching rst responders (orexample, policemen), and determining the right emergency servicedial strings. It is clear that the location must be automatic or therst and third applications, but experience has shown that auto-mated, highly accurate location inormation is vital to dispatchingas well, rather than relying on callers to report their locations to thecall taker.


6/40


6

Such inormation increases accuracy and avoids dispatch delayswhen callers are unable to provide location inormation because olanguage barriers, lack o amiliarity with their surroundings, stress,or physical or mental impairment.

Location inormation or emergency purposes comes in two repre-sentations: geo(detic), that is, longitude and latitude, and civic, thatis, street addresses similar to postal addresses. Particularly or indoorlocation, vertical inormation (foors) is very useul. Civic locationsare most useul or xed Internet access, including wireless hotspots,and are oten preerable or speciying indoor locations, whereas geo-detic location is requently used or cell phones. However, with theadvent o emto and pico cells, civic location is both possible andprobably preerable because accurate geodetic inormation can bevery hard to acquire indoors.

In almost all cases, location values are represented as PresenceInormation Data Format Location Object(PIDF-LO), an XML-baseddocument to encapsulate civic and geodetic location inormation. The

ormat o PIDF-LO is described in [7], with the civic location or-mat updated in [8] and the geodetic location ormat proled in [9].The latter document uses the Geography Markup Language (GML)developed by the Open Geospatial Consortium (OGC) or describingcommonly used location shapes.

Location can be conveyed either by value (LbyV) or by reerence(LbyR). For the ormer, the XML location object is added as amessage body in the SIP message. Location by value is particularlyappropriate i the end system has access to the location inormation;or example, i it contains a Global Positioning System (GPS) receiveror uses one o the location conguration mechanisms described later

in this section. In environments where the end host location changesrequently, the LbyR mechanism might be more appropriate. In thiscase, the LbyR is an HTTP/Secure HTTP (HTTPS) or SIP/Secure SIP(SIPS) URI, which the recipient needs to resolve to obtain the currentlocation. Terminology and requirements or the LbyR mechanism areavailable in [10].

An LbyV and an LbyR can be obtained through location cong-uration protocols, such as the HTTP Enabled Location Delivery(HELD) protocol[11] or Dynamic Host Confguration Protocol(DHCP)[12, 13]. When obtained, location inormation is required orLoST queries, and that inormation is added to SIP messages[14].

The requirements or location accuracy dier between routing anddispatch. For call routing, city or even county-level accuracy is otensucient, depending on how large the PSAP service areas are, whereasrst responders benet greatly when they can pinpoint the caller to aparticular building or, better yet, apartment or oce or indoor loca-tions, and an outdoor area o at most a ew hundred meters. Thisdetailed location inormation avoids having to search multiple build-ings, or example, or medical emergencies.



7/40


7

As mentioned previously, the ISP is the source o the most accurateand dependable location inormation, except or cases where the call-ing device has built-in location capabilities, such as GPS, when itmay have more accurate location inormation. For landline Internetconnections such as DSL, cable, or ber-to-the-home, the ISP knowsthe provisioned location or the network termination, or example.The IETF GEOPRIV working group has developed protocol mecha-nisms, called Location Confguration Protocols, so that the end hostcan request and receive location inormation rom the ISP. The BestCurrent Practice document or emergency calling[15] enumerates threeoptions that clients should universally support: DHCP civic[16] andgeo[12] (with a revision o RFC 3825 in progress [17]), and HELD[11].HELD uses XML query and response objects carried in HTTPexchanges. DHCP does not use the PIDF-LO ormat, but rather morecompact binary representations o locations that require the endpointto construct the PIDF-LO.

Particularly or cases where end systems are not location-capable,a VSP may need to obtain location inormation on behal o theend host[18].

Obtaining at least approximate location inormation at the time othe call is time-critical, because the LoST query can be initiated onlyater the calling device or VSP has obtained location inormation.Also, to accelerate response, it is desirable to transmit this locationinormation with the initial call signaling message. In some cases,however, location inormation at call setup time is imprecise. Forexample, a mobile device typically needs 15 to 20 seconds to get anaccurate GPS location x, and the initial location report is basedon the cell tower and sector. For such calls, the PSAP should be ableto request more accurate location inormation either rom the mobile

device directly or the Location Inormation Server (LIS) operated bythe ISP. The SIP event notication extension, dened in RFC 3265[19],is one such mechanism that allows a PSAP to obtain the locationrom an LIS. To ensure that the PSAP is inormed only o pertinentlocation changes and that the number o notications is kept to aminimum, event lters[20] can be used.

The two-stage location renement mechanism described previouslyworks best when location is provided by reerence (LbyR) in the SIPINVITE call setup request. The PSAP subscribes to the LbyR pro-vided in the SIP exchange and the LbyR reers to the LIS in the ISPsnetwork. In addition to a SIP URI, the LbyR message can also contain

an HTTP/HTTPS URI. When such a URI is provided, an HTTP-basedprotocol can be used to retrieve the current location[21].

Obligations

This section discusses the requirements the dierent entities need tosatisy, based on Figure 2. A more detailed description can be oundin [15].


8/40


8

Note that this narration ocuses on the nal stage o deployment anddoes not discuss the transition architecture, in which some imple-mentation responsibilities can be rearranged, with an eect on theoverall unctions oered by the emergency services architecture. Aew variations were introduced to handle the transition rom the cur-rent system to a ully developed ECRIT architecture.

Figure 2: Main Components Involved in an Emergency Call

DistributedMapping Database

PSAPESRPESRP

VSP

LIS

ISP

EmergencyServices

IP Network

(a)

(d)(c)

(b) (b)

With the work on the IETF emergency architecture, we have tried tobalance the responsibilities among the participants, as described in

the ollowing sections.

End Hosts

An end host, through its VoIP application, has three main respon-sibilities: it has to attempt to obtain its own location, determinethe URI o the appropriate PSAP or that location, and recognizewhen the user places an emergency call by examining the dial string.The end host operating system may assist in determining the devicelocation.

The protocol interaction or location conguration is indicated asinterace (a) in Figure 2; numerous location conguration protocols

have been developed to provide this capability.

A VoIP application needs to support the LoST protocol [6] in orderto determine the emergency service dial strings and the PSAP URI.Additionally, the device needs to understand the service identiers,dened in [5].



9/40


9

As currently dened, it is assumed that SIP can reach PSAPs, butPSAPs may support other signaling protocols, either directly orthrough a protocol translation gateway. The LoST retrieval resultsindicate whether other signaling protocols are supported. To pro-vide support or multimedia, use o dierent types o codecs may berequired; details are available in [15].

ISP

The ISP has to make location inormation available to the endpointthrough one or more o the location conguration protocols.

In order to route an emergency call correctly to a PSAP, an ISP mayinitially disclose the approximate location or routing to the endpointand give more precise location inormation later, when the PSAP oper-ator dispatches emergency personnel. The unctions required by theIETF emergency services architecture are restricted to the disclosureo a relatively small amount o location inormation, as discussed in[22] and in [23].

The ISP may also operate a (caching) LoST server to improve therobustness and reliability o the architecture. This server lowers theround-trip time or contacting a LoST server, and the caches are mostlikely to hold the mappings o the area where the emergency caller iscurrently located.

When ISPs allow Internet trac to traverse their network, the signal-ing and media protocols used or emergency calls unction withoutproblems. Today, there are no legal requirements to oer prioriti-zation o emergency calls over IP-based networks. Although thestandardization community has developed a range o Quality oService (QoS) signaling protocols, they have not experienced wide-

spread deployment.

VSP

SIP does not mandate that call setup requests traverse SIP proxies;that is, SIP messages can be sent directly to the user agent. Thus, evenor emergency services it is possible to use SIP without the involve-ment o a VSP. However, in terms o deployment, it is highly likelythat a VSP will be used. I a caller uses a VSP, this VSP oten orcesall calls, emergency or not, to traverse an outbound proxy or SessionBorder Controller (SBC) operated by the VSP. I some end devicesare unable to perorm a LoST lookup, VSP can provide the necessaryunctions as a backup solution.

I the VSP uses a signaling or media protocol that the PSAP does notsupport, it needs to translate the signaling or media fows.

VSPs can assist the PSAP by providing identity assurance or emer-gency calls; or example, using [30], thus helping to prosecute prankcallers. However, the link between the subscriber inormation andthe real-world person making the call is weak.


10/40


10

In many cases, VSPs have, at best, only the credit card data or theircustomers, and some o these customers may use git cards or otheranonymous means o payment.

PSAP

The emergency services Best Current Practice document [15] dis-cusses only the standardization o the interaces rom the VSP andISP toward PSAPs and some parts o the PSAP-to-PSAP call transermechanisms that are necessary or emergency calls to be processed bythe PSAP. Many aspects related to the internal communication withina PSAP, between PSAPs as well as between a PSAP and rst respond-ers, are beyond the scope o the IETF specication.

When emergency calling has been ully converted to Internet proto-cols, PSAPs must accept calls rom any VSP, as shown in interace(d) o Figure 2. Because calls may come rom all sources, PSAPsmust develop mechanisms to reduce the number o malicious calls,particularly calls containing intentionally alse location inormation.Assuring the reliability o location inormation remains challenging,particularly as more and more devices are equipped with GlobalNavigation Satellite Systems (GNSS) receivers, including GPS andGalileo, allowing them to determine their own location[24]. However,it may be possible in some cases to check the veracity o thelocation inormation an endpoint provides by comparing it againstinrastructure-provided location inormation; or example, a LIS-determined location.

Mapping Architecture

So ar we have described LoST as a client-server protocol. Similarto the Domain Name System (DNS), a single LoST server does notstore the mapping elements or all PSAPs worldwide, or both tech-

nical and administrative reasons. Thus, there is a need to let LoSTservers interact with other LoST servers, each covering a specic geo-graphical region. Working together, LoST servers orm a distributedmapping database, with each server carrying mapping elements, asshown in Figure 3. LoST servers may be operated by dierent enti-ties, including the ISP, the VSP, or another independent entity, such asa governmental agency. Typically, individual LoST servers oer thenecessary mapping elements or their geographic regions to others.However, LoST servers may also cache mapping elements o otherLoST servers either through data synchronization mechanisms (orexample, FTP or exports rom a Geographical Inormation System[GIS] or through a specialized protocol[25]) or by regular usage o

LoST. This caching improves perormance and increases the robust-ness o the system.



11/40


11

Figure 3: Mapping Element

expires

lastUpdated

source

sourceId

displayName

service

uri

serviceNumber

serviceBoundary

Unique identification of amapping element

Entity (e.g., PSAP or ESRP)

the call has to be routed to

Dial string corresponding tothe indicated service

Geographical area for whichall subsequent requests willlead to the same results

Lifetime of the mapping

Human readabledescription of the mapping

Service URN usedfor this mapping

A detailed description o the mapping architecture with examples isavailable in [29].

Steps Toward an IETF Emergency Services Architecture

The architecture described so ar requires changes both in already-deployed VoIP end systems and in the existing PSAPs. The speedo transition and the path taken vary between dierent countries,depending on unding and business incentives. Thereore, it is gener-ally dicult to argue whether upgrading endpoints or replacing theemergency service inrastructure will be easier. In any case, the transi-tion approaches being investigated consider both directions. We candistinguish roughly our stages o transition (Note: The ollowingdescriptions omit many o the details because o space constraints):

Initially, VoIP end systems cannot place emergency calls at all;1.or example, many sotware clients, such as GoogleTalk, cannotplace emergency calls.

In a second stage, VoIP callers manually congure their location,2.and emergency calls are routed to the appropriate PSAP as circuit-switched calls through PSTN gateways using technologies similarto mobile calls. This level o service is now oered in some countriesor PSTN-replacement VoIP services; that is, VoIP services that areoered as replacement or the home phone. In the United States,this service is known as the NENA I2 service.

In a third stage, PSAPs maintain two separate inrastructures,3.

one or calls arriving through an IP network and the traditionalinrastructure.

In the nal stage, all calls, including those rom traditional cell4.phones and analog landline phones, reach the PSAP through IPnetworks, with the traditional calls converted to the ECRITrequirements by the carriers or the emergency service inra-structure.


12/40


12

I devices are used in environments without location services, theVSPs SIP proxy may need to insert location inormation based onestimates or subscriber data. These cases are described briefy in theollowing sections.

Traditional Endpoints

Figure 4 shows an emergency services architecture with traditionalendpoints. When the emergency caller dials the Europeanwide emer-gency number 112 (step 0), the device treats it as any other callwithout recognizing it as an emergency call; that is, the dial stringprovided by the endpoint that may conorm to RFC 4967[26] or RFC3966[27] is signaled to the VSP (step 1). Recognition o the dial stringis then let to the VSP or processing or sorting; the same is true orlocation retrieval (step 2) and routing to the nearest (or appropriate)PSAP (step 3). Dial-string recognition, location determination, andcall routing are simpler to carry out using a xed device and the voiceand application service provided through the ISP than they are whenthe VSP and the ISP are two separate entities.

Figure 4: Emergency Services Architecture with Traditional Endpoints

ESRP

VSP

PSAP

ESINet

LIS

ISP

(4) Session Setup tourn:service:sosrouted via PSAP

(1) Session Setupto 112

(2)LocationRetrieval

(0) Dial 1-1-2

(3)LoSTPr

otoc

olExc

hang

e

DistributedMapping Database

There are two main challenges to overcome when dealing withtraditional devices: First, the VSP must discover the LIS that knowsthe location o the IP-based end host. The VSP is likely to know only

the IP address o that device, visible in the call signaling that arrivesat the VSP. When a LIS is discovered and contacted and some amounto location inormation is available, then the second challenge arises,namely, how to route the emergency call to the appropriate PSAP. Toaccomplish the latter task it is necessary to have some inormationabout the PSAP boundaries available.



13/40


13

Reerence [15] does not describe a complete and detailed solutionbut uses building blocks specied in ECRIT. Still, this deploymentscenario shows many constraints:

Only the emergency numbers congured at the VSP are under-stood. This situation may lead to cases where a dialed emergencynumber is not recognized.

Using the IP address to nd the ISP is challenging and may, in case

o mobility protocols and VPNs, lead to wrong results.

Security concerns might arise when a potentially large number oVSPs or ASPs are able to retrieve location inormation rom anISP. It is likely that only authorized VSP and ASPs will be grantedaccess. Hence, it is unlikely that such a solution would worksmoothly across national boundaries.

When the user agent does not recognize the emergency call, unc-tions such as call waiting, call transer, three-way call, fash hold,and outbound call blocking cannot be disabled.

The user-agent sotware may block callbacks rom the PSAP.

Privacy settings may not get considered and identity may get dis-closed to unauthorized parties. These identity privacy eatures existin some jurisdictions even in emergency situations.

Certain VoIP call eatures may not be supported, such as REFER(or conerence call and transer to secondary PSAP) and GloballyRoutable UA URI(GRUU).

User agents will not convey location inormation to the VSP (eveni available).

Partially Upgraded End Hosts

A giant step orward in simpliying the handling o IP-based emer-gency calls is to provide the end host with some inormation aboutthe ISP so that LIS discovery is possible. The end host may, or exam-ple, learn the ISPs domain name by using LIS discovery[28], or mighteven obtain a Location by Reerence (LbyR) through the DHCP-URIoption[13] or through HELD[11]. The VSP can then either resolve theLbyR in order to route the call or use the domain to discover a LISusing DNS.

Additional sotware upgrades at the end device may allow or rec-ognition o emergency calls based on some precongured emergencynumbers (or example, 112 and 911) and allow or the implementa-

tion o other emergency service-related eatures, such as disablingsilence suppression during emergency calls.


14/40


14

Outlook

In most countries, national and sometimes regional telecommunica-tions regulators, such as the Federal Communications Commission

(FCC) and individual states, or the European Union, strongly infu-ence how emergency services are provided, who pays or them, andthe obligations that the various parties have. Regulation is, however,still at an early stage: in most countries current requirements demandonly manual update o location inormation by the VoIP user. The

ability to obtain location inormation automatically is, however, cru-cial or reliable emergency service operation, and it is required ornomadic and mobile devices. (Nomadic devices remain in one placeduring a communication session, but are moved requently romplace to place. Laptops with Wi-Fi interaces are currently the mostcommon nomadic devices.)

Regulators have traditionally ocused on the national or, at most,the European level, and the international nature o the Internet posesnew challenges. For example, mobile devices are now routinelyused beyond their country o purchase and, unlike traditional cellu-lar phones, need to support emergency calling unctions. It appearslikely that dierent countries will deploy IP-based emergency servicesover dierent time horizons, so travelers may be surprised to ndthat they cannot call or emergency assistance outside their homecountry.

The separation between Internet access and application providerson the Internet is one o the most important dierences to existingcircuit-switched telephony networks. A side eect o this separationis the increased speed o innovation at the application layer, and thenumber o new communication mechanisms is steadily increasing.Many emergency service organizations have recognized this trend and

advocated or the use o new communication mechanisms, includ-ing video, real-time text, and instant messaging, to oer improvedemergency calling support or citizens. Again, this situation requiresregulators to rethink the distribution o responsibilities, unding, andliability.

Many communication systems used today lack accountability; thatis, it is dicult or impossible to trace malicious activities back tothe persons who caused them. This problem is not new, because payphones and prepaid cell phones have long oered mischie makersthe opportunity to place hoax calls, but the weak user registrationprocedures, the lack o deployed end-to-end identity mechanisms,

and the ease o providing ake location inormation increases theattack surace at PSAPs. Attackers also have become more sophis-ticated over time, and Botnets that generate a large volume oautomated emergency calls to exhaust PSAP resources, including calltakers and rst responders, are not science ction.



15/40


15

Reerences

[1] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Frameworkor Emergency Calling Using Internet Multimedia, InternetDrat, work in progress, draft-ietf-ecrit-framework-11 ,

July 2010.

[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M., and E. Schooler, SIP:

Session Initiation Protocol, RFC 3261, June 2002.

[3] Winterbottom, J., Thomson, M., Tschoenig, H., and H.Schulzrinne, ECRIT Direct Emergency Calling, Internet Drat,work in progress, draft-winterbottom-ecrit-direct-02.txt, March 2010.

[4] Schulzrinne, H., McCann, S., Bajko, G., Tschoenig, H., and D.Kroeselberg, Extensions to the Emergency Services Architectureor Dealing with Unauthenticated and Unauthorized Devices,Internet Drat, work in progress, draft-ietf-ecrit-unau-thenticated-access-00.txt, September 2010.

[5] Schulzrinne, H., A Uniorm Resource Name (URN) orEmergency and Other Well-Known Services, RFC 5031,

January 2008.

[6] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschoenig,LoST: A Location-to-Service Translation Protocol, RFC5222, August 2008.

[7] Peterson, J., A Presence-based GEOPRIV Location ObjectFormat, RFC 4119, December 2005.

[8] Thomson, M. and J. Winterbottom, Revised Civic LocationFormat or Presence Inormation Data Format Location Object(PIDF-LO), RFC 5139, February 2008.

[9] Winterbottom, J., Thomson, M., and H. Tschoenig, GEOPRIVPresence Inormation Data Format Location Object (PIDF-LO)Usage Clarication, Considerations, and Recommendations,RFC 5491, March 2009.

[10] R. Marshall, Requirements or a Location-by-ReerenceMechanism, RFC 5808, May 2010.

[11] M. Barnes, HTTP Enabled Location Delivery (HELD), RFC5985, September 2010.

[12] Polk, J., Schnizlein, J., and M. Linsner, Dynamic HostConguration Protocol Option or Coordinate-based LocationConguration Inormation, RFC 3825, July 2004.


16/40


16

[13] Polk, J., Dynamic Host Conguration Protocol (DHCP) IPv4and IPv6 Option or a Location Uniorm Resource Identier(URI), Internet Drat, work in progress, draft-ietf-geo-priv-dhcp-lbyr-uri-option-08 , July 2010.

[14] Polk, J., Rosen, B., and J. Peterson, Location Conveyance orthe Session Initiation Protocol, Internet Drat, work in prog-ress, draft-ietf-sipcore-location-conveyance-03 , July

2010.

[15] Rosen, B. and J. Polk, Best Current Practice or CommunicationsServices in Support o Emergency Calling, Internet Drat, workin progress, draft-ietf-ecrit-phonebcp-15 , July 2010.

[16] Schulzrinne, H., Dynamic Host Conguration Protocol(DHCPv4 and DHCPv6) Option or Civic AddressesConguration Inormation, RFC 4776, November 2006.

[17] Polk, J., Schnizlein, J., Linsner, M., and B. Aboba, DynamicHost Conguration Protocol Option or Coordinate-based

Location Conguration Inormation, Internet Drat, work inprogress, draft-ietf-geopriv-rfc3825bis-11 , July 2010.

[18] Winterbottom, J., Thomson, M., Tschoenig, H., and R. Barnes,Use o Device Identity in HTTP-Enabled Location Delivery(HELD), Internet Drat, work in progress, draft-ietf-geo-priv-held-identity-extensions-04 , June 2010.

[19] Roach, A., Session Initiation Protocol (SIP)-Specic EventNotication, RFC 3265, June 2002.

[20] Mahy, R., Rosen, B., and H. Tschoenig, Filtering Location

Notications in the Session Initiation Protocol, Internet Drat,work in progress, draft-ietf-geopriv-loc-filters-11 ,March 2010.

[21] Winterbottom, J., Tschoenig, H., Schulzrinne, H., Thomson,M., and M. Dawson, A Location Dereerencing ProtocolUsing HELD, Internet Drat, work in progress, draft-ietf-geopriv-deref-protocol-01, September 2010.

[22] Schulzrinne, H., Liess, L., Tschoenig, H., Stark, B., and A. Kuett,Location Hiding: Problem Statement and Requirements,Internet Drat, work in progress, draft-ietf-ecrit-loca-tion-hiding-req-04, Feb 2010.

[23] Barnes, R., and M. Lepinski, Using Imprecise Location orEmergency Context Resolution, Internet Drat, work in prog-ress, draft-ietf-ecrit-rough-loc-03 , August 2010.



17/40


17

[24] Tschoenig, H., Schulzrinne, H., and B. Aboba, TrustworthyLocation Inormation, Internet Drat, work in progress,draft-tschofenig-ecrit-trustworthy-location-00,September 2010.

[25] Schulzrinne, H., and H. Tschoenig, Synchronizing Location-to-Service Translation (LoST) Servers, Internet Drat, work inprogress, draft-ietf-ecrit-lost-sync-10 , March 2010.

[26] B. Rosen, Dial String Parameter or the Session InitiationProtocol Uniorm Resource Identier, RFC 4967, July 2007.

[27] H. Schulzrinne The tel URI or Telephone Numbers, RFC3966, December 2004.

[28] Thomson, M. and J. Winterbottom, Discovering the LocalLocation Inormation Server (LIS), RFC 5986, September2010.

[29] H. Schulzrinne, Location-to-URL Mapping Architecture and

Framework, RFC 5582, September 2009.

[30] C. Jennings, J. Peterson, and M. Watson, Private Extensions tothe Session Initiation Protocol (SIP) or Asserted Identity withinTrusted Networks, RFC 3325, November 2002.

HENNING SCHULZRINNE, Levi Proessor o Computer Science at ColumbiaUniversity, received his Ph.D. rom the University o Massachusetts in Amherst,Massachusetts. He was an MTS at AT&T Bell Laboratories and an associatedepartment head at GMD-Fokus (Berlin) beore joining the Computer Science andElectrical Engineering departments at Columbia University. He served as chair oComputer Science rom 2004 to 2009. Protocols that he co-developed, such as RTP,RTSP, and SIP, are now Internet standards, used by almost all Internet telephony andmultimedia applications. His research interests include Internet multimedia systems,ubiquitous computing, and mobile systems. He is a Fellow o the IEEE. E-mail:[email protected]

HANNES TSCHOFENIG received a Diploma degree rom the University oKlagenurt, Austria. He joined Siemens Corporate Technology, Munich, in 2001and joined Nokia Siemens Networks in April 2007 to move to Finland in December2007, where he ocuses on standards development. Most o his time is dedicated tothe participation in the Internet Engineering Task Force (IETF) where he, amongother responsibilities, co-chaired the ECRIT working group rom 2005 to early2010. Additionally, he co-chairs the Next Generation 112 Technical Committee o

the European Emergency Number Association (EENA) and contributes to the tech-nical specications developed within the National Emergency Number Association(NENA), and he co-organized the SDO emergency services workshop series. InMarch 2010 he joined the Internet Architecture Board (IAB).E-mail: [email protected]


18/40


18

Integration of Core BGP/MPLS VPN Networksby Paul Veitch, Paul Hitchen, and Martin Mitchell, BT Innovate & Design

This article explores the architectural and operationalchallenges involved in integrating an existing standalone coreBorder Gateway Protocol(BGP)/Multiprotocol Label Switch-

ing(MPLS) VPN network onto a target Next-Generation Network

(NGN). The rationale or consolidating and transorming multiplenetworks is explained, mainly in terms o potential cost savings andoperational simplication achieved by the network operator. Thearticle specically ocuses on the MPLS Carrier-supporting-Carrier(CsC) architectural ramework, which allows the serving nodes oone MPLS VPN network to be interconnected through the servingnodes o another MPLS VPN network. The required architecturalbuilding blocks to implement CsC, the manner in which routingprotocols must interact, as well as end-to-end packet fow and labelencapsulation are all explained. The main design and operationalchallenges, including maintaining perormance levels or customers,network resiliency, ault-handling, and capacity management, are

also addressed in this article.

Network operators are under increasing pressure to deliver excep-tional levels o customer experience and service while decreasing thecapital and operational cost base o their networks. Many operatorshave traditionally built multiple network platorms, each o whichhas been uniquely designed to meet the requirements o specic ser-vices targeted at specic customer markets, such as voice, broadbandIP, Virtual Private Networks (VPNs), etc.

In a bid to remain competitive and achieve cost reductions andoperational simplications, many operators have built all IP-based

NGNs. The principal transormational benets o an NGN with asingle protocol such as IP at its heart include versatility in cateringor multiple trac requirements (or example, by employing IPQuality-o-Service [QoS] techniques), the ability to introduce noveland reusable services and eatures in a fexible manner, and thepotential to maximise vendor interworking due to standards-basedtechnology.

When a network operator builds an NGN, the challenge remains asto how to migrate existingnetworks and customers onto the newplatorm. The ull commercial benets o an NGN can be properlyrealised only ater legacy networks are either consolidated orphased out completely. Many important actors must be considered,including the cost benets, the potential eect on end customers,and the operational approach to carrying out migrations. Theseconcerns must be weighed against the commercial and business risksassociated with the alternative approach o sustaining and runningmultiple standalone platorms indenitely.


19/40


19

This article ocuses on a specic scenario: how to integrate an existingBGP/MPLS VPN network that provides VPN services to a corpo-rate customer base with a target NGN. Following a brie overviewo MPLS VPN services and networks, the rationale or consolidat-ing multiple MPLS VPN networks is explained, mainly in terms opotential cost savings and operational simplication achieved by thenetwork operator. The article then details the MPLS CsC architecturalramework that allows the serving nodes or Points o Presence (POPs)o one MPLS VPN network to be interconnected to the serving nodeso another MPLS VPN network. The way in which routing proto-cols must interact and the subsequent eect on end-to-end packetorwarding across a CsC-enabled core network are explained. Theprincipal design and operational challenges introduced by integratingcore MPLS networks are then outlined, including maintaining per-ormance levels, network resiliency, ault management, and capacitymanagement.

The Business Case or MPLS VPN Network Consolidation

VPNs are an attractive solution to serve the enterprise networking

requirements o a wide range o businesses rom Small-to-MediumEnterprises (SMEs) to multinational blue-chip corporate organisa-tions. Essentially, VPNs provide a transparent network inrastructurethat allows multiple customer sites to communicate over a sharedbackbone network, as though they are using their own private net-work, regardless o geographical location. Typical applications thatrun across an organisations VPN include corporate Intranet, mailservices, and Voice-over-IP (VoIP) telephony.

Although distinct categories o VPN networking technology exist[1],this article ocuses exclusively on Layer 3 BGP/MPLS VPNs, asdened in RFC 4364[2] and other related Internet Drats. Such net-

works have been deployed or more than 10 years and have seensignicant growth during that period.

The critical core network elements o a provider-provisioned BGP/MPLS VPN network are Provider Edge (PE) and Provider Core (P)routers, as shown in Figure 1.

PE routers terminate customer access circuits, whereas P routers per-orm packet orwarding and typically do not have directly connectedcustomer access circuits. PE routers perorm label encapsulationand de-encapsulation, P routers run label switching, and both oper-ate control-plane protocols that build MPLS Label Switched Paths

(LSPs) rom each PE to each other PE. Many protocols can be used toestablish these LSPs; a commonly deployed approach uses the LabelDistribution Protocol(LDP) in conjunction with an Interior GatewayProtocol(IGP), such as Open Shortest Path First(OSPF).


20/40


20

Integrating BGP/MPLS Nets: continued

When a PE orwards a VPN-addressed packet across the core, itadds an inner MPLS label to identiy the VPN o which the packetis a member and then an outer MPLS label to identiy the egress PErouter. Any intermediate P routers switch the packet to the egressPE using the outer label only. The egress PE uses the inner label todetermine which VPN or port to orward the packet to.

Figure 1: Overview of BGP/MPLS VPN Network

VPN_B10.2.0.0/16Site 1

VPN_A10.6.0.0/16Site 3

VPN_B10.3.0.0/16Site 2

VPN_A10.4.0.0/16

Site 1

VPN_A10.5.0.0/16

Site 2

VPN_B10.4.0.0/16

Site 3

CE

CE

CE

CE

CE

CE

PE

PE

PE

PE

P

P

P

P

CE to PEPeering

Private Routes ofVPN Customer A

Private Routes ofVPN Customer BVPN A

VPN B

Provider Network

The Customer Edge (CE) router is not considered part o the providerscore network. It acts as a peer o the PE router, but not a peer o otherCE routers. Each PE router supports multiple routing and orwardingtables, called Virtual Route Forwarding(VRF) tables. VRF routes arelogically separate, and they may contain IP prexes received rom theCE router that overlap with addresses in other VRFs. (For example,in Figure 1, VPN_A, site 1 has the same private routes as VPN_B, site3.) VPNs are ormed by dening individual customer accesses to bemembers o a specic VRF table, with several sites ormed on one PEby dening all sites to use the same VRF table or allocating each site aVRF table and controlling connectivity through selective import and

export o the IP routes o each VRF table.

The PE routers use an extended variant o BGP or signaling be-tween themselves and propagating inormation about the actualroutes o each VPN, as well as the inner MPLS label. The extendedBGP, reerred to as Multiprotocol BGP, carries each VPN routetogether with two new elds, the Route Distinguisher (RD) and theRoute Target(RT), a orm o extended BGP Community.


21/40


21

The RD is added to each VPN route to ensure that routes rom dierentcustomers are unique; BGP treats VPN routes as equal only i boththe RD and the IP prex mask are equal. BGP uses RTs to indicatea group o routes, thus dening VPN membership inormation orexchange between PEs.

Maintenance Costs o BGP/MPLS VPN Networks

As detailed in the previous section, the main core components o a

VPN network based on BGP/MPLS technology are the PE and P rout-ers. Although not shown in detail in Figure 1, another critical elemento a core VPN network is the Wide-Area Network (WAN) topol-ogy that interconnects the P (core) routers residing in specic servicenodes, also called POPs. The WAN topology is essentially the way inwhich transmission linkstypically Synchronous Optical Network(SONET)/Packet over SONET/SDH(PoS), Gigabit Ethernet, or 10Gigabit Ethernetare used to interconnect the POPs together.

It ollows that maintenance costs associated with a sel-containedMPLS VPN network will be incurred or PE and P routers, as wellas the interconnecting WAN transmission links. These maintenance

costs will split into capital and operational elements.

Capital expenditures are required on an ongoing basis or all IP routerinrastructure (PE and P routers), or example, to upgrade hardwareto meet increasing capacity demands, replace aulty line cards andprocessors, or replace end-o-lie hardware with newer equipment.Capital expenditures are also needed on WAN links, or example,to replace aulty line cards and optics, as well as to deploy increasedcapacity transmission links to cater or trac growth across the corenetwork. Further capital costs accrue rom accommodation-relatedaspects such as power, racking, and air conditioning.

Additional maintenance costs reside in the operational space. Forexample, i an MPLS VPN network has 40 POP locations, each witha pair o P (core) routers, the 80 core routers will consume a certainamount o operational team resources or critical maintenance, sched-uled maintenance activities, and ongoing monitoring and reportingo router status (processors and line cards).

Benefts o Core Integration

I a network operator has deployed an IP-based NGN alongside anexisting MPLS VPN network, the question should be asked: can theexisting MPLS VPN network be integrated onto the NGN so as toavoid some or all o the previously stated maintenance costs? One

approach would be to target the P (core) routers and WAN trans-mission links or eventual removal (Figure 2) and replacement bysuitable connectivity o the MPLS VPN nodes to the NGN network.The VPN PE routers that oten terminate large volumes o customeraccess circuits and host the rich service-related unctions or corpo-rate VPN services can essentially be let in situ, minimising the eecton end customers and conning the integration o networks to theinner part o the core inrastructure. The way in which this goal canactually be achieved in practice is detailed in the next section.


22/40


22

The main benets that can be accrued or the network operator areas ollows:

Substantial cost avoidance or maintaining and upgrading P (core)routers and dedicated WAN links or the existing MPLS VPNnetwork can be achieved (Figure 2). As much as a 35-percentreduction o xed inner core capital costs is possible.

I the technical solution or core integration can be made as reusable

as possible, then in addition to allowing integration o sameprovider core networks, the network operator could providethe capability on a wholesale basis or other service providers.This capability could be a potentially signicant source o newrevenue.

From an operational perspective, integration o core networksshould lend itsel to a singular and much more streamlinedapproach to capacity planning, ault management, and networkmonitoring.

The combination o all these benets can produce a compelling

business case or network operators to consolidate core MPLS-basednetwork platorms.

Figure 2: MPLS VPN Network Showing Inner Core Components Targeted for Replacement

PEs

PEs TerminateCustomerAccess CCTS

Switches ProvideIntra-PoP Layer 2Aggregation

P Routers Provide Layer 3 Aggregationand Terminate WAN CCTSTo/From Other Nodes

If P Routers and WAN TopologyCan Be Bypassed, Will AvoidAssociated Maintenance Costs

Core Transmission

(e.g., POS, GigE, 10GigE)

Dedicated MPLS VPN CoreTransmission Topology

To Other MPLSVPN Nodes

MPLS VPN PoP MPLS VPN PoP

PEs

P

P

To Other MPLSVPN Nodes

P

P



23/40


23

Carrier-supporting-Carrier Framework

Carrier-supporting-Carrier (CsC) is a term used to describe a situationwhere one network, designated the customer carrier, is permitted touse a segment o another network, designated the backbone carrier[3].Although the term Carrier o Carriers is also used to describe thesame architectural ramework, this article uses Carrier-supporting-Carrier or consistency. In principle, the two carrier networkscould belong to the same organisation, or could belong to two di-

erent organisations. Whatever the case, there is no reason why thebackbone carrier cannot support multiple customer carrier networks.Furthermore, the customer carrier network itsel can be either a BGP/MPLS VPN network providing Layer 3 VPN services or an InternetService Provider (ISP) network[3].

A network operator with an existing BGP/MPLS VPN networkinrastructure that has also built an IP-based NGN based on BGP/MPLS technology as per RFC 4364[2] could choose to exploit theCsC architectural ramework to merge the two core networks. Insuch a scenario, the existing BGP/MPLS VPN network that servesthe needs o VPN business customers would be viewed as the cus-tomer carrier, whereas the NGN network would be positioned asthe backbone carrier.

Physical Connectivity and CsC VRF Creation

In order to integrate an existing BGP/MPLS VPN network such asthat shown in Figure 2, with an NGN core belonging to the sameor dierent organisation, the NGN network must be enabled toact as a backbone carrier. Assuming the NGN network is conguredto support BGP/MPLS VPNs as per RFC 4364[2], it comprises PEand P router core inrastructure. The PE routers o the NGN actingas the backbone carrier are denoted CsC-PEs. The PE routers o

the existing BGP/MPLS VPN network, that is, the customer carriernetwork that is being itsel integrated with the NGN core, are denotedCsC-CEs.

As shown in Figure 3, the NGN backbone carrier network providesMPLS VPN service to the customer carrier network using its ownVRF table enabled on the CsC-PE. One important distinctionbetween normal MPLS VPN service and CsC is the act that tracpassed between the CsC-CE and CsC-PE is labeled rather thannative IP[3, 4].

The CsC architecture is designed such that the backbone carrier net-

workthe network providers NGN networkneeds to know onlyabout internal routes within the customer carrier network. This setupallows ormation o ull any-to-any logical connectivity betweenthe customer carrier routers, which in this scenario are the PE rout-ers o the existing BGP/MPLS VPN network providing VPN servicesto end customers.


24/40


24

Furthermore, the backbone carrier routers themselves do not need toretain route prex inormation or the end-customer VPNs connectedto the customer carrier network because the end-customer trac istransported over a second level o VRF tables that bear relevanceonly to the customer carrier itsel, that is, the endpoint CsC-CEs. Thisnestingo MPLS VPN networks emphasises the inherent scalabilityo the CsC architecture. The CsC backbone carrier is eectivelybehaving like proxy P routers or the customer carrier network.

Figure 3: MPLS VPN Customer Carrier Network Connected Across NGN Backbone Carrier

CsC-CEs

VRF Created forEnd VPN Customer

Connectivity

VRF Created on NGNfor MPLS VPN PoP

Connectivity

Existing Customer CarrierDedicated P and WAN Links

Can Be Decommissioned

NGN Backbone

Carrier Network

MPLS VPN CustomerCarrier Network

MPLS VPN PoP MPLS VPN PoP

CsC-CEs

CsC-PE

CsC-PE

P

P

Switches ProvideIntra-PoP Layer 2

Aggregation

CsC-PE

PP

CsC-PE

P

P

Figure 3 also shows the physical connectivity between the customer

carrier network and backbone carrier NGN. Because many large-scale BGP/MPLS network deployments comprise large numbers oPE devices in the same service node or POP, there is oten a Layer 2Ethernet switch acting as an intra-POP aggregator. It is convenientto allow physical connectivity between the BGP/MPLS VPN servicenode and the CsC-PE in the NGN network using this aggregationswitch. One or more Virtual LANs (VLANs) can be conguredacross this physical trunk to provide logical Layer 2 connectivityinto the CsC-PE on the NGN, and be associated with the CsC VRFon that device. The Layer 2 switch also provides direct intra-POPconnectivity between CsC-CEs present on the same VLANs.

Control-Plane Routing ProtocolsThe previous section described the physical connectivity betweenBGP/MPLS VPN service nodes and the target NGN, with creationo a specic VRF route on the CsC-PEs. This section addresses theway in which the internal routes o the CsC-CEs (that is, the PErouters belonging to the customer carrier BGP/MPLS VPN network)are advertised into this VRF table.



25/40


25

Optional routing protocols include the use o an IGP such as OSPF,or Exterior Gateway Protocols (EGPs) such as BGP. With an IGPlike OSPF[5], the routing protocol itsel is used or route exchangebetween the CsC-CEs and CsC-PEs, and must be used in conjunctionwith an LDP[6] or MPLS label exchange between the CsC-CEs andCsC-PEs.

Separating the IP prex and label allocation protocols between an

IGP and LDP can introduce complexities with potential divergencebetween the two control planes. Such divergence in the extreme casecan lead to partial or complete loss in orwarding. Use o an EGP likeBGP, however, can be used to implement CsC as a single IP prexand Label Allocation control-plane protocol between CsC-CE andCsC-PE. Piggybacking MPLS label-mapping inormation in the BGPupdate messages helps ensure that an IP prex and its associatedMPLS label are always synchronised in their delivery. The way inwhich this synchronisation is achieved is documented in RFC 3107[7].BGP has the benet o being a mature protocol or use either withinthe same network organisation or between networks belonging todierent operators. Furthermore, BGP employs mechanisms or loop

avoidance and control over the number and type o routes advertisedand accepted.

Figure 4 shows an example scenario whereby two BGP peerings areestablished (or resiliency) between each o the our CsC-CEs (whichare actually PE routers o the BGP/MPLS VPN customer carriernetwork) and a pair o target CsC-PE routers (which are the PErouters o the NGN backbone carrier network).

Figure 4: BGP Plus Labels as the Routing Protocol Between CsC-CEs and CsC-PEs

VRF Created onNGN for MPLS

VPN PoP Connectivity

MPLS VPN PoP NGN Backbone Node

Csc-CEs

BGP Peering

CsC-PE

CsC-PE

Switches ProvideIntra-PoP Layer 2

AggregationPhysical Interconnects(e.g., GigE or 10GigE)


26/40


26

Label Switching o Customer Packets

As shown in Figure 5, viewing packet fow rom let to right, a uni-cast packet originates as a native IP packet when presented rom theend client CE router to the MPLS VPN PE router, which is behavingas a CsC-CE in this context. Upon traversal between CsC-CEs in di-erent MPLS VPN POP locations connected by an NGN backbonecarrier using CsC, the packet ultimately undergoes three levels olabel encapsulation:

The innermost label corresponds to the End Customer VRF. Thislabel is transparent to the NGN backbone carrier (that is, it is notoperated upon in lookup and orwarding tables with the NGN). Itis label A in Figure 5.

The middle label is the outer label as ar as the CsC-CE is con-cerned, swapped at the CsC-PE, and becomes the inner label asar as the NGN backbone carrier is concerned. In Figure 5, thislabel is assigned as label B by the CsC-CE as instructed by theCsC-PE through the BGP plus labels (RFC 3107-compliant) peer-ing. At the CsC-PE itsel, the label is swapped (to become labelC in Figure 5) and is used to associate the packet with the CsCVRF. The packet is then identiable at the destination CsC-PE atthe ar end o the backbone carrier network; it allows orwardingto the correct interace.

The outermost label (shown as label D in Figure 5) is assignedby the backbone carrier LDP process at the CsC-PE router, and ispresent only to allow transport across the backbone carrier CsCcore. Thus when a packet leaves the CsC-PE or transport acrossthe backbone carrier core it has three levels o labels on eachpacket.

Figure 5: Label Encapsulation and End-to-End Packet Flow Across a CsC Core Network

CsC-PE(NGN PE)

CsC-PE(NGN PE)

End VPNClient CE

End VPNClient CPE

NGN PCsC-CE(VPN PE)

NGN Backbone CarrierMPLS VPN Pop(Customer Carrier)

MPLS VPN Pop(Customer Carrier)

CsC-CE(VPN PE)

VRF created on NGN forMPLS VPN PoP Connectivity

VRF created for End VPNCustomer Connectivity

3-LabelEncapsulated

Packet

Native IPPacket

Native IPPacket

B

2-Label

EncapsulatedPacket

A

A DC

2-LabelEncapsulated

Packet

A C

1-LabelEncapsulated

Packet

A



27/40


27

As shown in Figure 5, the last P router in the backbone carrier pathhas popped the outermost label (label D) using penultimate-hop label orwarding. The destination CsC-PE uses and removes themiddle label (label C) to indicate the correct outgoing interace,leaving only the innermost label on presentation to the CsC-CE (labelA). This CsC-CE, which is the PE router in relation to the endVPN services, uses the last remaining label to determine the VRFroute and interace on which to send the native IP packet so that itreaches the required client CE router.

Design and Operational Challenges

The previous section outlined the architectural ramework o usingCsC to integrate one BGP/MPLS core network with another. Thissection addresses the important design and operational challengesthat such a network transormation brings about.

Maintaining Perormance Levels

Many existing operators o carrier-class BGP/MPLS networksexploit IP QoS mechanisms to allow dierent IP-based trac types

to be treated in dierent ways in terms o how the packets are con-veyed across the core network. This treatment relates chiefy toprioritisation o delay, jitter, and/or loss-sensitive trac, against tra-c types that are less sensitive to loss or delay. Customers o VPNservices supported on such networks generally demand support oa range o trac types, including corporate intranet, transactionalapplications, mail services, data backup, video, and VoIP telephony.

To deal with the range o trac types, BGP/MPLS VPN serviceproviders have developed the means o supporting IP QoS deningdierent transport classes with associated service levels. One suchexample may map, or instance, six service classes based on IETF

Per-Hop Behaviours as dened by the Dierentiated Services(DiServ) working group[8, 9] and the recommended DiServ CodePoint(DSCP) values or them. The classes in this example could bebroadly described as ollows:

Expedited Forwarding (EF), designed and optimised or the deliveryo jitter and delay-sensitive applications such as VoIP

Assured Forwarding (AF), intended to support priority dataapplications; the AF class is split into our equivalent sub-classes(AF1AF4) used to segregate data or video trac applications,with priority being maintained over the Deault class

Deault (DE), to support best-eort (that is, unprioritized) datatrac

The DSCP markings dictate the way in which such trac is placedinto queues and conveyed across the core network. At the edge o theMPLS core, the PE maps the incoming DSCP value into the MPLSClass-o-Service (CoS) bits (ormerly known as EXP bits).


28/40


28

The details o the mapping relate to the specic implementation andpolicy o the service provider. Under heavy trac load and conges-tion situations, such policies dictate how packets are treated in termso scheduling, queuing, and discard eligibility.

Both the existing BGP/MPLS customer carrier and the target NGNbackbone carrier networks already have their own implementationo QoS classes to allow management and prioritisation o multiple

trac types carried across their respective core inrastructures. A sig-nicant design challenge that arises with integrating the networks isthat a suitable mapping o the QoS schema present on the PE routerso the customer carrier network (the CsC-CEs in earlier diagrams) tothe QoS schema supported on the PE routers o the NGN (the CsC-PEs in earlier diagrams) is necessary.

It is imperative that such a mapping not compromise the existingcustomer experience or VPN services in terms o packet loss, packetdelay, and packet jitter (that is, delay variance). Careul design, map-ping o the required service levels, and ultimately end-to-end testingo the QoS mappings is thereore necessary to assure the maintenanceo perormance levels ater the networks are integrated with CsC.

Network Resiliency

As described earlier in the article and shown in Figure 2, an existingstandalone BGP/MPLS network platorm has interconnected POPlocations using underlying core transmission inrastructures such asSONET/SDH/Dense Wavelength-Division Multiplexing (DWDM).The actual number o WAN circuits deployed, the use o transmission-layer protection mechanisms, and the overall topological connectivitybetween POPs determine overall levels o network resiliency. In turn,this aspect o the network architecture signicantly aects the overall

level o service availability to end customers o VPN services.

When the standalone BGP/MPLS network has its existing coretopology replaced with that o the NGN backbone carrier, it is veryimportant to consider the levels o resiliency delivered with the newintegrated core architecture, compared with the existing standalonearrangement. Critical considerations include:

The physical connectivity between the serving nodes o the cus-tomer carrier and the backbone carrier should avoid single pointso ailure where possible.

I the physical connectivity between the customer carrier and back-

bone carrier requires the use o WAN transmission links becauselocations are geographically separate, then suitable levels o circuitprotection should be employed

Because the backbone carrier eectively replaces the existing coretopology o the customer carrier, the actual way in which backbonecarrier nodes are interconnected and levels o WAN transmissionprotection etc., should be analysed.



29/40


29

All these aspects should be assessed and incorporated into the actualdesign process such that there is no detrimental eect on overalllevels o service availability to the end customer. Service levels canbe veried by reliability modeling o the new network topology, andby comparing the results with the reliability data or the existingtopology.

Fault Management

There are many acets o monitoring and managing a core BGP/MPLS network in terms o assurance o service, alarm detection andltering, customer notication o aults, and so on. In a standalonenetwork environment, it is generally the responsibility o a particularoperational team to manage aults on the network and provide ser-vice continuity during various types o ailure scenarios. As shownin Figure 6, this operational unction usually covers all core networkelements, including PE and P (core) routers, as well as the WANtopology interconnecting the service nodes or POPs.

In an integrated core network scenario, however, part o the cus-tomer carrier networkthe P (core) routers and WAN transmissionlinks, or exampleare replaced by the NGN backbone carrier. TheNGN backbone carrier has its own operational team with specicprocesses and systems or carrying out monitoring and manage-ment o ault events. A crucial challenge arises in terms o how torealise end-to-end ault management holistically and transparentlybetween customer carrier and backbone carrier networks (Figure 6).Important considerations include:

The requirement or a clear and unambiguous demarcation betweencustomer carrier and backbone carrier core platorms must beaddressed in terms o operational responsibility or specic aultsand the hand-over procedures between operational domains.

The use o existing monitoring tools and systems in both the cus-tomer carrier and backbone carrier domains must be assessed todetermine whether new interaces between such systems need to bedeveloped to acilitate the hand-over procedures.

These topics must be actored in to determine the optimal solutionor realising smooth and transparent ault-management proceduresin an integrated core BGP/MPLS network environment.

Capacity Planning

As shown in Figure 6, in a standalone BGP/MPLS VPN network

environment, a particular operational unction exists or ongoingcore capacity planning to ensure P router and WAN link capacity aresuitably dimensioned to cope with current and uture trac demands.When an existing BGP/MPLS VPN network becomes a customercarrier network that is integrated with a target NGN backbone usingCsC, there will be a corresponding shit in responsibility or certainaspects o core capacity planning.


30/40


30

VPN service trac that would have been conned to its owndedicated core network will now be oered onto the NGN backbonecarrier core network. As such, the capacity-management unctionor the NGN backbone carrier must use trac planning inormationpertaining to the VPN services in addition to all the other servicetypes supported on the NGN. This aggregated view o trac demandswill accelerate the core capacity dimensioning on the NGN backbonecarrier network.

Figure 6: Fault-Management and

Capacity-Planning Functions

(a) Before Core Integration

(b) After Core Integration with CsC

BGP/MPLS Core

Fault-Handling

PE>P->WAN>P>PE

Capacity Planning

NGN Core

Fault-Handling

PE>P>WAN>P>PE

Capacity Planning

NGN Backbone Core

Customer Carrier

(b)(a)

Fault-Handling

PE>PE>P>WAN>P>PE>PE

Capacity Planning

Conclusions

The MPLS-based Carrier-supporting-Carrier (CsC) ramework pro-vides network operators with a potential solution or integrating anexisting BGP/MPLS VPN network, with a target all-IP based NGN.

This solution should enable both capital and operational cost reduc-tion by collapsing multiple core networks into a single NGN coredomain. The article emphasised that as well as understanding thecritical network architectural building blocks required to implementCsC, there are numerous critical design and operational challengesthat an integrated core network presents. These challenges includehow to maintain service levels and perormance metrics or existingVPN customers, resiliency, ault management, and capacity plan-ning. It is important to note, however, that in addition to the broadtopic areas covered in this article, many specic additional challengeswill present themselves to network operators who have implementedBGP/MPLS VPN networks, and/or NGN networks in their own spe-

cic way.



31/40


31

Reerences

[1] P. Knight and C. Lewis, Layer 2 and 3 Virtual Private Networks:Taxonomy, Technology, and Standardization Eorts, IEEECommunications Magazine, June 2004, pp. 124131.

[2] E. Rosen and Y. Rekhter, BGP/MPLS IP Virtual PrivateNetworks (VPNs), RFC 4364, February 2006.

[3] M. Mahmoud, Carrier-supporting-Carrier: The Whole Story

(1), Networkers Online, December 2008.http://networkers-online.com/blog/2008/12/carrier-

supporting-carrier-the-whole-story-1/

[4] M. Mahmoud, Carrier-supporting-Carrier: The Whole Story(2), Networkers Online, December 2008.

http://networkers-online.com/blog/2008/12/carrier-supporting-carrier-the-whole-story-2/

[5] J. Moy, OSPF Version 2, RFC 2328, April 1998.

[6] L. Andersson et al., LDP Specication, RFC 5036, October2007.

[7] Y. Rekhter and E. Rosen, Carrying Label Inormation inBGP-4, RFC 3107, January 2001.

[8] B. Davy et al., An Expedited Forwarding PHB, RFC 3246,March 2002.

[9] J. Heinanen et al., Assured Forwarding PHB Group, RFC2597, June 1999.

PAUL VEITCH holds an M.Eng. and a Ph.D. rom the University o Strathclyde,Glasgow. He joined BT at Martlesham Heath, Ipswich, UK, in September 1996,and worked on various aspects o broadband transmission architectures, multi-service platorms, and 3G network design. In 2000, he joined MCI-WorldCom in

Cambridge, UK, and led a number o projects on IP backbone network design. In2003, he returned to BT to work on IP VPN inrastructure design. He is currentlythe design authority or BT Retails Internet networks. He can be reached at:[email protected]

PAUL HITCHEN holds a B.Eng. in Electrical and Electronic Engineering rom theUniversity o Salord. He joined BT at Martlesham Heath in September 1990 andhas worked on numerous aspects o BTs data services. From 1990 to 1997 he ledthe development o BTs multiprotocol router portolio, developing routing and QoSunctions with BTs equipment suppliers and provided consulting to BTs customerson IP and Ethernet networks. During the same period he worked on the introduc-tion o Frame Relay, ATM, and SMDS WAN services or BT. In 1997 he developedBTs rst IP VPN service oering, working on the development and standardisationo MPLS and VPN technology. From 1997 to the end o 2006 he led the design o

BTs Global MPLS Network and service, expanding the network to provide serviceto more than 150 countries across the world. He is currently a principal consultantworking on BTs 21CN IP/MPLS network, ocusing on the integration o BTs net-works onto 21CN and introducing content delivery and IPTV into the network. Hecan be reached at: [email protected]

MARTIN MITCHELL holds an M.Sci. rom the University o Bristol and hasworked or BT since 2007. He is currently an IP network designer specializing inservice provider core design, Ethernet access, and network migrations. He can bereached at:[email protected]


32/40


32

Letter to the Editor

Hi Ole,

I enjoyed the article entitled PMIPv6: A Network-Based LocalizedMobility Management Solution in the last issue o The Internet

Protocol Journal(Volume 13, No. 3, September 2010).

I believe that in the Security Considerations section it should bementioned that the CSI (Cga & Send maIntenance) working group inthe IETF is also working on updating the Secure Neighbor Discovery(SEND) specication (RFC 3971) to include the possibility oauthenticating the proxied Neighbor Discovery (ND) messages sentbetween the terminal, the Mobile Access Gateway (MAG), and theLocal Mobility Anchor (LMA). This conguration should work inaddition to the proposed IP Security (IPsec) tunnel between the MAGand the LMA.

The reerence material is available at:

https://datatracker.ietf.org/doc/draft-ietf-csi-proxy-

send/

https://datatracker.ietf.org/doc/draft-ietf-csi-send-

cert/

Regards,

Roque Gagliano, Cisco [email protected]

One o the authors responds:

Dear Ole and Roque,

Thanks or reading our article and providing these valuable com-ments. We agree with your point. We just considered the basicsecurity mechanisms in our article, limiting the scope to the protocolsalready standardized, which cover only the protection o the MAG-LMA signaling. We agree that the eorts being carried out within theCSI working group are worth mentioning with regard to the securityaspects o PMIPv6.

Thanks,

Carlos J. Bernardos, Universidad Carlos III de [email protected]


33/40


33

Book Review

A History o the Internet A History o the Internet and the Digital Future, by Johnny Ryan,Reaktion Books, ISBN 978 1 86189 777 0, September 2010.

Any attempt to document a 50-year history o people and activi-ties that had such a proound and global eect as the Internet acessome challenges. Sequences are complex; written source materials aresketchy; and the many dierent memories confict. Added to this real-ity, o course, are legitimate disagreements about intents and eects.To evaluate such writing eort means rst looking or useul criteria.Here are mine: In terms o basic research, was the eort extensive,looking or multiple, appropriate sources and exploring a wide rangeo probing and constructive questions? Were the sources and ques-tions interesting? This line o thinking leads to a query about theway the author integrates the resulting massive body o data. Is therean eort to develop critical analyses? Are alternative explanationsexplored?

Johnny Ryans ambitious A History o the Internet and the DigitalFuture is a rather modest 246 pages, including 28 pages o reerences.Overall my eeling is that he does quite an interesting job o satisy-ing the rst hal o his title, but a somewhat disappointing job withthe second hal. His research was extensive throughout, but he takesa more critical view o the history than he does o the social aspectso our digital uture. In the rst hal, he integrates inormation andreports discrepancies and curiosities. In the second hal, he indulgesin the common, wide-eyed wonderment that technology uturisteorts inherently risk. (Full disclosure: By way o demonstrating thethoroughness o his research, Ryan even included me as one o his

many sources.)

Organization

The book is divided into three parts. Broadly, they cover origins,growth, and social eects. Ryans use o centriugal is contrastedwith centripetal and is meant to distinguish paradigmatic tensionsbetween approaches that centralize control versus approaches thatdistribute it. (Oddly, neither o these pivotal terms is in the index.)On page 8 he sets the stage:

Three characteristics have asserted themselves throughout theInternets history and will dene the digital age to which we must all

adjust: The Internet is a centriugal orce, user-driven and open.

By centriugal he means moving outward, away rom centralizedcontrol. For me, the terminology proved distracting, because I kepthearing my 8th-grade science teacher condescendingly explainingthat there is no physics orce called centriugal. Rather it is a percep-tion o the interaction between inertia and centripetal orce.


34/40


34

For those with less compulsive (or eective) science teachers, theanalogy might prove more helpul, because the design choice reallyis central to the history o networking. The tension between central-ized versus distributed has markedand continues to markmucho the development o networking. In act, I wish Ryan had exploredits continuation as much as he explored its eect on origins.

Early History

In general, Ryan presents a narrative with ne-grained detail o thedierent players who played a critical role in the creation and pursuito packet switching and then its evolution to link independentnetworks and technologies[1]. Eorts to take credit or the ormerhave oten become quite public and unseemly; Ryan dissects theplay o actors, the essence o their technical ideas, and the detailso their activities with documentation and diligence, and evenuncovers some discrepancies. He develops a narrative that I oundintriguing, enlightening, and credible. What I especially liked wasthat he explored the organizational milieu in which the activitiestook place. So we hear o the origins o groups such as the Advanced

Research Projects Agency (ARPA), Lincoln Labs, and The RandCorporation; the social and political orces that created them; andthe roles they played.

Narrative Arcs

The ollowing is really the strength o this book: It develops narrativearcs about social, political, and organizational environments and thesteps taken within them that moved along the path o the Internet.It explores who, when, how, and what, both overall and in detail.At its best, the book provides comparative perspective to help thereader understand what was risky and truly innovative and therebyunderstand what was really challenging to develop and get adopted.

As a minor example, Ryan deserves credit or his exploration anddebunking o the media distortions surrounding Al Gores role andstatements concerning the Internet. Strictly speaking, debunkingmedia excesses would not normally seem relevant to a review o thehistory o a technology, but Ryan uses this example or some con-sideration o the role o politics in the development o the Internet.The U.S. government could have chosen to assume more control overthe Internet; it might have quickly turned it into a telecommunica-tions monopoly, rather than letting it develop through independentmarket orces.

As would be expected or a story this sweeping, Ryan is sometimes

redundant and sometimes inconsistent. Overall, the book would havebeneted rom more careul editing. So it has a quick reerence tothe invention o e-mail messaging at Bolt Beranek and Newman,but later has a more accurate, detailed account o Ray Tomlinsons1971 eort, there, to add networking to the existinge-mail mechanism.(E-mail messaging was present on the rst time-sharing systems othe 1960s, but these systems were standalone services. Tomlinsongot them to talk each other.)

Book Review: continued


35/40


35

Another touchstone I use or discussions o Internet history is therole o the Computer Science Network (CSNet), because I workedon that. CSNet served as the orerunner o the larger and moreobviously pivotal National Science Foundation Network (NSFNet).With NSFNet the Internet developed the ability to support multiplebackbonesessential or a truly competitive Internetand the mar-ket-priming creation o regional operational services, rom which theseeds o the commercial Internet were sown. Ryan notes the roleo CSNet as a kind o market research that led to NSFnet, and inthis observation his discussion is notable. But his account o CSNetdetails is somewhat skewed, because CSNet is cast as having ullpacket-level connectivity, with e-mail-only telephone-based linkagesas a secondary service. In reality ull connectivity came later; theoriginal years o CSNet were e-mail-only. Why this act is importantto notebesides overly personal ault-ndingis as a reminder thatthe accounting eorts or this sort o history are always noisy; thestory signal is never pure, even with a diligent eort.

A urther touchstone topic is the Domain Name System (DNS) andthe development o the Internet Corporation or Assigned Namesand Numbers (ICANN). The interesting part o this saga is later-stage Internet history, and Ryan is relatively sloppy with the details.For example, he muddles what generic Top-Level Domains (gTLD)already existed and what new ones were proposed, such as .com ver-sus .biz; he also muddles the distinction between gTLDs and nationaldomains, such as .uk. On the other hand, he certainly captures thecontinuing tone o controversy that surrounded the development andoperation o ICANN, the organization now managing assignment oIP addresses and domain names.

But the most obvious, later-stage touchstone or a history like this one

must be the development o the World Wide Web. Ryan gets mixedmarks here. He misses the long history o open document publishingthat existed even in the earlier Advanced Research Projects AgencyNetwork (ARPANET), with anonymous FTP, and he misses thatthe use oGopher predated the web

Internet protocol cisco

Documents