Communications between Administrative Domains

Andrew Draper WVdevmt-WS adraper at DEV.MADGE.COM
Wed Sep 2 08:20:42 EDT 1998

On Wed, 2 Sep 1998 10:37:32 +1000 Douglas Clowes wrote:
> From my POV, this underscores the need for thought on the Back End
> Services, both in terms of the services to be offered, and the protocol(s)
> to support those services.

Just for my information, where does the term Back End Services come from?
Is this related to some sort of protocol currently run by telcos (SS7
database services for example)?

Does the term always refer to a third server somewhere else which
communicates with both the originating and destination border elements?

While discussing billing, I assume that we are only discussing payment from
the originating administrative domain to the destination administrative
domain and that we are not discussing payment to the transport network
providers (such as ISPs) for QoS connections (such as those set up by RSVP).

> Here, it is fairly clear that authentication and billing is a Back End
> Service. The available destinations for a call may be dependent on the
> (authenticated) identity of the caller.

Yes, I agree that some entities will reject SETUP messages which are not
authenticated and do not provide a suitable payment token.  However, I
think we should try hard to design a protocol which will not cause
hopeless (bound to fail) SETUP messages to be sent.  This is important
because a) SETUP messages create state in the recipient and b) SETUP
messages may involve charges to the originating administrative domain.

Later on in this message I use the term "setup requirements" to refer to a
description of setup messages which the destination administrative domain
will accept.  Examples would be "you must authenticate using mechanism X
(and server Y)" or "you must pay using method Z" (are there any other forms
of setup requirement?).  I use the term "setup capabilities" to refer to
the set of mechanisms which the originating border element is able to send
in a SETUP message (because they have been implemented and enabled).

>                                         The "token" to be included in the
> Setup message is produced by the Back End Service and may well be
> destination sensitive.

I agree.

>                        Which raises the possibility of address translation
> also being a back end service.

In the sense of having a third party server (not belonging to the
originating or destination administrative domain) perform address
translation I agree.

> Back-End Services (may) include:
> o caller identification, authentication, and authorisation;
> o address translation, gateway location;
> o call pricing;
> o call detail recording, billing, and settlement;

By my understanding of the term back-end services (which might be wrong)
call pricing is for the destination administrative domain and is unrelated
to any third party server.  Call detail recording is also a problem only
for the destination administrative domain.

> which are all interrelated

Out of interest, are you expecting/requiring that the services provided by
each of your bullet points must be provided by the same third party server
(or would using one server for address translation and another for billing
be acceptable).  If not then how are they all interrelated?

>                            and, in total, outside the scope of the
> gatekeeper to gatekeeper communications.

I disagree.  Here are my reasons for thinking that identifying the
requirements of the destination administrative domain fall within the scope
of communications between administrative domains (an important subset of
gatekeeper-gatekeeper communications).

To prevent hopeless SETUP messages from being sent the originating border
element (or a third party) needs to work out the intersection of its setup
capabilities and the destination border element's setup requirements.

As far as I can tell there are three ways for the originating BE to find
out the destination administration domain's setup requirements:

a) It can find out during the resolution stage (the stage where an email-ID
or E.164 number is translated to the address of a border element).

b) It can find out during the LRQ/LCF exchange.

c) We could design an extra protocol which is used before/after LRQ/LCF to
let the originating BE find out what the requirements of the destination BE

For an email-ID type destinationAddress using the DNS to find the
destination border element seems non-controversial.  DNS only provides the
name and address of the destination, so method a is not appropriate.

In this case I favour method b over method c for two reasons: firstly
because it reduces the number of round trips required for a call setup and
secondly because requirement 7 (of the latest annex G draft "diff0201.doc")
suggests that the minimum number of changes to existing protocols should be

The E.164 to border element address protocol is as yet unspecified, so it
could return the requirements of the destination administrative domain at
the same time as it returns the address to which to send LRQ.

If the E.164 number resolves to an administrative domain which can be
contacted directly then this doesn't seem to help much (as only one address
is provided to which an LRQ must be sent anyway - so there are no
efficiency savings to be made).

If the E.164 number would resolve to one or more third party gateways (eg.
for a POTS number) then passing the setup capabilities of the originating
border element might help narrow down the responses which the resolution
server returns.  However this has security implications and so should be a
choice for the originating BE.  We still need a mechanism for the
originating BE to ask the destination BE about its setup requirements if it
is being paranoid and not telling the resolution server.

Hope this makes sense (and my assumptions aren't too wildly different from



Andrew Draper - Principal Development Engineer - WAVE Software
Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks.
mailto:adraper at  phone:+44 1753 661329
pgp fingerprint D6 ED 72 4F 96 BB CA 2D  68 74 4C E0 CB B9 0B 3F

More information about the sg16-avd mailing list