Subject: [Megaco] Ia Profile - Treating a group of ephemeral terminations as a trunk

From: "Annie Benitez Pelaez" <[email-masked]>
Date: Thu, 16 Aug 2007 23:49:08 -0400

Dear H.248 experts,
 
Hi! As you know the ETSI TISPAN Ia profile defines a TerminationID strucutre
in the following format:
  <prefix>/<group>/<interface>/<id>
where <interface> may refer to a logical and/or physical interface.
 
In the case of a Border Gateway all terminations that we deal with are
Ephemeral terminations, and therefore the NULL context really does not
exist.
 
In certain implementation I imagine vendors will group certain number of
ephemeral terminations to a particular <interface>, and the need to report
failures on such interfaces arises. This is quite straight forward as it is
possible to send a wildcarded service change command to indicate all
terminations of a given <interface> are IS or OOS.
 
Now where it gets tricky, is if the controller would like to efficiently
Audit the state of a given interface. Typically in a TDM land one could
Audit the TerminationState of a wildcarded termination present in the NULL
context. Is that something that could be done in the case of Ephemeral
Terminations?
 
Transaction = 1 {

   Context = - {

      W-AuditValue = ip/*/core/* {

         Audit {

            Media {

               TerminationState {ServiceStates}}}}}}

or due to the fact that ephemeral terminations don't exist in the NULL
context cause this type of command to be invalid?
(now you couldn't put a "*" for the Context as that way you would get too
much information back, as we're looking for a simple IS/OOS indication)
 
If it is invalid, then what would be an alternate mechanim to perform such
an Audit? 
One option would be to define an H.248 package (similar to the root
package), where the interface names could be returned, but I am not very
convinced about that option as it may not scale very well and I don't
believe a package is a way to go.
 
I would appreciate your input on this...
Best regards,
- Annie
 
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Maridi R. Makaraju \(Raju\)" <[email-masked]>
Date: Fri, 17 Aug 2007 10:11:53 -0500

Annie,
 
You could use the following option if this IS/OOS audit for a given interface is done infrequently (which I assume):
Send an Add request with just one such IP termination with mode set to inactive:
Transaction = 88 {
  Context = $ {
    Add = ip/group/interface/$ {
      Media {
        Stream = 1 {
          LocalControl {
            Mode = inactive,
          } } }
    } } }
 
If GW returns a successful Add reply then the interface is INS and then you can delete the new context(and termination).
If GW returns an Add failure then depending on the failure you ("502 - Not ready" means OOS,  "510 - Insufficient resources"
could mean the interface is in INS but unable to add more terminations).
 
Optionally one could include a Local Descriptor, if needed by the GW, to the Add.
 
The advantage of this option is it does not involve any new pkg definition and uses basic h248 msgs.
 
-Raju

  _____  

From: Annie Benitez Pelaez [mailto:[email-masked]] 
Sent: Thursday, August 16, 2007 10:49 PM
To: [email-masked]
Subject: [Megaco] Ia Profile - Treating a group of ephemeral terminations asa trunk

Dear H.248 experts,
 
Hi! As you know the ETSI TISPAN Ia profile defines a TerminationID strucutre in the following format:
  <prefix>/<group>/<interface>/<id>
where <interface> may refer to a logical and/or physical interface.
 
In the case of a Border Gateway all terminations that we deal with are Ephemeral terminations, and therefore the NULL context really
does not exist.
 
In certain implementation I imagine vendors will group certain number of ephemeral terminations to a particular <interface>, and the
need to report failures on such interfaces arises. This is quite straight forward as it is possible to send a wildcarded service
change command to indicate all terminations of a given <interface> are IS or OOS.
 
Now where it gets tricky, is if the controller would like to efficiently Audit the state of a given interface. Typically in a TDM
land one could Audit the TerminationState of a wildcarded termination present in the NULL context. Is that something that could be
done in the case of Ephemeral Terminations?
 
Transaction = 1 {

   Context = - {

         Audit {

            Media {

 
or due to the fact that ephemeral terminations don't exist in the NULL context cause this type of command to be invalid?
(now you couldn't put a "*" for the Context as that way you would get too much information back, as we're looking for a simple
IS/OOS indication)
 
If it is invalid, then what would be an alternate mechanim to perform such an Audit? 
One option would be to define an H.248 package (similar to the root package), where the interface names could be returned, but I am
not very convinced about that option as it may not scale very well and I don't believe a package is a way to go.

---

From: "Jerker Zetterlund (TN/EAB)" <[email-masked]>
Date: Mon, 20 Aug 2007 14:38:59 +0200

Hello Annie,
 
I agree with you that there is a need for the MGC to be up to date on
which realms in the MG are available for traffic. In Ia v2 the realm or
network is specified by the MGC using the ipdc/realm property while the
<interface> field in the termination ID is an identifier assigned by the
MG so that the MG can group terminations in a convenient way. There is
no relation between ipdc/realm and <interface>. Therefore there is a
need for the MGC to be aware of which of the possible values of
ipdc/realm are available to be used for traffic.
 
Ericsson is planning to contribute in this area to the upcoming TISPAN
meeting so that a method for this is included in Ia v2. Please find a
part of the draft version of the contribution pasted below. Any
questions or suggestions on the proposal before the TISPAN meeting are
very much welcomed!
 
Thanks & best regards,
 
Jerker

Background

When a SPDF controls multiple BGFs, which in turn are connected to
multiple IP realms, there is a need for the SPDF to be able to select a
suitable BGF when e.g. opening a media plane pinhole between the IMS
core network and a specific access network IP realm. Different BGFs can
be connected to different IP realms and the service level of connected
realms can be different between the BGFs. Therefore there is a need for
the SPDF to have a view of the availability of realms per BGF.

This is also recognized by the RACS Functional Architecture Stage 2
(ETSI TS 182 019 V0.7.1 (2007-07)) which contains the following general
requirement in section 6.2.1.1:

Based on a discovery mechanism, the SPDF determines the appropriate
entity or entities among A-RACF, BGF and interconnected SPDFs to
interrogate in accordance with the required transport capabilities, and
with the indication included in the transport control service request
received from the AF or an interconnected SPDF, along with Local
Policies.

Editor's Note: The discovery mechanism is still an open issue for RACS
R2. Contributions are expected on the subject.

Proposal

There are two parts of the discovery mechanism which needs to be
addressed from an Ia profile and H.248 perspective:

1. How the SPDF shall discover the realm support in the BGFs after a
(re-)establishment of the H.248 control association. This is both after
a restart of one of the entities to address possible inconsistencies as
well as after an initial control association establishment.

2. How the BGF shall inform the SPDFs when changes in the realm support
occurs.

This contribution proposes two functions to be added to Ia v2 to cater
for the two parts of the realm discovery mechanism:

1. A new Root property which indicates the currently supported realms
which can be audited by the SPDF.

2. A new Root event which enables the BGF to indicate that the realm
support has changed.

Root property

A root property can easily be audited after link (re-)establishment and
provides the information about supported realms in a compact way. The
format of the new property is proposed to be as follows:

Property Name: Active Realms

Property ID: activerealms

Description: This property lists the IP realms which are currently
available for usage on request by the MGC.

Type: Sub-list of strings

Possible values: Strings mutually understood by MG and MGC and which are
also addressable through the ipdc/realm property.

Default: None

Defined in: TerminationState

Characteristics: Read-Only

Root event

A root event allows the BGF to dynamically inform the SPDF about changes
which occur in the set of available realms, e.g due to management
actions or network interruptions. The format of the new event is
proposed to be as follows:

Event Name: Active Realms Changed

Event ID: chactiverealms

Description: This event indicates that the availability of realms in the
MG has changed.

EventsDescriptor Parameters: None.

ObservedEventsDescriptor Parameters: 

Parameter Name: Active Realms

Parameter ID: activerealms

Description: This parameter gives the list of currently available realms
in the MG.

Type: Sub-list of strings

Optional: Yes

Possible values: Strings mutually understood by MG and MGC and which are
also addressable through the ipdc/realm property.

Default: None

It is proposed that TISPAN WG3 sends a liaison to ITU-T SG-16 to propose
an extension package to be created to the ipdc package (H.248.41)
containing the above described property and event. It is further more
proposed that the usage of such package is then incorporated the Ia v2
profile to allow realm discovery by the SPDF.

Conclusion

It is proposed that a liaison is sent to ITU-T SG-16 proposing extension
of H.248.41 with a new root property and a new root event. It is
proposed that this extension is incorporated with the Ia v2 profile
after it has been agreed in ITU-T.

________________________________

From: Annie Benitez Pelaez [mailto:[email-masked]] 
Sent: den 17 augusti 2007 05:49
To: [email-masked]
Subject: [Megaco] Ia Profile - Treating a group of ephemeral
terminations asa trunk

Dear H.248 experts,
 
Hi! As you know the ETSI TISPAN Ia profile defines a TerminationID
strucutre in the following format:
  <prefix>/<group>/<interface>/<id>
where <interface> may refer to a logical and/or physical interface.

In certain implementation I imagine vendors will group certain number of
ephemeral terminations to a particular <interface>, and the need to
report failures on such interfaces arises. This is quite straight
forward as it is possible to send a wildcarded service change command to
indicate all terminations of a given <interface> are IS or OOS.
 
Now where it gets tricky, is if the controller would like to efficiently
Audit the state of a given interface. Typically in a TDM land one could
Audit the TerminationState of a wildcarded termination present in the
NULL context. Is that something that could be done in the case of
Ephemeral Terminations?
 
Transaction = 1 {

   Context = - {

         Audit {

            Media {

 
or due to the fact that ephemeral terminations don't exist in the NULL
context cause this type of command to be invalid?
(now you couldn't put a "*" for the Context as that way you would get
too much information back, as we're looking for a simple IS/OOS
indication)
 
If it is invalid, then what would be an alternate mechanim to perform
such an Audit?