RFC 3620:The TUNNEL Profile
RFC-Ref

start


Click on the red underlined text to get to the source

... out of the way," simply passing octets transparently, and both the initiating and terminating machines perform a "tuning reset," not unlike the way starting a TLS negotiation discards cached session ...
... session state and starts anew. Another use for this profile ...


... ----- xport connect -----> <------- greeting --------> --- start TUNNEL [1] ----> ----- xport connect ------> ...
... ----- xport connect ------> <-------- greeting --------> ---- start TUNNEL [2] ----> <---------- ok ------------ ...
... [3] At this point, immediately after sending the <ok/> element, proxy1 starts passing octets transparently. It continues to do so until either transport connection is closed, after which it ...
... --- xport connect --> <---- greeting ------> --start TUNNEL [1]--> -- xport connect ---> ...
... -- xport connect ---> <----- greeting -----> --start TUNNEL [2]--> --- xport connect ---> ...
... --- xport connect ---> <------- greeting -----> ---start TUNNEL [3]---> <-------- ok ---------- ...
... tunnel/> [4] Proxy2 starts passing octets transparently after sending the <ok/>. ...
... <ok/>. [5] Proxy1 starts passing octets transparently after sending the <ok/>. ...
... --- xport connect --> <---- greeting ------> --start TUNNEL [1]--> --- xport connect --> ...
... --- xport connect --> <----- greeting -----> --start TUNNEL [2]--> ---- xport connect ---> ...
... --- xport connect --> <---- greeting ------> --start TUNNEL [1]--> --- xport connect --> ...
... --- xport connect --> <----- greeting -----> --start TUNNEL [2]--> ---- xport connect ---> ...
... [3] Each proxy starts transparently forwarding octets after this <ok>. ...
... --- xport connect --> <---- greeting ------> --start TUNNEL [1]--> -- xport connect ---> ...
... -- xport connect ---> <----- greeting -----> --start TUNNEL [2]--> --- xport connect ---> ...
... --- xport connect ---> <------- greeting -----> ---start TUNNEL [3]---> <-------- ok ---------- ...
... element to the final machine. [4] Proxy2 starts transparently forwarding octets after this <ok>. [5] Proxy1 starts ...
... starts transparently forwarding octets after this <ok>. [5] Proxy1 starts transparently forwarding octets after this <ok>. ...
... --- xport connect --> <---- greeting ------> --start TUNNEL [1]--> -- xport connect ---> ...
... -- xport connect ---> <----- greeting -----> --start TUNNEL [2]--> --- xport connect ---> ...
... --- xport connect ---> <------- greeting -----> ---start TUNNEL [3]---> <-------- ok ---------- ...
... element to the final machine. [4] Proxy2 starts transparently forwarding octets after this <ok>. [5] Proxy1 starts ...
... starts transparently forwarding octets after this <ok>. [5] Proxy1 starts transparently forwarding octets after this <ok>. ...


... between one and 65535, inclusive. The format of the "srv" attribute is a pair of identifiers each starting with an underline and separated by a period, such as "_sep._tcp". The format of the "profile ...


... element from the initiator, either in the "start" element on channel ...
... the listening session, and the tunneling of data starts. No BEEP greeting (or indeed any data) from the final hop is expected. ...
... BEEP greeting (or indeed any data) from the final hop is expected. Starting with the octet following the END(CR)(LF) trailer of the ...
... session, and the stripped (inner) element is sent to start the next hop. In this case, the peer is considered a "proxy" (meaning that ...
... element back on the listening session. Starting with the octet following the END(CR)(LF) ...


... tunnel" Messages starting one-to-one exchanges: "tunnel" ...



Google
Web
RFC-Ref