Subject: Re: Transport layer interface

From: Stephen Terrill <[email-masked]>
Date: Wed, 1 Sep 1999 10:02:01 +0200

I feel that Keith has hit on a crucial point here.

Drage, Keith wrote:

> [cut]

> Unless you want to make the primitive interface an open interface, there is
> no need to implement the primitives. But because they define the behaviour
> of the protocol, they do need to be normative, and therefore in the main
> document. What you do need is some accompanying text that then gives the
> status of the primitive definitions and the requirements on implementations
> to support them. By making them informative, you simply waste the space
> where you document them.
>
> [Cut]

> Keith Drage
> Siemens Communications Limited
>

The primitives do not imply the implementation, but describe the functional behaviour of the protocols.  I do not support the primitive interface being an open interface, hence it is not testable.  Checking conformance to the Megacop/H.248 protocol is dependant upon the activities which happen on the line, not upon whether the internals of the box are layered or how it is internally structured.  This approach has been taken in some protocol systems for at least 15 years.

This technique can be used make use of the existing defined signalling transports.

Regards,

..//Steve

---

From: Stephen Terrill <[email-masked]>
Date: Wed, 1 Sep 1999 11:05:09 +0200

Hi Tom,

I support that in general there are two types of signalling transport as you have mentioned.  However within each "type" of transport there are a number of signalling transports which will be used (the requirements reflect a large number of application domains where there will be STM, ATM and IP signalling transport).  Is there a way to describe this in a interoperational manner.  I viewed that the primitive interface as way to describe the functionality.

Regards,

..//Steve

Regards,

..//Steve

Tom-PT Taylor wrote:

> Basically the transport layer interface proposal is an attempt to make the
> protocol transport-independent in the sense I understand it.  However, I
> think it is overkill.  I would suggest that we specify that the protocol is
> designed to run over two types of transport.
>
> Type 1: reliable (error-free, loss-free, unduplicated) datagram service,
> including congestion control.  TCP augmented by RFC 1006 TPKT is an example
> of such a service.  There should be one section of the document defining how
> Megaco/H.248 uses reliable datagram service.  I'm wondering whether we
> require this transport to also be sequence-preserving.
>
> Type 2: unreliable datagram service, where reliability, sequencing, and
> congestion control are the responsibility of the Megaco/H.248 protocol
> layer.  This is what people mean by ALF in the present discussion.  There
> should be a second section describing the required characteristics of
> implementations which use unreliable datagram service.
>
> AFAIK there is no difference on the wire at the Megaco/H.248 level between
> the two approaches; the differences are entirely in behaviour at the two
> ends.
>
> > -----Original Message-----
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Sep 1999 08:43:24 -0400

> This thread seems to be following a total misunderstanding as to why
> primitives exist in protocol definitions in the first place.
I don't think so, but let's see.

> Primitives are there as an abstract concept of what the layer
> above can
> initiate / be presented with, and similarly for the layer
> below. Behaviour
> of the protocol implementation is then defined in terms of
> the primitives
> and the PDUs, rather than in terms of the PDUs at the above
> layer, the below
> layer and the PDUs at the layer under definition.
Behavior is defined in terms of the primitives.

Okay, let's just take the "congestion" primitive.
It states that you get congestion.indication with a 0-10
parameter indicating congestion.  So the behavior of an
H.248 implementation must be defined in terms of this
primitive.

So, if my implementation, rather than having a primitive
that indicates 0-10, has an indication that has average
delay time to transfer a message, then I am not conformant,
right?

> You cannot define a protocol solely in terms of the PDU
> behaviour at the
> protocol layer itself. If you do this, you will get all the
> right responses
> from the remote end, but the remote end will not necessarily
> do what you
> asked it to.
I think this is a false statement.

I believe that one of the characteristics of a protocol is
that is it possible to determine, by external testing,
whether the implementation does in fact do what you asked
for it to do.

I would ask for an example of where some aspect of MEGACO
protocol is not externally testable.

Remember that we are talking about the PROTOCOL, and not
the absolute MG or MGC behavior (that is, I'll agree that
you can ask for a context to be created with some
terminations and the box could respond as if it did this,
but in fact totally ignored what you asked for it to do).
The protocol states how you make a request, and how that
request is acknowledged.  All protocol behavior is visible,
and should be testable.

> document.
Why?

Why should they define the behavior?
Why do we need to constrain implementations in this way?
What is the benefit of requiring all implementations to,
as in the example, have the same congestion model, regardless
of network, transport protocol, or circumstances?  Why?

The purpose of a protocol is to produce interoperable
implementations.  That is why we go through this process.
So I can build an MGC and you can build an MG, and when we
plug them together, they work.

What aspect of interoperability is affected by how the
protocol implementation interacts with its transport?
Just look at the layer definition.  I'll admit that EVERY
transport just has to have some kind of "transfer"
primitive in some way or other, but go down the list:
" IN-SERVICE.indication:
A primitive indicating that the signaling transport is able
to exchange signaling messages with the peer entity H.248.
This indication shall be provided without the H.248
signaling entity requesting any service across the SB-SAP."

What if I only tell it I'm out of service when you ask for
a message to be transferred?  What interoperability is affected?

What if I NEVER say this - black hole, but I rely on my application level
timer?

" OUT-OF-SERVICE.indication:
A primitive indicating that the signaling transport is
unable to exchange signaling messages with the peer entity
H.248. This indication shall be provided without the H.248
signaling entity requesting any service across the SB-SAP. "

