Subject: RE: [Megaco] Wildcarded Action Reply

From: Carl Rutter <[email-masked]>
Date: Wed, 10 Jul 2002 09:53:40 -0400

I believe this thread is going to be going on for awhile
as this won't be an easy nut to crack.

I think we need to address this as this issue will just
grow with time.  I'll throw out another idea for discussion:

We push the burden of this issue onto the MGC(the controlling entity)
If the MGC requests for example an AuditValue on all terminations in the ALL
context
and the MG internally determines that the Reply to this request will be too
large
for its transport mechanism, the MG with reply will an error code saying 
"700 - Requested Reply too Large"  or something like this.
As an example right now we only allow an AuditValue wildcards to the T1
level which limits
it to 24, so if it was wildcarded at the T3 we would send an error 700 on
this.
Maybe in the Error Reply we could somehow indicate what would be acceptable?

Comments,

Carl

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 1:51 AM
To: [email-masked]
Subject: Re: [Megaco] Wildcarded Action Reply

G'Dy,

Whilst having this type of functionality in a package is an interesting
exercise
I'm a little concerned about the precedent that it is setting in that by
setting
a new event you modify the behaviour of the core protocol. ie. the MG rather
than sending replies in a single Transaction Reply must wait for additional
requests and responses. If multiple requests are responses are needed in
both
cases then the current mechanism of asking for a limited number of
context/terminations should be fine also. 

I agree that segmentation is an issue that needs to be looked at. My initial
thoughts would be that we have a layer under H.248/Megaco that could be a
general mechanism to achieve segementation where needed. ie. if you have
SCTP
you probably don't need it. It would be applicable to all versions of H.248.
Something like sect 7 of I.366.1 could be used for this purpose.

Regards, Christian

