C.1 S-NAPTR procedure base pseudo-code

29.3033GPPDomain Name System ProceduresRelease 17Stage 3TS

The primary purpose of clause C.1 is to show practically any differences that are normatively documented in clause B.2. The changes to the IETF RFC 3958 [9] pseudo-code make this much clearer and self-contained than the normative text from clause B.2.

The pseudo-code immediately following is the pseudo-code from IETF RFC 3958 [9] Appendix A.1 modified to incorporate the clarifications from clause B.2.

target = [initial domain]

; Next line is changed from Appendix A.1 of RFC 3958

usable-service-protocol-set = [initial desired service and protocol pairs]

naptr-done = false

while (not naptr-done)

{

NAPTR-RRset = [DNSlookup of NAPTR RRs for target]

; Next two lines are changed from Appendix A.1 of RFC 3958

NAPTR weight := 65535 – NAPTR PREF for each RR

[sort NAPTR by ORDER, and by statistical NAPTR weight within each ORDER]

rr-done = false

cur-rr = [first NAPTR RR]

while (not rr-done)

; Next three lines are changed from Appendix A.1 of RFC 3958

compatable-service-protocol-set =[ [usable-service-protocol-set] set interclause with

[SERVICE field of cur-rr] ]

if ([compatable-service-protocol-set] is not empty)

rr-done = true

target= [REPLACEMENT target of NAPTR RR]

; Next line is changed from Appendix A.1 of RFC 3958

usable-service-protocol-set = [compatable-service-protocol-set]

else

cur-rr = [next rr in list]

if (not empty [FLAG in cur-rr])

naptr-done = true

}

port = -1

if ([FLAG in cur-rr is "S"])

{

SRV-RRset = [DNSlookup of SRV RRs for target]

; Next line is changed from Appendix A.1

[Sort SRV RRset using the algorithm described on page 4 of IETF RFC 2782 [8]]

target = [target of first RR of SRV-RRset]

port = [port in first RR of SRV-RRset]

}

; now, whether it was an "S" or an "A" in the NAPTR, we

; have the target for an A record lookup

; Remaining lines are changed from Appendix A.1 of RFC 3958

; or AAAA record lookup

IPv4_hosts = [DNSlookup of A RRs for target]

IPv6_hosts = [DNSlookup of AAAA RRs for target]

randomized order of IPv4_hosts and IPv6_hosts

hostname = [target]

return (hostname, usable-service-protocol-set, IPv4_hosts, IPv6_hosts, port)

The significant differences in the above Pseudo-Code and the IETF RFC 3958 [9] Pseudo-Code are :

A) [Sort SRV RRset using the algorithm described on page 4 of IETF RFC 2782 [8]]
which was changed from
[sort SRV-RRset based on PREF]
The Pseudo-Code in IETF RFC 3958 [9] simply has an error. There isn’t even a PREF in a SRV record. Again see page 4 of IETF RFC 2782 [8] for the proper procedure.
The NAPTR weight is defined to be 65535 – NAPTR preference and is handled analogously to the SRV case.

B) IETF RFC 3958 [9] Appendix A.1 starts with "Assuming the client supports 1 protocol for a particular application" so the pseudo-code obviously was designed for one protocol at a time. The lines with usable-service-protocol-set and compatable-service-protocol-set above are the most important change to support multiple service/protocol combinations and are really the primary reason for providing the above Pseudo-Code.

There are two possible ways to interpret the last paragraph of clause 2.2.5 of IETF RFC 3958 [9] when a list of multiple services/protocols is desired. One is the above interpretation using "set interclause" which allows multiple services/protocols. The other is to run the above procedure for one service and protocol at a time from the "desired service_and_protocol_set" and get a separate list for each service and protocol. In both approaches the relative ordering within a particular service and protocol is identical. If the proper interpretation of IETF RFC 3958 [9] is one service and protocol at a time, then the IETF RFC 3958 [9] does not define order between different service or protocols. Thus 3GPP is free to order between different 3GPP service and protocol types so long as the order within a service and protocol is respected. The above method does respect the order within a service and protocol therefore it is valid in either interpretation of clause 2.2.5 of IETF RFC 3958 [9] and also valid in IETF RFC 3402 [14]).

The remaining changes in Pseudo-Code above are minor and mostly intended to show that the S-NAPTR procedure logically outputs following:

(hostname, usable-service-protocol-set, IPv4_hosts, IPv6_hosts, port)

where the returned hostname is the FQDN of the topologically aware node name with topon/topoff and interface information.

NOTE: Lookup of the A and AAAA records to get the IPv4 and IPv6 addresses may be deferred until they are needed to contact a selected server as an optional optimization.

In the 3GPP scope, a full implementation of RFC 3958 SHALL implement "backtracking" as described by IETF RFC 3958 [9] clause 2.2.4 as required in clause B.2.

For simplicity of the presentation in this Annex we assume a full IETF RFC 3958 [9] implementation with a call back interface as described in Appendix A.2 of the IETF RFC 3958 [9].

procedure S_NAPTR_to_callback(targetFQDN,

desired_service_and_protocol_set,

call_back_function)

where the call_back_function has interface

call_back_function (hostname, usable_service_and_protocol_set, port, IPv4_list,IP6_list)

The call_back_function returns "stop" if it does not want more records otherwise it returns "looking" and will be called with the next record.