Subject: RE: Reminder//Status of ATM SDP internet draft

From: "Mark Watson" <[email-masked]>
Date: Mon, 7 Aug 2000 12:40:20 +0100

Leslie,
 
Unless I have missed something, SDP is the way that Megaco/H.248
communicates a variety of parameters between MGC and MG, and this work is
the IETFs approach to extending Megaco/H.248 to support ATM bearer types.
 
We need a way of communicating the BIWF address and BNC ID from MG to MGC so
that they can then be placed in the BAT ASE for the non-tunnelled Bearer
Control case that we use with ATM. This draft provides such a capability
(amongst many other things more relevant to the BMC interface than CBC).
 
I think that IETF and ITU-T approaches to the non-tunnelled bearer control
case are slightly different, but amongst all the noise, we are both trying
to solve the same problem of communicating these two information elements on
the vertical interface, so we should at least study whether there is scope
for an aligned solution.
 
Regards,
 
Mark Watson
Nortel Networks

-----Original Message-----
From: Leslie Graf [mailto:[email-masked]]
Sent: 07 August 2000 12:13
To: Watson, Mark [MAIFP:EP11-M:EXCH]
Cc: 'Rajesh Kumar'; [email-masked]; [email-masked];
[email-masked]; 'BICC ITU-T SG11 ([email-masked])'
Subject: Re: Reminder//Status of ATM SDP internet draft

Hi Mark, 
I am also very interested in this for work I am involved in (nothingto do
with BICC). However what I am missing at the moment is seeing the
significance of the ATM additions to SDP to the work for BICC CS2. 
As you are aware of have concerns on the timeframe in meeting our objectives
for CS2 by the end of the year. Could you please enlighten me with why this
should be of any interest to BICC CS2, is anyone planning for ATM BCP's
using SDP for BICC environment? 
This is the only item I can think of which would make it relevant. 
Regards Leslie 

Mark Watson wrote: 

 Hi Rajesh,The ITU-T Study Group 11 BICC group are meeting from 18 to 22nd
September. It would be very useful if your updated draft could be input into
that meeting, so that we can study whether or not it meets the Study Group
11 requirements, and if not whether there is an easy way of getting
alignment. Do you think the draft will be ready by then ?Regards,Mark
WatsonNortel Networks 

-----Original Message----- 
From: Rajesh Kumar [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: 04 August 2000 18:36 
To: Joerg Ott 
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked] 
Subject: Reminder//Status of ATM SDP internet draft 
 
Hi Jeorg,At the end of the MMUSIC session on Wednesday, you asked me to
remind you to send me the *comments* you have on
draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do so. Your help in clearing
all technical and logistic hurdles in moving this internet draft to
standards track is critical. Thanks for your help and co-operation so
far.FYI-- I have made careful notes of the comments that were provided
during my presentation at the IETF. I do not see any problem in
incorporating them into the next round of the internet draft, which I hope
to release in the mid-September time-frame.- I am expecting further inputs
from  Sean Sheedy. FYI, Sean and I have met informally before the MMUSIC
meeting and talked after the meeting, and we are in agreement in what needs
to be done for MPEG support. Sean needs to confirm certain things with his
CTO, following which he will provide me with detailed input via email.- I
have found a few more inputs on the atmsdp mailing list following my return,
and I will address each and every one of them.If we can get all this input
sorted out in an internet draft to be posted in mid-September, what do you
think is the time-line for moving this to standards track?Thanks 

- Rajesh Kumar 
+--------------------+ 
|Carrier Packet Voice| 
|Cisco Systems       | 
|San Jose, California| 
+--------------------+ 
  [email-masked] 
  408 527 0811

---

From: Leslie Graf <[email-masked]>
Date: Tue, 08 Aug 2000 15:47:08 +1000

