Subject: [Ecrit] ECRIT Simplified E-9-1-1 workflow proposal

From: Francois Menard <[email-masked]>
Date: Thu, 6 Aug 2009 07:50:56 -0400

Is anything wrong with the following E-9-1-1 workflow to be possible  
with any ATA that can be upgraded to become Phone-BCP compliant.

Step 0) ISP is provided with a copy of the MASTER STREET ADDRESS GUIDE  
already pre-formatted in PIDF-LO format. ISP provisions a DHCP server/ 
HELD server with a PIDF-LO object to be associated with the IP address  
to be assigned to an end-user based on the WIREMAP circut-ID.  In DSL  
wholesale, the ISP uses the CIRCUT-ID acquired by RADIUS for a given  
MSAG-VALID CIVIC PIDF-LO object.  The ISP then simply matches the PPP  
username and password arriving on a given CIRCUIT-ID to create a  
binding between the PUBLIC-IP associated dynamically to the CIRCUIT-ID  
and the PIDF-LO object.  The ISP really does not care about the PPP  
credentials.  All it wants to do is BIND a PIDF-LO to a CIRCUIT-ID to  
an IP address and allow for that PIDF-LO to be retrieved EITHER via  
HELD, or via DHCP OPTION 99.

For instance, ILECs for their L2TP LAC's are transitioning to Juniper  
E320's - 8.2.3 patch-0.4 which is capable of the following formats to  
pass along the unique DSLAM port to be associated with a CIVIC address  
over RADIUS to the wholesale ISP as described in https://www.juniper.net/techpubs/en_US/junose10.0/information-products/topic-collections/broadband-access/l2tp-calling-number-avp.html

Step 1) In DSL wholesale, PPPoE will assign an IP.  The reverse lookup  
would be done for this IP by the ATA.

Step 2) If the ATA is behind nat, it would be provisioned with a STUN  
server IP address.  The STUN server will return to the ATA, what  
public IP address the ATA is behind.

Step 3) The ATA would then perform an inverse lookup for that IP  
address in the DNS server of that domain name, and would expect there  
to be a DNS entry for LOCATIONSERVER.DOMAIN-GATHERED-BY-REVERSE- 
LOOKUP.DOMAIN-GATHERED-BY-REVERSE-LOOKUP-SUFFIX

Step 4) The ATA would then use its HELD stack to download the  
location  object (PIDF-LO).

Step 5) ATA Memorizes PIDF-LO.

Step 6) Upon having to dial 9-1-1, ATA sends PIDF-LO via SIPCORE  
LOCATION CONVEYANCE (attached)

Step 7) VoIP server provider will steer the call to the an ILEC SIP  
PROXY and send the 9-1-1 RTP media to the ILEC 9-1-1 media gateway

Step 8) ILEC will inspect the content of the PIDF-LO and will route  
the call to the appropriate PSAP

All ILEC needs to do is to stop blocking the CIRCUIT-ID's over the  
RADIUS accounting interface and accept to  implement a SIP-based  
gateway + media gateway on the INTERNET which would provide access to  
all the PSAPs the ILEC manages (which is the case in Canada where  
PSAPs only interconnect directly with the ILEC and no other  
competitors).

I would appreciate answers by the end of the day on friday as I am  
submitting this to the Canadian FCC (CRTC) friday evening.
F.

--
Francois Menard
[email-masked]

Francois Menard
[email-masked]

---

From: John Lange <[email-masked]>
Date: Thu, 06 Aug 2009 14:28:59 -0500

> with any ATA that can be upgraded to become Phone-BCP compliant.

...

> the call to the appropriate PSAP

I know the focus of your question is regarding the various RADIUS
capabilities but I believe the description of steps 5-8 aren't entirely
accurate with regard to phonebcp and ecrit-framework.

The VOIP endpoint obtains its PIDF-LO and then uses it to obtain the
SOS:URI. It caches that information and then uses it to dial the correct
ESGW should the need arise.

Your description implies that the ESGW URI is obtained in real-time
during call routing which I don't believe is what ecrit-framework and
phonebcp describe.

> PSAPs only interconnect directly with the ILEC and no other  

Unfortunately I'm clueless with regard to PPPOE, RADIUS, and DSL so I
can't help you with the main point of your question.

BTW, the rest of your description is nearly identical to the submission
I've been working on. Great minds thing alike even if they think in
different languages ;)

Regards,
-- 
John Lange
http://www.johnlange.ca

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 7 Aug 2009 11:03:07 +0300

Hi Francois, 
 
Quick feedback below.

>Is anything wrong with the following E-9-1-1 workflow to be 
>possible with any ATA that can be upgraded to become Phone-BCP 
>compliant.
>
>Step 0) ISP is provided with a copy of the MASTER STREET 
>ADDRESS GUIDE already pre-formatted in PIDF-LO format.

This is not really necessary for the ISP to have. I suspect you want to
provide that information to the ISP since then he can do civic address
validation locally. The solution would still be OK by not having it locally
but rather maintained by someone else, such as the emergency services
network, in the spirit of NENA i2/i2.5, via LoST or some other mechanisms. 

Hence, I don't see this part as crucial for your solution. 