Same as above!

" TRANSFER.request:
A primitive used by a H.248 signaling entity to convey a
signaling message to its peer entity. This primitive has a
single parameter, the Message."

What if I have more than one parameter, priority for example?  I'll admit
it's hard to have a transport without some form of transfer request :)

" TRANSFER.indication:
A primitive indicating the reception of a signaling message from the peer
entity at a H.248 signaling entity. This primitive has a single parameter."

Same as above!

 CONGESTION.indication:
Covered above

>What you do need is some accompanying text that
> then gives the
Well, at one point I thought you wanted to do this so that
all transports could be defined in a uniform way.
I understood this, although I didn't agree that this way
was an appropriate way.  If it was a convenience for
description, then making the text that described this
interface informative was reasonable - it did not constrain
implementations.

When you try to make it normative - to constrain implementations - then I
think it's very wrong.

>
> Of course, if you have no layering, and merge the transport and the
> application completely, then you have no need of primitives,
> but who wants
> something that is totally monolithic in this manner.
I'd say most of us, if we actually voted, and the question was: do we want
to mandate a particular interface between the protocol and transport which
constrains implementations and is not externally visible.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Sep 1999 08:44:59 -0400

Works for me.  If you describe how the protocol works for
a reliable, non duplicative protocol, then any such transport
can easily be accommodated, and my ALF over
raw AAL5 also is covered by the unreliable part.
I like it a lot.

I think in practice that the "reliable" (e.g.
TCP/SSCOP/SCTP) protocols should be, in at least this
version, assumed to be ordered delivery (sequence
preserving).  I'm not sure it makes any difference,
because MEGACO has its own ordering provisions,
but I think it will be easier in the text to assume it is
so, and all the reliable transports that I have heard
people consider do in fact preserve sequence order.

