1 / 7

TURN- Lite : A Lightweight TURN Architecture and Specification ( draft-wang-tram-turnlite-02 )

TURN- Lite : A Lightweight TURN Architecture and Specification ( draft-wang-tram-turnlite-02 ). Aijun Wang (China Telecom) Bing Liu (Speaker) (Huawei) IETF 92@Dallas, March 25 2015. Why we proposed a new architecture. We’ve been exploring:

bpantoja
Download Presentation

TURN- Lite : A Lightweight TURN Architecture and Specification ( draft-wang-tram-turnlite-02 )

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. TURN-Lite: A Lightweight TURN Architecture and Specification(draft-wang-tram-turnlite-02) Aijun Wang (China Telecom) Bing Liu (Speaker) (Huawei) IETF 92@Dallas, March 25 2015

  2. Why we proposed a new architecture • We’ve been exploring: • Service Providers might provide TURN relay service to their customers (mostly ICPs, Application Providers) • Utilize the already deployed CGN/CDN devices as TURN servers • But we found it was complex • Every CGN (TURN server) needs reserve and plan Address/Port, which is a big burden for SPs, especially there are many CGN devices deployed in a distributed manner • Signaling is complex: ICE-based interaction; different processing for UDP, TCP and v4-v6 communication • So many CGN devices can hardly directly open to customers (interface issue)

  3. TURN-Lite Architecture (Updated since last meeting) • Architecture • RS—Relay Selection • CGN—Data Relay • Client---Connection Initial • Reduce the complexity • each relay needs only one transport address/port • signaling procedures are significantly simplified • a single RS interface is much easier for opening to customers • So that • SPs can easily integrate the relay functions into distributed devices such as CGNs. • SPs can easily provides data relay service to ICP/App Provider via RESTful Interfaces App Provider 1 App Provider 1 App Provider 1 SP’s Domain RS(Relay Selector) CGN-1(TURN-Lite Server1) CGN-2(TURN-Lite Server1) CGN-3(TURN-Lite Server1) NAT-1 NAT-2 Host-1(V4/v6)TURN-Lite Client Host-1(V4/v6)TURN-Lite Client

  4. Communication Procedures Clients register to their App server, and gets the RS address, get their reflective addresses to RS(REFLX_RS) and report them to App server App server sends REFLX_RS pair to RS, let RS select one optimal relay device to relay data. Clients get their reflective addresses to Relay (REFLX_Relay) and report them to RS, RS form COUPLE packet and send it to the selected CGN devices. Clients send TCP/UDP packet via the selected CGN device, CGN device relay the data based on the table built by COUPLE command. App Provider 1 App Provider 1 App Provider 1 ② SP’s Domain ① RS(Relay Selector) ③ CGN-1(TURN-Lite Server1) CGN-2(TURN-Lite Server1) CGN-3(TURN-Lite Server1) ④ NAT-1 NAT-2 Host-1(V4/v6)TURN-Lite Client Host-1(V4/v6)TURN-Lite Client

  5. Relationship with TURN • TURN-Lite is NOT intended to be a full alternative of TURN • We consider it as a complementary solution for SP-Public-Relay-Service (e.g. for network operators or CDN providers .etc)

  6. Next Steps • Feedbacks are welcomed • Especially from ICP perspective • Also from ISP/CDN provider perspective • A useful work? Possibly added to the charter?

  7. Comments?Thank you!wangaj@ctbri.com.cnleo.liubing@huawei.comIETF92@Dallas

More Related