Hi Mark,
I had a chat with Christian before answering this, as you took me quite
by suproze. I had never thought SDP was needed to be generated from the
CSU to the BCU. In CS1 in our supplements we passed down the codec type
and TMR, etc. I feel this is a transport technology independant way of
doing things and requires no additional standardisation in other forums.
This would be part of our package definition in the BICC group. I see no
reason why the CSU need know anything about SDP, could you please
clarify if I have missed something? The only use of SDP in the BICC
domain that I am familiar with is in the IP BCP running in the tunnel.
This is completely transparent to the CSU.
Could you explain to me what we gain by going to SDP generated from the
CSU rather than using the work we did in CS1?
Regards Leslie

Mark Watson wrote:

>  Leslie,Unless I have missed something, SDP is the way that
> Megaco/H.248 communicates a variety of parameters between MGC and MG,
> and this work is the IETFs approach to extending Megaco/H.248 to
> support ATM bearer types.We need a way of communicating the BIWF
> address and BNC ID from MG to MGC so that they can then be placed in
> the BAT ASE for the non-tunnelled Bearer Control case that we use with
> ATM. This draft provides such a capability (amongst many other things
> more relevant to the BMC interface than CBC).I think that IETF and
> ITU-T approaches to the non-tunnelled bearer control case are slightly
> different, but amongst all the noise, we are both trying to solve the
> same problem of communicating these two information elements on the
> vertical interface, so we should at least study whether there is scope
> for an aligned solution.Regards,Mark WatsonNortel Networks
>
>      I am also very interested in this for work I am involved in
>      (nothingto do with BICC). However what I am missing at the
>      moment is seeing the significance of the ATM additions to
>      SDP to the work for BICC CS2.
>      As you are aware of have concerns on the timeframe in
>      meeting our objectives for CS2 by the end of the year. Could
>      you please enlighten me with why this should be of any
>      interest to BICC CS2, is anyone planning for ATM BCP's using
>      SDP for BICC environment?
>     > Hi Rajesh,The ITU-T Study Group 11 BICC group are meeting
>     > from 18 to 22nd September. It would be very useful if your
>     > updated draft could be input into that meeting, so that we
>     > can study whether or not it meets the Study Group 11
>     > requirements, and if not whether there is an easy way of
>     > getting alignment. Do you think the draft will be ready by
>     > then ?Regards,Mark WatsonNortel Networks
>     >
>     >      From: Rajesh Kumar [mailto:[email-masked]]
>     >      Cc: [email-masked]; [email-masked];
>     >      [email-masked]; [email-masked];
>     >      [email-masked]; [email-masked]
>     >      Hi Jeorg,At the end of the MMUSIC session on
>     >      Wednesday, you asked me to remind you to send me
>     >      the *comments* you have on
>     >      draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please
>     >      do so. Your help in clearing all technical and
>     >      logistic hurdles in moving this internet draft
>     >      to standards track is critical. Thanks for your
>     >      help and co-operation so far.FYI-- I have made
>     >      careful notes of the comments that were provided
>     >      during my presentation at the IETF. I do not see
>     >      any problem in incorporating them into the next
>     >      round of the internet draft, which I hope to
>     >      release in the mid-September time-frame.- I am
>     >      expecting further inputs from  Sean Sheedy. FYI,
>     >      Sean and I have met informally before the MMUSIC
>     >      meeting and talked after the meeting, and we are
>     >      in agreement in what needs to be done for MPEG
>     >      support. Sean needs to confirm certain things
>     >      with his CTO, following which he will provide me
>     >      with detailed input via email.- I have found a
>     >      few more inputs on the atmsdp mailing list
>     >      following my return, and I will address each and
>     >      every one of them.If we can get all this input
>     >      sorted out in an internet draft to be posted in
>     >      mid-September, what do you think is the
>     >      time-line for moving this to standards
>     >      track?Thanks
>     >
>     >      - Rajesh Kumar
>     >      +--------------------+
>     >      |Carrier Packet Voice|
>     >      |Cisco Systems       |
>     >      |San Jose, California|
>     >      +--------------------+
>     >        [email-masked]
>     >        408 527 0811
>     >
>     >
>     >

