Subject: Chaining IP and ATM descriptions

From: Rajesh Kumar <[email-masked]>
Date: Wed, 28 Jun 2000 17:54:45 -0700

At 08:36 AM 6/27/00 -0400, Rosen, Brian wrote: 
>
> Multiple session descriptions are used as alternatives in Megaco, so your
> first solution would
> be difficult to use.  

I am aware of that. However, I have an idea which I want to run by these
mailing lists before incorporating it into the draft.

How about a "chain" attribute that chains an SDP descriptor to an immediately
adjacent one (next, previous) so that it is possible to describe a connection
with an IP SDP descriptor as well as an ATM SDP descriptor. Comes in handy in a
number of scenarios such as RSVP-over-SVCs, MPLS etc.

The mechanics of how this is accomplished are trivial.
     a=chain: <pointer>
     <pointer> ::= "next"| "previous"|null

Omitting this attribute is equivalent to null.

As Brian indicated, the current concept in megaco etc. is that multiple
adjacent descriptors imply alternation rather than concatenation of SDP
descriptions. My proposal above would allow both, and would obviate the need to
create horrendously complex SDP descriptions that describe a connection that is
dynamically established at both the IP and ATM layers. Separate, clean SDP
descriptions are provided for the IP and ATM layers, IP is on top of ATM, and
these are chained using the chain attribute.

>
> I'd prefer that the solution show you the complete description, which could
> be multiple "layers".  

I strongly feel that the problems Sophia brought up is an important one and
warrants a simple, elegant solution rather than including a lot of IP
parameters into what is basically an ATM SDP description. Providing separate,
chained descriptors for the layers will keep it simple and clean.

>
> I do wonder if we are getting really complex for no good reason.

Perhaps, but we need to address the possibility of RSVP-over-SVCs, MPLS etc.
i.e cases in which there is multi-layer connection establishment.

>
> Specifically, we have a way to specify Annex C, so the real issue is a way to
> specify a full
> IP/UDP/RTP where the underlying connection is an ATM connection, and, for
> some reason,
> you have to say that specifically.  

Yes, specifying that the underlying connection is an ATM connection will work
in simple cases. As I mentioned in my last email, you just add an fmtp to the
RTP/IP description.

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

This might not be adequate when you are trying to establish an IP and the
underlying ATM connection at the same time, and trying to link them together. I
think the chaining mechanism I described above will do the trick and will keep
the descriptions for IP and ATM separate, clean and crisp.

>
> Is that really useful - are there applications that, for example,
> want to have the MGC establish an ATM VC to a specific end point,and then run
> IP over it,

Yes, there are. RSVP over SVCs is an example. This has been discussed publicly
by several companies. Will this succeed? I don't know. We do not want to muddy
the ATM descriptor with several IP parameters, but we should be able to chain
to an IP descriptor (I think).

If I do not receive inputs to the contrary, I will incorporate the chain
attribute I mentioned above. Hope, this will not ruffle feathers in h.248 and
elsewhere. Please let me know.

>
> as opposed to using the more automatic mechanisms like LANE/MPOA and/or
> standard
> routing over an ATM infrastructure?  
>  
> Brian
>>
>> -----Original Message-----
>> From: Rajesh Kumar [mailto:[email-masked]]
>> Sent: Monday, June 26, 2000 7:39 PM
>> To: Sophia Scoggins
>> Cc: [email-masked]; Mark Watson; [email-masked];
[email-masked]
>> Subject: Scope of ATM SDP work
>>
>> 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                
>> ^^^^^^^^^^^^^^^^^^^^^
>>  
>

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 [email-masked]                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 29 Jun 2000 17:57:25 -0400

We have another mechanism in Megaco, but I'm not sure how well it would work
in MGCP and other
users of SDP.  We create separate terminations for the ATM VC and the flow
on it.  We use this
mechanism because it handles cases like AAL1 and 2 where you have a
multiplexed flow on the same
connection.  So you use one SDP descriptor for the VC, and another, entirely
separate one for 
(each of ) the subflow(s).  It allows you to create and destroy the subflows
independently of the VC.
In particular, it allows you to keep the VC when you have no flows, and
subsequently delete it when you
decide you won't need it again.  While not strictly usefull for the case of
IP over AAL5, using the same
mechanism is good.
 
Brian

-----Original Message-----
From: Rajesh Kumar [mailto:[email-masked]]
Sent: Wednesday, June 28, 2000 8:55 PM
To: Rosen, Brian; Sophia Scoggins
Cc: [email-masked]; Mark Watson; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Chaining IP and ATM descriptions

How about a "chain" attribute that chains an SDP descriptor to an
immediately adjacent one (next, previous) so that it is possible to describe
a connection with an IP SDP descriptor as well as an ATM SDP descriptor.
Comes in handy in a number of scenarios such as RSVP-over-SVCs, MPLS etc.

As Brian indicated, the current concept in megaco etc. is that multiple
adjacent descriptors imply alternation rather than concatenation of SDP
descriptions. My proposal above would allow both, and would obviate the need
to create horrendously complex SDP descriptions that describe a connection
that is dynamically established at both the IP and ATM layers. Separate,
clean SDP descriptions are provided for the IP and ATM layers, IP is on top
of ATM, and these are chained using the chain attribute.

I strongly feel that the problems Sophia brought up is an important one and
warrants a simple, elegant solution rather than including a lot of IP
parameters into what is basically an ATM SDP description. Providing
separate, chained descriptors for the layers will keep it simple and clean.

Specifically, we have a way to specify Annex C, so the real issue is a way
to specify a full
IP/UDP/RTP where the underlying connection is an ATM connection, and, for
some reason,
you have to say that specifically.  

Yes, specifying that the underlying connection is an ATM connection will
work in simple cases. As I mentioned in my last email, you just add an fmtp
to the RTP/IP description.

        a=fmtp: <lower layer>

This might not be adequate when you are trying to establish an IP and the
underlying ATM connection at the same time, and trying to link them
together. I think the chaining mechanism I described above will do the trick
and will keep the descriptions for IP and ATM separate, clean and crisp.

Is that really useful - are there applications that, for example,
want to have the MGC establish an ATM VC to a specific end point,and then
run IP over it,

Yes, there are. RSVP over SVCs is an example. This has been discussed
publicly by several companies. Will this succeed? I don't know. We do not
want to muddy the ATM descriptor with several IP parameters, but we should
be able to chain to an IP descriptor (I think).

If I do not receive inputs to the contrary, I will incorporate the chain
attribute I mentioned above. Hope, this will not ruffle feathers in h.248
and elsewhere. Please let me know.

Brian

-----Original Message-----
From: Rajesh Kumar [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Monday, June 26, 2000 7:39 PM
To: Sophia Scoggins
Cc: [email-masked]; Mark Watson; [email-masked];
[email-masked]

Sophia, Mark, Brian,

        a=fmtp: <lower layer>

 
^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 [email-masked]                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
 [email-masked]                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^