Presentation Transcript
Slide1 : Global IP Network Mobility
using Border Gateway Protocol (BGP)
Brian L. Skeen
brian.l.skeen@boeing.com
BGP Network Mobility : BGP Network Mobility Connexion Service Summary
Current IP Mobility standards
Network and Service Challenges
BGP as a mobility solution
Questions
Enabling 2-Way Onboard Communications Services… : Enabling 2-Way Onboard Communications Services… To Passengers:
Real-time, Internet Access
VPN Support
Connectivity throughout their travel experience
Extending commonly known hotspot connection method
Television to Singapore Airlines in 2005 To Airlines:
Simple cabin design
Reliable and robust system
Use wireless to reduce weight & power
Real-time crew information services
E-Enabled Aircraft Initiatives
802.11 HotSpot In The Sky : 802.11 HotSpot In The Sky Notional representation
Slide5 : Data Transceiver & Router Antenna Ground Stations Enterprise & Network Operations Centers Internet Core Network Unit Antenna
Controller Connexion by Boeing – System Architecture
2004 Service Region : 2004 Service Region Satellite Network Operations Center (NOC)
Ground Station & Data Center 75o 60o 45o 0o -15o -30o -45o Latitude Ground Station
Current Mobility Standards : Current Mobility Standards Target host mobility rather than network mobility
Mobile IP protocols for IPv4 & IPv6
Require mobility support in protocol stacks
Do not provide “intuitive routing” over a wide geographic area
Network Mobility only being seriously addressed in IPv6, through the NEMO working group. NEMO Basic Support Protocol (under development) relies heavily on IP tunneling
Routing optimization is limited to within a BGP autonomous system
Network & Service Goals & Challenges : Network & Service Goals & Challenges Our network challenges are unique in a number of areas
Our platforms move,
But not just a little…they also move fast
Hosts remain stationary with regard to the platform
Hosts may number in the hundreds
A typical flight between Europe & Asia will use 3 different ground stations and 4 satellite transponders within half a day
Leads to a desire for seamless handoff between satellite transponders and between ground stations
The Latency Tax : The Latency Tax Using BGP allows us to directly influence traffic within the Internet as a whole and not just within our own network
Mobile IP protocols are not optimized for the vast distances that a jet aircraft normally travels in a single day. Most rely on tunneling & static homing which adds large latencies when the mobile router is not near the home router
For Example: Latency with an aircraft homed in Europe currently over east-Asia to an Asia website - one-way
320ms – Aircraft -> geo-synchronous satellite -> ground East Asia
130ms – Asia -> North America
70ms – East Across North America
80ms – North America to Europe
80ms – Europe to North America
70ms – West Across North America
130ms – North America -> Asia
30ms – Within Asia
890ms Total
Almost 2.7 seconds to complete a TCP 3-way handshake!!!
Finding a better path through the ether… : Finding a better path through the ether… Find a better way to route traffic, reduce latency, improve network reliability, and allow for global connectivity
Static homing & tunneling solutions would require us to provision a substantial global IP backbone to carry the backhauled traffic. These WAN costs would be substantial
The solution needed to allow seamless user connections throughout a flight
The solution needed to leverage existing routing technology, couldn’t require outside networks to make changes to accommodate our mobile platforms & needed to be acceptable to network operators worldwide
In general, traffic flows should follow geography!
Our solution: Leverage BGP
Natively supported worldwide
Uses the global routing table for mobility
Selective announcement and withdrawal mobile platform prefixes as the platforms move
Fighting Latency Back : Fighting Latency Back Instead of having mobile platforms homed to a specific geographic network, send & receive the mobile network traffic to & from the Internet at each satellite ground station
For Example: Aircraft dynamically homed in Asia to Asian website
320ms – Aircraft -> geo-synchronous satellite -> ground East Asia
40ms – within Asia
380ms Total
1.1 seconds to complete a TCP handshake
1.6 seconds or 56% reduction TCP handshake time
Using BGP for mobile routing : Asian
Gateway
ASN 23918 US
Gateway
ASN 30533 European
Gateway
ASN 29257 Commercial passenger traffic is released at each ground station
Each ground station only advertises the IP’s for the planes it is serving.
When a plane leaves a region, that gateway stops advertising its IP’s. Announce Mobile Netblocks
Internet X.Y.Z.0/24 Using BGP for mobile routing Announce Mobile Netblocks
X.Y.Z.0/24 X.Y.Z.0/24 X.Y.Z.0/24
Connexion Network Architecture : Connexion Network Architecture Internet Route Servers ISP #2 ISP #1 BGP Route Reflectors iBGP Peering eBGP Peering
Challenges using BGP for Mobility : Challenges using BGP for Mobility /24 network propagation
Concerns about the growing number of BGP routes in the global default free zone have caused some network providers to filter smaller route announcements
We currently advertise a /24 address block for each mobile platform. Testing of route propagation found that most providers will accept and propagate our /24 announcements
In the event that some providers don’t accept our /24 announcements we are advertising a larger aggregate containing all of the mobile platforms
We only really require all of our Internet providers to exchange our routes among themselves, mobile platform routes could be filtered at the edge of the network without a loss of connectivity
Challenges using BGP for Mobility : Challenges using BGP for Mobility BGP convergence vs. handoff time between ground stations
Our testing has shown that the period of time required to achieve 2-way communications on a new satellite transponder is complementary to the time BGP will converge on global providers
Provider concerns
Prefix churn
route changes happen only a few times a day
As a percentage of total global route-updates our updates are very small
Prefixes may have an “inconsistent” origin ASN
Currently originates at the active ground station
Changes when platform moves…
… but does not originate from two places at once
Prefix Transition in Action : Prefix Transition in Action An actual Lufthansa flight from East-Asia to Europe
November 17, 2004 01:00 -> 19:00 UTC
BGP update collectors located throughout the globe collected mobile platform BGP updates as seen from their point of view
This shows the transition process from one ground station to another
Each number on the plot represents a BGP autonomous system
Red spots represent the originating autonomous system numbers
BGP data modeling and extraction provided by the route-views project from the University of Oregon
http://www.routeviews.org/
Routes Announced from Ibaraki, Japan : Routes Announced from Ibaraki, Japan Ibaraki
Ground Station AS Moscow
Ground Station AS Leuk
Ground Station AS SCC PoweredCom
ISP AS Internap Japan
ISP AS
Routes Announced from Moscow, Russia : Routes Announced from Moscow, Russia KPN
ISP AS TeliaSonera
ISP AS
Routes Announced from Leuk, Switzerland : Routes Announced from Leuk, Switzerland KPN
ISP AS Sprint
ISP AS
Route Flapping and Dampening : Route Flapping and Dampening Route Flapping and Dampening
Will our routes be dampened by some providers?
Testing & research has shown that a single route update is unlikely to cause a route to be dampened by core networks. We see some dampening after about 5 changes within a short period of time. Dampening for global network operators is also not as popular as it used to be
We always announce a stable aggregate “safety net” for our mobile platforms to ensure a stable path from the dark corners of the Internet
Satellite handoff within a ground station: A ground station may serve more than one satellite transponder. When a handoff occurs within a ground station, we do not propagate a route withdrawal beyond our autonomous system
Future Prefix Management : Future Prefix Management Dynamic Prefix Management
A system that could allow for mobile platforms to “lease” address blocks for the duration of a “flight”. Similar to DHCP for hosts. This will allow for more efficient use of address space
Regionalization of address space
Address blocks can also be regionalized. Certain “flights” generally stay within the service of a single ground station
By noting which “flights” will be served by a single ground station, we can then assign address space from a larger aggregate which is tied to the ground station. This will allow us to not announce specific blocks for flights when they are not needed
Conclusions : Conclusions BGP as a Mobility Solution
Does not require special IP stacks on customer hosts
Does not require special routing onboard the mobile platform
Does not require any special treatment of BGP attributes
Does not require special operational support from peers
Only suitable for /24 and bigger networks
Special thanks to all members of the Connexion Network Team
Gordon Letney, Andrew Dul, Terry Davis, Carlos Montes, Ben Abarbanel
Slide23 : Thank you http://www.connexionbyboeing.com
Catch the
buzz on authorSTREAM
Copyright © 2002-2008 authorSTREAM. All rights reserved.