Transcript Process Overview #2

DP POP Integration with
Inmarsat for BGAN Services
CN Team
Version 0.93 Q1 2014
Introduction
This presentation describes the process involved when a DP
wants to connect their own POP to Inmarsat’s BGAN network.
The description focuses on connecting at Amsterdam Telecity,
& New York Telx.
There is also potential to connect directly into Paumalu and
Burum SAS.
DPs can also connect into the Sydney MMP, although this
requires a dedicated APN.
Technical Overview
BGAN Network 2014
I4F3
I4F1
I4F2
China FRG
DP POPS
DP POPS
HKG
MMP
Spare
Paumalu
Burum
SAS Core
Network
Inmarsat Edge Routers
STM1
HKColo MMP, Hong Kong
PAUMALU
MMP
Sydney FRG
BURUM
MMP
SYDNEY
MMP
Fucino
STM1
SAS Core
Network
Internet
(Special
conditions
apply)
SAS
Network
SAS
Network
100Mbit
STM1
DP POPS
DS3
NYC MMP
AMS MMP
Inmarsat Edge Routers
DP POPS
SAS DCN
DS3
DP POPS
Telex MMP, New York
Inmarsat Edge Routers
Telecity MMP, Amsterdam
SAS Core
Network
DP POPS
Basic DP POP Design at the MMP
How Traffic Routing to a DP POP is
done
Within the BGAN core network and RAN, user traffic is separated through
the use of GTP tunnels, bearer connections and other mechanisms
From the GGSN to the DP’s network user traffic is routed using IPSec or
GRE tunnels. This allows DPs to use overlapping private address ranges
and ensures traffic separation between different DPs
All traffic originating from a user terminal (UT) will be sent to the DP’s
network through the tunnel. The DP is responsible for ensuring that traffic
destined for a specific user is routed back through the tunnel to the
GGSN.
If the DP wishes to allow user to user communication then normally they
must loop this traffic around within their POP/network. However this can
also be done in the GGSN if preferred.
Connecting to Inmarsat at a Meet Me
Point
Inmarsat uses two carrier class routers operating in primary/secondary
mode at each MMP.
The DP may have one or two routers on their side of the interconnect
point but must connect to both Inmarsat routers.
Inmarsat’s preference is that the DP has a direct connection using
Ethernet.
E1 terminations are not supported.
Once the connection details are decided, Inmarsat will provide details of
its circuit IDs and physical connection points in the required MMP.
Inmarsat will also allocate the IP addresses for the termination interfaces
at both ends of the interconnect.
NOTE: It is the DPs responsibility to arrange for any cabling/patching
necessary to connect to Inmarsat at Telecity / Telex / HarbourMSP. This
process can be protracted and should not be underestimated.
Design Considerations for Resiliency
Usually static routes will be used between the Inmarsat
routers at the MMP and the DP’s equipment. If the
interconnect is not a point-to-point connection, it will be
necessary to run a routing protocol such as BGP to monitor
up/down connectivity.
DPs should consider the use of loopback addresses rather
than physical interface addresses for flexibility.
The tunnel endpoint should be a VIP that can be shared
between two physical devices and the tunnel should end
behind the point of physical interconnect.
It is possible to use the internet as a last resort for routing
traffic between the Burum SAS and the DP’s POP and this
can be discussed further if desired.
POP Design Requirements
The DP tunnel endpoint, whether IPSEC or GRE, must use a
globally unique public IP address. This is to avoid any overlap of
private IP addressing schemes used within the Inmarsat BGAN
network.
The tunnel ACL scope proposed by the GGSN must be any-any.
This is so any future expansion of the UT address ranges will not
result in tunnel ACL modification or outages.
Ideally the traffic tunnels from the GGSN to the POP (if carried
across private links) should remain unencrypted. IPSEC AH-Only is
the most commonly used tunnel type. Be aware though that this
type of tunnel is not supported on Cisco ASA firewalls IOS 7.x or
later.
POP Requirements Continued
The MTU size before tunnel encapsulation is depends on the
tunnel type used and the transform set. Fragmented packets are
supported.
By default all connections established by a terminal are
processed by a TCP accelerator (PEP) in the BGAN network.
This can be disabled if preferred.
The TCP accelerator will normally enforce the TCP MSS limit but
in case the PEP is unavailable the DP should do this as
mentioned above.
RADIUS Requirements
DPs should plan on providing their own radius capability. The best
solution is a primary and a secondary radius server with full
redundancy and replication between each.
Primary / secondary RADIUS servers should share current user
address assignments in the case of failover.
Ideally the IP address of the radius servers should be a public
address but this is not mandatory.
The address of the radius servers and any other network service
nodes must not be in the UT address range.
Inmarsat does not mandate the use of any particular radius server
but the chosen server must support the standard 3GPP
extensions.
APN Requirements
If the DP’s customers require private DNS services then this must
be provided by the DP, it cannot be provided by Inmarsat. DPs can
allocate primary and secondary DNS addresses in the radius
Access-Accept message. If necessary the GGSN can allocate the
DNS addresses on a per APN basis.
Capacity on Fast Ethernet ports is restricted to 4 Mbit/s per DP by
default in the DP->Inmarsat direction. This can be changed if the
traffic levels justify raising the threshold.
If providing a gateway to the internet, DPs should have firewall and
monitoring capability in place to prevent unwanted traffic such as
port scanning and DOS attacks being sent to their customers and
wasting bandwidth. Inmarsat does not filter any traffic either to or
from satellite terminal devices.
QoS Considerations
Traffic from the GGSN will be marked as follows
º
º
Streaming class – DSCP 10 (AF11)
Background class – DSCP 0 (BE)
To-mobile traffic from the DPs POP should be marked in the
same way to give priority to streaming class.
Through the BSS a DP can provision users with a maximum
streaming rate of either 32kbit/s, 64kbit/s, 128kbit/s, 256kbit/s
or 384+kbit/s. Background class (standard IP) is provisioned
at 512kbit/s as standard irrespective of the maximum
streaming rate allowed.
Process Overview for Arranging
an APN and Establishing an
Interconnect with Inmarsat
Process Overview #1
Before deciding that a POP is necessary the DP should take the time
to read the interconnect documents as these contain detailed
information about Inmarsat’s network and the options available
including the use of the shared infrastructure.
Once a decision has been made to implement a fully fledged POP
with a dedicated APN the DP needs to fill out the “DP Questionnaire”
which is the key document used to capture all of the information
necessary for both Inmarsat and the DP to carry out the required
configuration work in their networks.
The DP questionnaire will contain the physical interconnect details
and the APN details.
Process Overview #2
The first step in the process is to arrange the physical interconnection.
Inmarsat will not carry out any other network configuration until this
has been done and connectivity proven.
To arrange the physical connection at the chosen MMP the DP will
use the information provided in the Questionnaire and ask the
helpdesk at the MMP to do the work.
The MMP will contact Inmarsat to issue a letter of authority (LOA) to
proceed with the connection. Once this has been done the physical
connection will be made.
The DP must use the /30 addresses provided by Inmarsat to configure
the interfaces on their equipment where the physical connection
terminates.
Once completed it will be possible to ping between the termination
interfaces on both sides.
Process Overview #3
Inmarsat will provide a checklist of tasks to be completed by the DP
and once the DP confirms that this has been done Inmarsat will
complete the remaining configuration in its network.
When the configuration is complete, Inmarsat will work with the DP to
establish the traffic tunnel from the GGSN to the POP and set up a
PDP context.
Once this has been achieved, the DP will be free to carry on their own
testing. However Inmarsat requires that the DP completes the relevant
tests detailed in the DP APN test plan matrix. This is a self certification
process, but based on experience Inmarsat has found that this range
of tests should ensure everything is working correctly and will give the
DP an appreciation of the performance their customers can expect.
Process Overview #4
During the initial testing of the APN by the DP and Inmarsat, the
number of active PDP contexts will be limited until the APN is
announced as live.
When the DP has completed the required tests they must submit a
test report to Inmarsat for review.
The DP must also provide contact details for support staff and any
escalation procedures if appropriate. These will be passed to the
Inmarsat NOC in London and to the SAS Controllers.
Once Inmarsat has reviewed the test report and carried out any
independent testing deemed necessary the POP will be considered as
live and treated as such by the Operations team.
Connection to Inmarsat BSS
To receive billing CDRs from the Inmarsat BSS, Secure FTP
protocol is used to transfer CDRs from Inmarsat London to the
DP’s billing system.
There are 2 sites to connect to; the live and backup site. This
can be performed across the internet.
DP Engineer Pre-requisites
DP engineers need to possess extensive technical skills.
They should have an IP background with IPSec VPN, BGP,
routing, RADIUS knowledge.
Experience of dealing with carrier data centres an advantage.
Timelines to implement POP
interconnect activities
Initial discussion and agreement on parameters for BSS,
Interconnect and APN – 2 weeks
MMP physical connection on Inmarsat side – 2 weeks (This
doesn’t include DP cabling to MMR)
Interconnect and DCN access for APN – 1 week
BSS VPN – 1 week
APN, APN DNS & HLR configuration – 1 week
Time to complete APN Test Matrix; up to DP, but approx 1
week.
(Some of the activities above can be undertaken in parallel)