Speermint Use Case for Cable

1
Speermint Use Case for Cable

• IETF 66
• Yiu L. Lee
• JULY 2006

2
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
Peering Reference Architecture
4
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
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
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 ltsipbob_at_mso-t.comgt.
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-os IP
   address.
6. DNS returns PP-os 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 Bobs domain "mos-t.com".

7
Peering Logics for SIP INVITE (2)

• 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.
• 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 Bobs home proxy.
• SM-t receives the SIP INVITE. SM-t contains the
  registration information of Bobs UE-t. This is
  the home proxy which hosts the contact
  information of Bobs UE-t. SM-t forwards the SIP
  INVITE request to UE-t.
• Bob's UE-t receives the SIP INVITE request. Bob
  accepts the call. UE-t sends the 200OK and Alice
  acknowledges it.

8
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
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 wont know that IPv6 network
  is running IPv6.

10
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?