Re: A new draft submitted to tsvwg: Simplemux
2014-12-17 09:41:01 GMT
> - Multiplexing layer 3 packets in layer 2 frames?
My idea is that this is an IETF draft, so the protocols considered are those defined by IANA: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
The "protocol" field to be included in Simplemux would be 8 bits long, in my opinion. This would not be the “EtherType” field of the Ethernet frame (16 bits long): http://en.wikipedia.org/wiki/EtherType.
However, if someone thinks a 16 bytes protocol field could be interesting, we can also consider it as an option (with a bit indicating it in the first header).
> - Multiplexing layer 3 packets in layer 3 packets?
This would allow these kind of things, if the “multiplexing protocol” is IP:
- encapsulating a number of IP packets in an IP packet: Encapsulated Protocol number=4 (IPv4 encapsulation, RFC2003)
- Encapsulating a number of Transport Segments in an IP packet (this would be equivalent to TMux, RFC1692, https://tools.ietf.org/html/rfc1692 ). Encapsulated Protocol number=6 (TCP, RFC793)
- Encapsulating a number of Ethernet Frames in an IP datagram: Encapsulated Protocol number=97 ETHERIP, Ethernet-within-IP Encapsulation, RFC3378
> Multiplexing layer 3 packets in layer 4 datagrams?
If the “multiplexing protocol” is UDP, it would also make sense: this would avoid the need for a new “protocol” number. The two extremes would just need to agree on a port number. In fact, this is what is done in the implementation. https://github.com/TCM-TF/simplemux
What multiplexing and what multiplexed protocols are you considering here? Are you focused on a determined protocol layer options? Or maybe you are defining something generic?
- Multiplexing layer 3 packets in layer 2 frames?
- Multiplexing layer 3 packets in layer 3 packets?
- Multiplexing layer 3 packets in layer 4 datagrams?
This is an Internet Draft I submitted yesterday to tsvwg:
Simplemux could be seen as a generic protocol for multiplexing any protocol on any other protocol. The initial idea was: could this be used instead of PPPMux in TCM? However, I think it may have more fields of application.
The idea is similar to that of PPPMux (RFC3153). However, PPP, and L2TP in turn, are not required, thus reducing complexity:
| Ext hdr || Mux hdr | packet || Mux hdr | packet || ...||
It is different from TMux [RFC1692], because TMux combines multiple short transport segments, but not full packets, so it works between the same pair of machines. However, there are scenarios where a number of low-efficiency flows share a common path, but they do not travel between the same pair of machines.
A “Protocol” number should be requested to IANA for saying in the external header that Simplemux is inside. Each Mux header would include another “Protocol” field, so it would permit the multiplexing of different packets in the same bundle: IPv4, IPv6, ROHC, etc.
If you could have a look to the draft and send your comments, it would be fine.
An implementation of Simplemux using IP/UDP as the multiplexing (external) protocol and IP or ROHC as the multiplexed protocol can be found here:
Thanks in advance!
Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição