Subject: MSF Review of it's requirements vs. current draft protocol

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 1999 12:11:12 -0400

MSF Media Control Working Group Liaison to IETF MEGACO

Abstract:
The MSF MCWG submitted requirements to the IETF MEGACO 
Working Group, which were largely accepted into the MEGACO 
requirements.  We have reviewed the most recent protocol 
draft against these requirements.  This liaison documents 
our findings.  

Disclaimer:

This document has been approved by the MSF Technical 
Committee as a liaison to the IETF MEGACO Working Group.  
The attachment is the current version which was issued 
August 26, 1999.  It is representative of the current state 
of work in the MSF Media Control Working Group.  However, 
this liaison and its attachment in no way binds MSF or any 
of the member organizations of MSF to the ideas presented.  
It should also be noted that this work is being submitted 
at this time in the interests of developing industry 
agreement.  The MSF may revisit this work in the future and 
reserves the right to make additions, changes, or 
deletions, including complete withdrawal.

This liaison is a comparison of the MSF requirements vs. 
the most recent protocol draft (Berlin meeting output).  
In the following:
· MEETS means that the requirement appears to be met in the 
current draft
· DOES NOT MEET means that the requirement does not appear 
to be met in the current draft
· COULD BE MET means that the requirement does not appear 
to be met in the current draft, but if the suggested 
additional syntax for support of ATM bearers identified in 
another liaison from the MSF MCWG to IETF MEGACO was 
adopted, the requirement would be met.
· PARTIALLY MET means that some of the requirement appears 
to be met in the current draft, but not all of the 
requirements are covered.

Connect: The Protocol shall support requests for multi-
media connections from circuit to packet for ATM and vice 
versa. Req. 5.2 a, b.   COULD BE MET.

Connect: The Protocol shall support requests for multi-
media connections from circuit to packet for FR and vice 
versa. Req. 5.2 a, b.  DOES NOT MEET.

Connect: The protocol shall allow the specification of 
bearer plane on a call by call basis since a MG may support 
more than one bearer plane e.g. Frame Relay, IP, etc.  Req.
5.2 c.   COULD BE MET.

Connect: The Protocol shall allow for the de-coupling of 
creation/deletion of the narrow-band connection from the 
creation/deletion of the underlying VCC. Req. 11.1.3.2 a. 
DOES NOT MEET.  There is no way to delete a bearer channel 
that does not have a termination on it.  For example, if a 
channel is retained after use to see if a subsequent call 
will re-use it and sufficient time elapses without such 
use, the bearer should be deleted, but there is no way to 
reference the bearer.  This is not an ATM-specific problem,
as an RSVP reservation, or any other "expensive" resource 
allocation procedure, will require similar capability.

The narrow-band connection established using this Protocol, 
may be carried over a VCC, which may be:
· a PVC or SPVC,
· an SVC established on demand, either by the MGC itself or
 by a broker acting on its behalf or
· an SVC originated as required by the local MG, or by the
 remote end to the local MG through UNI or PNNI signaling.
DOES NOT MEET, see above.

Connect: The protocol shall be able to refer to an existing
VCC as the physical interface + Virtual Path Identifier 
(VPI) + Virtual Circuit Identifier (VCI).  COULD BE MET.

Where the VCC is locally established (SVCs signaled by the 
Gateway through UNI or PNNI signaling or similar), the VCC 
must be indirectly referred to in terms which are of 
significance to both ends of the VCC. i.e. a global name 
or the ATM address of the ATM devices at each end of the 
VCC. However, it is possible/ probable that there may be 
several VCCs between a given pair of ATM devices. 
Therefore the ATM address pair must be further resolved by 
a VCC identifier unambiguous within the context of the ATM 
address pair. COULD BE MET.

Connect: The Protocol shall be able to refer to a VCC as 
the Remote GW ATM End System Address + VCCI. COULD BE MET.

Connect: The Protocol shall allow the VCCI to be selected 
by the MG or imposed on the MG. DOES NOT MEET.  SDP doesn't 
currently do this yet (can not underspecify with return of 
fully specified block).  There is no concept of wildcard in 
SDP.  In a strict reading of the wording, the requirement 
is met.   If you don't specify a VCCI, it will pick one 
(but not return it).  If you give it the VCCI, it will use.

