Subject: RE: [Enum] IP-Telecoms Interworking Workshop 25-27 January 2000 at ITU

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 2 Feb 2000 12:54:21 -0500

Shaw, Robert [mailto:[email-masked]] wrote:

> Material, PowerPoint presentations, and results are at
> http://www.itu.int/ITU-T/ip-telecoms/ip-telecoms.htm

The very interesting "Interworking Between Public Data Networks and the
Internet" presentation by Peter Hicks I think lays out the whole problem
that enum has to work to support (not solve per se, but support other
efforts that will solve this generic interworking problem).

I suggest that what the above presentation is asking for is precisely the
opposite (photographic negative) of the Next Hop Resolution Protocol (RFC
2332). NHRP assumes the end user can be any old IP host, connected even to a
standard Ethernet/IP net, and that an intervening ATM network can either
carry the IP datagrams part way to the final destination, or perhaps the
final destination is an IP over ATM host.

Peter Hicks' problem is to have a telephone call over the Public Data
Network (PDN), say ATM or FR, perhaps travel to the destination over an IP
network, and (I suggest) the end station may or may _not_ be an IP host. It
should not be mandatory that the destination be IP for the call to be
carried over an IP net -- perhaps only part way between source and
destination.

How does NHRP solve the reverse problem? By supporting a network of VCs
between ATM switches which are also IP routers. The ingress switch, when it
sees the first IP packet arrive, uses the IP destination address to find an
efficient IP route across the ATM net, using standard IP routing. Then, when
the closest ATM switch to the final IP destination is reached (which might
not be connected to the destination host), this final ATM switch sends back
an NHRP reply to the ingress switch, with its (the egress switch's) ATM
address. Now the ingress ATM switch establishes a direct ATM SVC to this ATM
switch closest to the IP destination. The data packets are then sent on this
direct path SVC. Where alternate routes are possible, the route which
directly supports the longest IP prefix toward the destination IP address is
used.

Note that NHRP does not mandate that the final destination be ATM-connected.
ATM can just be an island net between source and destination hosts. But _if_
the destination were ATM-connected, with an ATM address (AESA), and _if_ the
DNS could directly respond with such an address when queried by the ingress
ATM switch, then some of this NHRP process could be eliminated. The direct
SVC could be established more quickly.

The inverse could be done here. The PDN signaling message is intercepted by
an E.164-aware IP router at the ingress of the IP net. Assuming enum is a
fact, the ingress router queries DNS to see if the destination E.164 number
has an IP address as well. If it does, then all PDN PDUs are encapsulated in
UDP/IP packets and sent to that destination, presumably with some
preparatory "signaling" packets to indicate that a streaming audio session
is about to begin. This can all be best effort or diffserv, or maybe the PDN
signaling message can be used to initiate an RSVP PATH/RESV transaction
somehow. But I don't think we should obsess over RSVP. The presumption here
is that a connectionless method, best effort or diffserv, will suffice to
provide the QoS needed.

If the DNS enum does _not_ provide an IP address for that E.164 destination,
the the IP network maintains a routing table of E.164 (hierarchical) numbers
and best IP egress router for that number (the opposite of the network of
VCs between IP routers in the ATM case). The PDN PDUs are sent through the
IP network, and the egress E.164-aware router has the task of generating the
PDN signaling sequence to the destination PDN host, and forwarding the PDUs
on this circuit.

The role enum is pretty limited with respect to the whole problem, but I
think the DNS can fairly easily support this useful role.

Also, if the calling party on the PDN has strict QoS requirements in his
SETUP message, it is perfectly fair to bypass the IP network entirely _if_
the IP ingress router deems the QoS requirement to be beyond what it can
handle.

Bert
[email-masked]

_______________________________________________
enum mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/enum

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Feb 2000 15:02:38 -0500

> is that a connectionless method, best effort or diffserv, will suffice to

I do not agree here, for two reasons. First, I think you are a layer
below where we need to be. The e.164 resolution process is not for some
kind of layer 3 routing function, as you imply. It is for applications.
Thats why enum returns a URI, not an IP address.

Secondly, the function you are seeking here is more of a routing
function; I know that I need to get to some PSTN terminal with some
e.164 number, and I need a gateway to get there. This is handled by
TRIP, not enum. Furthermore, corrupting the IP routing infrastructure
with E.164 addresses, as you suggest (I think) below, is a sure way to
crash the Internet. No thanks. We debated that on the iptel list and is
was unanimously rejected.

> PDN signaling sequence to the destination PDN host, and forwarding the PDUs

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com