There is clearly an "on-the-wire" difference in that the
chosen transport headers, etc. are visible, and the rules
(for congestion avoidance for example) of the chosen
transport is observable.  The behavior of the MEGACO part
is, as you observe, not visible.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Tuesday, August 31, 1999 9:14 PM
> To: [email-masked]
> Subject: Re: Transport layer interface
>
>
> > From: Brian Rosen [SMTP:[email-masked]]
> > Sent: Tuesday, August 31, 1999 4:45 PM
> > To:   [email-masked]
> > Subject:      Re: Transport layer interface
> >
> > Christian
> >
> > We seem to be having a problem with English.
> >
> > If the interface is normative, then every implementation
> > must follow it exactly as written.  In this case, I would
> > have to find a place in the code where there was something
> > that conformed to the transfer primitive, and there must be
> > something that conformed to the congestion indication.
> >
> > Suppose my implementation does not have a congestion
> > indication, with a 0-10 value.  Suppose it returns the
> > average delay time to get a message through from whatever
> > I use to request a transfer.
> >
> > Am I conformant to the current draft?  This question has a
> > yes/no answer -- I am conformant, or I am not conformant.
> >
> > If I am conformant, the layer definition does not define
> > implementation and is informative - the words do not convey
> > a conformance requirement, they are merely illustrative.
> >
> > If I am non conformant, the layer definition does define
> > implementation and is normative - the words state what I
> > must do in my implementation.
> >
> > If it is normative, and its use is required to claim
> > conformance, then I should be able to define a conformance
> > test for it.  Is that what you advocate?
> >
> > We clearly need some normative text around transport.
> > There are aspects that we have decided all implementations
> > must conform to.  These aspects are externally visible.
> > For example, requiring that MG implementations not all hit
> > their MGCs simultaneously if they all happen to restart.
> >
> > I'm not afraid of having a couple of lines here and there
> > that are informative (implementations may wish to consider
> > ....), but not a page and a half of text that may or may
> > not illustrate how some undefined transport might interface
> > to the protocol.
> >
> > I clearly understand the distinction between a primitive
> > and an API.  We aren't arguing that.  I'm also agreeing
> > that there isn't any magic in protocol design, although
> > there is an art to describing a protocol in a clear manner
> > which does not constrain implementations and yet produces many
> > interoperable
> > implementations.  I would go so far as
> > to say that most protocol definitions are not clear and
> > they do unnecessarily constrain implementations.  Trying to
> > argue that there are lots of bad protocol documents out
> > there and so we should be as bad is not a very good
> > argument to me.
> >
> > Brian
> >
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Tuesday, August 31, 1999 12:31 AM
> > > To: [email-masked]
> > > Subject: Re: Transport layer interface
> > >
> > >
> > > Primtives are an abstraction. Primitives are used to define
> > > the flows of
> > > data between the Application and transport. The interface
> between the
> > > Application and the transport must support these flows on
> > > data. How you
> > > implement it is up to you and your application. For instance the
> > > transfer.data primitive - it may be as simple as setting a
> > > push bit on a
> > > TCP packet. The transfer.data primitive says you have to
> be able to
> > > support sending data to the transport it doesn't say to set a
> > > bit which
> > > is implementation specific.
> > >
> > > I think people are intelligent enough on this list to realise that
> > > there's no magic in protocol design.
> > >
> > > I'm glad that its accepted that conformance to H.248 on
> an interface
> > > between the application and transport. Does that mean that
> > > the transport
> > > sections for ALF and non-IP transport will both be made into
> > > informative
> > > annexes? By mandating ALF its making an implementation
> decision for
> > > everybody who will use the protocol with IP transport.
> > >
> > > Cheers, Christian
> > >
> > >
> > > Brian Rosen wrote:
> > > >
> > > > Okay, so now we have a different story from what I understood.
> > > >
> > > > You want to MANDATE that EVERY implementation of a non-IP
> > > transport have the
> > > > layer primitives as defined.  If the
> > > > layer changes, implementations must change.
> > > > Implementations not conforming to the layer interface would
> > > > not be conformant to the protocol.  That is why you want it
> > > > to be normative - you really do want to define
> > > > implementation.
> > > >
> > > > In a prior message you said:
> > > > >....Layering is not
> > > > >defining an IMPLEMENTATION it is actually allowing the
> opposite.
> > > > That was what got me to the idea that you advocated an
> > > abstraction, not a
> > > > conformance requirement.
> > > >
> > > > That makes it easier, I think.  As long as you claimed the
> > > > layer was an abstraction for the purpose of making the
> > > > definition of transport simple, I think you had support
> > > > from people who always think transport is a black hole -
> > > > put bits in, they magically appear on the other side.
> > > >
> > > > When you make the layer mandatory to implement, I think
> > > > you lose many of these folks.  I'll let them speak for
> > > > themselves.
> > > >
> > > > For me, I don't think that conformance to H.248 should be
> > > > conditioned on the implementation of any particular
> > > > interface between the protocol and it's transport.
> > > > That is an implementation decision.
> > > >
> > > > Brian
> > > >
> > > > > From: Christian Groves [mailto:[email-masked]]
> > > > > Sent: Monday, August 30, 1999 7:10 AM
> > > > > To: [email-masked]
> > > > > Subject: Re: Transport layer interface
> > > > >
> > > > >
> > > > > A compromise would be easy if one was put forward. I
> > > don't see moving
> > > > > the choice from : not being in the protocol at all, to: leave
> > > > > it in for
> > > > > a while before it is removed (ie. informative) is a serious
> > > > > compromise.
> > > > >
> > > > > I believe that both transport descriptions can live together.
> > > > > In Berlin
> > > > > we had the option to  introduce the layered transport for IP
> > > > > solutions.
> > > > > I however I think we saw that both solutions can live
> > > together. This
> > > > > "was" the original intention. Thus again I would like them
> > > > > documented in
> > > > > the same way.
> > > > >
> > > > > The primitive interface defines the functionalities
> that must be
> > > > > supported in the interface between the application and
> > > transport. In
> > > > > this way people are free to implement it how they like as
> > > long as they
> > > > > provide for the flows described by the primtives. If the
> > > layer changed
> > > > > completely then the implementation would change because
> > > the data flows
> > > > > would
> > > > > be different. ie. if you change an API people's
> > > implementations will
> > > > > change. People's applications are free to  drive the
> > > transport as they
> > > > > see fit, without a certain ALF being mandated.
> > > > >
> > > > > Its not an observable interface because there's nothing
> > > going across a
> > > > > wire I believe this is the same as ALF.
> > > > >
> > > > > If a primitive interface crys out to be Informative then
> > > I suggest the
> > > > > ITU has a very big task adhead of it to redocument a lot
> > > of protocols
> > > > > as 'Informative'.
> > > > >
> > > > > Christian
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brian Rosen wrote:
> > > > > >
> > > > > > I can see that compromise is not going to be easy.
> > > > > >
> > > > > > The text is INFORMATIVE because it does not define the
> > > > > operation of the
> > > > > > protocol.  It tells you how to interpret some
> > > > > (non-existent) definition of a
> > > > > > transport.  By definition, and your own statements, the
> > > > > layer does NOT
> > > > > > define implementation -- it is a convenience for describing
> > > > > a transport.  It
> > > > > > isn't required to be able to define a
> > > > > > transport, and it may or may not be used to describe future
> > > > > transports - we
> > > > > > just don't know.
> > > > > >
> > > > > > If the layer definition changed completely, no
> > > > > implementation would have to
> > > > > > change, right?  It's not
> > > > > > an observable interface.
> > > > > >
> > > > > > Gets to the heart of the problem, doesn't it?
> > > > > >         It has no purpose in the current edition
> > > > > >         It may or may not be used in a future edition
> > > > > >         If it is used, it doesn't define behavior, or
> > > > > >                 implementation
> > > > > > Doesn't that really yell out "informative" (at best) to you?
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > From: Christian Groves
> [mailto:[email-masked]]
> > > > > > > Sent: Sunday, August 29, 1999 7:44 PM
> > > > > > > To: [email-masked]
> > > > > > > Subject: Re: Transport layer interface
> > > > > > >
> > > > > > >
> > > > > > > I would like the layering section remain pretty much
> > > as is. I've
> > > > > > > mentioned before that I'd be happy with moving the
> > > > > primitive interface
> > > > > > > to the non-IP section but keep the other text
> where it is. I
> > > > > > > definately
> > > > > > > do NOT want it moved to an INFORMATIVE annex because
> > > it won't be
> > > > > > > retained. I see that ALF and transport layering
> have the same
> > > > > > > status in
> > > > > > > that they are equally valid for transport.
> Therefore I would
> > > > > > > like to see
> > > > > > > them documented in the same way. If ALF is moved to an
> > > > > > > informative annex
> > > > > > > then i'll be happy doing the same with the non-IP section.
> > > > > > >
> > > > > > > The idea of presenting the sections as they are today in
> > > > > H.248 is that
> > > > > > > there is a 'core' protocol. Which exists
> irregardless of ALF
> > > > > > > or layered
> > > > > > > transport and a transport section which defines different
> > > > > transports.
> > > > > > > This is to ensure independence.
> > > > > > >
> > > > > > > The purpose of a mailing list is to discuss issues if
> > > > > people feel that
> > > > > > > they want to discuss the applicability of ALF then they
> > > > > should be able
> > > > > > > to, if they want to talk about SCTP then they
> should as times
> > > > > > > change and
> > > > > > > it may be appropriate for consensus.
> > > > > > >
> > > > > > > My original sentiment (which I believe Chip
> > > expressed) was that
> > > > > > > different transports could exist (in harmony) if the
> > > transport was
> > > > > > > seperated from the protocol section and that they had an
> > > > > equal footing
> > > > > > > in the document. I don't see why one should preclude
> > > the others.
> > > > > > >
> > > > > > > Cheers, Christian
> > > > > > >
> > > > > > > Brian Rosen wrote:
> > > > > > > >
> > > > > > > > It was clearly and decisively concluded in Oslo
> that there
> > > > > > > was a consensus
> > > > > > > > that ALF using UDP should be one of the transport
> > > > > > > mechanisms.  Similarly,
> > > > > > > > TCP had a strong consensus.  SCTP was
> discussed, and there
> > > > > > > was, at that
> > > > > > > > time, no consensus.
> > > > > > > >
> > > > > > > > This debate is NOT about which tranports Megaco/H.248
> > > > > > > should be defined
> > > > > > > > for.  It is whether defining an abstract layer
> to describe
> > > > > > > the interface
> > > > > > > > between the protocol and some undefined, future, non-IP
> > > > > transport is
> > > > > > > > appropriate.
> > > > > > > >
> > > > > > > > It has the curious characteristic that it's absence will
> > > > > > > not be missed -
> > > > > > > > there are no protocols defined using it, and it's use or
> > > > > > > non use would not
> > > > > > > > change externally visible behavior.  In
> particular, it is
> > > > > > > missing the
> > > > > > > > following statement:
> > > > > > > > "NOTE: The abstract layer DOES NOT define nor suggest an
> > > > > > > IMPLEMENTATION's
> > > > > > > > interface between protocol and transport.  It
> is strictly a
> > > > > > > convenience for
> > > > > > > > describing transports.  Not all transports are,
> or will be
> > > > > > > described using
> > > > > > > > this abstraction."
> > > > > > > >
> > > > > > > > I'm in the mood for a compromise.  Suppose we take the
> > > > > text, add the
> > > > > > > > disclaimer, and move it to an INFORMATIVE annex.
> > > > > > > >
> > > > > > > > Brian
> > > > > > > >
> > > > > > > > > From: Rex Coldren [mailto:[email-masked]]
> > > > > > > > > Sent: Thursday, August 26, 1999 4:35 PM
> > > > > > > > > To: [email-masked]
> > > > > > > > > Subject: Re: Transport layer interface
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hong,
> > > > > > > > >    THE reason that we balked on using SCTP as
> a transport
> > > > > > > mechanism
> > > > > > > > > is that, even though it is "mature",  it is not yet a
> > > > > > > > > standard.  I also note that
> > > > > > > > > ALF is not a standard and I don't believe
> that anyone has
> > > > > > > > > even tried to
> > > > > > > > > define it as such.  But perhaps you could help me
> > > here.   Is
> > > > > > > > > ALF the subject
> > > > > > > > > of standardization within any active working
> > > group or is it
> > > > > > > > > an already published
> > > > > > > > > standards-track RFC?.
> > > > > > > > >
> > > > > > > > >    What I am saying is you either include all
> reasonable
> > > > > > > > > choices for describing
> > > > > > > > > transport in the protocol spec or you exclude
> them.  The
> > > > > > > > > requirements have
> > > > > > > > > been clearly stated in the MEGACO
> requirements document
> > > > > > > > > already (or if they
> > > > > > > > > haven't they should have been).  If a
> particular candidate
> > > > > > > > > transport cannot meet
> > > > > > > > > these requirements, then we should not be
> spending time in
> > > > > > > > > the protocol spec
> > > > > > > > > trying to make it do so.  If we allow one
> > > exception to this
> > > > > > > > > rule (e.g.-ALF), we
> > > > > > > > > should allow them all (e.g.-include SCTP).
> > > > > > > > >
> > > > > > > > >    And, yes, I am a proponent of keeping the
> transport and
> > > > > > > > > the application cleanly
> > > > > > > > > separated.  ALF does not do that.  It does the
> > > opposite.  It
> > > > > > > > > should not be a topic
> > > > > > > > > of the protocol spec, IMHO.  Describing a
> transport layer
> > > > > > > > > interface is more
> > > > > > > > > appropriate in a protocol spec than ALF is.
> > > > > > > > >
> > > > > > > > > Rex
> > > > > > > > >
> > > > > > > > > Hong Liu wrote:
> > > > > > > > >
> > > > > > > > > > Rex,
> > > > > > > > > >
> > > > > > > > > > I don't think the issue here is for or against
> > > using SCTP
> > > > > > > > > or other transport
> > > > > > > > > > mechanism for MEGACOP/H.248. As Tom said in
> a previous
> > > > > > > > > email, when SIGTRAN matures,
> > > > > > > > > > people may find a way of using it. So let's
> do mix this
> > > > > > > > > topic with ALF.
> > > > > > > > > >
> > > > > > > > > > ALF, stands for APPLICATION level framing.
> The idea is
> > > > > > > > > general, but how it can be
> > > > > > > > > > done depends on each application. You seem to think
> > > > > > > > > otherwise. Why don't you show
> > > > > > > > > > us how you can separate ALF completely from
> > > MEGACOP/H.248?
> > > > > > > > > We all will see whether
> > > > > > > > > > it makes sense.
> > > > > > > > > >
> > > > > > > > > > ALF has been proven to work in various
> applications. In
> > > > > > > > > particular, it has been
> > > > > > > > > > shown to work in similar environment as
> MEGACOP/H.248. I
> > > > > > > > > think the intent of this
> > > > > > > > > > thread is on how to provide non-IP transport,
> > > not to remove
> > > > > > > > > or redefine ALF in
> > > > > > > > > > MEGACOP/H.248.
> > > > > > > > > >
> > > > > > > > > > I just hope it is not another attempt to do
> > > !####! again.
> > > > > > > > > Maybe I am too naive to
> > > > > > > > > > think that we have already passed that part.
> > > > > > > > > >
> > > > > > > > > > --Hong
> > > > > > > > > >
> > > > > > > > > > Rex Coldren wrote:
> > > > > > > > > >
> > > > > > > > > > > Qiaobing,
> > > > > > > > > > >    I definitely agree with you on this.
> > > That's why the
> > > > > > > > > arguments about ALF
> > > > > > > > > > > and the transport layer interface are so
> > > baffling.  I've
> > > > > > > > > thought all along that
> > > > > > > > > > > ALF is just a mechanism for allowing use of a
> > > transport
> > > > > > > > > layer that doesn't
> > > > > > > > > > > meet the basic requirements of the
> > > application protocol
> > > > > > > > > (the examples being
> > > > > > > > > > > UDP and H.248, respectively).
> Consequently, I believe
> > > > > > > > > that ALF should be
> > > > > > > > > > > something defined outside of the protocol since it
> > > > > > > > > presumably could be used
> > > > > > > > > > > for other applications needing the same kinds
> > > of support.
> > > > > > > > >  The argument for
> > > > > > > > > > > including ALF in the protocol specification
> > > is analogous
> > > > > > > > > to arguing that SCTP
> > > > > > > > > > > should be part of the protocol specification.
> > >  And trust
> > > > > > > > > me on this one, if I
> > > > > > > > > > > believed that including this type of thing in
> > > a protocol
> > > > > > > > > spec was acceptable I
> > > > > > > > > > > sure would be stumping for use of SCTP
> instead of ALF!
> > > > > > > > > > >
> > > > > > > > > > > Rex
> > > > > > > > > > >
> > > > > > > > > > > Qiaobing Xie wrote:
> > > > > > > > > > >
> > > > > > > > > > > > If it's this easy, people can stop
> worrying about
> > > > > > > diffserv :)
> > > > > > > > > > > >
> > > > > > > > > > > > In certain sense I do see your point,
> that if the
> > > > > > > > > application can take
> > > > > > > > > > > > over responsibilities from all the
> "layers", you can
> > > > > > > > > potentially optimize
> > > > > > > > > > > > the application behivors. However, this
> makes things
> > > > > > > > > unimplementable (is
> > > > > > > > > > > > this one of the reasons the layered model was
> > > > > > > > > introduced in the first
> > > > > > > > > > > > place).
> > > > > > > > > > > >
> > > > > > > > > > > > regards,
> > > > > > > > > > > >
> > > > > > > > > > > > -Qiaobing
> > > > > > > > > > > >
> > > > > > > > > > > > On Aug 26,  7:35am, Brian Rosen wrote:
> > > > > > > > > > > > > Subject: Re: Transport layer interface
> > > > > > > > > > > > > This is too easy:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1. E911 - 12 calls are queued in buffers,
> > > network is
> > > > > > > > > busy and a 911 call
> > > > > > > > > > > > > comes through -- it is put at the
> head of the line
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2. "Olympic" service.  Service
> provider offers a
> > > > > > > > > variety of plans, at
> > > > > > > > > > > > > different costs.  Under congestion,
> Gold service
> > > > > > > > > customers get better
> > > > > > > > > > > > > performance
> > > > > > > > > > > > >
> > > > > > > > > > > > > 3. 30 messages are queued, some of them
> > > "Adds", some
> > > > > > > > > subtracts.  A
> > > > > > > > > > > > > message comes from the MG which is
> something that
> > > > > > > > > equates to "out of
> > > > > > > > > > > > > DSP" resources.  Reorder the messages
> so subtracts
> > > > > > > > > are ahead of Adds.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The first one may turn out to be a
> > > requirement, and
> > > > > > > > > that may FORCE
> > > > > > > > > > > > > ALF in EVERY implementation.  YMMV.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Brian
> > > > > > > > > > > > >
> > > > > > > > > > > > > > From: John Segers
> [mailto:[email-masked]]
> > > > > > > > > > > > > > Sent:
> Thursday, August 26, 1999 3:38 AM
> > > > > > > > > > > > > > To: Brian Rosen
> > > > > > > > > > > > > > Cc: [email-masked]
> > > > > > > > > > > > > > Subject: Re: Transport layer interface
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > All,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't quite understand how ALF will be
> > > > > > > > > substantially better for
> > > > > > > > > > > > > > congestion management than a
> layered approach.
> > > > > > > I understand
> > > > > > > > > > > > > > that if the
> > > > > > > > > > > > > > the application has control over message
> > > > > buffers, it can
> > > > > > > > > > > > > > reorder them.
> > > > > > > > > > > > > > What I'm wondering is whether
> > > > > > > reordering/canceling MEGACO
> > > > > > > > > > > > > > messages will
> > > > > > > > > > > > > > lead to a sufficient reduction in
> > > traffic, in the
> > > > > > > > > presence of media
> > > > > > > > > > > > > > streams on the same network.  Can
> someone give
> > > > > > > an example
> > > > > > > > > > > > > > where it would
> > > > > > > > > > > > > > help?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > John
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > John Segers
> > >      email:
> > > > > > > > > [email-masked]
> > > > > > > > > > > > > > Lucent Technologies
> > > > > > > > >        Room HE 306
> > > > > > > > > > > > > > Dept. Forward Looking Work
> > > > > > > > > phone: +31 35 687 4724
> > > > > > > > > > > > > > P.O. Box 18, 1270 AA  Huizen
> > > > > > > > > fax: +31 35 687 5954
> > > > > > > > > > > > > >
> > > > > > > > > > > > >-- End of excerpt from Brian Rosen
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 1 Sep 1999 12:24:25 -0500

