Subject: RE: Chaining IP and ATM descriptions, PLUS

From: Rajesh Kumar <[email-masked]>
Date: Fri, 30 Jun 2000 11:14:23 -0700

At 05:57 PM 6/29/00 -0400, Rosen, Brian wrote: 
>
> 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.

Yes, I agree. However, to make the SDP draft generic I will include the 'chain'
attribute I described below.

Another point: We need to freeze the draft for the Pittsburgh IETF. I will be
issuing the next draft
draft-rajeshkumar-mmusic-sdp-atm-04.txt next week  with the page numbers
etc.    I will be submitting it to the IETF.

I will still be receiving and recording comments, but I will defer updates
until after the Pittsburgh IETF. Hopefully, we will have a standards track
version of this Internet Draft following the Pittsburgh meeting.

Rajesh

>
>  
> 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
>>
>> 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                
>> ^^^^^^^^^^^^^^^^^^^^^
>>  
>

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