80 likes | 167 Vues
Explore cable IETF use cases with a reference architecture divided into User Location Layer and Session Routing Layer, detailing SIP invite logic, NAT, IPv4-to-IPv6 translation, and future considerations.
E N D
Presented by Yiu L. Lee SPEERMINT Use Cases for Cable IETF 66 Montreal 11 JULY 2006
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:
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".
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.
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.
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.
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?