You don't gain any interoperability by specifying a primitive interface --
just portability of your implementation.  Specifying a set of primitives
which doesn't match your chosen transport protocol means you also need an
adaptive layer above the transport.  The adaptive layer means the
Megaco/H.248 layer is shielded from transport details, but the total amount
of specification and implementation is the same either way.

> From: Stephen Terrill [SMTP:[email-masked]]
> Sent: Wednesday, September 01, 1999 5:05 AM
> I support that in general there are two types of signalling transport as
> you have mentioned.  However within each "type" of transport there are a
> number of signalling transports which will be used (the requirements
> reflect a large number of application domains where there will be STM, ATM
> and IP signalling transport).  Is there a way to describe this in a
> interoperational manner.  I viewed that the primitive interface as way to
> describe the functionality.
>
> Regards,
>
> ..//Steve
>
> Regards,
>
> ..//Steve
>
> Tom-PT Taylor wrote:
>

---

From: "Drage, Keith" <[email-masked]>
Date: Wed, 1 Sep 1999 16:45:22 +0100

I understand what Steven is saying here, when he says he does not want the
primitive interface to be testable, but the form of words used is
misleading. The primitive interface carries actions which do result in a
test of the protocol.

As an example, consider the N to the N+1 layer. A primitive
(ESTABLISH.request) is defined from N+1 to N which specifies a request for
establishment of a new connection. A requirement exists in the protocol:

