Subject: Topology

From: Brian Rosen <[email-masked]>
Date: Sat, 21 Aug 1999 22:40:37 -0400

In the Berlin draft, a concept called "topology" was introduced.
This provides a pairwise control of flow (isolate, one way, both way) to the
terminations in a conference.  This item has not received any discussion on
the list.

Assuming it is acceptable, I have an issue with syntax.  As defined,
it is a "parameter" to an action.  Right now, the only parameters to an
action are commands.  We can make it a command, although it requires a
pair of terminationIDs, which makes it weird.

I'm soliciting ideas of how to do this.  Here are some thoughts:
;command, with termid, extra termid as a parameter
Context=123 {Add=termA{...},Topology=termA{termB,oneway}}
;command, but no=termid
Context=123 {Add=termA{...},Topology{termA,termB,oneway}}
;separate syntatic thingy
Context=123 {Add=termA{...}},{Topology=termA,termB, oneway}
;or
Context=123 {Add=termA{...}},{Topology(termA,termB, oneway}}
;or
Context=123 {Add=termA{...}}{Topology=termA,termB, oneway}

Brian

---

From: John Segers <[email-masked]>
Date: Mon, 23 Aug 1999 15:46:18 +0200

Brian,

The way I see it, the topology is a parameter to a command.  For
instance, when a new Termination is Add'ed to a Context, the Topology
parameter can be included to change the topology.

The question arises what command to send when the only thing to be
changed is the topology (no Terminations added or deleted).  I would say
that a Modify would be sent in that case.  There are several
possibilities for the TerminationID of the Modify:
* the ID of a (random) Termination in the Context of which the topology
is to be changed
* TerminationID ALL, because the command does not change any properties
of a specific Termination, but it changes a property of the Context
* No TerminationID, for the same reason as above

The third option would require a change to the syntax, making
TerminationID an optional parameter to the Modify command.  The second
option does not require this change.  Of course it does require the
addition of an optional TopologyDescriptor to the Add and Modify
commands.

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

---

From: Mike Buckley <[email-masked]>
Date: Mon, 23 Aug 1999 16:18:21 +0000

John,

I think the third option is the cleanest and best maintains the integrity of the
connection model.  It seems logical that a modify commands could be used to
modify the properties of a termination or a context.  In the first case these are
parameters, in the second topologies or even parameters (the possibility of a
combining  parameter was discussed in Berlin).  Artificial construsts such as in
one or two are a bit of a kluge and could lead to difficulties when we may wish to
extend the model later.

Mike

____________________ Begin Original Message
___________________________
Date: Mon Aug 23 15:46:18 +0200 1999
From: internet!LUCENT.COM!jsegers (John Segers)
Subject: Re: Topology
To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
Content-Type: Text
Content-Length: 2380

Brian,

John

---

From: Chip Sharp <[email-masked]>
Date: Mon, 23 Aug 1999 09:57:44 -0700

In going over the ABNF, I found the following editorial corrections that I
believe need to be made.

1. There are several cases in which non-terminals use different
capitalizations through the ABNF.  Technically, according to RFC2234,
productions and non-terminals are case-insensitive, but in order to provide
easier reading the capitalization should be consistent.
         SubtractToken
         PackagesDescriptor
        ServiceChangeToken
        MediaToken
        streamParm
        extensionParameter
        ItemId
        eventsDescriptor
        signalsDescriptor
        PackagesItem
        DIGIT

3. In the signalsDescriptor production there is a ";" inserted before the
"EQUAL RequestID":
signalsDescriptor = SignalsDescriptorToken ; EQUAL RequestID
                      LBRKT signalRequest *(COMMA signalRequest) RBRKT

4.  There is a substitution in the ABNF of "amm" for "add".  Thus, there is
the "ammRequest", the "ammParameter", etc.  This should be changed to "add".

Chip

--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Abdallah Rayhan <[email-masked]>
Date: Mon, 23 Aug 1999 13:13:52 -0400

I want to have my two cents worth of input before this thread runs into
a religious ware ;-)

The topology seems to be a good idea and gives flexibility in managing
terminations and contexts. To incorporate this concept we need to differentiate
between the context topology, and command topology ABNF, and introduce
minimal changes to the current syntax. In order to accomplish this I
propose a new command called changeTopology and a new descriptor
called topologyDescriptor that goes with changeTopology, move, add
and modify.

When current topology is to be changed, changeTopology command is
used. When a termination is to be added, moved or modified, topologyDescriptor
is used to set it in the proper topology.

