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)