"On receipt of an ESTABLISH.request primitive the protocol entity shall send
a SETUP PDU."

For testing purposes, a question will exist in the PIXIT proforma that
requests the required action on the system under test that will result in
the generation of a SETUP PDU. This information is supplied by the system
designer.

A test purpose will exist that checks for the generation of a SETUP PDU
based on the stimulus specified in the PIXIT.

Therefore while the primitive interface will not be explicitly tested, the
actions implicitly performed across that primitive interface will be tested.

Similar specification, and therefore testing, would take place between the N
and the N-1 layer to ensure that the SETUP PDU identified above is
encapsulated in the correct N-1 layer PDU. This would be part of the the N
layer PDU constraint definition within the N-layer test suite, and tests
would also be performed at the N-1 layer based on a primitive request to
transfer a data packet.

As an aside, I would point out that definition of the protocol requirements
in this fashion do make the creation of test suites for the protocol easier.

I would stress yet again that the layering and primitives are an abstract
concept, and while normative, definitions should make this clear; they only
turn into physical reality if you wish to define an open interface between
software packages in an implementation.

> Sent: Wednesday, September 01, 1999 9:02 AM
> To:   [email-masked]
> The primitives do not imply the implementation, but describe the
> functional behaviour of the protocols.  I do not support the primitive
> interface being an open interface, hence it is not testable.  Checking
> conformance to the Megacop/H.248 protocol is dependant upon the activities
> which happen on the line, not upon whether the internals of the box are
> layered or how it is internally structured.  This approach has been taken
> in some protocol systems for at least 15 years.
>