> ISP 
>provisions a DHCP server/ HELD server with a PIDF-LO object to 
>be associated with the IP address to be assigned to an 
>end-user based on the WIREMAP circut-ID.  In DSL wholesale, 
>the ISP uses the CIRCUT-ID acquired by RADIUS for a given 
>MSAG-VALID CIVIC PIDF-LO object.  The ISP then simply matches 
>the PPP username and password arriving on a given CIRCUIT-ID 
>to create a binding between the PUBLIC-IP associated 
>dynamically to the CIRCUIT-ID and the PIDF-LO object.  The ISP 
>really does not care about the PPP credentials.  All it wants 
>to do is BIND a PIDF-LO to a CIRCUIT-ID to an IP address and 
>allow for that PIDF-LO to be retrieved EITHER via HELD, or via 
>DHCP OPTION 99.
>
>For instance, ILECs for their L2TP LAC's are transitioning to 
>Juniper E320's - 8.2.3 patch-0.4 which is capable of the 
>following formats to pass along the unique DSLAM port to be 
>associated with a CIVIC address over RADIUS to the wholesale 
>ISP as described in 
>https://www.juniper.net/techpubs/en_US/junose10.0/information-p
>roducts/topic-collections/broadband-access/l2tp-calling-number-avp.html
>

The details of how the association of an IP address with location is done
very much depends on the specific deployment at the ISP. Some operators
might, for example, do IP address allocation within the AAA server and do
not run a separate DHCP server. Hence, the interaction between the DHCP
server and the AAA server becomes a local matter.   

So, in short you only want to say that the ISP has to provide the capability
to associate the IP address with location. 

>Step 1) In DSL wholesale, PPPoE will assign an IP.  The 
>reverse lookup would be done for this IP by the ATA.
>
>Step 2) If the ATA is behind nat, it would be provisioned with 
>a STUN server IP address.  The STUN server will return to the 
>ATA, what public IP address the ATA is behind.
>
>Step 3) The ATA would then perform an inverse lookup for that 
>IP address in the DNS server of that domain name, and would 
>expect there to be a DNS entry for 
>LOCATIONSERVER.DOMAIN-GATHERED-BY-REVERSE-

I guess that the previous 3 steps have the purpose of LIS discovery. Right? 
Maybe it would be good to say that. One could even provide example
references to documents, such as
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lis-discovery/ and
http://tools.ietf.org/id/draft-thomson-geopriv-res-gw-lis-discovery-02.txt

>location  object (PIDF-LO).

OK. 

>Step 5) ATA Memorizes PIDF-LO.

OK. 

>
>Step 6) Upon having to dial 9-1-1, ATA sends PIDF-LO via 
>SIPCORE LOCATION CONVEYANCE (attached)

OK.

>
>Step 7) VoIP server provider will steer the call to the an 
>ILEC SIP PROXY and send the 9-1-1 RTP media to the ILEC 9-1-1 
>media gateway

You might want to provide some details on how this routing works and why the
ILEC runs the SIP proxy. There is no reason why this gatewaying cannot be
provided by someone else. 

For example, how would the VoIP provider figure out what proxy to send it? 
Would it have some "mapping database" in the style of LoST or the NENA i2
solution? 
Or: Would it use anycast, like the guys in Sweden want todo? 

This step is important and requires more description. 

>
>Step 8) ILEC will inspect the content of the PIDF-LO and will 
>route the call to the appropriate PSAP

Depending how you do 7 this step might be omittet. 

>
>All ILEC needs to do is to stop blocking the CIRCUIT-ID's over 
>the RADIUS accounting interface and accept to  implement a 
>SIP-based gateway + media gateway on the INTERNET which would 
>provide access to all the PSAPs the ILEC manages (which is the 
>case in Canada where PSAPs only interconnect directly with the 
>ILEC and no other competitors).

Why would you put this burden on the ILECs? I could imagine that PSAPs would
either accept direct VoIP calls from the VSP or would allow the VSPs to pick
their provider of choice for doing the VoIP-to-PSTN gatewaying when you have
to deal with legacy PSAPs. 

>
>I would appreciate answers by the end of the day on friday as 
>I am submitting this to the Canadian FCC (CRTC) friday evening.
>F.

Ciao
Hannes

>
>--
>Francois Menard
>[email-masked]
>
>
>
>
>Francois Menard
>[email-masked]
>
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Francois Menard <[email-masked]>
Date: Fri, 7 Aug 2009 06:41:16 -0400

> network, in the spirit of NENA i2/i2.5, via LoST or some other  

The ILECs here have committed to provide access to the MSAG, but they  
did not detail how the access would be provided.

What's important, is this be not the source of improv.  If CIVIC's are  
already pre-formatted in XML, them the ISP only has to cut and paste  
and send stuff to the ILEC SIP PROXY in the manner the proxy will  
dispatch for it being MSAG valid to begin with.

> server and the AAA server becomes a local matter.

The interface of interest is not that of the ISP to AAA server, but  
rather that of the ILEC to ISP.

In the ILEC to ISP interface, there is no IP addresses travelling back  
and forth, just PPP session ID's and CIRCUIT-ID's and PPP user  
credentials with domain.

> to associate the IP address with location.

I actually want to say that the Access Network provider has to EMPOWER  
the ISP to do that.

> http://tools.ietf.org/id/draft-thomson-geopriv-res-gw-lis-discovery-02.txt

Absolutely.

> provided by someone else.

That's all stuff described here:

http://www.crtc.gc.ca/public/cisc/es/ESCO283.doc

In those jurisdictions where the ILECs want to step up to the plate  
and take that much insofar as responsibility, this ENABLEs the  
simplified workflow as described here.

> Would it have some "mapping database" in the style of LoST or the  

No need. There is only ONE destination to choose for the ISP under the  
Canadian i2 proposal.

> Depending how you do 7 this step might be omittet.

Under

http://www.crtc.gc.ca/public/cisc/es/ESCO283.doc

This is what the ILECs propose in Canada

> to deal with legacy PSAPs.

The PSAPs in Canada do  not accept interconnection from providers  
directly. You need to send them to the ILEC here...

F.

>> I am submitting this to the Canadian FCC (CRTC) friday evening.

Merci beaucoup!

f.

Francois Menard
[email-masked]