Speermint Use Case for Cable

download report

Transcript Speermint Use Case for Cable

Speermint Use Case for Cable
IETF 66
Yiu L. Lee
JULY 2006
7/6/2006
1
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.
7/6/2006
2
Peering Reference Architecture
Originating MSO
Terminating MSO
DNS
ENUM
DNS
ENUM
SIP
SIP
SIP/NCS
Session
Manager
Peering
Proxy
Peering
Proxy
SIP
Session
Manager
SIP/NCS
eMTA
eMTA
7/6/2006
3
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.
7/6/2006
4
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:
7/6/2006
5
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
<sip:[email protected]>.
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/6/2006
6
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.
7/6/2006
7
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.
7/6/2006
8
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.
7/6/2006
9
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?
7/6/2006
10