Transport layer interface

[Christian Groves]

Hello Roy,

I don't think the issue is that a complete protocol proposal is needed.
In the ITU there are many instances where a protocol is designed and
place holders are left for further study. It shows that the issue was
explored but for time reasons it was not developed.

I would not like to confuse issues by adding detailed transport sections
for AAL1, AAL2 at this stage because it will delay the protocol.

IP is what is being developed today but we should allow for future
additions.

Cheers, Christian

"Roy, Radhika R, ALARC" wrote:
>
> Folks:
>
> I had also a brief discussion with Christian Groves in Berlin related to his
> high level contribution. His proposal has some merits. However, I requested
> him to provide a complete proposal (Christian can elaborate on this) how the
> actual protocol (procedures & semantics) can be separated from the
> transport.
>
> Radhika R. Roy
> AT&T
>
> > -----Original Message-----
> > From: Christian Groves [SMTP:Christian.Groves at ERICSSON.COM]
> > Sent: Thursday, August 19, 1999 3:36 AM
> > To:   MEGACO at 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:
> >
> > 1. 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 at RESEARCH.TELCORDIA.COM]
> > > > Sent: Thursday, August 19, 1999 10:26 AM
> > > > To: MEGACO at 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 at ENG.FORE.COM]
> > > > > > > Sent: Wednesday, August 18, 1999 5:51 PM
> > > > > > > To:   megaco at 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 at eng.fore.com
> > > >