---

From: Rajesh Kumar <[email-masked]>
Date: Tue, 08 Aug 2000 17:53:53 -0700

I'll try and answer Leslie's question based on my understanding of the BICC
work. Correct me where I am wrong.

The CSU described below is the equivalent of the MGC in h.248/Megaco, and the
BCU is the equivalent of the MG.

I guess CSUs communicate with each other through Q.1901-enhanced ISUP. They
communicate  with BCUs through some protocol not addressed by BICC, such as
Megaco/h.248. Now, Megaco uses SDP to communicate parameters.

I guess the CSUs have two options in relaying the bearer-specific parameters to
the far-end CSU via ISUP enhanced through Q.1901. One option is to interwork
the Megaco/h.248 parameters into Q.BICC(Q.1901) parameters. The other option is
to just tunnel these parameters as a character string to the far-end, via
Q.1901-enhanced ISUP. I guess this is what you mean by "tunneled" and
"non-tunneled", but I may be wrong.

Given this, the CSU would need to understand SDP in the non-tunneled approach
if Megaco is the protocol between the CSU and BCU. Is SG11 devising a protocol
for use between the CSU (MGC) and the BCU (MG) that is an alternative to
Megaco/SDP?

Thanks,

Rajesh

At 03:47 PM 8/8/00 +1000, Leslie Graf wrote: 
>
> Hi Mark, 
> I had a chat with Christian before answering this, as you took me quite by
> suproze. I had never thought SDP was needed to be generated from the CSU to
> the BCU. In CS1 in our supplements we passed down the codec type and TMR,
> etc. I feel this is a transport technology independant way of doing things
> and requires no additional standardisation in other forums. This would be
> part of our package definition in the BICC group. I see no reason why the CSU
> need know anything about SDP, could you please clarify if I have missed
> something? The only use of SDP in the BICC domain that I am familiar with is
> in the IP BCP running in the tunnel. This is completely transparent to the
> CSU. 
> Could you explain to me what we gain by going to SDP generated from the CSU
> rather than using the work we did in CS1? 
> Regards Leslie 
>
> Mark Watson wrote: 
>>
>>  Leslie,Unless I have missed something, SDP is the way that Megaco/H.248
>> the IETFs approach to extending Megaco/H.248 to support ATM bearer types.We
>> need a way of communicating the BIWF address and BNC ID from MG to MGC so
>> (amongst many other things more relevant to the BMC interface than CBC).I
>> think that IETF and ITU-T approaches to the non-tunnelled bearer control
>>> From: Leslie Graf
>>> [<mailto:[email-masked]>mailto:[email-masked]]  
>>> As you are aware of have concerns on the timeframe in meeting our
>>> objectives for CS2 by the end of the year. Could you please enlighten me
>>> with why this should be of any interest to BICC CS2, is anyone planning for
>>> ATM BCP's using SDP for BICC environment? 
>>>> September. It would be very useful if your updated draft could be input
>>>> into that meeting, so that we can study whether or not it meets the Study
>>>> Group 11 requirements, and if not whether there is an easy way of getting
>>>> From: Rajesh Kumar [<mailto:[email-masked]>mailto:[email-masked]]  
>>>> draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do so. Your help in
>>>> clearing all technical and logistic hurdles in moving this internet draft
>>>> to standards track is critical. Thanks for your help and co-operation so
>>>> meeting and talked after the meeting, and we are in agreement in what
>>>> needs to be done for MPEG support. Sean needs to confirm certain things
>>>> with his CTO, following which he will provide me with detailed input via
>>>> email.- I have found a few more inputs on the atmsdp mailing list
>>>> following my return, and I will address each and every one of them.If we
>>>> can get all this input sorted out in an internet draft to be posted in
>>>> mid-September, what do you think is the time-line for moving this to
>>>> standards track?Thanks 
>>>>
>>>> - Rajesh Kumar  
>>>> +--------------------+  
>>>> |Carrier Packet Voice|  
>>>> |Cisco Systems       |  
>>>> |San Jose, California|  
>>>> +--------------------+  
>>>>   [email-masked]  
>>>>   408 527 0811   
>>>>   
>>>>  
>>>
>>
>
>
>
> - Rajesh Kumar
>         
> -------------------------------------------------------
> Rajesh Kumar                             :         :
> Carrier Packet Voice                    .|.       .|.
> Cisco Systems                         .:|||:.   .:|||:.
> San Jose, California               ..:|||||||:.:|||||||:..
> 408 527 0811                       C i s c o S y s t e m s
> [email-masked]  
> -------------------------------------------------------
>           
>  
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 09 Aug 2000 11:56:27 +1000