---

From: "Drage, Keith" <[email-masked]>
Date: Wed, 1 Sep 1999 18:13:45 +0100

See comments below. I do not think we are a million miles apart - it is just
that Brian is drawing different conclusions!!!

Keith Drage
Siemens Communications Limited.

> Sent: Wednesday, September 01, 1999 1:43 PM
        [Drage, Keith]  I think the main misunderstandings are as to how
they constrain implementations, and a view that if they are defined as
normative, they have to be implemented. If I take as an example another
abstraction, the abstract syntax notation (ASN1). What I implement is the
transfer syntax (the BER or PER). The abstract syntax definition is
normative, but as an implementor I am totally free to decide whether to
compile the abstract syntax and therefore hard code the compiled version
into the implementation, or whether to interpret received bits against the
abstract syntax when I receive them. Therefore, if I so wish, the abstract
syntax may never be found in the final implementation.

> delay time to transfer a message, then I am not conformant,
        [Drage, Keith]  First decide what behaviour you want to be
standardised. See comments below on selecting the behaviour either side of
the primitive interface. If I understand correctly, as currently defined,
apparently there is a requirement to present the congestion information in a
quantised fashion to the recipient. That is a constraint. It may be better
that the recipient itself does the quantising. Conversely there may need to
be a specific understanding and behaviour within the protocol for each
quantised value. You are designing the protocol, not me.
> I think this is a false statement.
        [Drage, Keith]  In most cases, on receiving a PDU, you will want to
