Subject: Scope of ATM SDP work

From: Rajesh Kumar <[email-masked]>
Date: Mon, 26 Jun 2000 16:38:42 -0700

Sophia, Mark, Brian,

At 07:58 AM 6/26/00 -0400, Sophia Scoggins wrote:
>Rajesh,
>
>
>When a MG is capable of routing/switching on IP and different ATM
>layers, then it becomes an issue of how both ends agree on which layer
>to route/switch. If both ends are capable of doing ATM (and the same
>AAL), then all the ATM parameters must be agreed upon by both MGs. In
>that case, c=ATM is used. If we don't use c=ATM and provide necessary
>ATM parameters, the mismatch may happen on the ATM layer setup. 

The IP applications I had in mind involved no call-by-call ATM set-up, although
ATM PVCs could be used for some or all of the IP routing hops. In this case,
the voice call is routed at only on layer (IP) and the ATM connectivity is
fixed.

Of course, if you want to use ATM SVCs that are mapped into an RSVP-based VoIP
network, then what you have said is absolutely true. At the SDP-level, the way
I see it being addressed is through multiple SDP descriptions (multiple v=)
lines. THis is what Megaco mentions too: "When multiple session descriptions
are provided in one descriptor,the "v=" lines are required as delimiters..." 
There would be an ATM session description and an IP session description.

By its very nature, the ATM SDP  internet draft addresses ATM session
descriptions only. My question to you, to Brian and to the rest of this mailing
list is: Is is adequate for that? Do we need to add special constructs to it? I
do not believe so.

On the other hand, you might want to define a way to use SDP  for IP to declare
whether a lower layer protocol is ethernet or ATM or Packet-over-sonet or
packet-over-lambda. For instance, you can state

        a=fmtp: <lower layer>
       
where <lower layer> is defined as
           ATM | Ethernet | POS | POLambda | .....

>
>Once the ATM layer is setup, the applications on both MGs may use the IP
>layer information to do further processing. In that case, the IP layer
>information can either be encapsulated in the ATM payload or be
>explicitly specified in the SDP. If an intermediate node is involved, we
>usually don't like it to peek into the payload to find the information.
>The needed information should be in the SDP. At the same time, we don't
>want the same information be put in two places (SDP and payload),
>either.  
>
>The layering protocol principle is that if layer 2 get you where you
>want to be, then don't go up to layer 3. We go up to layer 3 in the
>situation that layer 2 protocols are different. For example, one end
>does VOIP/ATM and the other end does VOIP/ETHERNET. Any intermediate
>nodes can use different protocols, but that is transparent in the SDP
>for end-to-end description.
>
>The question is how does the originating MG knows which layer 2 protocol
>the terminating MG uses? Mark Watson and I have a proposal in draft,
>which will be submitted to ITU-T SG11 BICC/CS2, to provide a solution
>for this type of situation. However, ITU-T SG11 may not be the right
>group to evaluate the idea. This group or SG16 may be the right one for
>discussion.

It would be great if you can share your draft with us at the right time.
However, I am not sure if this is the right group since you're not looking at
VoATM but VoIP via flexible lower layer selection. As I mentioned before, at
the SDP level, this would be handled in a separate IP SDP descriptor, placed
just next to the ATM SDP descriptor.

I do not want the ATM SDP work to be side-tracked at this point or in the
Pittsburgh IETF on issues that, while being very important and interesting, are
tangential to ATM SDP. However, I would be glad to review, discuss and offer
suggestions on your scheme in this or in another forum.

Please let me know if you agree.
 
>Rajesh Kumar wrote:
>> 
>> Sophia,
>> 
>> 
>> >Do you know if VOIP/ATM will use both c=IN and c=ATM?
>> 
>> VoIP will use c=IN regardless of whether it runs over ATM or not. In
>> some cases, it might run partially over an ATM segment and partially
>> over a non-ATM segment. This case should be treated in the SDP as a
>> VoIP.
>> 
>> c=ATM will be used when RTP is encapsulated raw over AAL5 (no IP)as in
>> H.323 Annex C.
>> 
> 
^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 [email-masked]                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^

---

From: "Sophia Scoggins" <[email-masked]>
Date: Tue, 27 Jun 2000 10:16:51 -0400

Rajesh,

I still have questions on some of your answer. I am leaving for one week
of vacation. I will get back with you later on, with the paper -- it is
related to how to use SDP for different bearer capabilities (IP, ATM,
FR) in the same message.

Regards, Sophia

--------------------------------------------------
Sophia Scoggins, Ph.D.
Succession Access Architect
Nortel Networks

Rajesh Kumar wrote:
> The IP applications I had in mind involved no call-by-call ATM set-up,
> although ATM PVCs could be used for some or all of the IP routing
> hops. In this case, the voice call is routed at only on layer (IP) and
> the ATM connectivity is fixed.
> 
> Of course, if you want to use ATM SVCs that are mapped into an
> RSVP-based VoIP network, then what you have said is absolutely true.
> At the SDP-level, the way I see it being addressed is through multiple
> SDP descriptions (multiple v=) lines. THis is what Megaco mentions
> too: "When multiple session descriptions are provided in one
> descriptor,the "v=" lines are required as delimiters..."  There would
> be an ATM session description and an IP session description.
> 
> descriptions only. My question to you, to Brian and to the rest of
> this mailing list is: Is is adequate for that? Do we need to add
> special constructs to it? I do not believe so.
> 
> On the other hand, you might want to define a way to use SDP  for IP
> to declare whether a lower layer protocol is ethernet or ATM or
> Packet-over-sonet or packet-over-lambda. For instance, you can state
> 
>         a=fmtp: <lower layer>
> 
> It would be great if you can share your draft with us at the right
> time. However, I am not sure if this is the right group since you're
> not looking at VoATM but VoIP via flexible lower layer selection. As I
> mentioned before, at the SDP level, this would be handled in a
> separate IP SDP descriptor, placed just next to the ATM SDP
> descriptor.
> 
> I do not want the ATM SDP work to be side-tracked at this point or in
> the Pittsburgh IETF on issues that, while being very important and
> interesting, are tangential to ATM SDP. However, I would be glad to
> review, discuss and offer suggestions on your scheme in this or in
> another forum.
>