1 / 8

SPEERMINT Use Cases for Cable

This presentation discusses the two-layered peering reference architecture for SIP sessions, including the user location layer and session routing layer. It explains the logic behind the SIP INVITE request and explores topics such as network address translation, IPv4-to-IPv6 translation, peering policies, user location service, peering security, peering QoS, and peering accounting and billing.

hfloyd
Download Presentation

SPEERMINT Use Cases for Cable

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Presented by Yiu L. Lee SPEERMINT Use Cases for Cable IETF 66 Montreal 11 JULY 2006

  2. Peering Reference Architecture

  3. Two Layers for Peering • We divide the architecture into two layers: (1) User Location Layer (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. • 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:

  4. Peering Logics for SIP INVITE (1) • Perform an ENUM query on the called party in the SIP request URI. • If the ENUM server fails to return the response, SM-o forwards the call to PSTN. • ENUM server returns a NAPTR record. SM-o parses the regular expression and formulates the sip uri of Bob which is <sip:bob@mso-t.com>. • SM-o finds out that it does not own "mso-t.com". SM-o has local policies to send the request to PP-o. • SM-o sends a DNS query to locate PP-o’s IP address. • 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. • 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".

  5. 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 Bob’s home proxy. • 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. • Bob's UE-t receives the SIP INVITE request. Bob accepts the call. UE-t sends the 200OK and Alice acknowledges it.

  6. Network Address Translation • Some parts of our network may 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. IPv4-to-IPv6 Translation • Comcast may test IPv6 eMTAs 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.

  8. 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?

More Related