This DNS HOWTO assumes you have Googled the basic setup of your BIND service and master/slave deployment. We will only focus on the 3GPP aspect of the zone file and how you can use it with an ASR5000. The 3GPP specification 29.303 Annex A4.3(S10) Annex 4.11(S11 and S5), 23.003, RFC 2915, and RFC 3958(2.2.3) are the main references used in this HOWTO.
Basic DNS Syntax
Below we show the basic header of a zone file and what each element is and how to use it.In the beginning you will see an $ORIGIN epc.mnc111.mcc222.3gppnetwork.org. value. Every record in the zone file that does not end with a dot will automatically inherit the $ORIGIN value. For example the record foobar does not contain a trailing dot so the BIND service would read it as foobar.epc.mnc111.mcc222.3gppnetwork.org. On the other hand if the record was foobar., BIND would read this as foobar and nothing else.
Now the next item in the top of your zone file will be the TTL field. The TTL is sent to the DNS client of the ASR5000 to let it know when the data expires and it need to do a new DNS query. Please note this TTL value can be overwritten locally on the ASR5000 via the TTL command in the DNS client configuration section.
For the Start of Authority(SOA), you can refer to the zone file snippet used for EPC below. Note that the email in dot form root is just the root user for the system and will likely be different for your deployment.
@ IN SOA ns root ( 1 ; Serial 3600 ; Refresh 30 ; Retry 3600 ; Expire 600 ) ; Negative Cache TTL
Name Authority Pointer (NAPTR) for us will only use two flag types (a & s) which is also called S-NAPTR or Straightforward-NAPTR. In S-NAPTR you will see many service types which are all defined in 23.003 section 19.4.3 “Service and Protocol service names for 3GPP”. The first number in the S-NAPTR RR after the word NAPTR is Order and the second number is Preference. Also note the existence of application service of “x-3gpp-sgw” & “x-3gpp-pgw” with their corresponding application protocol of “x-s5-gtp”. These service represents if its a SGW or PGW while the S5 protocol means both node types support GTP based S5 and not PMIP. Note that since we have NAPTR with flag type “s” for our TAI resolution and gw-selection is co-location, we will not use order or preference in selection criteria unless we have multiple best matches in which case lowest order value will trump.
;TAI S-NAPTR ;TA which exist within the north or south ;North: tac-lb03.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._north tac-lb04.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._north ;South: tac-lb01.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._south tac-lb02.tac-hb00.tac IN NAPTR 100 100 "s" "x-3gpp-sgw:x-s5-gtp" "" _sgw._south ;APN NAPTR ;APN's which exist only on one PGW use NAPTR "a" flag ;North: apnName3.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName3.site3.north apnName4.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName4.site4.north ;South: apnName1.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName1.site1.south apnName2.apn IN NAPTR 100 100 "a" "x-3gpp-pgw:x-s5-gtp" "" topon.s5-pgw.nodeName2.site2.south ;Common APN on all PGW's use NAPTR "s" flag apnName.apn IN NAPTR 100 100 "s" "x-3gpp-pgw:x-s5-gtp" "" _nodes._pgw
Service(SRV) records give you the ability to load balance per weight and set destination port numbers in SRV record. The first number in the SVR record after the word SRV is Priority and the second number is Weight followed by port number. Note that when we have multiple best matches with equal order values in the NAPTR results then we can use priority to tie break (lower better) and weight in the SRV record to balance traffic if priorities were equal(more to add once R14 is released).
;SRV Records for SGW ;North _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName1.site1.north _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName2.site2.north _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName3.site3.south _sgw._north 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName4.site4.south ;South _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName3.site3.south _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName4.site4.south _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName1.site1.north _sgw._south 1800 IN SRV 20 100 2123 topon.s5-sgw.nodeName2.site2.north ;SRV Records for< PGW ;PGW, Equal weight for common apn's. TTL 1800. Port gtp-c v2 is 2123 _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName1.site1.north _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName2.site2.north _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName3.site3.south _nodes._pgw 1800 IN SRV 20 100 2123 topon.s5-pgw.nodeName4.site4.south
A or AAAA are the final record pointing to the IP address of node.
;A records for PGW ;S5 address of PGWs that support GTP based S5 interfaces. topon.s5-pgw.nodeName1.site1.north IN A 220.127.116.11 topon.s5-pgw.nodeName2.site2.north IN A 18.104.22.168 topon.s5-pgw.nodeName3.site3.south IN A 22.214.171.124 topon.s5-pgw.nodeName4.site4.south IN A 126.96.36.199 ;A records for SGW ;S11 addresses of SGWs that support GTP based S5 interfaces. topon.s5-sgw.nodeName1.site1.north IN A 188.8.131.52 topon.s5-sgw.nodeName2.site2.north IN A 184.108.40.206 topon.s5-sgw.nodeName3.site3.south IN A 220.127.116.11 topon.s5-sgw.nodeName4.site4.south IN A 18.104.22.168
Basic MME Configuration (co-location)
Below you will find basic MME configuration to support node selection plus static selection in the event DNS/BIND is down or unreachable. The top element in the structure is the lte-policy/subscriber-map which calls the operator-policy. Then the operator-policy calls the call-control-profile and apn-profile. The call-control-profile below is used to say “use dns look up for both SGW and PGW selection” and if DNS is down use static list TMD1. The static tai management DB is also used to define TA Lists that are sent to UE to inform it about the TA is can move between before it needs to perform a TAU. The important part in the call-control-profile for node selection is the use of gw-selection co-location which tells the MME to use best match of SGW and PGW and longest conical name match. In the example above we would match conical names up to the nodeName# portion of the FQDN. The apn-profile is used for static PGW assignment for when DNS is unreachable.
Please note that if the DNS client gets multiple answers with equal order or preference and we have round-robin-answers enabled in the client, we will round robin across the results on a per service/PCS2 basis. This may result in what looks broken functionality as the first results may get used always until all session managers have done so and move on to next result.
context local operator-policy name OP1 associate call-control-profile CCP1 apn default-apn-profile AP1 #exit call-control-profile CCP1 dns-sgw context GP-GN dns-pgw context GP-GN gw-selection co-location associate tai-mgmt-db TMD1 #exit apn-profile AP1 pgw-address 22.214.171.124 pgw-address 126.96.36.199 pgw-address 188.8.131.52 pgw-address 184.108.40.206 #exit context S1 mme-service MME-SVC associate subscriber-map SM1 exit context GP-GN ip name-servers 220.127.116.11 10.10.10.10 dns-client DNS bind address 18.104.22.168 round-robin-answers #exit GlobalConfig lte-policy subscriber-map SM1 precedence 1 match-criteria all operator-policy-name OP1 exit tai-mgmt-db TMD1 tai-mgmt-obj TMO1 tai mcc 111 mnc 222 tac 1 sgw-address 22.214.171.124 s5-s8-protocol gtp weight 100 sgw-address 126.96.36.199 s5-s8-protocol gtp weight 100 sgw-address 188.8.131.52 s5-s8-protocol gtp weight 100 sgw-address 184.108.40.206 s5-s8-protocol gtp weight 100 #exit tai-mgmt-obj TMO2 tai mcc 111 mnc 222 tac 2 sgw-address 220.127.116.11 s5-s8-protocol gtp weight 100 sgw-address 18.104.22.168 s5-s8-protocol gtp weight 100 sgw-address 22.214.171.124 s5-s8-protocol gtp weight 100 sgw-address 126.96.36.199 s5-s8-protocol gtp weight 100 #exit tai-mgmt-obj TMO4 tai mcc 111 mnc 222 tac 3 sgw-address 188.8.131.52 s5-s8-protocol gtp weight 100 sgw-address 184.108.40.206 s5-s8-protocol gtp weight 100 sgw-address 220.127.116.11 s5-s8-protocol gtp weight 100 sgw-address 18.104.22.168 s5-s8-protocol gtp weight 100 #exit tai-mgmt-obj TMO4 tai mcc 111 mnc 222 tac 4 sgw-address 22.214.171.124 s5-s8-protocol gtp weight 100 sgw-address 126.96.36.199 s5-s8-protocol gtp weight 100 sgw-address 188.8.131.52 s5-s8-protocol gtp weight 100 sgw-address 184.108.40.206 s5-s8-protocol gtp weight 100 #exit
Gateway Selection Logic
Below we detail the co-location gateway selection criteria available in IOS-M R12.2.
- co-location as the determining factor for gateway selection. What this means is the MME will take all records received from DNS and pair together all SGW and PGW with exact conical name match. If failures happen in the pairs, they will be black listed on a per subscriber basis during a attach procedure. Once all the pairs are exhausted from failures during a single attach procedure, the MME will start using all left records as random pairs until success is reached or you run into the four fall back limit mentioned below.
- P/SGW retries configured in egtp service
- P/SGW fall back happens four times per subscriber to the selected nodes equaling total of 5 nodes pair attempts before reject (we only have four co-located pairs in the example).
- If order and priority are all equal and round robin is configured, the MME will use a list for each session manager per PSC card as follows 1,2,3,4,5 to each card for its first sub. Then 2,3,4,5,1 for all PSC cards for it next subscriber and so one as will round robins through the results.
- PGW selection uses Order/Priority on PGW only when more than one PGW is available and only one SGW is available.
|Record Type||Flag||Metric Type||Is it Used?|
|NAPTR||s||Order||Yes, only when DNS returns two or more SGW RRs FQDN length as a tie breaker (lower is better)|
|NAPTR||s||Preference||Used for load balancing in R14 (65535 – value sent by DNS)|
|NAPTR||a||Order||Yes, only when DNS returns two or more SGW RRs FQDN length as a tie breaker (lower is better)|
|NAPTR||a||Preference||Used for load balancing in R14 (65535 – value sent by DNS)|
|SRV||N/A||Priority||Yes, only when DNS returns two or more SGW RRs FQDN length as a tie breaker (lower is better)|
|SRV||N/A||Weight||Yes, When multiple equal length longest matches are returned, this value dictates what percent each will be load balanced. For example if you have two results with priority of 20 and 80 then the 20 result will get 20% of bearer requests and the other will bet 80% per session manager(only in R14.0)|
Below we have a table showing the supported app-service types and app-protocol types.
|Description||IETF RFC 3958 section 6.5 ‘app-service’ name||IETF RFC 3958 section 6.5 ‘app-protocol’ name|
|PGW and interface types supported by the PGW||x-3gpp-pgw||x-s5-gtp|
|SGW and interface types supported by the SGW||x-3gpp-sgw||x-s5-gtp|
|MME and interface types supported by the MME||x-3gpp-mme||x-s10|
- From 3GPP Specification 23.401:
- 220.127.116.11.2 X2-based handover without Serving GW relocation
“The MME determines that the Serving GW can continue to serve the UE” (this means translates 100% to fact that SGW can handle UEs target TA)
- 18.104.22.168.3 X2-based handover with Serving GW relocation
“the MME decides that the Serving GW is to be relocated” (this means translates 100% to fact that SGW cannot handle UEs target TA)
- 22.214.171.124.2 X2-based handover without Serving GW relocation