Aleksandr Ryabin wrote:
> 
> Hi,
> 
>         Sorry for not being clear.
> As I indicated Modify is included "in a (wildcard) transaction", that is
> a transaction that has wildcard(s) and thus potentially can be large.
> Although it does not limit MGC to put it into non-wildcarded transaction
> as well it will not do any harm in this case since it will manifest in
> one enum iteration (that is reply will have "end=yes").
> Since the order of command execution is guaranteed in a transaction
> MGC shell place such Modify right before action to be "enumerated".
> Thus we can even try to allow MGC to include several Modify commands
> within one transaction which has multiple wildcarded actions. This might
> complicate the matter so I'll leave it out for now up to the time package
> to be worked on, if ever.
> 
> Here are simple examples of complete proposed text messages.
> 
> 1.1 MGC includes Modify with handle=0 to instruct MG that it shell
> start enumeration for this transaction which includes a wildcarded action.
> It includes Audit descriptor with ObservedEvents token to be sure that
> MG sends ObservedEvents descriptor with enumeration handle, e.g.:
> 
> !/1 [1.2.3.4]:2944
> T=1{C=-{MF=ROOT{E=123{split/enum{end=no,handle=0}},AT{OE}}},
> C=*{W-SC=*{MT=FO,RE=905}}}
> 
> 1.2 MG starts enumeration, generates enumeration handle=567 and
> sends it back in observed event descriptor along with partial
> replies to wildcarded request. Lets assume MG has active contexts
> 5,6,7,8,9,10 and reply can only hold 4 of them, e.g.:
> 
> !/1 [1.2.3.5]:2944
> P=1{C=-{MF=ROOT{OE=123{split/enum{end=no,handle=567}}},
> C=5{W-SC=*},C=6{W-SC=*},C=7{W-SC=*},C=8{W-SC=*}}
> 
> 2.1 Now MGC request to "continue enumeration" by including Modify with
> returned by MG handle = 567 and setting end=no. Note that transaction
> id is different from previous transaction, e.g.:
> 
> !/1 [1.2.3.4]:2944
> T=2{C=-{MF=ROOT{E=123{split/enum{end=no,handle=567}},AT{OE}}},
> C=*{W-SC=*{MT=FO,RE=905}}}
> 
> 2.2 At this point there will be no more replies left after this, since MG
> has only left to send replies for context 9 and 10, thus MG stops
> enumeration, by sending back an observed event descriptor with
> handle=567 and end=yes, along with rest of the partial replies
> to wildcarded request, e.g.:
> 
> !/1 [1.2.3.5]:2944
> P=2{C=-{MF=ROOT{OE=123{split/enum{end=yes,handle=567}}},
> C=9{W-SC=*},C=10{W-SC=*}}
> 
> Enumeration complete, handle discarded.
> 
> Note: to be completely RFC compliant in the examples above
> first reply should probably include error 533 "Max PDU reached"
> as a last command reply, e.g.:
> 
> !/1 [1.2.3.5]:2944
> P=1{C=-{MF=ROOT{OE=123{split/enum{end=no,handle=567}}},
> C=5{W-SC=*},C=6{W-SC=*},C=7{W-SC=*},C=8{W-SC=*},
> C=*{W-SC=*{ER=533{"Reached max, ask for more"}}}}
> 
> Now come to think about it, even without any package right now
> for SeviceChange and Subtract in ALL Context MGC can simply
> repeat same request (like it is done above but with no modify)
> over and over again until it gets no replies at all, that is it gets
> error 435 "no match", since MG will process for each request
> as many terminations as it can include in the reply. Thus
> eventually all terminations will be returned into NULL context
> and no replies will be sent. But again, this would only work for
> SC and S in ALL ctx while proposed package approach will
> work for any command in any context.
> 
> This package can also include "split/compress=yes|no" property
> which will act as analog to W-Command for Context. That is if MGC
> sets split/compress=yes on ROOT then reply would look exactly as
> Ron originally wanted it to be, e.g.
> !/1 [1.2.3.5]:2944
> P=1{C=*{W-SC=*}}
> 
> Thanks
>         Aleks
> 
> At 03:53 PM 7/9/2002, Kevin Boyle wrote:
> 
> > Here's some constructs I've attempted based on the description(text
> > examples... I'm not fluent in binary at this moment!):
> >
> > 1) !/2 [1.2.3.4]:2944
> > T=1{C=-{MF=Root{E=123{split/enum{end=no,handle=0}},AT{OE}}}
> > -- It is not apparent to me how this command solves the problem.  This
does
> > not seem to perform segmentation of a particular transaction response,
and
> > the audit is directed only at OE.
> >
> > 2) !/2 [1.2.3.4]:2944
> > T=1{C=*{MF=Root{E=123{split/enum{end=no,handle=0}},AT{OE}}}
> > -- This will return an error every time.  Root exists solely in Null and
> > Null is not part of *.
> >
> > 3) !/2 [1.2.3.4]:2944
> > T=1{C=*{MF=<termname>/*{E=123{split/enum{end=no,handle=0}},AT{OE}}}
> > -- This would have detrimental effects on existing Events descriptors on
the
> > given terms.
> >
> > I can only conclude that I do not properly understand what you are
> > proposing.  The idea of utilizing a package is attractive, becuase it
means
> > that syntax changes are not required to the protocol.  But I am worried
> > about possible side effects on established events descriptors in the
> > meantime.  Perhaps some more explanation will clear this up for me...
> >
> > Kevin
> >
> > -----Original Message-----
> > From: Aleksandr Ryabin [mailto:[email-masked]]
> > Sent: Tuesday, July 09, 2002 12:41 PM
> > To: Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked]
> > Cc: Carl Rutter; 'Christian Groves'; [email-masked]
> > Subject: RE: [Megaco] Wildcarded Action Reply
> >
> >
> > Hi,
> >
> >         This is similar to "enumeration" and now come to think about it
> > this functionality could be defined as a package thus I don't see any
reason
> >
> > why can't it be added for any version, including v1.
> >
> > For example, let say we define a package "split" for ROOT termination
with
> > event "enum", event parameters "end = yes|no", "handle = <integer>" and
> > observed event parameters "end = yes|no", "handle = <integer>".
> > Where "handle = 0" from MGC means to start new enumeration.
> >
> > Then at any time MGC can include Modify on ROOT with
> > Events = 123 { split/enum { end = no, handle = 0 }} and Audit {
> > ObservedEvents }
> > in a (wildcard)  transaction which will direct MG to start
"enumeration".
> > MG would return then reply with handle in Modify reply as
> > ObservedEvents = { split/enum { end = no, handle = 567 }}
> > and as many replies to the rest of the transaction as it can.
> > MGC then can repeat transaction request including Modify
> > with Events = 123 { split/enum { end = no, handle = 567 }}
> > and Audit { ObservedEvents } to continue, or
> > Events = 123 { split/enum { end = yes, handle = 567 }}
> > to stop enumeration. Also MG can reply to Modify with
> > ObservedEvents = 123 { split/enum { end = yes, handle = 567 }}
> > to let MGC know that there is no more replies.
> > MG can also send Notify with ObservedEvents in case there is
> > a long delay from MGC, or some kind of error to stop enumeration.
> >
> > Additional "split/tmo=<integer>" property can be defined for ROOT
> > to control the delay time-out.
> > The package can also define "stale handle" error to report on stale
> > enumeration handles.
> > More over to speed up a process we can even define "expect=<integer>"
> > observed event parameter to let MGC know in how many iterations MG
> > expects the enumeration to be completed such that MGC can fire up
> > that number of transactions at the same time once it gets reply to
initial
> > transaction with a "handle".
> >
> > Comments?
> >
> > Thanks.
> >         Aleks
> >
> > At 11:07 AM 7/9/2002, Kevin Boyle wrote:
> >
> >
> > I have given some thought to application-based message segmentation (as
> > opposed to transport-based), and I haven't thought of a way to do it
that
> > works real well, without adding a ton of new complexity.  Here are some
> > components of the "best" idea I have personally been able to come up
with
> > (which really isn't saying much):
> >
> > - a new "descriptor" that indicates more is coming, and gives a sequence
> > number.  This requires the sender to break transactions only in specific
> > places.  While the receiver will be able to reassemble the transaction,
they
> > will not know when the transaction ends.
> >
> > - a token to indicate "end of transaction" when it is broken across
several
> > messages.  This allows the receiver to know it can assemble all the
pieces
> > together and start processing.
> >
> > - a "partial ack" token, to allow senders to know when pieces have to be
> > retransmitted.
> >
> > In order to make this all work, the sender would have to repeat the
message
> > from the beginning all the way through the transaction id on EACH piece
(for
> > example: "!/2 [1.2.3.4]:2944 T=12345{").  The new pieces would go INSIDE
the
> > transaction, at the action level. ("...action reponse here},
TP{SEQ=1}}")  A
> > similar method could be used to segment long action replies.
> >
> > Now, this all adds a lot of complexity to the protocol that hasn't
existed
> > before.  It also requires application segmentation of protocol messages,
> > which also hasn't existed before.  I am not sure how wise it is to add
> > something this complicated to the protocol, and it certainly wouldn't
happen
> > before v3 at the earliest, as tacking this on would break early v2
> > implementations.
> >
> > I think that using more granular audits is the answer -- but only in
some
> > cases.  Recovery from a catastrophic failure requires getting as much
> > information as possible, as quickly as possible.  The ability to segment
> > messages would be a great boon to that recovery effort, instead of
trying to
> > audit pieces at a time.  I'm not so sure my thoughts are the best way to
> > achieve this segmentation, but I would like to eventually see something
that
> > effectively allows us to generate/process long messages.
> >
> > Kevin
> >
> > -----Original Message-----
> > From: Carl Rutter [mailto:[email-masked]]
> > Sent: Tuesday, July 09, 2002 9:42 AM
> > To: 'Christian Groves'; Carl Rutter
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Megaco] Wildcarded Action Reply
> >
> > Thanks,
> >
> > We limit the wildcards to a T1 right now on our switch
> > so at most 24 replies would come back.
> >
> > It would be nice to send back a transaction reply
> > with a flag saying there is another transaction reply(same transaction
#)
> > coming with more response data, or something like that??
> > This would then break the transaction ack etc.  But some concept
> > like this seems warranted??
> >
> > Carl
> > -----Original Message-----
> > From: Christian Groves [mailto:[email-masked]]
> > Sent: Monday, July 08, 2002 8:22 PM
> > To: Carl Rutter
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [Megaco] Wildcarded Action Reply
> >
> > G'Day Carl,
> >
> > The work around would be to wildcard on a finer grain size. That way you
can
> >
> > manage the number of replies. The alternative is that the MGC shall
known
> > the
> > relationship between Termination IDs and Contexts IDs and it can release
> > each as
> > appropriate.
> >
> > Regards, Christian
> >
> > Carl Rutter wrote:
> > >
> > > This seems to be a significant flaw.
> > > If there are many contexts the transaction would be
> > > way too big.  This also would happen on Audits etc.
> > > Anyone have thoughts on how we avoid/work around this?
> > >
> > > Carl
> > >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Monday, July 08, 2002 1:36 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: [Megaco] Wildcarded Action Reply
> > >
> > > G'Day Ron,
> > >
> > > Unfortunately as you have pointed out the wildcarded only works on a
> > command
> > > level and not a context level. So in the case you point out the
response
> > > will be
> > > larger than the requests. The original intention of w- responses was
to
> > > limit
> > > the sizes of Audit responses.
> > >
> > > Unfortunately unless there is a protocol change you'll get a long
response
> >
> > > back
> > > for commands with wildcarded (ALL) contextIds.
> > >
> > > Regards, Christian
> > >
> > > Ron Stoughton wrote:
> > > >
> > > > Greeting Megaconians:
> > > >
> > > > If our MG desires to take an interface out of service that has
active
> > > > circuits engaged in calls on it, it very likely would send a command
to
> > > the
> > > > MGC that looks like the following:
> > > >
> > > >     MEGACO/2 <mg1.acc.com>:16384
> > > >     Transaction = 6 {
> > > >             Context = - {
> > > >                     W-ServiceChange = DS1/3/1/* {
> > > >                             Services {
> > > >                                     Method = Forced,
> > > >                                     Reason = 905
> > > >                             }
> > > >                     }
> > > >             }
> > > >             Context = * {
> > > >                     W-ServiceChange = DS1/3/1/* {
> > > >                             Services {
> > > >                                     Method = Forced,
> > > >                                     Reason = 905
> > > >                             }
> > > >                     }
> > > >             }
> > > >     }
> > > >
> > > > My question is, what should I expect the transaction reply to look
like?
> >
> > > I
> > > > would prefer to receive something like the following:
> > > >
> > > >     MEGACO/2 <xanadu>:2944
> > > >     Reply = 6 {
> > > >             Context = - {
> > > >                     ServiceChange = DS1/3/1/*
> > > >           },
> > > >             Context = * {
> > > >                     ServiceChange = DS1/3/1/*
> > > >           }
> > > >     }
> > > >
> > > > However, the ABNF does not appear to provide a way to ask for a
> > wildcarded
> > > > action reply (e.g. by sending "W-Context = *"), so I think I am more
> > > likely
> > > > to get something like:
> > > >
> > > >     MEGACO/2 <mgc.acc.com>:2944
> > > >     Reply = 6 {
> > > >             Context = - {
> > > >                     ServiceChange = DS1/3/1/*
> > > >           },
> > > >             Context = 2 {
> > > >                     ServiceChange = DS1/3/1/3
> > > >           },
> > > >             Context = 5 {
> > > >                     ServiceChange = DS1/3/1/11
> > > >           },
> > > >             Context = 6 {
> > > >                     ServiceChange = DS1/3/1/13
> > > >           },
> > > >             Context = 9 {
> > > >                     ServiceChange = DS1/3/1/14
> > > >           }
> > > >     }
> > > >
> > > > assuming the MG has 4 active terminations on the interface.
> > > >
> > > > Is there any way to request a wildcarded reply?
> > > >
> > > > Ron Stoughton
> > > > [email-masked]
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/megaco
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 12:02:03 -0400

Hi,

If I understand you correctly you are trying to solve this issue
by changing a "granularity" of a wildcard sent from MGC, To indicate
this MG would send "boo large" error. The good thing about this is
it will currently work (since there is already an error 533 which can
be used for that), but the bad thing is that it will not work in all cases.

I'm not saying it is a bad approach, but just pointing out some issues :)

That is even for 24 for T1 (or 31 for E1) terminations the reply can be too
large to fit into one PDU. As an example I can think of a AuditValue from
MGC to get current state information for one T1 trunk on recovery.
If all termination on the trunk are active an ultimate reply would include
all contexts (e.g. up to 24 for T1) with one termination in each of them
with Media, Events, Signals, etc. descriptors. That can be quite large
even for one termination and thus 24 might not fit in one reply.

Another problem is that granularity will not help if MGC would like
to manipulate ephemeral and physical terminations at once.
That is even if MGC provisioned with ephemeral termination pattern
(for example: domain/RTP/*) it will not be able to match ephemeral
and physical terminations in one command since the only wildcard
which matches both is ALL ("*"), but that is too big (from granularity
point of view).

Also generally speaking MG does not have to be a trunking gateway
thus the lowest level of granularity (the last term) might be any size.

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Wed, 10 Jul 2002 12:02:03 -0400

Hi,

Thanks
         Aleks

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Jul 2002 16:34:32 +1000

G'Day Carl,

This type of functionality was added in H.248.8 (ex Annex L).

L.4.2.56 Error Code # : 533 Name: Response exceeds maximum transport PDU size
Definition: The MG or MGC is unable to assemble a complete transaction response
because the number of bytes for the message would exceed the maximum protocol
data unit size of the underlying transport. The command instance in the response
to that would have caused the overflow is treated as if it were in error, and
the reminder of the transaction is not executed, even if the command was marked
"optional". 
This situation will typically arise in conjunction with the use of wildcarding,
which causes the original command to be expanded into a series of similar
command instances.
If the request contained wildcarded a termination ID the MGC or MG should send
later requests with a smaller subset of termination Ids.
Package: -
Reference: H.248 Clause 8.
Error Text in the error Descriptor: NA
Comment: Implementors' note: the detection of PDU overflow must occur at a point
where there is still room in the PDU for the error descriptor.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 11 Jul 2002 16:34:32 +1000

G'Day Carl,

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2002 09:55:42 +0300

Hi all,

I get very confused when I try to follow this thread :)

We have now two issues:

1. Segmentation

2. Wildcard matching

My proposal is that we split them up in two separate threads, since they are
completely separate issues.

So, from now on, could we agree to change the mail subject when we send a reply,
depending on which issue we are commenting? Mails related to wildcard matching could
keep the current subject ("Wildcarded Action Reply"), while mails related to the
segmentation could use the subject "Segmented Action Reply".

...or something like that :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Jul 2002 09:55:42 +0300

Hi all,

We have now two issues:

1. Segmentation

2. Wildcard matching

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Carl Rutter" <[email-masked]>
Date: Thu, 11 Jul 2002 08:27:32 -0400

Thx Christian,

Sounds like that would atleast be a mechanism the MGC could utilize in this
case
today.  And is possibly sufficient enough longterm?
There is a little more burden on the MGC.
Procedurally the MGs need to flag the requests, say Audit * on ALL Context
(if too big)
as 533s consistently and not Unsupported or another error code.

Works for me,
Carl

---

From: "Carl Rutter" <[email-masked]>
Date: Thu, 11 Jul 2002 08:27:32 -0400

Thx Christian,

Works for me,
Carl