G'Day Rajesh,

SG11 is not defining a new protocol, it is using H248. Please see some
clarifications below marked [CHG].

Cheers, Christian

Rajesh Kumar wrote:
> 
> I'll try and answer Leslie's question based on my understanding of the
> BICC work. Correct me where I am wrong.
> 
> The CSU described below is the equivalent of the MGC in h.248/Megaco,
> and the BCU is the equivalent of the MG.
[CHG] The BCU is part of a larger function called the Bearer
Interworking Function (BIWF). Another function called the Bearer Media
Unit (BMU) is also contained. The interface between the CSU (Call
Serving Unit/MGC) and the BCU is called the Call Bearer Control
Interface (CBC). The interface between the BCU and BMU is called the BMC
interface. BICC CS2 is currently only addressing the CBC interface. The
BMC is currently out of scope.

> 
> I guess CSUs communicate with each other through Q.1901-enhanced ISUP.
> They communicate  with BCUs through some protocol not addressed by
> BICC, such as Megaco/h.248. Now, Megaco uses SDP to communicate
> parameters.
[CHG] Sort of. BICC will not change the core H.248 but will define a
profile which includes package definition to communicate across the CBC
interface.

> 
> I guess the CSUs have two options in relaying the bearer-specific
> parameters to the far-end CSU via ISUP enhanced through Q.1901. One
> option is to interwork the Megaco/h.248 parameters into Q.BICC(Q.1901)
> parameters. The other option is to just tunnel these parameters as a
> character string to the far-end, via Q.1901-enhanced ISUP. I guess
> this is what you mean by "tunneled" and "non-tunneled", but I may be
> wrong.
> 
> Given this, the CSU would need to understand SDP in the non-tunneled
> approach if Megaco is the protocol between the CSU and BCU. Is SG11
> devising a protocol for use between the CSU (MGC) and the BCU (MG)
> that is an alternative to Megaco/SDP?

[CHG] As we have 2 interface CBC and BMC and a tunnelling option we
really have 3 instances of SDP potentially being used.

The first is the pure CBC interface protocol that will go in the Local
and Remote descriptors in the H.248 commands. Associated with this is
what is defined in packages. For what we need across the BICC interface
we will need to define packages. SDP nor H.248annexC covers everything
we need. To avoid the religious discussion on text vs binary we could
define all the elements we need in packages because these are encoding
independent. It also gives us the opportunity to define elements which
match the BICC horizontal protocol. ie. codecs, tmr, usi etc. I'm
currently working at updating the set of packages for BICC to illustrate
this.

The 2nd set of SDP is what will be contained in the IP bearer control
protocol (IPBCP) this could be carried as a property in a Package. This
is being defined in SG11 and only relevant for IP connections so the
ATMSDP work isn't really relevant.

