[tcmtf] TCMTF: Document A discussion: content and charter version 2

["Jose Saldana" <[e-mail]>]

After the discussion about what to include in Document A, and what signaling
issues we can leave to Document C, I think we could proceed this way:

 

- Document A will only include the things necessary in order to have a
"working" protocol (not too-static, as Juan Antonio says)

- Document C would add new signaling functionalities to TCMTF. It would not
be explicitly included in the Charter now.

 

The content of (A) would be then:

 

1.- Content of the Document

 

Currently it contains the description of the question and the protocols
which could be used on each layer (tunneling, compressing, multiplexing). It
says that the signaling issues would be that of each protocol.

 

There is consensus (I think) about this: we should include some signaling
issues. The question is: What should we include in Draft A and what in Draft
C?

 

- *Auto-negotiation* Negotiation mechanisms to decide the options at each
layer (compression, multiplexing and tunneling) between mux and demux.
Perhaps the mux has ROHC, ECRTP and IPHC, and the demux only has ECRTP and
IPHC, so the two machines will have to negotiate in order to decide which
compression protocol use.

 

This should be included in (A). I think there is consensus about this:

Juan Antonio: "The first kind of signaling ("auto-negotiation") is needed
from the beginning if we don't want an extremely static protocol and
therefore possibly difficult to get it working, especially when in most of
cases the peers belong to different entities/companies."

 

Dan: "We need that -- it is capabilities negotiation.  It is needed because
the protocol will fail if one side mistakenly thinks the other side has
certain functionality, and because we will want to add some fancy new
compression in the year 2020 and will need to negotiate it."

 

Fernando: "I also agree with the idea of including the mux-demux signaling
within the draft A (as Dan said, they are capabilities negotiation). This
draft should be able to get two boxes with TCMTF fully working between them.
Under my point of view this includes the definition of the capabilities in
each node and the negotiation of that capabilities."

 

Does this mean that Document (A) will no longer be a Best Current Practice?
I think so.

 

 

- *dynamically establishing, modifying and releasing tunnels*

 

#1. A *mechanism for a muxer to discover a de-muxer (and vice versa)*.

 

We can leave this for Document (C)

 

                Muthu: "(.) and I agree we should begin with the
architecture + basic signaling."

Fernando: "I think TCMTF establishing should be quite similar to the
establishing procedures of tunnels defined in draft A (L2TP, GRE.), actually
at network level TCMTF is a tunnel. Once established signaling will
negotiate upper levels (multiplexing and HC) to perform TCMTF (draft A)."

 

#2. A mechanism to *elect an optimal muxer and a de-muxer when there are
more than one muxer/de-muxer for a flow*.

 

We agree: This can wait for Document (C).

 

                Fernando: "#2 is more related to the higher entity that has
to decide whether a flow should be TCMTFed or not, and under my point of
view it can be addressed in a different draft."

                Muthu: "#2 can be added later."

 

 

3. A mechanism to *setup/release a tunnel b/w a muxer and a de-muxer*.

 

We agree: This has to be included in (A).

 

                Fernando "#3 I think should be included in the draft A,
since it is a mechanism within the TFMTF protocol itself."

                Muthu: "#3 many not require much specification."

 

 

 

2.- Should we include it in the Charter now?

 

Of course, Document (A) should be in the charter.

 

 

Best regards,

 

Jose