send an indication to the application / next layer up. Similar you will
normally send a PDU on receipt of an indication from the application from
the application / next layer up. This is behaviour. If you do not define
such behaviour, then a full conformant implementation can spontaneously
generate all sorts of information and still be conformant. It can receive
PDUs and totally ignore them. OK, the market will soon eliminate the product
in many cases, but in ISDN implementations we still find odd things that are
fundamentally due to a misunderstanding / misinterpretation of the primitive
interface between L2 and L3, for example, and we have to allow for those
misunderstandings in the peer entity as the other product has been on the
market for a number of years. Therefore interoperability problems can exist.
> whether the implementation does in fact do what you asked
        [Drage, Keith]  Depends how many points of control you have. For
example, in ISDN testing, one point of control is on the wire, i.e. some
layers below (and therefore some primitive interfaces below) what is being
tested, and the other point of control is either on another port (in the
case of network testing) or on the user interface (in the case of terminal
testing), also above another primitive interface.

> > of the protocol, they do need to be normative, and therefore
        [Drage, Keith]  Fundamentally, so that you do not need to fully
define the behaviour on the other side of the primitive interface to the
layer which you are defining.

> Why should they define the behavior?
        [Drage, Keith]  The important thing is to separate the behaviour to
be standardised, from that which is not to be standardised. For application
protocols (e.g. ISUP and DSS1, B-ISUP and DSS2) we have worked hard to
ensure that the minimum behaviour is standardised (below the primitive
interface) and the maximum is left to the the application process to perform
in an implementation dependent fashion (i.e. above the primitive interface.
In many cases, all the behaviour that is needed is to inform the application
that a valid PDU has been correctly received, or respond to the application
by sending a syntactically correct PDU. Other areas, e.g. channel selection
in ISDN, require more behaviour to be specified.

> of network, transport protocol, or circumstances?  Why?
        [Drage, Keith]  If they constrain implementations, then the
application functionality has been over defined. This problem can exist with
or without primitive definitions.

> plug them together, they work.
        [Drage, Keith]  There are many reasons for a requirement to exist a
protocol, of which this is only one, albeit an important one. Fundamentally,
when we write a requirement in a protocol, very little discussion takes
place as to why that requirement exists, rather than remains unwritten.
Other reasons for insertion of requirements into protocols are:
        -       because the law requires it
        -       to avoid interference with systems other than the peer
system
        -       to secure information with certain parts of a system (by
requiring it not to be transferred into the protocol at that user)
        -       to specify the circulation of information round systems
(i.e. if I subscribe to CLIP, you will send me a envelope, even if it is an
empty envelope because the address is restriced).
        This list is not complete, nor is it consistently checked for all
protocols.

> a message to be transferred?  What interoperability is affected?
        [Drage, Keith]  None. Examine the requirement to see if it is
needed. The fact that a primitive exists currently does not necessarily mean
that the design is correct. However note that I have already said that
interoperability is not the only reason for a requirement.

> signaling entity requesting any service across the SB-SAP. "
        [Drage, Keith]  Same as above.

> What if I have more than one parameter, priority for example?
        [Drage, Keith]  If I understand the point that you are making, this
is a problem that only arises if you try to specify an implementable
primitive interface. While it is abstract, you do not need to worry about
queues at the primitive interface itself.
> I'll admit
        [Drage, Keith]  Quite.

> entity at a H.248 signaling entity. This primitive has a single
        [Drage, Keith]  Agreed.

> think it's very wrong. [Drage, Keith]   It can be normative, without
> constraining the implementations.
>
> >

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Sep 1999 18:25:05 -0400

Well it's possible we are converging in the following
manner:

If the only primitives defined are transfer.request and
transfer.indicate, no parameters are defined, and there
is no other discussion of the layer, then we have reached a
point at which at least I can say it isn't wrong.  Whether
it makes any sense to have a layer that only has those
primitives becomes the issue at hand.

> syntax may never be found in the final implementation.
I would say that you are merely describing the difference
between primitives and an explicit API.  I already agreed
that the layer did not define the syntax, it did define
semantics.  When it states "there is only one parameter",
that does not say how parameters are represented, but it
does state that 0 or 2 of them is non-conformant.

> quantised value. You are designing the protocol, not me.
We didn't define a congestion model until this layer
proposal came along.  I further believe it is inappropriate
to define a particular congestion model independent of
network and transport protocol.  So if the bottom line is
that if this primative isn't what we want then either
redefine it to represent what we want or get rid of it,
then we would get rid of it.

> > > behaviour at the protocol layer itself. If you do
> > > this, you will get all the right responses
> > > do what you asked it to.
>       [Drage, Keith]  In most cases, on receiving a PDU, you
> will want to send an indication to the application /
> next layer up. Similar you will normally send a PDU on
> receipt of an indication from the application from
> the application / next layer up. This is behaviour.
> If you do not define such behaviour, then a full
> conformant implementation can spontaneously
> generate all sorts of information and still be
> conformant. It can receive PDUs and totally ignore them.
> OK, the market will soon eliminate the product
> in many cases, but in ISDN implementations we still find odd
> things that are fundamentally due to a misunderstanding /
> misinterpretation of the primitive interface between L2
> and L3, for example, and we have to allow for those
> misunderstandings in the peer entity as the other product has
> been on the market for a number of years. Therefore interoperability
> problems can exist.
I don't see the relevance here.  Yes transports usually
accept messages to send, and notify someone when a message
is received.  The protocol defines when bits on the wire
should or should not occur.  Internal layers don't
(shouldn't) change bits on the wire.  If the
implementations generates "extra" information, but does not
change bits on the wire, the implementation is conformant.
It may not be efficient, but it is conformant.  Anything
that proscribes INTERNAL behavior, not visible on the wire,
is not appropriate in a protocol description.

> testing), also above another primitive interface.
That only means you have a non-trivial test environment.
Real H.248 testing will need a non-trivial test
environment.  This does not change the validity of my
assertion that if it's in the spec, it has to be testable.
Just because it's hard to test is not a good excuse.

> > > no need to implement the primitives. But because they define
> > > the behaviour of the protocol, they do need to be
> > > normative, and therefore in the main document.
> > Why?
Seems like this is impossible - if you constrain one side
of the interface, you constrain the other.  In the example
above, if the primative is a 0-10 congestion indication,
then the transport has to be able to determine congestion
and assign a level.   The behavior of the transport MUST
follow the behavior of the primative interface.

>       [Drage, Keith]  The important thing is to separate the
> behaviour to be standardised, from that which is not to be standardised.
> For application protocols (e.g. ISUP and DSS1, B-ISUP and
> DSS2) we have worked hard to ensure that the minimum
> behaviour is standardised (below the primitive
> interface) and the maximum is left to the the application
> process to perform in an implementation dependent fashion
> (i.e. above the primitive interface.
A layer consisting of transfer request and transfer
indicate with no other behavior specified is silly.
The question at hand is, are there any other behaviors
that need to be specified?  I believe there are not.

That means the layer has no usefull function.

> or without primitive definitions.
Having a specific congestion model constrains
implementations quite a bit.  I gather then you would say
it is not appropriate to specify and should be removed.
I agree :)

>       This list is not complete, nor is it consistently
I agree with this.  That is the "why is the protocol
defined this way".  That does NOT imply that the protocol
has behavior specified beyond that which is visible on the
wire.  I'll again agree that it's close to impossible to
avoid defining what you expect the device to do when it is
told something by the protocol, but the actual protocol
definition (the NORMATIVE part anyway) is the issue at
hand -- I expect MGs to make connections to a TDM
interface, and the protocol says this, but it isn't
actually a requirement of the PROTOCOL.  All of the
items listed are why we specify something in an
interoperable way.  If it does not express what is required
behavior for interoperability, it does not belong in a
protocol spec.
> interoperability is not the only reason for a requirement.
I think this answer is "we don't need it".  There are no
requirements that would lead you to having to have
transport tell you it is out of service without a message
being past.  Quite the contrary, there are mechanisms
defined in the protocol which are intended to detect MG or
MGC or communciation failure.

I'll go on to point out that there is no function left - we
don't need any indication that communication is lost from
the transport interface. So we could reasonably delete the
entire primative.

> queues at the primitive interface itself.
Not so fast.  If the primative definition says "this
primative has a single parameter" that is proscriptive.
It doesn't matter why I would want more than one parameter,
if the primative states "this primative has a single
parameter" and any implementation has 2 parameters, it is
non-conformant.  The only way out is to not say that.
So the definition of transfer.request is would be simply
that it transfers a message.

So what are we left with?

Transfer.request and transfer.indication that transfer messages.

That is ALL.  So now, does the layer help?

Brian

---

From: "Drage, Keith" <[email-masked]>
Date: Thu, 2 Sep 1999 11:09:06 +0100

I have come to the conclusion that we are discussing this with different
objectives in view.

My reason for intervention in the argument was that if we have a layered
architecture, then the interface between the layers, and that to the
application process, should be properly defined using primitives. That way
we have a clear understanding of whether the functionality is in the scope
of this document (or outside the scope and therefore defined elsewhere or
implementation dependent).

Brian's conclusion, by examining the currently proposed primitives, is that
the layer has null functionality, and because it has null functionality, we
do not need it. There have been long discussions on the list as to the need
for such a layer or not, and I will leave it to other members of the list to
complete that argument.

As a final remark, I would note that other discussions on this thread have
led to identification of possible text stating "for further study". I do not
wish to see this text in something that gets used as a standard (using the
term "standard" in the loosest interpretation). A standard has a scope, and
the subject matter is either in the scope, and fully documented, or outside
of the scope, and not documented within this standard. However, the standard
does represent the complete statement of what is required to be conformed to
at the moment of its publication. I cannot conform to "a further study
item". As placeholders, such indicators also tend to be misleading - in
reality they give very little indication as to where standards get extended
in the future.

Keith Drage

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Wednesday, September 01, 1999 11:25 PM
> To:   'Drage, Keith'; [email-masked]
> Subject:      RE: Transport layer interface
>