Subject: RE: [Ecrit] Emergency Context Routing of Internet Technologies -Architecture Considerations

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 6 Sep 2005 19:03:38 -0500

Hi Andy and James,

In general a pretty good read.
A few comments and questions below.

The definitions you have between ISP and ASP seem to make the ASP a
subset of ISP functionality, which I don't think is always the case.
Furthermore I think that your definition of IAP is more in line with
what I have considered to be an ISP.

I think, that there is a Physical Access Provider (PAP if you like) that
provides you with access to a network, an Internet service provider
(ISP) that defines an associated domain that may be accessed from the
physical access network, and an ASP whose services can be accessed from
the domain. This is also more inline with how physical networks are
actually built, and avoids the super-set definitions that are apparent
in your document.

Conversion or LCMS Mapping
One of the most common problems that results in conversion being
necessary is that the information is not provided in the format required
by the recipient. If location is stored at the source in a variety of
forms, then two clear options exist for reducing the need for
conversion.
1) provide all forms when ever asked for location
2) provide a reference to the source, and allow the recipient to request
the type that they need.

LCMS Mapping
Can you clarify something for me here, are you really expecting the SIP
URI of the local PSAP to be provided directly to an end-point? This is
certainly something that is likely to cause large gasps within the NENA
community, and is one of the reasons for the ESRP functionality.

Rerouting/Transfer could also address things like overflow, load sharing
etc, which are also potential functions of an ESRP.

Cheers
James 
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Sep 2005 20:11:20 -0500

>In general a pretty good read.

Thanks

>subset of ISP functionality, which I don't think is always the case.

no, we didn't want that, but we wanted to define it as being a Service 
Provider for "an application" like voice, which differs from the more 
general ISP which is (generally) all data protocols, yet can be a separate 
company/organization.

An ASP is more focused.

>what I have considered to be an ISP.

To be clear, a "Vonage" is a ASP (they do voice)

a "Comcast" or an "AOL" is an ISP - which isn't generally limited to an 
application or technology, but there typically are no guarantees other than 
best effort connectivity

Comcast in the above example *can* also be the access provider because they 
own the HFC cable connectiving one to the Internet, but this does not have 
to be the case.

>the domain.

yeah - we just use IAP, ISP and ASP for your 3 terms above (in order BTW)

>This is also more inline with how physical networks are

again, we didn't intend to mean any subsets were involved, just 
separations, as each of the 3 layers could easily be 3 separate 
companies/organizations

>2) provide a reference to the source, and allow the recipient to request

#1 likely will not always be available to the endpoint, and the endpoint 
will likely get stuck with what the IAP gives them (ex RFC3825).
#2 is also dependent on the sender of the information

so, there is a need for format conversion sometimes

we didn't mean all the time, just when it is important or necessary

for example, with NENA's i2, there has been a recent movement to mandate 
the civic format as the only one sent to the ESRP. If the UA doesn't have 
this format, it may know how to convert GPS to civic ahead of time to send 
to the ESRP when the UA makes the 911 call.

This conversion function will likely exist for many other reasons (outside 
of emergency calling).

>URI of the local PSAP to be provided directly to an end-point?

This is one option, and one that is less error prone - as it doesn't occur 
during call set-up.

Or the PSAP URI is provided to the Cable/DSL modem that has a DHCP server 
and client in it, to send to any requesting IP device within that dwelling 
when it boots up. This could also work for Commercial, SMBs and enterprise 
networks.

This is seperable from Location, which we believe needs to be sent to the 
endpoint also.

The URI staleness factor can be addressed by the DHCP refresh function, or 
can be pushed to endpoints whenever the server wants to.

>This is

ultimately we want the INVITE to get to the right PSAP. Mapping can be done 
before a user calls 911/112 or during the call set-up. This section of the 
document suggests how it can be done prior to a phone calling 911.

>etc, which are also potential functions of an ESRP.

I agree. Do you want more text stating these additional reasons/functions?

>James

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 6 Sep 2005 23:10:56 -0500

Comments inline.

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 7 September 2005 11:11 AM
> To: Winterbottom, James; [email-masked]
> Subject: RE: [Ecrit] Emergency Context Routing of Internet
Technologies -
> Architecture Considerations
> 

[AJW]
Okay, but if you could make this more clear it would be good. Removing
the I from IAP I think will help a lot here. Also removing the services
provided by the ISP with the exception of giving you an IP address and
access to the Internet. Anything else should be considered a service,
and may or may not be tied to your ISP. 

> #2 is also dependent on the sender of the information

