Live Transcription - Tuesday - 14:00 - 15:30
Note: Please be advised that this transcript is the output of the real-time captioning that was used on a trial basis during the RIPE 55 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.
PATRICK: Good afternoon, everyone. Settle down, take your seats, please.
I want to make a start to this afternoon's session. The first speaker we have is Maurizio Pizzonia. We'll be talking about BGPlay.
MR. PIZZONIA: Thank you. I am from [] /RO mat /RA University, Computer Network Research Group, and I am going to talk to you about BGPlay and its evolution.
Well, in our research group, one of the main research fields is a computer network visualisation, and we do a tool called BGPlay. It is available as a risk [] wearing tool since 2004, and it basically shows the data that [is] collected by the routing information system, and so it shows graphically, [] given a certain prefix, what is the incoming traffic path that's chosen by the route collectors to reach that prefix.
Well, I [dare] to say that this is a quite successful service. We have about 200 queries per day with bits of 500 queries and the trend is slowly increasing as the linear fit shows. You have here on the the [] axis, the days on the vertical axis the query per day. And this is one of the most used RIS services; it's the second after the looking glass service.
Well, we developed a new version of BGPlay, we call it internal BG [] playing that shows graphically the data that are taken from your routers, the data from the routers of an Internet Service Provider. The interaction with the system is quite [similar] to BGPlay, but the semantics is different. The user has to select a set of prefixes that he is interested in monitoring and the system shows outgoing travelling paths from your router, the router that you choose.
Well, this is the architecture. Suppose you have some of your routers and we have a [] /KHRAOUT collector that is that collects data by means of Internet BGP session configured as a router collector [] /KHRAOUPBT and then through a chain of software, the BGP changes in the routes seen by this these routers are stored in the database. Then, with an internal BGPlay [client] which is a job application or an [] /AP let, it is possible to query that data and to have a graphical representation of them.
Well, I have several slides that I leave to you as a reference, because I am now going to show you the system live.
Well, first of all, the data that we are going to see are kindly provided by [GAR], which is the Italian Academic and Research Network, and we have, with them, five internal BGP [] rings. When you start the system, you have you see a form and you can select here the router from which you want to see the routing. And now I select a router that is located in the room, and then you have to select prefixes, the prefixes you want to monitor.
Well, there are many ways you can select those prefixes and you can have here you can insert the prefix directly. You can make some kind of search according to many parameters. And I start with a very simple query. I just look for all the systems that contains the word 'Google', then I see that one of them is not actually Google, so I select only the ones that I am interested in, and these are all the prefixes that are announced by those other systems. I just leave all selected, so I selected all the prefixes announced by those up on the system and then I have a list of prefixes. Now, I specify an interval of time that is basically about the last two days, and I disseminate the query.
Now, what is happening now: my client is talking with a server that is located in your room, so there is the Internet in the middle. And what you see here, a routing status at a certain moment at the beginning of the interval we selected, and you have, in the middle, a number that represents your router, and the blue numbers represents autonomous systems that contains the prefixes that you specify and the black ones are used only for transit [] /PWORT represent the next note used by this router to represent the prefixes.
To understand what is the [] bath from this router to, for example, these autonomous systems, you just follow the black [] dashed path and you see that, to reach here, you go through this next [] /O*EP, then 3356, then 15169 and then 36385. And, well, callers have no special meaning, but are used to [assemble] the drawing.
Well, the solid path represents the prefixes that change the routing during the interval time. The time is represented on the left, and this is the time panel, this is the past and this is the future and [magenta peaks] represent the real routing changes and green peaks represent just the router announcements that means that you have some BGP announcements, but the routing didn't change, actually. Then you can animate the routing and you can see that, for example, here a path disappeared and then another one disappeared, and so on, then appeared again in a different position than the one changed, and so on. You can also start an animation that goes automatically.
Here, the yellow part represents the past with respect to the instant we are looking for, we are looking at. This is more or less what you can see from this situation. Oh, of course, for each event, you have here details for the event, and also if I show for example, this one. This is a [] reannouncement that is not I mean, it is shown as one, but it is related to many prefixes, actually, for []. This is done because those prefixes behave the same during the period of time, so it is better to graphically show as one single event, and having them specified in this way.
Now, I would like to show another query, and well, GAR is a member of [two] Internet exchange points in Italy, [] require /TPHAPL /EUBGS and mix, one located in Rome, one located in Milan. I prepared a configuration of prefixes for the member of the [NAMUS] consortium and now I am going to see what would happen if I see the routing for those members from their own router.
Well, what you see here is the situation for the last two days for the [NAMIX] members. These are mostly [NAMIX] members. Actually, these are all the [NAMIX] members, plus, well, some NAMIX member actually is reached, are here, and you can see here another feature of internal BGPlay, that is to show that those these necessary [] /TOEPS are actually collated to an exchange point so that you see many of the many of the members are actually reached through an exchange point, but some of them are reached through another exchange, and it is located in Milan and some of them are reached through private [] peerings and some of them through to upstream providers this is not the case, actually. We have here an upstream providers which means that in some that some eventually moved, some router to these upstream provider. We are going to see it. And here it is. Animating the routing []) these the prefix announced by this autonomous system is actually reached through the upstream provider even if it is a member of the [NAMIX] consortium.
Well, we can animate a scene, for example, that there is an oscillation over the router announced by this member, and the routes oscillate through three Internet exchange points.
You can also have a continuous monitoring for a certain set of prefixes. For example, we can have well, for the same query, we can click not on 'submit' but on dashboard, which is a visualisation in which you have the situation I mean, now what is the last routing status that that is present in your database and you see it and this visualisation is updated continuously every 30 seconds. In this moment, the collection of data, the BGP events go into the database every 15 minutes, but we can go down to five minutes, and we expect that soon we will be able to have collection in [] sub minutes, with [] sub minutes delay.
Well, I prepared a configuration that, in a certain sense, represents some of you, in the sense that I went through the list of people participating in the meeting and I selected some names and picked prefixes from the autonomous system. Of course, this is just a random sampling, so what you see here is not representative of the entire routing of the autonomous system.
Then you can see, maybe, something that is familiar to you, and I can help you to think, for example, names on it. Well, something happened yesterday on the prefixes I am monitoring for that. It's okay.
Well, what is the contribution the direct community are [giving] to the project and what is the contribution we can give to the community? Of course, our intent is to make internal BGPlay a valuable tool for Internet Service Provider. The software can be considered stable, but we are looking for feedback and suggestions for improvements, and our current partners are:
1. Internet exchange point;
2. European scientific research networks and [] two Internet Service Provider.
How can you collaborate?
Well, first of all, we have, basically, two options: The first option is you can set up an internal BGP peering with us. Of course, it's just a peering to exchange BGP data, not to make real routing, as happens with the route information service. And you are provided with a client, with a software to collect to view your data. The second options [ ] if you don't want that, we collect your data is that you provide a [Linux] box and we install the software in this [Linux] box and you can view your data.
Other maybe more interesting forms of collaboration. Consider this: Two or more Internet Service Providers can agree [to] share their data. We can set up things so that they view the data of the other members of the group. And, also, an Internet exchange point could offer this service for the members and this can be done in many ways; for example, as a service which each member sees their own data or as a service in which each member can see all the data that is in the system.
Well, future works:
We have quite a dense agenda. These are put in the order of, I mean, in the order in which I feel they are more appealing.
First of all, we would like to make exchange between Internet Service Providers' data, BGP data, easy. And, of course, there are many questions about this, but, I mean, I won't go into the details now, but this would open the research of visualisation of the paths in both ways.
Then we would like to apply the visualisation techniques we have used here on the visualisation of other routing data; for example, OSPF and MPLS data, and these topics we are looking for collaborations, and also, we are trying to develop a visualisation way that shows you visually a comparison of the routing seen by more than one router, and a summary of visualisation of the address space versus your BGP peers versus your routers.
And then we just mention it, that we would like to go toward a real time routing data selection, routing collection.
Well, if you are interested in this project, if you are interested in having in being able to use internal BGPlay according to the ways that we just mentioned, or if you have any ideas or if you want to collaborate with us, just contact us by e mail at the mail address that is shown in the slide or, better, contact me here and if you have any questions, I am here.
(Applause)
PATRICK: Are there any questions at all? I guess not. Thank you very much.
So next up we have Michael Finkenzeller who is going to be talking about a [] hundred
wavelength delivery over current wavelengths.
MR. FINKENZELLER: Hello, everybody. I am Michael Finkenzeller from Nokia Siemens Networks and it's a pleasure for me to speak today at the RIPE meeting. It's the first time for me to speak at the RIPE meeting, and I hope it's an interesting talk for you.
The topic is delivering 100 [] G per wavelength on today's DWDM infrastructure, and, in the morning, we had a very interesting session from Peter who explained to us a lot on DWDM already, so I was happy that I have not to explain too much about it.
So, in the first step, we talk a little bit about the motivation, and here you have the inavoidable traffic growth metrics, and I have to admit I have borrowed that from the [] ey cock presentation of MS and what it shows, and you should be pretty much aware of that, that it's about every 30 months it seems that the traffic is ten fold increasing, and this, of course, gives the motivation, of course, to have a faster speed for transmission.
As I mentioned already, Peter did a very good job in explaining DWDM basics here, so I just put it here very simple, what it's doing. You take more or less wavelengths of different colours and [] offer every wavelength you transmit your data, and finally, you multiply all the different colours to get them to one fibre and transmit it over a fibre.
When you do this at a channel spacing of 50 grid [], gigahertz grid or 100 gigahertz grid, that means for the C band you end up with about 80 channels and it's called dense wavelengths [multiplexing].
And you might know that this is an analog world and most of the computer scientists wanted to, maybe, to avoid all this physics, but it's not unavoidable here. So we have, when we want to transmit over a longer distance, a signal. First of all, you have [] attendation coming in. This leads to amplification. You have to introduce amplifier for the wavelength and every amplifier that is a problem, that it introduces noise. Another nasty thing Peter already mentioned was dispersion. It comes as traumatic dispersion or polarisation, [] more dispersion both have different causes, [syncmatic] dispersion, as Peter says. It's because level [] light of different wavelengths travels at different speeds, and at the receiver side you get, instead of a smaller peak, you get the broader peak, and that would be bad for the receiver.
And if you introduce too much power to a fibre, you will face non linear effects, so you [] don't just be able to amplify an amplifier, and that's it. So it has a certain threshold for it.
For 100G transmission, we ended up with something more elaborated than just putting a light on and off, and we will see in a later talk what it is.
I would like to present here two interesting experiments on Nokia Siemens [] /ET works. One is the first one was into the and it transmitted at a field trial together with AGT 107 gigabits per second over installed fibre and the interesting part here is not only the transmission speed, because it was done already before, but that experience before mainly used optical components for multiplex and demultiplexing, and so on. Here, the interesting thing is to do it [electically], the receiver side. Let me mention here, this is basically on/off keying, and the receiver side you have integrated on one chip clock and data recovery, together with the multiplex of 1 to 2, to process the signal coming out of the receiver chip with lower speed electronics. Nothing here [] it low speed, but lower speed electronics. So this provides you with a very cost effective way to build 100 gigabit system, but, of course, it's not well suited for long distances here. It's more or less mentioned, targeted for line applications, maybe, and more compass applications.
So what to do about just switching light on and off. We have to come up with different modulation schemes. Most of them are well known already from the mobile networks. Some of them we will have a short look at. DPSK and DQPSK were already mentioned in the morning, but I explain it a little bit differently.
Polarisation multiplex gives you another degree of freedom and, at the end, coherent receivers, we will also have a short look at this.
First of all, what is DPSK and what's all this [] Q and [] poll /PHUBGS, and so on, bringing? DPSK just makes one bit [] certificate system distinguishable by the face of the signal. For example, you transmit a signal, and while you are looking at the face of the signal, you see, oh, this is a 180 degree shifted from 0, so it has to be a 1, for example, and here this can be a 0. When you split this in the middle, and you distinguish not only 180 degree face shift but also in between the half you end up DQPSK where K [] can standing for [] /KWAURT, that means you can []... you have four different things to distinguish at the receiver side. You can do that also on a [] /PHEUFRPB level by using [polarisation] when you [split] up the light in different polarisation modes. You can also transmit two bits per symbol, and when you combine both of those modulation techniques, you end up with a horrible word called [] poll /PHUBGS DQPSK, which gives you a total of 4 [bits] better symbol you can transmit.
What is this all about for? In 2007 we made a very interesting experiment. This was a lab trial, it was not installed [finally], it was a lab trial. Here, you see a small picture of the setup of it and so the important part here is that it's done on a 50 gigahertz grid, transmission, by using this [] /POLT /PHOBGS caving, and this allows more or less that the symbol rate is reduced from 100 [] big bits per symbol down to giga []bawd and this makes it easier for you to transmit the signal over the fibre because we have much slower transmission then. And, again, the important thing is that you are able to use it as currently installed gigahertz grid infrastructure which is currently used for 10G transmissions.
A short look at the I mentioned it already, partly []. It has a very narrow spectral width and it allows you also to use 40G electrical components and you don't have to build up 100G electrical components because that's a pretty more sophisticated. And you can handle chromatic dispersion PMD electically and the correct detection allows you not only to receive the aptitude and the [] face, but also the polarisation, so you have very [] /TK PL [ ] you need to distinguish what kind of symbol will stand.
Here, you have as a transmitter which modulates, first of all, its laser split into the polarisation parallel and vertical. And then you have here two times, one time here, one time here, a DQPSK modulator which adds up the data, two times here, and two times there and finally recombines the signal to transmit it over the fibre. At the receiver side it again splits the signal and you have this local loop, this local oscillated laser which interferes with the received signal and gives you then it's a four path which can be detected by the [] niece die odds here. And then you have to we have to admit that it be done in the post processing process and this will be the future challenge for us to integrate this post processing because this was done on a PC for clock recovery, equalisation, carrier recovery and error counter and this has to be integrated in the near future. This is one of the major challenges we face.
A short word on so called [] conCAT /TPHAEUTed [] N times 10G to achieve 100 gigabits, let's call it 'Native'. This is a pretty good technique for operators that are not short on fibre and it combines a well known [] ten an sheet transmission with all the advantages here. For example, the reach and the robustness and it just balances 10 times 10G to achieve the 100 transmission. On the other hand, when you do this, you don't make use of the whole fibre capacity because when you have 80 [] /KPAPBLs with 100G, you end up with eight terabits per second, and this is only is a tenth part of it, of course.
Another advantage we see here for Native is that service routing is easier. When you imagine a meshed network, you have to take care that all those 10G landers can be routed the same path and this has to be done for every node in the network and so you maybe end up in a partly concasted network with points where you don't have the actual wavelengths available, but you need []. So this is a little bit more complicated, the [] conCAT /TPHAEUTed approach.
It's easier to have one service per port, so we think native 100G in the medium future, it's a technology of choice.
Some word on standards.
Most of you are already quite well known here, usually, you come with the next step of technology in factors of 10 from 1G to 100G. Usually it is [] shone on shorter distances of up to 40 kilometres. On the other hand, you have ITU guys, the transport guys, which traditionally is always in steps of four. And this was 2.5G to 10G to 40G [] the case. And they have a focus more on longer distances, from two kilometres up to several thousand kilometres.
So, this is two different worlds first, but what we would like to have is that they cooperate to deliver real end to end standard for 100G. For 40G, one of the recent meetings they decided to also standardize 40G together with 100G and this came mainly out of the reason why the data senders and server where people had the need currently for 40G and they don't see that 100G is ready to be deployed currently and they need it [] quite now, so ITB decided to go for the 2G, but this brought up again the discussion on the ITU side how to aggregate that. For example, you have two options here. This is 111 or 112G versus 130G. When you see the 40G from the [IEEE] side and you combine the two of them together, you end up with roughly 80 gigabits per second. This gives you a lot of overhead here because the remaining 20 [gigabits] per second are to be used somewhere else or to be utilised somehow.
So, the promoters of 120G say, "Okay, let's go to the next step, let's bundle three 40G signals," and you end up with less overhead. But our experience showed that 430G, you have even more of this nasty optical impairments we faced before and you have to spend more research work on the electronic components and we think that this might delay the availability of products even further.
Another source of uncertainty is, of course, the standardisation, that IEEE and ITU find a common ground, and one not so good example was for the standardisation of [] ten she. Here, there was land interface []...... standardised and due to the popularity of the land interface, it was one on one, more or less. But this product is the use that the data rate were not to be fitted into the transport and it led to the problem that you have to do some over clocking here, which leads, again, to inability here and this is nothing which cannot be handled, but it's not so nice thing here and we hope for 40G will be different and for 100G also there will be more [clarification].
Anyhow, there are a lot of operators out there who currently see the need for 100G, and I picked up some article where AT&T said, "Okay, we need it. We wanted today more likely than tomorrow and we would even go for pre standard solutions here."
When you talk about standards of 100G, you also have to mention carrying the Internet, because it gives you another level of optimisation, and as the current traffic in the Internet is mostly [either Net] or [] P based, we think it's good to think about optimisation not only on layer 1 or layer 3, but also on layer 23, and this is more or less the idea of carrying a transport. And a good application example, we think, is at the aggregation side or the [] meet relevant side to establish tunnels, we are using the [] /AO*ET err net to have here a cost effective solution on this application.
So, to come to the conclusion:
I think it's the demand for 100G is very real. You see it from press releases and you both you see it from your own traffic statistics, I guess.
The IP traffic is the main payload for the future.
The [experiment] we have shown, that technology of 100G is right on track. It's been shown in several experiments and I think we will see very much good experiments in the future, too.
And they think that the standardisation of 100 gigabit [] eater net will play a major role, so that products are available in about 2010.
And as I said already, we think that the standardisation plays a major role and that there has to be a close synchronisation between ICUT and IEE to get this thing running.
And finally, we think that a [] carrierey err /PH*ET transport might be a good [] collusion for [meeting] relevant aggregation to offer a further [] /TK PL of optimisation here.
So thank you very much your view and I am ready for questions.
(Applause)
PATRICK: Questions?
SPEAKER: I am with the RIPE NCC.
If you say that the main payload will be [] eater net based service and probably IP packets, I wonder why this whole standardisation shebang is still concentrating on a particular set of bit rates, because that's what I think was important in the times when we actually wanted to multiplex and demultiplex all this stuff. We don't want that any more. I don't actually care whether the it runs at 95 or 105 as long as the order of magnitude is sort of good enough. So why standardise these things actually at that level and worry about that? Why not make a standard that actually adapts to what the wavelength can give you a little bit, and, in the end, doesn't give you spot on 100 or spot on 110 or spot on 95, or maybe even go to the point where you say, "Well, actually, I just want a connection band, I don't care whether it's 40 or 100, you know, as long as it's at least 40.
Answer: If I understand you right, would you say that the line speed isn't a matter of standardisation, right?
SPEAKER: I'd like a standard that, basically, if you wish, that goes back to the this is not my idea, by the way; I am just sort of proxying it a little bit [] about that goes back to the old modem days where the 2,400 modem actually [] /KAUBGD to the 1,200 modems, and if I couldn't get 2,400, I was happy to get 1,200. You know, I would probably not be happy, especially if you think about these exchange point things or even if you think about the long haul, the [] Mum /AEU net kind of thing, if it's easy to assemble. I don't care, give or take 10 wavelength, right.
SPEAKER: So speak more or less about leaving all the transport to this packet based [](mark mark), right.
[]
SPEAKER: That arises from your [] mine [payload] would be [] eater net based.
A.
I think for the transport side they are currently living a long time with this connection and they know that it's not so popular in our [] P based world, but it gives you a certain level of management which is quite well understood currently and I think maybe a way to meet together is on layer 2 and to introduce not only SDH [] toll net for 100G, but to think about different optimisations like you mentioned before, so multiplexing is able on an easier way.
SPEAKER: Keith [] /PHEUFP /ELG, ISC. It's great to know, after today's presentation, that there is going to be enough band width after all. A year ago, I was kind of worried.
Typically, when we have had a new generation of /AO*ET err net technology, it's giving [] about an order of magnitude, not [exactly] an order of magnitude, more capacity, and typically the cost [] pace is about two and a half times more expensive, so you are not only getting band width, you are getting economics of scale. Do you think the kind of technologies that you are talking about here are going to achieve that kind of economic break point, or do you think it's going to take some years, it's going to come down to these kinds of cost benefits?
SPEAKER: I think it's a [] like of 40G now. We are currently also have now this distinguishable 2.5 factor of the cost. It's more a balance of how much do you need and how much you need it, you know. At the end of the day, I think in two or three years we end up with 40G at this level, and in 2010, for example, when 100G might become reality, of course you face not this economic target, but I think it's not rocket science. It's manageable and it will be a higher price in the beginning like it was with 40G, but it depends on the adaptation, or an acceptance of the people, the operators to get here, volumes here and to reduce the price.
SPEAKER: I think it's interesting, is effectively, it's the same technology that's going to be used to achieve 100G if both short and long haul. So clearly, it's going to be cost benefit for the long haul and then the land and metro applications will probably be cost effective later.
SPEAKER: That's right.
Thank you.
SPEAKER: My name is Anthony. I was interested in Slide 11, there was a post processing done. Did you mention that it was done on four PCs or four channels split on
MICHAEL FINKENZELLER: I am not sure how many PCs were involved here. I think it's not much of a problem if you paralyse it on the PCs because it's not done in line or just in time; it was done off line.
SPEAKER: So you recorded optical
SPEAKER: Right. Because you had to all this checking if errors occurred and so on was analysed in the PC as later.
SPEAKER: So the optical signal is recorded and then passed on
SPEAKER: Then it's analysed on the PC off line.
PATRICK: Any other questions at all? If not, thank you very much, Michael.
(Applause)
Can we have the next speaker, Alexander.
ALEXANDER MAYRHOFER: Good afternoon. My name is Alexander Mayrhofer. I work for Nic.at which is the Austrian country code of clever domain name registry and today I am going to speak about one of our development projects. I am team leader of a small research and development team in Vienna and one of the projects that we are currently investigating is Internet based emergency calls. And what I am trying to do today is give you a rough introduction into the topics. I think it might be interesting, especially if you are an Internet Service Provider or if you are acess service provider or if you are a voice over IP service provider of course.
So, what I am going to talk today is how "legacy" emergency calling works. Legacy is, in that term, describes the telephoning service as we know it existed until voice IP became feasible. Special issues that come up with emergency calling once you go to IP based telephoning. An overview of the architecture that the IETF proposes to use for emergency calling. A rough overview of, to achieve this architecture, who in the whole chain of service providing needs to do what? A bit on regulation. And finally, that's to say the sales show what is Nic.AT doing with regards to IP based emergency calling?
So, if we look at the most simplist example, so to say the "hello world" of emergency calls, what happens if you pick up your phone at home and dial an emergency number? First of all, your phone is connected to a switch. That is pretty stable. That's probably stable until you move out of your flat, or whatever, until you cancel your phone service. So there is a relation between your phone, between your phone number and a piece of equipment in the central office. So if you dial an emergency number like in that example, the European emergency number, I don't know whether it's popular here or there are local emergency numbers, it's essentially the same for all emergency numbers. The first thing that some piece in a chain has to do is to recognise that it's actually an emergency call. So usually the switches have a configured list of short codes, which are used to reach emergency services, and in the next phase, one important thing is that, of course, if you are living in one part of Amsterdam, you want to connect to the local police there and not to the police of, like, Rotterdam, so there is a configuration in the switch which is usually statical, so it doesn't change for years, that maps that sort code to another phone number usually, and that phone number is then the destination of the emergency call. So that number is being used to route the call to the 'best' public service access point. The reason why the best is in quotes is that the best one might not always be the best one, in any case. For example, if you are speech impaired, or something like that, you might request from your service provider that you get routed to a PSAP which has extra speech or something like that.
So the call can be routed through the normal telephoning network. It probably gets prioritised because it's been recognised as an emergency call and it's being delivered to the police so what the police then sees is your phone number. Usually they have specially configured ISDN lines where, even if you suppress your caller ID, it gets displayed to the operator there. And how do they find out where to send the police if you hang up right after you make the call? Well, the answer is, in most cases, very simple. They answer the call, they try to figure the location and they send help and how they do it in most cases is they look you up in the phone book. So it's as easy as that and, in most cases, there is no separate infrastructure for, like, finding out the address of a phone number. So that's the easiest example. That's how it works since, like, 50, 60, 70 years.
It's the "hello world" of emergency calls.
It also the three things that are under the figure are the important things that you need to do when you route emergency calls. In the first place, you have to detect that it's an emergency call. In the second place, you have to route it to the right public service access point. And the third thing is that the public service access point, in turn, has to find out where you are and how to send you help. So that's the three properties that are common to emergency calls, no matter what the underlying technology is.
It gets a little trickier once you go to mobile [stop]. When you switch on your mobile wherever you are, you get associated to a base station. You get associated to a couple off but anyway you are using one of them. So if you place a call, the first step is very similar, so the base station has a configuration table which says, oh, 112 is an emergency call, I have to do something different than with a normal call to is translates the number into another number. Sometimes that happens in another network element, but anyway. That configuration is specific to the base station, so based on the position of the base station, the translation is being done.
And the call gets routed to the police as well in that case, hopefully to the nearest police, and the phone book in that case is not of much use, because the service by definition is mobile, so the only party who knows where you are, is actually the service provider itself. So there is cooperation required between the public service access point provider and the provider of the access network, which in that case, is also the provider of the service network because it's simply the mobile operator and he knows in which cell euro and you could also give you more detailed information about where exactly in that cell you are.
So, in that case, it's a bit tricky err because once the call destination depends on the location of the hand set, so when you move with your hand set you probably get to a different public service access point and the hand set location, the location of the caller, is not available in the phone book so you have to look it up using cooperation between the public service access point and between the operator of the access network, which, in that case is a mobile operator.
It's a bit like real estate. It's all about location. Once you know where your caller is you can send him help and it's the most important thing of finding out that location of the caller. So, the two properties that I said before: You need caller location to find the correct PSAP. It doesn't help me anything if I place an emergency call on my mobile and I get connected to the police in Vienna just because it is an /A*US /RAOEPB mobile phone and in turn, the caller location needs to be available to the public service access point because if I can't, like recollect tell the PSAP operator where I am or for example, simple, a child that tries to help his mother is probably unable to tell his location, so getting the /HROEBG of the caller through to the PSAP is an important thing of that.
The plain tell he have knee uses the phone number, the phone book as autoey to leaks. That's very /HREUFRPL and that is worked for a long time. Mobile telephoning uses the access network, cooperation with the service provider to figure the location of the mobile phone and another question is: What does mobile voice ISP use? And if you look at it what kind of network elements are involved when, for example, I start up my voice IP client or my notebook here and I would try to place an emergency call? Then my voice I S service provider would have no chance in figuring out where I am and he would have no chance in figuring out where to send the emergency call, actually the voice IP provider using would route the call to the police in Vienna.
That's of course very bad, because cooperation between police in Vienna and police in Amsterdam is for sure so good that they can reroute the emergency call in a minute. (ISP) some can, by the way.
So, the problem is the voice ISP service provider would need the location of the client to properly route the call to the public access service point but he doesn't know it. On the other hand, the exercise P knows very well where I am because he has the location of the D S L line, he probably knows where his access point is standing and so on and so forth, but because the Internet is transparent for any service that runs over it, he doesn't even notice the call, and so, he can't do anything about it.
So, the problem of emergency calls on the Internet is that the Internet has a separation between the service provider and the access provider. The classical telephoning world is very much integrated. You can't like buy the telephone line from one operator and then buy a telephone service from another operator, in most cases, and it's very easy to acquire location because you have a phone number, you have a phone book entry and that's it. Usually, unless it comes bundled like a D S L line or something like that, separates that, the access is completely /EUPBD /PEPBLT. I can Rome about as a voice IP client wherever I want to and the access provider doesn't even know that I am using voice ISP. Worse they don't know each other so it's very hard to cooperate between them.
The only thing that they have in common is the user because I am using at the same time a service and an access network, so that's one angle that you could use to fix that problem.
There are a couple of other issues that are related with voice /EUP P, emergency calls on the Internet. One of them is that because of the worldwide mobility of some services like voice IP telephoning, it also requires worldwide standards in the emergency calling handling. There are a couple of services which don't even use phone numbers which is a problem for a traditional PSAP because they are used to using the phone number as a look up key in some kind of database and they're used to being able to call their user back. So if I just have a sit it might be impossible as of today that I get called back by any PSAP in this world. And in addition, it might be more than just voice. I mean it's probably now not very realistic to think of that I would send an emergency call via instant messaging, but who knows? I mean, maybe in five years from now we will be used to using instant messaging or something else as our primary communication method, and at that time, it might be feasible to look into providing emergency services for other services rather than telephoning as well.
Now, most piece ups don't even handle short messages, which is a problem for example, in case of bank robbery where some of the employees in the bang tries to send an S MS to the police and it doesn't work. So that's already a sign that PSAP's need to add up more services, and, for example, instant messaging would be very nice for people who are speech impaired who simply can't call emergency services.
And last of all, VoIP is not always VoIP. For example, the VoIP that /SKAOEUP is selling is very much different from the ID F standard VoIP that's probably hopefully most of us use.
So there are a couple of problems with that.
And the IETF has recognised pretty early that there is something that needs to be solved and is work indicating two working groups, the names of the working groups are he can /REUT and gee owe /PREUF. He can /REUT is the Internet emergency response part it have and gee owe /PREUF is doing the geographic location, privacy of that location stuff, so they are working very closely with each other.
And the main points that the IETF is working at is location delivery, why is some kind of location configuration protocol. Service identification, so how do I recognise an emergency call? And service discovery, which has a funny name, which is name is LoST, which is location to service translation, but anyway the IETF is probably funny for names for protocols, most of the protocols that start with S and the acronym is should mean something simple or not so simple at all.
There is a couple of other topics, for example, privacy, location of the users of course, there are a couple of concerns regarding privacy (acronym) and security, for example, how simple would it be to forge a location and send the whole police of Amsterdam to the wrong place? Location signing and location hiding, which is I want to make my location only usable for a certain party so I just want to make the location usable for the police but not for, well other parties that might see the location.
So, two documents, we have seen he can criteria is probably an good introduction for if you want to read about that topic, that the the IETF he can criteria framework draft and the IETF phone best current practice draft which talks about how a phone should actually do emergency calling.
Regarding the IETF architecture first, we saw already that the only thing that a service network and an access network have in common is the user itself. So it makes most sense that the information goes via the user, even if you think that the user would also be the party that controls privacy and security of that location. So the first step in the IETF architecture is the location configuration which means I switch on my Internet device, wherever I am, and the network tells me where I am. There are three protocols that provide this functionality right now.
The first one is DHC P, there is an option in the DHC P protocol which allows you to provide either gee /TKPWROFBG coordinates or like a street name, street address. Then there is something LL T P that is, so to say, CD P, discovery protocol reloaded. It's a link protocol where you can transmit a protocol to the other end of the link line.
And H T T Pen enabled location discovery, which is an X M L based protocol in a you have a architecture where a client can talk to a server and request information, for example, location information.
Those are the three options for getting the location from the access network to the user.
So the next step then, the client or the service provider, who gets the location, can use a different protocol to figure out which services are available for that location and whom he has to contact for that. I have included a sketch on the next slide so it's probably easier.
The name of the protocol is LoST, as I mentioned already and the ex pans of the name is location to service translation. It's a think of a /PAOEZ /AEU delivery service, I am here and I want to have certain services and which service /R S available and whom do I need to contact for those services?
That returns, the services that are available, for example, contacts of the public access service point and the important thing, the dial string that I can use. If I move with my IP client to the US I would expect that 911 would work, and not 112 like it does in Europe. It's not this knowledge has to be provided by client of the infrastructure of the network.
And of course, the emergency call, once my telephone recognises that I want to make an emergency call, conveys the location, so there is a special format defined by the IETF, it's at present a document, which contains location information.
So the first step that I mentioned on the previous slide is the location discovery. We have a new element in the access network actually, which is a location server and that location server is located with the localised people with whom I have access to, because the /WHOEPBL one that can actually know where a D S L line ends for example, in which city, in which building. So the local ISP provides the client with location information. So he tells me where I am. Oh, I forgot on the slide before that of course another thing to require location would for example be GP S of course but I won't expect any Internet enabled client will have GP S in the next two years or something like that.
So now the client knows about the location. My Internet phone knows that it's now in /KRAZ in a poll ski hotel and so on and so forth.
Still the VoIP service provider doesn't have to do anything with that.
Location configuration has /TRO options. You can either provide spacious coordinates like longitude or latitude or you can provide civic coordinates which would be a street address, likes for example the address of our office versus rev coordinates of Vienna, I don't have the coordinates right now.
There is another occupation business eye he will know verse /SRES by reference. By value means the very value of the location is conveyed and by reference means that the client only receives a URL where he or others could very much the location information. So that is part of location hiding and location, obfuscation actually.
By reference of course, easier to handle with regards to privacy because the only that I think /TPHAS private might be the URL itself and the information that I need to get the location would be controlled by other TR L.
I talked already about the actual protocols that you can use to convey lex to the client, that is the H C P and two RS PCs. The other is the spacious and the other is the civic. There is extension to LL T P which is media end point discovery, that is as I said before LL D P, think of it as CC D P reloaded. Then there is held H T T P enabled location delivery, which is, as far as I know still an Internet draft stays us but should become an RS U very soon.
So the next thing is the phone needs to discover what services are available and whom can I contact in case I have an emergency call. So, there is another element in the network. It might not necessarily be close to the access network, but it needs to be somewhere in the network. There is a couple of options of them that is being discussed. The client uses the location to service translation protocol to discover, for example, the local dial string, the contact addresses of the public service access point. So what happens is the client delivers the location to the LoST service, and in that request, the LoST server looks up in his database, for example, okay, you are in Amsterdam so you would want to contact the Amsterdam police. The local dial string for emergency calling is 112. Available services are U R N service, S O S dot police and by the way the police also is a very modern police and has a sip account where you can contact them and they also have a tell you're eye where you can make a simple phone call.
So, that is expected to happen in a couple of few seconds after you for example start your voice IP client and after that the telephone is essentially ready to place an emergency call even though it didn't know that the location of the public service access point before.
Okay, that's maybe a lot of what I said already. Input to is the location information that was acquired before. Output data can be the available services, in that example we had S O S dot police as the service. Contact U R Is, we had two of them. And what I didn't mention is the service boundary, which means that the telephone can, like, catch the boundary of where the Amsterdam police would be responsible and once the telephone moves out of the boundary, it would have to requery the LoST service for a new location, like if I hop on the train and go to Rotterdam. It would need to /KRE create the LoST service for the emergency information in Rotterdam.
The protocol is X M L and H T T P based, so it's probably nothing new. And what is probably interesting is that is considered to be shall to have a similar query rate in importance as to the DNS itself, so if you think about, like, a couple of million of clients moving on highways where they need to update their location every couple of minutes, that is quite an interesting load on that point of the infrastructure.
I will talk later about where it makes sense to put the LoST service in.
So, in the search step after that all that is happened, hopefully without interaction by the user, the user could dial an emergency call like 112, telephone will successfully recognise that this is in the local dial plan, an emergency call, and he has already the contact address to say deliver the call to the right piece err, either directly (PSAP) or as I can show in the next step, indirectly via the voice over piece service provider, where the service provider itself makes a LoST query because he didn't know about the location of the user before (PSAP) and then the service provider delivers the emergency call to Amsterdam police.
Together with that emergency call, the client is expected to deliver the location information to the PSAP, so that the PSAP knows where the caller is.
Of course that sounds all like a /HROLT lot of work and it actually is, especially when you look at the location enabling effects networks, so what can be expected to happen? First of all, in most European countries it's a requirement to provide emergency calling services for telephoning. It /SAOEUPLS depends on the classification for the telephoning (sometimes) service. For example N /AUS re /AEU, if you can you can use that service to call useers on the normal PS D N so you are interruptability. Then it's being classified as telephoning service. And then you have to provide emergency services.
There is, however, because also the regulators know that technology that I have just tried to introduce to you, is not available yet or not available on a large scale, that there is some weak execution. So you have some wording like from the European Union, you have wording like in the best way technically feasible, which is actually like, if you can do it, you don't do it. But that might change and my consideration is that we have seen it before, that public pressure for whatever silly reason might give you bad press. For example, if in your network, four kit Inns died because somebody failed to make a successful emergency call, you might not want that headline in the newspaper. And that has actually happened with a larger American /SROEURBGS IP service provider where a burglar actually murdered someone in the house and the kid was unable to call the police because they had voice IP, so that is for example one thing where the FC T has reacted already and stepped up in doing something been this.
The stand /ARD identification is progressing rapidly, but the industry which I mean the voice up service providers and the access providers, they are barely watching. They are not up to date what is happening and what that might means to their networks and to their service. And it looks a bit like E...... as long as nobody is being pushed to do anything, nobody actually does it and the changes cost money (IPv4) but there is an (IPv6) there is an /PR G property with regard to emergency calling because most governments consider emergency calling an important part of their service to the community and to the residents. So there are a lot of funding projectings actually going on with regard to security, especially since September 11, so (projects) there are a lot of projects going on in that space where network operators, service providers could get some funding and also there is the universal services fund which is exactly for providing such services so there could be funding from that as well.
So, getting back to looking at who needs to do what is, I have tried to compile a list. It's for sure it's not complete but anyway you get a rough picture.
For access networks, which means tore Internet service providers, they need to location enable their access lines. So when I connect something to whatever service IP service provider offers, I get a location of that connection.
That is a lot of effort because you have to go through your provisioning system, you have to look whether you have correct data with regard to your lines and so on and so forth and there is a low incentive because actually the access provider doesn't have anything from it, just that he has to have another service that he has to manage. So they cost a lot of money and of could say there is some priority related considerations.
Would your terms and conditions actually allow that you provide location to Internet access lines out there? So a lot of investigation.
On the other hand, the VoIP service providers, they have to recognise, route and priority eyes emergency calls, so they have to implement all the recognition stuff. They have to implement /KWEURG /AOEG a LoST server and so on and so /TPORLT. They have to setup trust relations to operate a LoST server and probably to their own users because it would be very easy to actually forge a location.
Software vendors recollect that's also an important part. Of course that all needs to be supported by the VoIP telephoning clients that we have out there and I'll mention later that we are actually run ago small project where we try to expand such a voice IP client to perform all that functionality.
Piece ups, an interesting point. For the first time in history they need to surface coverage which is a problem for some them because they don't even know T they don't know which calls come to them. They just noted it from experience and it's an interesting point that you have a white spot in some countries or you have overlaps where one PSAP says that we also get calls for that /AOEPBLG and that is because it might depended on which network from which you are calling. So the coverage of the PSAP he is /TPHAOESDZ to be puts into the LoST server so that a client can successfully contact the best PSAP for thinks current location.
And of course if they want something else, then PS D N voice telephoning, they need to ex /PAPBLD their service by implementing inbound gateway into their PB X or by extending their systems to also be able to receive instant messaging and S MS.
That's all very interesting systems and they have of course requirements of high availability and so on and so forth so there is a lot of investigation to be done there.
And someone needs to run a LoST server actually in a country, which takes a location and gives out the respective niece up for the location and also the service coverage and that server needs to be highly available of course because its very course function is that in case of a crisis or something like that, that service must be available because it's the very core of routing emergency calls.
(PSAP is PS A P) there is also a different point, the IT E F S also try to produce a standard that works with all addresses worldwide, but, for example, for every country there needs to be a mapping definition. Like, for example in /AUS re /AEU we have addresses which are (/A*US /AEU) it's the part of house number 24 and now you need to map that to the IT F standardization where you don't have the definition of opposite of something else. So there is to be some work done and you have to coordinate between piece ups and the Government and access providers, particularly Internet access providers recollect it's a very new topic for them, they never before talked to an emergency emergency services providers except they had to use their services.
So that is all that needs to be done in that system.
And related to that, what is the contents of our /O project?
We are investigating the practical application of the / PB standards that are being produced and we are trying to feedback our experience into that. For example, what we have done is we have written a small location enabled access network in a box that is actually an additional package open W R T waive land router, so that you can simply plug it in some where and demo all that stuff.
We are trying to or we are producing an Internet draft about the mapping of /A*US arena dresses to the IT F standards for conveying location information and we are working together with two public service access points to VoIP enable their PB Xs, and we are doing a bit of consulting to PS A P Yours sincerely, to voice up service providers.
There is also an organisational part in all that work and that's why we participate in the /A*US /RAOEPB emergency services forum, that's a forum where Telecom operators, regulators, niece up he is and the Government talk to each other, there are very, very few ISPs and most of them are only there because they are in tell could he also and they are zero voice over service providers and my suggestion is if there is a similar forum in your country, go there at least once and try to make contact with them.
We are also working with the regulator on that pee sap boundary data collection so that we have the date available where each pee sap is responsible for each area and we are doing LoST server /PROET owe type or we are currently in the early stages of planning one. The interesting thing about this is that it's very similar to regard to availability to the domain name service, in terms of requirements and availability. So it makes sense that we, as an established provider of a central infrastructure structure in Austria also looks at this function.
And as with every other company, we are we need to fund that and so for that reason, we have asked the Government for funding for that. And we don't know about the outcome yet, but we will see.
So, a couple of conclusions. The standards are progressing quickly. Essentially, most of the things is all right done.
Implementation of that standards means a lot of effort. The regular later is currently looking into the other direction. They are saying we know that it doesn't work for voice IP but the technology isn't there, so I think that they might change their opinion once the technology is finished it's there to be used (voice over IP) so a suggestion to Internet service providers, I mean watch closely for that and prepare for once you need to location identify your users, especially look at your provisioning systems, whether you keep some kind of addressing data with the local access lines, or with your /WAOEURLS land with your /WAOEURLS provider.
The suggestion to VoIP providers, expect to receive a nice letter from the regulator if you don't properly route emergency calls. I know of a /KUFPL cases where the regulator (couple of) has asked VoIPs to properly route emergency calls, so that's not just theory. And especially watch related consultations because those consultations might affect your business in the next upcoming years.
And a personal conclusion from me. Location information is a big business. There might be additional value to Monday advertise. I don't see how could you do it right now. The simple example is I don't have to event my location if I want to order a /PAOEZ /AEU is probably true, but anyway access providers might be in a position to actually sell the location to somebody else.
So I think that was the last slide. Thank you very much for your attention and I am open to any questions. I am here until Friday morning so you can also approach me in person or right now, if we still have time, yes a couple of minutes.
PATRICK: Questions.
Mike Hughes, links. Question rather than comment. You commented by whether devices have actually got GP S in them. Sat on my desk back in my office is a Nova E 90 and that does have on on board GP S /SHRAOEUPBT as well as a Y /TPAOEU and a zip client T could in fact find itself and tell me where it is. It is one of very few device that is I know of can do that. You are right about them not being widespread but there is such a thing.
SPEAKER: There are other things that GP S doesn't work in a sent base meant for example and that's the reason for Ned work identification is probably the way to go. I mean, I don't want to mention gal lay owe here, but anyway...
Daniel con/PWRUG, I am with RIPE NCC. Thank you for this very good overview of this stuff. I never quite understood where all the pieces fitted, so that helped.
The thing that immediately comes to my mind is the whole LoST stuff is very interesting to /SPAOL. For instance if you want to rob a bank, to tell all the phones there not to call the right place, right.
SPEAKER: Exactly.
Q. Is there anything in the technology that the IT F developed explicitly addressing that sore that just pushed to the lower layers?
SPEAKER: I mean first of all, the LoST protocol itself is running a T L S and there are a couple of discussions around location signing and securing that location, so that it boils down to a cert /KAEUTS and the usual stuff. (Certs) actual the reason why I am doing the slides and not the work behind it because I have a colleague of mine who is investigate that go so I can't answer the question down to the protocol right now but I can come back to you if you like. The
Q. The answer that's identified as being worked on is a good answer. Thank you.
SPEAKER: I have a question from jab /AEU from holiday gay /STKPWHRAOUL /TKPWA. He would like to now /HOE, by which protocol the LoST server is discovered by the client?
SPEAKER: That's a very good yes. Actually there is an Internet draft which delivers the address or the host name of the LoST server via the H C P. So that is one option. And there are also discussions the LoST protocol includes an mechanism where one server can refer to another server. So, you can you can return the result, you can also return the address of another server. So there might be an architecture similar to the DNS route where like you have a route LoST server and that LoST server then refers you like to the net err lands LoST server and the knelt err lands LoST server says, there is a dedicated LoST server nor Amsterdam. So that's the answer in short.
PATRICK: Okay. Are there any other questions?
Okay. Obviously not. Okay. Thank you very much. I'd like to thank all three speakers for keeping absolutely fabulously to time because it's exactly 3:30. We have a 30 minute break for tees, could have /AOES, out the back. Can the speakers for the next session during the break, come up and make your presentations are on the lap top and let your session chair, who is going to be rob, no that your actually here and so forth. Thanks to all the speak E. Enjoy your break. Thank you.
|
|
|
 |
| RELATED TOPICS |
| RESOURCE LINKS |
|
|
|
|
| |
|
you
are here: RIPE -> RIPE
Meetings -> RIPE 55 