These two changes are incorporated into the syntax as follows:

commandRequest = (ammRequest / subtractRequest / auditRequest /
                                  notifyRequest / serviceChangeRequest /
                                  changeTopology )

changeTopology = ChangeTopologyToken LBRKT topologyDescriptor RBRKT

ammParameter = (mediaDescriptor / modemDescriptor / muxDescriptor /
                              eventsDescriptor / signalsDescriptor /
digitMapDescriptor /
                              topologyDescriptor )

topologyDescriptor = TopologyToken LBRKT "ALL" / BOITopology RBRKT

BOITopology = (("Bothway" / "Isolate") LBRKT topologyList RBRKT) /
                          ("Oneway" LBRKT binarytopologyList RBRKT)

topologyList =   LBRKT terminationIDList RBRKT
                          *(COMMA  LBRKT terminationIDList  LBRKT)

binarytopologyList = LBRKT TerminationID COMMA TerminationID RBRKT
                                    *(COMMA LBRKT TerminationID COMMA
TerminationID RBRKT)

If you find the ABNF hard to follow here are some examples:

; make the full connection
ChangeTopology {Topology{ALL}}

; selective bothway
ChangeTopology {
         Topology{ Bothway {{term1,term2,term3},{term1,term5,term6}},
                          Oneway {{term6,term7},{term6,term7}}
         }
}

; selective isolate
ChangeTopology {
         Topology{
               Isolate {{term1,term2,term3}}
          }
}

; selective oneway
ChangeTopology {
         Topology{
                Oneway {{term1,term2} ,{term5,term3}}
          }
}

The gains of this proposal: consistent with the encoding style of the protocol
and
does not change the current ABNF

Disadvantages: adds a new command and a new descriptor.

Feedback ?

regards
Abdallah Rayhan

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Aug 1999 14:04:31 -0400

>called topologyDescriptor that goes with changeTopology, move, add

I am not sure whether the "topology" addition is worth the added
complexity.  We can already use the termination-mode to select which
termination is or is not sending/receiving in the context. The topology
addition moves us from the basic "star" definition of a context, which we
add agreed to back in Minneapolis, towards a "shape on demand" definition.
Frankly, this seems like a non-benign departure from the original model. At
a minimum, if we add anything of that nature, support should be optional.
Christian Huitema

---

From: John Segers <[email-masked]>
Date: Mon, 23 Aug 1999 23:16:17 +0200

Christian,

I'm sure you see that some of the things that can be done with the
topology addition cannot be done with termination mode.  It was brought
in at the Berlin meeting by Ericsson, citing a one-way legal intercept
requirement.  Maybe someone from Ericsson (or someone else) can explain
in more detail where that requirement comes from.

I agree with you that support of this would not be mandatory on MGs.
Doing a legal intercept on a customer premises residential gateway is
probably not the best way to catch criminals :)

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 344
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Stephen Terrill <[email-masked]>
Date: Tue, 24 Aug 1999 00:28:48 +0200

Hi Christian,

There is a need for certain traffic cases to be able to control the "topology" of the connections, not just the output of a mixing function (which is what the termination mode can provide us).

This was recognised in the draft of the protocol which went into the Berlin meeting (output of Oslo) where there was a place holder for the "topology (who sees/hears whom)".  This is also included in the requirements - 5.2.d, "support unidirectional, symetric bi-directional and asymmetric bi-direction flows of media", and 5.2.f  "suport point-to-point and point-to-mulitpoint connections".

The most urgent application that has been identified for this is the "legal intercept" requirement (included in the requirements in 11.2.1.d).  To support the strigent requirements for legel intercept, it must be possible to take a un-interupted connection from one of the terminations" and transfere that towards the "monitoring center".

It is always a vendors choice as to which parts of the protocol are implemented, and this is true for the topology as well as any part of the protocol.  In my opionion, the topology handling has the same status as any other command/action in the protocol in this respect.

Regards,

..//Steve

---

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Aug 1999 19:00:28 -0400

>probably not the best way to catch criminals :)

Regardless of whether this is a good idea or not, you can definitely
install a one way intercept using the termination mode. Add to the context
a termination that feeds to the intercept, and set the termination mode to
"send only."
Christian Huitema

---

From: Stephen Terrill <[email-masked]>
Date: Tue, 24 Aug 1999 01:34:04 +0200

Hi Christian,

