1 / 8

NTLP NAT Traversal solution

NTLP NAT Traversal solution. NATFW NSLP crusaders. Requirements. Application friendliness Reuse existing NAT traversal mechanisms Minimum performance impacts on end systems. Challenges. NR behind NAT: Need to provide the NI with the address and port on which it could send the NSIS msgs:

nascha
Télécharger la présentation

NTLP NAT Traversal solution

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. NTLP NAT Traversal solution NATFW NSLP crusaders

  2. Requirements • Application friendliness • Reuse existing NAT traversal mechanisms • Minimum performance impacts on end systems

  3. Challenges • NR behind NAT: • Need to provide the NI with the address and port on which it could send the NSIS msgs: • The datagram discovery messages • And the rest of the NSIS msgs • Raw transport mode can’t be used • Existing self learned translated address supports only UDP transport • NI behind NAT: • Raw transport mode can’t be used

  4. Proposed solution STUN server 10.1.2.3 1-DISCOVER mapped address 3-App msg QNI QNR + STUN NAT QNE 2-Return mapped address 193.129.2.1 1 & 2 are used to learn the media stream translated address and port 3 used to provide media stream address information, NSIS Discovery msg wil be sent on same socket l

  5. Proposed solution STUN server 10.1.2.3 4-NSIS Discover 5-NSIS Discover response QNI QNR + STUN NAT QNE 193.129.2.1 4- NSIS Discover datagram msg sent on address and port reported by the STUN query response 5-NSIS Discover response, will have private address information of the QNR, QNE will know that QNR need datagram mode. Can it report this to QNI? RTP packets might be received in the same time as the NSIS msgs, NSIS msg need to have a clear identifier (for example first 2 bits on the wire should be 00 or 01) field in the beginning of the NSIS header to distinguish it from RTP msgs

  6. Proposed solution STUN server 10.1.2.3 QNI QNR + STUN NAT QNE 193.129.2.1 Once the other QNEs involved discover that a none NSIS aware NAT is involved, the NSIS Msgs continue to be sent in datagram mode on the same socket. First 2 bit on the wire of NSIS msgs being different than 10 (first 2 bits of RTP packets) allows to distinguish it from RTP. Is it that problematic to use the same socket for RTP and NSIS? Even with the different first 2 bits?

  7. Proposed solution STUN server 10.1.2.3 1-DISCOVER mapped address QNI QNR + STUN NAT 193.129.2.1 QNE 2-Return mapped address Alternative proposal: Once the first NSIS Discover is received, the QNR provides an IP address and port on Which datagram NSIS msgs could be sent (this will be provided by STUN). Very few (if none) RTP packets will be reached on the opened socket during that phase. Is this more suitable? Case C-mode needed MA needs to be established by upstream node (case of the Device behind the NAT)

  8. NSIS NATFW NSLP role with NSIS unaware NATs Net x Alice a.b.c.1/24 k.l.m.n/30 Phil The net a.b.c.e Bob REA REA ACK e.f.g.h a.b.c.d 1-Request address/port mapping “STUN-like capability” NSIS NATFW NSLP un-aware NAT NSIS NATFW NSLP signaling Data Flow

More Related