Subject: RE: [Ieprep] access links

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 14 Nov 2002 11:48:56 -0500

I absolutely agree with the part of your reply copied below.  

In fact, the GETS users may not be willing to pay ANYTHING until some crisis
occurs in which important communications don't get through.  This is what
happened with wireless/mobile phones.  There had been, for several years, an
under funded, "back burner" project looking at extending GETS-like service
to mobile phones, with  5 year and 10 year objectives.  On and after
September 11,  various emergency personnel discovered that GETS worked great
on a landline phone, or on a mobile phone in an uncongested area, but a
mobile phone in a congested area never even got a chance to place the GETS
call.  Suddenly the user community was willing to pay for a Wireless
Priority Service, and the 5 and 10 year plans became 1 and 2 year plans.
Which it looks as if we are actually going to be able to do.

One of the main reasons we are able to do this rapid implementation is
because there are parameters already there in the  ISUP IAM (e.g.., the HPC
value for the CPC parameter, and the Precedence parameter) that we could
use.  There has been extensive software development by the switch vendors,
and a lot of effort from the carriers, but if the parameters had not already
been there in the protocol, we could not possibly meet the schedule.

I foresee that, at some point in the future, something similar will happen
with IP telephony, or other Internet functionality.  Some crisis will
happen- GETS will work fine for the regular phones.  WPS will work fine for
the mobile phones.  But the emergency users who try to use a SIP phone won't
get through.   Or an important video feed won't get through.  (Possibly
because of congestion in an IP network, but more likely because of
congestion in, or at the interface to, a circuit switched network which is
part of the end-to-end path).

When that happens, the user community (and/or the government on their
behalf) will be prepared to fund a project to solve that problem.  When that
happens, and whatever the exact nature of the problem, or the appropriate
solution, it will be A WHOLE LOT EASIER if there are already parameters in
the protocol suite to indicate which "calls" (or other services) are
entitled to priority service.

My perception is that at least PART of the objective of IEPREP is to make
sure that the parameters, or other "hooks" are already there in the protocol
suite, so that when we DO have a SPECIFIC problem, with a SPECIFIC solution,
we can rapidly implement the solution. (Scott, correct me if I am wrong
here.)

We can't see the future, so we can't tell EXACTLY what the problem will be.
And what we think will be problems in the future is heavily influenced by
what we have seen be problems in the past.  So we want to structure any
enhancements to the protocol suite in as generic a way as possible.

But I don't think it is wise to say "Lets not even think about how we can
prepare for it until the crisis occurs."

As I said in another message, I am MOST concerned with what happens at the
interface between the IP and the circuit switched network.  But let's
structure what we do there in such a way that IF some kind of "special
service" is needed within the IP network (including access links and private
networks, not just the ISP's core network), there will be parameters that
can be used in conjunction with that "special service".

-----Original Message-----
From: Bill Woodcock [mailto:[email-masked]]
Sent: Thursday, November 14, 2002 7:33 AM
To: Gunn, Janet
Cc: 'Dean'; RJ Atkinson; ieprep
Subject: RE: [Ieprep] access links 

I think part of Rex's point is that if the GETS users had a voice here,
they'd be asking for a less expensive solution that would provide
functionality more of the time..

                                -Bill

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Scott Bradner <[email-masked]>
Date: Thu, 14 Nov 2002 14:22:21 -0500 (EST)

> can be used in conjunction with that "special service".

this fits my picture of what we should be focusing on

plus - developing a clear understanding on where doing something
specific to support for "special service" in an IP network may be
need and where is is not likly to be needed

e.g. - it is unlikly that one needs "special service" functions inside
of a big, fiber-based, mesh-based ISP since that part of the net
will provide the required service without any special handling of the
packets (data or signaling packets)

but it is unlikly that someone with a narrow tail circuit will
get the "required service" (quality that is - note that call 
completion is mostly a given ) as-is in times of heavy load, whatever
the cause of the heavy load

the inability of the tail circuit to support the load could be 
delt with by getting a fatter tail circuit or by handling packets
differently on the narrow link

figuing out if there are reasonable ways to do the latter should
come after we figure out a better description of the cases where
'don't do anything' is the right answer

Scott

---

From: Bill Woodcock <[email-masked]>
Date: Thu, 14 Nov 2002 12:14:37 -0800 (PST)

On Thu, 14 Nov 2002, Gunn, Janet wrote:
    > interface between the IP and the circuit switched network.

Currently, that handoff is most commonly NxPRI, according to the
couple of people who've commented, and my own admittedly limited
experience.  I'm assuming that GETS-like information is not currently, or
cannot be contained in PRI signalling, just SS7?  Or is it there in PRI as
well?

In the future, that SS7-to-SIP conversion will happen inside the legacy
telcos, and they'll hand off to the rest of the network as pure IP...  At
that point, we (the IETF) only care that they implement existing protocols
properly, we don't care what they do internally.

But my understanding is that you have a specific need for them to have
some reliable, interoperable way of making that transition
(IP-to-PSTN-to-IP or PSTN-to-IP-to-PSTN) internally, while retaining and
conveying any priority information which may be needed to get the call
through the PSTN portions of the path.  Is that a fair summary?

Presumably that can be standardized in such a way that it could be used
subsequently in the rest of the network, if needed.  Nothing there should
require touching anything other than SIP.

                                -Bill