1. 7/6/20061 Speermint Use Case for Cable IETF 66 Yiu L. Lee JULY 2006

2. 7/6/20062 Cable Use Case for Session Peering MSO has started VoIP trial hosted by CableLabs for two years. The objective of this trial is to evaluate the ENUM technology and the SIP routing capability of PacketCable 1.x architecture for peering. From this trial, we evaluated the architecture and moved on to design the peering architecture for Cable.

3. 7/6/20063 Peering Reference Architecture

4. 7/6/20064 Two Layers for Peering (1) We divide the architecture into two layers: (1) User Location Layer and (2) Session Routing Layer. User Location Layer is responsible for locating the peering point of the user. Session Routing Layer is responsible for routing the SIP messages.

5. 7/6/20065 Two Layers for Peering (2) User Location Layer consists of the ENUM server and DNS server. Session Routing Layer consists of the Peering Proxy, Session Manager and the User Endpoint. When Originating User Endpoint wants to call the Terminating Endpoint, SIP INVITE request follows the following logic:

6. 7/6/20066 Peering Logics for SIP INVITE (1) 1.Perform an ENUM query on the called party in the SIP request URI. 2.If the ENUM server fails to return the response, SM-o forwards the call to PSTN. 3.ENUM server returns a NAPTR record. SM-o parses the regular expression and formulates the sip uri of Bob which is. 4.SM-o finds out that it does not own "mso-t.com". SM-o has local policies to send the request to PP-o. 5.SM-o sends a DNS query to locate PP-o’s IP address. 6.DNS returns PP-o’s IP address to SM-o. SM-o sends the SIP INVITE to PP-o. SM-o MAY choose to record-route to stay on the signaling path. 7.PP-o receives the SIP INVITE. It examines the request URI and sends a query to DNS server to get the IP address of Bob’s domain "mos-t.com".

7. 7/6/20067 Peering Logics for SIP INVITE (2) 8.PP-o performs all the necessary operations such as sip header normalization and THIG function and sends the INVITE to PP-t. Optionally, PP-o MAY act as a B2BUA. 9.PP-t receives the INVITE. It examines the request URI to verify the domain is one of its serving domains. If it is, PP-t will forward the INVITE to some proxy that has access to Bob's user data to locate Bob’s home proxy. 10.SM-t receives the SIP INVITE. SM-t contains the registration information of Bob’s UE-t. This is the home proxy which hosts the contact information of Bob’s UE-t. SM-t forwards the SIP INVITE request to UE-t. 11.Bob's UE-t receives the SIP INVITE request. Bob accepts the call. UE-t sends the 200OK and Alice acknowledges it.

8. 7/6/20068 Network Address Translation Some MSOs use RFC1918 addresses to address their User Endpoint. We need to find a way to *NAT* the IP address to a routable public IP address. Two Options: –Use Endpoint User Endpoint uses ICE, STUN and TURN. –Network Network uses Relay Server.

9. 7/6/20069 IPv4-to-IPv6 Translation Some MSOs are planning to trial IPv6 eMTA in 2007. eMTA registers its IPv6 address to the Session Manager. Our assumption is the IPv6 network is responsible for all the necessary NAT-PT translation. The outside IPv4 network won’t know that IPv6 network is running IPv6.

10. 7/6/200610 Future Works Peering Policy –Policies are local. Do we need to exchange peering policies between peers? User Location Service –Is RFC 3263 enough? Do we need more sophisticated user location information? Peering Security –TLS? VPN? IPSec? How to enforce asserted user identity? Peering QoS –How to convey the QoS policy from Layer-5 to Layer-3? Peering Accounting and Billing –What is the right model for billing? Per minute usage or Total Bandwidth usage?