Since Christian Groves has reflected his latest, here is mine.
-----Original Message----- From: Brian Rosen [mailto:brosen@fore.com] Sent: Thursday, August 19, 1999 1:44 PM To: MEGACO@standards.nortelnetworks.com Subject: Re: Transport layer interface
I work for a company that is pretty well involved with ATM. We have customers who would like to run MGCP directly on ATM, not IP over ATM. While there are no actual proposals, if we were to write one, it would almost certainly be ALF over ATM AAL5. In particular, any effort we put into intelligent handling of congestion by letting the application get in on the decisions of what to send and when to send it is 90% applicable to an ATM transport, and we would be foolish to handle the circumstances another way. If we desire to use something like SSCOP providing reliable, ordered delivery, then the transport would look very much like the TCP transport defined in the draft.
It may be that some want to deliver MEGACO over an AAL2 subchannel. Fine, and although congestion using AAL2 (assuming that for other reasons the AAL2 QoS is something like rt-VBR) is not the same, the transport mechanism will very, very likely look like ALF if there is no other layer, or like TCP, if something like SSCOP were used.
There would clearly need to be some kind of document that described ATM transport of H.248. That document might originate in the ATM Forum, and subsequently be made part of H.248, or it might be done wholly within ITU. Regardless, it will very likely end up being an annex to the main document, just like Annex C of H.323.
While the wording of the annex would clearly be different if the layer wording stayed in the main document, there is NO functional difference with or without it, primarily because the layer is not visible outside either the MG or the MGC. The entire layer exercise is defining the IMPLEMENTATION of the protocol, which is usually considered not to be a good idea in a protocol document.
There are lots and lots of instances in the ITU and in the IETF that add things like another transport mechanism to a protocol by either editing the base document, adding an annex, or writing a new spec referencing the old spec with the changes required to achieve the goal. The only thing the layer does is make this process a little less like surgery. What you lose is application flexibility.
Defining a layer between protocol and transport does not make defining a non-IP transport any more or any less work, does not alter the observable results, and does not affect the feasibility, document organization etc.!
And, I'll point out again, that if we did standardize ALF over ATM AAL5 (or AAL2 for that matter), then the layer mechanism as proposed is entirely inadequate.
Brian
-----Original Message----- From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] Sent: Thursday, August 19, 1999 3:36 AM To: MEGACO@standards.nortelnetworks.com Subject: Re: Transport layer interface
G'Day all,
Seeing my name was mentioned several times I guess I better speak up on this issue. There were a number of points:
- A contribution was made to be able to use H.248 across non-IP
transport technologies 2. The rational is that if you have a gateway with ATM, AAL2 etc you may not want an IP signalling transpport. 3. The layered approach was introduced as a way of doing this. 4. I recognise that IP is the current and primary means of deploying H.248 I wanted to document H.248 a way that allows continued developed of the protocol without having to delay it whilst adding seperate transport technologies. 5. We wanted the H.248/Megaco specification NOT to be tied to an IP transport technology that is why we proposed the changes to the document structure to allow the actual protocol (procedures & symantics) to be separated from the transport issues. 6. ALF is tied to IP and is not suitable to other transport technologies this I think is reflected in the specification 7. I think it was agreed in the Berlin meeting (the italics section) of the document that ALF and TCP transport sections should be re-written to make them sound like a protocol document rather than a educational peice of writing. We suggested some headings. 8. We made no attempt to change the technical parts of the ALF and TCP sections the changes we proposed were to aid clarity. 9. I was not at the Oslo meeting however I understand that there was still discussion of the transport issues after this meeting as the outcome was not clear. 10. If we don't do this then another device control protocol will be defined for ATM based MGs and we'll end up with the situation where we have 2 procedurally and symantically different media gateway control protocols. This will cost. Its better to have to have the same protocol.
Therefore I feel strongly that the sections regarding non-IP transport should remain. Hopefully I've captured most of the points from this thread.
Cheers, Christian
Brian Rosen wrote:
I'll point out again that the layer is not appropriate for ALF under non IP transport. So it would have to be something like:
"The following section illustrates a possible way to define
the interface
between the protocol implementation and a non-IP transport where Application Level Framing does not need to interact with the order messages are actually sent. This section is informative and implementations need not follow it"
Given that, it has no business taking up space in the document.
Brian
-----Original Message----- From: Hong Liu [mailto:lhong@RESEARCH.TELCORDIA.COM] Sent: Thursday, August 19, 1999 10:26 AM To: MEGACO@standards.nortelnetworks.com Subject: Re: Transport layer interface
Rex,
I think what Tom meant by "consensus" was from all the participants in the Oslo meeting. In that sense, it was a consensus from that meeting. Of course, Christian Grove was not in that meeting, and his contribution in Berlin reflects a different opinion in this topic.
I remember that the transport issue was indeed discussed in Berlin around 4:00am. Instead of debating the pros and cons then, the group decided to just put the text in for further discussion on the list. In other words, the intent was not to reflect any agreement reached in Berlin, rather it was to capture the issue. Maybe Nancy or John can comment on this.
Chip made the point a number of times in the meeting that the proposed sublayer, if added, shall be put in a separate session for "non-IP" transport. I think this is a reasonable proposal for compromise. It seems to me that this is also what the many people think from the emails I read along this thread.
--Hong
Rex Coldren wrote:
Tom, The one thing you would see that indicates that Oslo
didn't capture
consensus is the proposal from Christian Groves and the
reaction to
it in Berlin. The discussion went on for a while.
Unfortunately I don't
remember the exact outcome. Working all night tends to
blur things.
Perhaps Christian can summarize for us what was agreed or wasn't agreed to at that meeting before we kill the idea on the list.
Rex
Tom-PT Taylor wrote:
I kind of agree that this one is surplus to requirements.
It's main point
would be to provide a hook for transport evolution (e.g.
to Sigtran), if we
saw that in our future, but we should probably let the
future take care of
itself. This was an issue over which we took
considerable pains at Oslo,
and I haven't seen anything on the list to make me think
Oslo failed to
capture consensus.
-----Original Message----- From: Brian Rosen [SMTP:brosen@ENG.FORE.COM] Sent: Wednesday, August 18, 1999 5:51 PM To: megaco@standards.nortelnetworks.com Subject: Transport layer interface
Berlin inserted a concept that was discussed and discarded in the IETF process; defining a transport
independent interface
to the transport layer. The layer defines a set of
primitives
to be used between the protocol implementation and
any transport
layer. The goal is to maximize interoperability,
and to permit
transport over non-IP networks.
One of the major benefits of ALF is that it allows the
application
to make dynamic decisions on sending of messages in
the face of
congestion. You could, for example, queue a
message, discover
there was congestion, and decide to send another message before the enqueued message. You could even decide to not send the message at all. The application may make these decisions. Layered interfaces that only have simple "transfer" primitives cannot provide this kind of reaction to congestion.
For that reason, I question an attempt to provide a
transport
independent layer. The current wording is not
sufficient, as
the comments point out, and there are no submissions that would get us to a complete description.
The sections on transport using ALF and transport using TCP are, I think, satisfactory without the extra layer. Any additional transports, IP based or not, could be defined in subsequent editions, or in separate documents
without a layer
definition. Since there is not any claimed desire
to be able to
have a literal "plug this protocol code into that
transport code",
I don't think we will miss it.
What to do?
Brian
Brian Rosen, Principal Engineer FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 (724) 742-6826 mailto:brosen@eng.fore.com