Connect: All ATM addressing variants (e.g. NSAP & E.164) 
SHALL be supported within the Protocol. COULD BE MET.

Connect: The protocol SHALL allow ATM transport parameters 
and Quality of Service parameters to be passed to the MG. COULD BE MET.

Connect: The protocol shall allow for the MG to report 
cause codes for success or failure of the lower layer 
connection setup.  DOES NOT MEET.  In addition to an error 
code, it should be allowed to have parameters that are 
passed from the bearer to the MGC.  Currently, you could 
report a MEGACO cause code.  

Connect: The protocol shall allow for the MG to report 
cause codes for abnormal failure of lower layer connections 
e.g. TDM circuit failure, ATM VCC failure. DOES NOT MEET.  
In addition to an error code, it should be allowed to have 
parameters that are passed from the bearer to the MGC.  
Currently, you could report a MEGACO cause code.  

Connect: The protocol shall allow for the MG to report 
Usage Parameter Control (UPC) events.  DOES NOT MEET.  
This will probably be a package event description.  
Packages must be defined with these events; the mechanism 
is there to do this but there is not a package yet.  
Also need a better definition of UPC and what it entails.

Adapt: The protocol shall allow for Media adaptation for 
circuit to ATM connections (e.g. analog loop to 
G.729/AAL2/ATM)  COULD BE MET.

Adapt:  The protocol shall allow for Media transadaptation 
for packet-to-ATM or ATM-ATM connections (e.g. 
G.723/RTP/UDP/IP to G.726/AAL2/ATM). COULD BE MET.

Adapt: The protocol shall allow for ATM transadaptation 
only (no media adaptation) e.g. for switching voice streams 
between IP and AAL2/ATM or between AAL2/ATM links.  COULD 
BE MET.

Adapt: The protocol shall allow  AAL parameters to be 
passed to the MG. COULD BE MET.

In AAL2 multiple narrow-band calls may be mapped to a 
single VCC. These calls are differentiated within each VCC 
by a AAL2 channel identifier. An AAL2 connection may span 
more than 1 VCC and transit AAL2 switching devices. ATMF 
standards are working on an end-to-end AAL2 connection 
identifier as part of the AAL2 signaling set. COULD BE MET.

Adapt: The Protocol SHALL allow for unambiguous binding of 
a narrow band call to an AAL2 connection identifier within 
the specified VCC. COULD BE MET.

Adapt: The Protocol SHALL allow the AAL2 connection 
identifier to be selected by the MG or imposed on the MG.  
DOES NOT MEET. no wildcard in SDP (see above comment).

Adapt: The Protocol SHOULD allow AAL2 channel identifier 
(cid) instead of AAL2 connection identifier. COULD BE MET.

Adapt: The protocol shall allow for the AAL2 voice profile 
to be imposed or negotiated before the start of the 
connection.  AAL2 allows for variable length packets and 
varying packet rates, with multiple codecs possible within 
a given profile. Thus a given call may upgrade or downgrade 
the codec within the lifetime of the call.  Idle channels 
may generate zero bandwidth. Thus an AAL2 VCC may vary in 
bandwidth and possibly exceed its contract. Congestion 
controls within a gateway may react to congestion by 
modifying codec rates/types. COULD BE MET.

Adapt: The Protocol shall allow for the MGC to instruct 
the MG of how individual narrow-band calls behave under 
congestion.  DOES NOT MEET.

Accounting information may be passed via the control 
protocol, or by some other means. The Protocol should 
specify what is included and when it is reported.  
DOES NOT MEET. Can not "fine grain" the level of what is 
returned.  Currently, get them all or none.

Report: The Protocol shall allow for the following 
accounting parameters to be transported from the MG to the 
MGC:
· Bandwidth/QoS requested and received  Bearer specific 
statistic. COULD BE MET.
· Absolute time of connection startup and teardown  DOES 
NOT MEET.
· Types of resources used such as echo cancellers, codecs, 
receivers, silence suppression, etc. and the duration of 
utilization of these resources  DOES NOT MEET.