Unfortunately this approach does not meet all the requirements.  In a multiparty call (conference etc), it must be possible to monitor a single stream from an idetified termination.  That does not work when just using the mode of the termination.

Regards,

..//Steve

---

From: Chip Sharp <[email-masked]>
Date: Mon, 23 Aug 1999 22:49:37 -0700

In thinking about this, it seems that the same effect could be achieved if
a termination can belong to more than one context.

The basic requirement is for a special termination (the Monitor
termination) to be able to hear either or both sides of a conversation with
control over which side of the conversation to hear.

If a termination is allowed to belong to multiple contexts, then the MGC could
add the termination to be monitored to a context with the
MonitorTermination indicating that the MonitorTermination receives the
traffic from the other termination (e.g., send-only).

Chip

---

From: John Segers <[email-masked]>
Date: Tue, 24 Aug 1999 09:18:51 +0200

Chip,

Thanks for your detailed comments.

1. You're right, we'll take care of the capitalization.
2. Consider it done :)
3. The semicolon is gone.
4. The Add, Move and Modify requests have the same parameters. amm is
the first letters of these commands.

John

---

From: John Segers <[email-masked]>
Date: Tue, 24 Aug 1999 09:52:10 +0200

Chip,

There are some elements in your proposal that have to be looked at
carefully.   One thing that comes to mind is the question what happens
if a Termination is Subtract'ed in a Context while it is part of
multiple Contexts.  Or what happens if a Move is applied to such a
Termination?

A disadvantage of the approach you propose is that it requires more
messages to set up an intercept or operator.  A new Termination has to
be created (there's no avoiding that), a new Context has to be created,
and the existing Termination has to be replicated in the new Context.

John

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 Aug 1999 10:38:02 -0400

At 01:34 AM 8/24/99 +0200, Stephen Terrill wrote:
>Unfortunately this approach does not meet all the requirements.  In a
>multiparty call (conference etc), it must be possible to monitor a single
>stream from an idetified termination.  That does not work when just using
>the mode of the termination.

Looks like an infortunate consequence of the "context" model -- monitoring
a single termination is indeed very easy with MGCP. If you follow the
context model, then you probably need a separate context for each
subconference, and an internal connection between the contexts.
Christian Huitema

---

From: Chip Sharp <[email-masked]>
Date: Tue, 24 Aug 1999 08:14:16 -0700

>multiple Contexts.  Or what happens if a Move is applied to such a

I agree that there a open questions on this proposal.  I have a few myself.
These are good ones.  I believe that commands and notifications would have
to be interpreted in the context of the context. ;-)

Thus a Subtract on a termination in a context would only apply to the
context in which the command was issued.

A Move of a termination from one context to another would affect only the
context indicated.

>and the existing Termination has to be replicated in the new Context.

Yes, I believe an additional command would be needed.   Whether a new
message is needed depends on how the MGC wants to bundle the messages.  But
I think you probably meant commands.
The whole monitor/wiretap procedure needs a lot more definition. For
example, it will require different operation for a MG that support analog
lines than for a SS7 controlled T1/E1 trunk.

First, the MGC has to know that a wiretap is to occur.  This is outside the
scope of megaco.  Then the MGC has to be able to initiate the wiretap on
the occurence of some event.  This could be on command for an ongoing call
or on the indication of an outgoing or incoming call to/from the target.

For an analog line the target can be correlated with an analog line
termination.  For a trunk, it would have to be correlated with a phone number.

The MGC would then send an Add creating a context and adding the two normal
terminations to it.  It would also issue an Add creating another context
and adding the Monitor termination to the termination that it wants to
listen to.
If the monitor wants to listen to both, it could indicate that in the Add,
but would probably be more efficient to add it to the original Add as
send-only.

In either case, it brings up the question of directionality in the
context.  So far, the context has been viewed as a star in which everyone
listens/sends to everyone.  Now we are converting the topology of the
context to a mesh.

Chip

---

From: Ajay Sharma <[email-masked]>
Date: Tue, 24 Aug 1999 17:25:35 -0500

Brian:

> Assuming it is acceptable, I have an issue with syntax.  As defined,

Why dont we call it "Flow" instead, if thats what it conveys ?

> Context=123 {Add=termA{...},Topology{termA,termB,oneway}}

I prefer this.

--
_____________________________________________________________________
Ajay Sharma
Ficon Technology, Inc.
Tel: 972.671.7701 x101
Fax: 972.671.7099
mailto:[email-masked]
http://www.ficon-tech.com