Communications between Administrative Domains

[Douglas Clowes]

At 13:20 02/09/98 +0100, Andrew Draper WVdevmt-WS wrote:
>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)?

I don't know where "Back End Services" comes from, but it is in several
diagrams, including one in the copy of Annex G "Communication Between
Administrative Domains" which is sitting on my desk. It may have arrived
there from an ETSI TIPHON liaison, because it also appears in
DTS/TIPHON-02001 "Basic Call Reference Configuration".

I use the term BES to mean both Back End Server(s) and Service(s),
depending on context.

Reference points are depicted between the Gateway and BES, and between the
Gatekeeper and BES, in TIPHON. In Annex G, there is a reference point
between a Border Element and BES.

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

My expectation that, depending on the definition of the services, they
could be colocated with any H.323 entity, or could service the requirements
of any H.323 entity. The services have not yet been identified and defined.
I think they should be, so that we may better understand what is in there
and what is elsewhere.

For example, it's of little use defining how a gateway asks a border
element for a service that is to be provided by BES, if it makes more sense
for that service to be requested of the BES by the gateway.

>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).

No, I think of that as settlement. Billing is more about generating
"telephone bills". Although that is only terminology.

Various aspects of the problem include pricing, identification,
authentication, authorisation, routing, recording, rating, billing and
settlement. How you define them and divide them is an open issue. But, I
think that most/all are in the back end arena.

Pricing involves setting a price for a call. This can be retail (for the
end user) or wholesale (between ADM). It can be simple or complex.

Caller identification (userid), authentication (password), and
authorisation (permission) is complex and many-faceted problem.

Routing ("call routing" vs any other kind) involves destination location.
This would include address translation, both in the context of the caller
(abbreviated dialling) and the callee (call-forward), as well as gateway
dial through.

Call detail recording is logging the usage information for purposes such as
billing, settlement, fault isolation, performance management, capacity
planning, etc.

Rating involves combining the pricing information, and the usage
information to determine the cost of the call, both to the caller and for
interdomain settlement.

Billing involves sending billing information to customer sccounting
systems, and all that downstream money-type stuff that accountants and
shareholders love.

Settlement is the process of, well settling the debts between ADMs. This
may be anything from a net dollar value, to complex reconcilliation of
respective usage information to verify the numbers.

>> 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.

I would prefer that a SETUP message not be sent unless it has been
authorised. Even if the authorisation process is a null function, as it
might be in a private domain.

By combining several of the functions above, address resolution will
provide a destination address only if the user has been identified ... and
a suitably authorised destination can be located (by the BES).

Whether the access request to the BES is made by the gateway before the
ARQ, or by the GK on receipt of the ARQ, is also open to discussion, but
it's around that timeframe, and it results in a destination address which
could be a transport address or an alias. In my view, it should be a
sequence of destination addresses, allowing for line hunt, load shedding,
and fail over.

Much of the communication between the domains, IMO, should be between the
BES, rather than the GK. In effect, the BES is the Border Element, although
not at the call signalling level.

>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.

I tend to think that one service request to the BES, from either H.323
endpoint (EP) or gatekeeper (GK) should be an "Access Request" which
encompasses several of the above.

The request should include information to identify the caller, information
about the endpoint and its environment, and destination information (e.g.
dialled number).

The BES can look at all of this information to determine whether access
will be granted (the call authorised), and what the effective destination
will be.

The response to this request will include the new destination information,
possibly new caller identity information, and a (complex) authorisation
token to be included in the SETUP. Or failure.

The new destination information, and possibly new source information from
the BES, are placed in the ARQ to the GK. That destination information may
be an alias known to the GK, but more likely would be a transport address.

The complex authorisation token, in the SETUP message, will be validated by
the BES of the destination, through a "Validation Request". The SETUP
message could be EP-EP or GK routed, but does not need to go through a
Border Element.

I fully expect there to be exchanges between the BES in different ADMs. It
will probably be a "Access Request" which identifies the source ADM as the
call originator for settlement purposes. It will return an authorisation
token that is valid for the destination endpoint in the destination ADM. It
is that token (possibly combined with source ADM stuff) that is returned to
the endpoint in the response to the original "Access Request". The SETUP
message carries a token that authorises the call from the destination EP's
BES.

This inter-BES exchange also allows the destination BES to do the address
translation in its own context, and select the appropriate destination
without every BES having to know it all.

BES location becomes an issue. I'm expecting relationships to exist which
expose BES in other ADM that will accept calls. DNS may be applied, or the
Access Request may be multicast like LRQ.

>> 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.

Price and cost are (almost) unrelated, but we usually try to ensure that
the price we charge is greater than the cost we incur. As a service
provider, I will have a retail price list that I charge my customers for
sourcing calls, and a wholesale price list that I charge other service
providers for terminating calls.

When I place a call between ADM, whether sourcing or terminating, I want to
get paid for it. So, I want to record it. In addition, if I'm sourcing it,
I expect to get a bill for it from the other domain at settlement time. I
would like to have an idea beforehand, from my own records, what my
exposure is. I would also like to have some idea about the veracity of the
settlement account, so I would like to reconcile my records with theirs if
there is any questions or discrepancies.

That's a long way of saying call detail recording is everyone's issue.

>> 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?

I suspect that it depends on the complexity of your business application,
and how integrated you want it to be. In my mind, however, it is one
(logical) server.

>>                            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).

If the inter-domain communication is BES-BES then it is not GK-GK. It still
happens though.

If there are parts of the puzzle that can only be provided by BES, and
BES-BES communications, ten either the GK needs to *be* a BES, or the GK-GK
stuff goes up a level and becomes BES-BES.

If the BES is doing all of this, maybe there isn't a need for a BE? Or the
BES *is* a BE?

>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
>are.
>
>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
>made.
>
>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.

I'm not sure if, by setup requirements, you mean "security and business
requirements" or the sort of thing that's in "capability exchange".

>Hope this makes sense (and my assumptions aren't too wildly different from
>yours).

In the main, I think they match. But you assume a BE and I assume a BES and
that's leading us down different paths.

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

Most of the functionality of the GK has been fairly low level so far. Much
of the functionality of BES is more complex. If we divide the functions
between them so as to allow a GK to remain a "simple" device, it does not
preclude the BES and GK being coresident, if desired. It would, however,
allow a fairly simple GK to be deployed that specialises in zone management
and, as someone else put it, has zero angular momentum (no disks).

That's why I say lets define what is in Back End Services and we may then
see that some of this functionality that is being shoehorned into
inter-gatekeeper really belongs in inter-BES.


Regards,

Douglas