Report: The Protocol shall allow for any accounting 
parameters shall be passed to the MGC as required by the 
MGC. This may include:
· At time intervals as specified by the MGC.  DOES NOT 
MEET.
· At unit usage thresholds as specified by the MGC.  DOES 
NOT MEET.

Report: The protocol SHOULD allow any end-of-call 
statistics to show loss/restoration of underlying VCC 
within the calls duration, together with duration of loss. 
DOES NOT MEET.

Report: The protocol SHOULD allow notification, as 
requested by MGC, of any congestion avoidance actions taken 
by the MG. DOES NOT MEET.

ATM VCCs may be considered as resources under the control 
of the MGC.  Report: The Protocol shall allow for ATM VCCs 
to be audited by the MGC. DOES NOT MEET.  No fundamental 
mechanism to do this.  The VCC is not a construct the 
protocol recognizes.

Report: The Protocol shall allow for changes in status of 
ATM VCCs to be notified as requested by the MGC.  DOES NOT 
MEET.  Currently, you could define an event that would 
occur. 

Report: The protocol shall allow the MGC to query the 
resource & endpoint availability. Resources may include 
VCC's, & DSP's. VCCs may be up or down. Endpoints may be 
connection-free, connected or unavailable.  PARTIALLY MET.  Can query
terminations and figure what is going on.  Can't 
query VCC or DSP unless DSP is a termination (such as IVR).

Function: The protocol shall allow a command precedence to 
allow priority messages to supercede non-priority messages. DOES NOT MEET. 

Function: The protocol shall allow an MGC to reserve a 
bearer, and specify a route for it through the network. 
DOES NOT MEET. The mechanism is there, but no definition 
for any specific bearer, even no specific route for IP.

Report: The protocol shall allow for the MG to detect and 
notify as required events in the audio stream. e.g., 
voice/silence detection. DOES NOT MEET. The mechanism 
exists; you could define a package that would do it.  
We haven't seen base packaged definition, don't know if 
there or not.

Report: The protocol shall allow the request and 
notification of mid-call trigger events. DOES NOT MEET. 
The mechanism exists; you could define a package that would 
do it.  We haven't seen base packaged definition, don't 
know if there or not.

Function: The protocol call setup shall allow for a 
priority marking to flag a given connection as having a 
higher priority.  DOES NOT MEET.

Function: The Protocol shall allow the recovery or 
redistribution of traffic without call/packet loss.  
DOES NOT MEET. There is no specific mechanism to this.  
However, if it is a failover situation, then it is handled.

QoS: The protocol shall allow the MGC to specify QoS 
thresholds, and the MG to notify the MGC of threshold 
crossing events.  DOES NOT MEET.  It could be met as the 
mechanisms are there but no definition has been created 
for it.

QoS: The protocol shall allow the MGC to modify QoS 
parameters after the connection is established. COULD BE 
MET.

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 30 Aug 1999 12:24:45 -0400

The particular item I have selected below implies an extension to the scope
of the Megaco/H.248 protocol, into control of bearers rather than media
streams.  I'll be interested in other reactions, but I suspect that's
outside our scope.

> -----Original Message-----
> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Monday, August 30, 1999 12:11 PM
> To:   [email-masked]
> Subject:      MSF Review of it's requirements vs. current draft protocol
> 
        [[TomT]]  ...

---

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 1999 12:46:28 -0400

Tom

This was accepted into the MEGACO requirements.  It's
hard to see how we can now say "out of scope".
It is something we could consider a Version 2 item, but
it's likely to be interesting other cases as noted.

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Monday, August 30, 1999 12:25 PM
> To: [email-masked]
> Subject: Re: MSF Review of it's requirements vs. current 
> draft protocol
> 
>

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 30 Aug 1999 20:50:30 -0700

It's definitely within the scope as Brian says. But I'll agree on Brian's 
other point that it is perhaps a phase 2 work item.

If it's out of scope for MEGACO, then it will be in scope for another 
protocol which could subsume MEGACO. I think that most people agree that it 
would be nice to have one protocol controlling both VoIP and VoATM systems. 
That has been the background premise of our efforts all along.