[AJW]
My point with #2 is that allowing the recipient to ask means that the
sender does not need to presuppose. So as an end--point, rather than
requesting option 123, and whatever the civic option ends up being, I
can just send a location URI, and the LCMS can ask for my location in
the format that it wants. So while yes, there may be a restriction on
what the sender provides, not making that assumption clearly has its
advantages.
 
> to the ESRP when the UA makes the 911 call.

[AJW]
I am not sure that I agree with this statement. If the end-point only
has one format, then that is the form it should send for i2, no
conversion is wanted, as there is no way to specify that this has
occurred over the VE2 interface to the PSAP.

Also i2 has a VPC, which is more like the LCMS. The ESRP is like a
combination of ESGW and SR.

> This is one option, and one that is less error prone - as it doesn't
occur

[AJW]
I think that this will not work well for mobile devices, and by the time
we have RFCs and implementations for much of this stuff, I fully expect
a significant proportion of IP devices to be mobile, so solutions need
to factor this in. I would prefer to see a solution that build once now,
than something that will need significant overhauling to accommodate a
new class of access device. Why not just have one solution that will
accommodate all classes of access device, and thereby simplifying the
plethora of potential solutions.

Note that NENA i2 takes this approach by performing the PSAP routing
functionality in real time with the call setup, and not by
bootstrapping. The result is that while NENA do not come out and say
that i2 supports mobile devices, the fact is that it is capable of
supporting mobile devices now.

> document suggests how it can be done prior to a phone calling 911.

[AJW]
I think that this approach is at odds with NENA, which does not want
every Tom, Dick and Harry having the ultimate address of the PSAP. I
tend to agree with the NENA approach. It may be prudent to provide the
address of the ESRP, but an ESRP is likely to service a number of PSAPs.
This gives the flexibility within the emergency services network to
determine how internal routing is performed, without revealing its
internals to the rest of the world.

> I agree. Do you want more text stating these additional
reasons/functions?

[AJW]
I think that more statements here would be good, so that these functions
can be described. If you still have access to the NENA website, Nadine
Abbott put together a good set of functions that an ESRP might perform.

Cheers
James

---

From: "Abbott, Nadine B" <[email-masked]>
Date: Fri, 9 Sep 2005 11:25:53 -0400

James and Andy,

I appreciate your contribution to additional discussion of architectural
considerations that provide a context for the focus of on requirements
for location-based mapping protocols in the ECRIT discussions.  I think
this is very helpful.

I have a few observations and suggestions:

In section 1, a suggested definition for
Location Information Server (LIS) -- Provides a mapping function to
relate unique identifiers for IP devices at physical network access
points and the geographic descriptions of their location (e.g., civic
location/street addresses or geographic coordinates).  Responds to
queries for location information.

In Section 2, the list of methods for delivering configuration and
location information to the client does not include  the proposed HELD
method for IP clients to acquire location information from an Internet
access provider (described in HTTP Enabled Location Delivery [HELD],
draft-winterbottom-http-location-delivery-01).  This should be to be
added to the list to address the needs of a number of potential Internet
access providers that would be called upon to provide location
information in North America.

In Section 4, I suggest the addition of a paragraph with wording
something like the following to include an example of an ESRP concept
previously described in Section 6.1 of I-D: "Emergency Services for
Internet Telephony Systems," Henning Schulzrinne, October 18, 2004,
draft-schulzrinne-sipping-emergency-arch-02.
        
      At the option of the PSAP, more than one ESRP function may be
implemented in series, 
      to provide increasingly precise routing to the appropriate PSAP. 
      This allows for simplification of emergency call routing at the
originating network, 
      and for decision-making at local jurisdictional or at aggregate
levels for 
      real-time control of call routing.  This might also allow for some
additional jurisdictional 
      control of the visibility of emergency call routing information.

Thanks again,

Nadine Abbott  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tschofenig, Hannes
Sent: Tuesday, September 06, 2005 1:59 PM
To: [email-masked]
Subject: [Ecrit] Emergency Context Routing of Internet Technologies
-Architecture Considerations

hi all, 

james and andy just submitted a draft with the following content:

"
   This document discusses architectural considerations for emergency 
   context routing of Internet technologies.  The purpose of this 
   document is to provide a systemic view of emergency context routing,
   discuss unresolved issues, and explain the relationship of some of 
   the proposals to these issues, while discussing potential directions 
   that might be still be necessary for the working group to 
   investigate.  
"

i have copied the draft to
http://www.ietf-ecrit.org/cache/draft-polk-newton-ecrit-arch-considerati
ons-00.txt

thanks to both of them for touching a number of interesting discussion
topics. 

ciao
hannes