The 3rd is the ATM_SDP work as I mentioned before is for use in the core
H.248 for
the BMC interface. There's no BICC packages defined there so I don't
think we have an overlap problem and as its generic SDP its not a BICC
specific issue.
> > I had a chat with Christian before answering this, as you took me
> > quite by suproze. I had never thought SDP was needed to be generated
> > from the CSU to the BCU. In CS1 in our supplements we passed down
> > the codec type and TMR, etc. I feel this is a transport technology
> > independant way of doing things and requires no additional
> > standardisation in other forums. This would be part of our package
> > definition in the BICC group. I see no reason why the CSU need know
> > anything about SDP, could you please clarify if I have missed
> > something? The only use of SDP in the BICC domain that I am familiar
> > with is in the IP BCP running in the tunnel. This is completely
> > transparent to the CSU.
> > Could you explain to me what we gain by going to SDP generated from
> > the CSU rather than using the work we did in CS1?
> > Regards Leslie
> >
> > Mark Watson wrote:
> >
> >> Megaco/H.248 communicates a variety of parameters between MGC and
> >> MG, and this work is the IETFs approach to extending Megaco/H.248
> >> to support ATM bearer types.We need a way of communicating the
> >> BIWF address and BNC ID from MG to MGC so that they can then be
> >> placed in the BAT ASE for the non-tunnelled Bearer Control case
> >> that we use with ATM. This draft provides such a capability
> >> (amongst many other things more relevant to the BMC interface than
> >> CBC).I think that IETF and ITU-T approaches to the non-tunnelled
> >> bearer control case are slightly different, but amongst all the
> >> noise, we are both trying to solve the same problem of
> >> communicating these two information elements on the vertical
> >> interface, so we should at least study whether there is scope for
> >> an aligned solution.Regards,Mark WatsonNortel Networks
> >>
> >>           [mailto:[email-masked]]
> >>           Cc: 'Rajesh Kumar'; [email-masked];
> >>           [email-masked]; [email-masked]; 'BICC
> >>           ITU-T SG11 ([email-masked])'
> >>           I am also very interested in this for work I am
> >>           involved in (nothingto do with BICC). However what
> >>           I am missing at the moment is seeing the
> >>           As you are aware of have concerns on the timeframe
> >>           in meeting our objectives for CS2 by the end of the
> >>           year. Could you please enlighten me with why this
> >>           should be of any interest to BICC CS2, is anyone
> >>           planning for ATM BCP's using SDP for BICC
> >>           environment?
> >>           > Hi Rajesh,The ITU-T Study Group 11 BICC group are
> >>           > meeting from 18 to 22nd September. It would be
> >>           > very useful if your updated draft could be input
> >>           > into that meeting, so that we can study whether or
> >>           > not it meets the Study Group 11 requirements, and
> >>           > if not whether there is an easy way of getting
> >>           > alignment. Do you think the draft will be ready by
> >>           > draft-rajeshkumar-mmusic-sdp-atm-02.txt.Please do
> >>           > so. Your help in clearing all technical and
> >>           > logistic hurdles in moving this internet draft to
> >>           > standards track is critical. Thanks for your help
> >>           > and co-operation so far.FYI-- I have made careful
> >>           > notes of the comments that were provided during my
> >>           > presentation at the IETF. I do not see any problem
> >>           > in incorporating them into the next round of the
> >>           > internet draft, which I hope to release in the
> >>           > mid-September time-frame.- I am expecting further
> >>           > inputs from  Sean Sheedy. FYI, Sean and I have met
> >>           > informally before the MMUSIC meeting and talked
> >>           > after the meeting, and we are in agreement in what
> >>           > needs to be done for MPEG support. Sean needs to
> >>           > confirm certain things with his CTO, following
> >>           > which he will provide me with detailed input via
> >>           > email.- I have found a few more inputs on the
> >>           > atmsdp mailing list following my return, and I
> >>           > will address each and every one of them.If we can
> >>           > get all this input sorted out in an internet draft
> >>           > to be posted in mid-September, what do you think
> >>           > is the time-line for moving this to standards
> >>           > track?Thanks
> >>           >
> >>           > - Rajesh Kumar
> >>           > +--------------------+
> >>           > |Carrier Packet Voice|
> >>           > |Cisco Systems       |
> >>           > |San Jose, California|
> >>           > +--------------------+
> >>           >   [email-masked]
> >>           >   408 527 0811
> >>           >
> >>           >
> >>
> >>
> >
> > - Rajesh Kumar
> >