RE: Question on ATM SDP draft

[Rajesh Kumar <[e-mail]>]

Sophia and Mark,
Since H.248 allows the use of the CHOOSE wildcard ("$") for all parameters,
presumably it allows it for the <network type>. I haven't written that up in
the ATM SDP draft because it is one level above the draft. In the context of
the ATM SDP draft, <network type> is always ATM. However, I can add <network
type> = "$" as a permissible syntax.

Regarding the consistency of <network type>, <ATMaddressType> and <ATMaddress>,
I agree with Sophia. These need to  be consistent, and there is no point in
wildcarding <network type> if you know, for example, that <ATMaddressType> =
NSAP. Naren's ABNF, modified in Section 10 of the ATM SDP draft, will not allow
inconsistent <ATMaddressType> and <ATMaddress>. Some higher-level document,
such
as the Megaco documents, should capture the need of the <network type> being
consistent with the rest of the SDP (perhaps, SDP consistency is an axiomatic
requirement)!

So in other words, I can add something about <network type> = "$".  I will not
make it illegal if other parameters such as address type = NSAP are specified,
only a caveat that the freedom implied by "$" is meant to be restricted by the
values of other parameters in the same SDP descriptor. I will also allow
<network type> = "-", with a statement that

c=- NSAP <address> 

is more appropriate than 

c=$ NSAP <address>

because, "-" means "I don't care, but choose wisely" and "$" means "choose any
darn value you want".

My concern is that by specifying wildcarding rules for <network type> I am
overstepping the boundaries of an "ATM" SDP draft. 

Comments?


Rajesh Kumar
At 10:04 AM 10/9/00 -0400, Sophia Scoggins wrote: 
>
> The "c=" line is hierarchical. It would be better to have the address type
> based on the network type and the address format depends on the address type.
> For example, "network type = IN'" will only have the "address type = IP4 or
> IP6", while "network type = ATM" has several address types that are not
> applicable to IN. In the case that many layer 2 (such as ATM and FR) networks
> can have NSAP, their address formats are not the same. I worked on FR several
> years ago. Don't remember the exact FR address format (left that at home),
> but the FR address format is different from the ATM's. So, if a MGC or MG
> does not know the network type, it should not provide address type or
> address. 
>  
> What is the advantage of providing network address type and address while
> don't know the network type? If the MGC or MG does not know the network type,
> then it should not have the address type or address. 
>  
>  
> Regards, Sophia
>  
> -----Original Message-----
> From: Watson, Mark [MAIFP:EP11-M:EXCH] 
> Sent: Monday, October 09, 2000 9:33 AM
> To: Scoggins, Sophia [NC1:8740:EXCH]; '[e-mail]';
> '[e-mail]'
> Subject: RE: Question on ATM SDP draft
>
> Sophia,
>  
> I was asking whether the <AddressType> field is independent of the
> <NetworkType> field. I think it should be, if it is going to be possible to
> keep the MGC 'bearer indepenent'.
>  
> This would allow the gateway address to be interpreted without understanding
> the <NetworkType> field. You could even have:
>  
> c=$ NSAP <address>
>  
> in the case that a gateway supports multiple network types which can all use
> NSAP addressing.
>  
> It would also mean that the presently defined values of <AddressType> would
> be valid with all future values of <NetworkType>, as far as this made sense
> for the specific technology.
>  
> Regards...Mark
>>
>> -----Original Message----- 
>> From: Scoggins, Sophia [mailto:[e-mail]] 
>> Sent: 09 October 2000 14:01 
>> To: Watson, Mark ; '[e-mail]'; '[e-mail]' 
>> Subject: RE: Question on ATM SDP draft
>>
>> The "c=" line is applicable to other type of networks as well. It has been
>> implemented in the IP network: 
>>   
>> c=IN IP4 <IP address> 
>>   
>> Furthermore, there was no restriction on either MGC or MG must provide the
>> network type. So, if the MGC is bearer independent, it would send a '$' to
>> let the MG decide which type of network is. Similarly, if the MGC knew the
>> network type, but not the address type, it can let the MG to decide the
>> bearer technologies. So, all of below formats should be valid: 
>>   
>> c= $ $ $ 
>> c=IN $ $ 
>> c=IN IP4 $ 
>> c=ATM $ $ 
>> c= ATM NSAP $ 
>>   
>> In addition to the "c=" line, the "m=" line also allows $ in many arguments
>> fields. 
>>   
>> The difference between "$" and "-" is that "$" means the argument is in use,
>> but the value has been determined. The recipient of the SDP should
>> provide/return the value, while "-" means the argument is not in use
>> (therefore, it should be ignored). 
>>   
>> However, if "$" seems caused potential interop problems. Because a MGC can
>> let as many fields be "$" as it wishes, while a MG may rely on the MGC's to
>> determine the value of several arguments. This is not a protocol issue, but
>> an implementation agreement / interop issue. 
>>   
>>   
>> Regards, Sophia 
>> -----Original Message----- 
>> From: Watson, Mark [MAIFP:EP11-M:EXCH] 
>> Sent: Monday, October 09, 2000 7:01 AM 
>> To: '[e-mail]'; '[e-mail]' 
>> Subject: FW: Question on ATM SDP draft
>>
>> Anyone have any opinions on this ? 
>> Regards, 
>>   
>> Mark Watson 
>> Nortel Networkd 
>> -----Original Message----- 
>> From: Watson, Mark [mailto:[e-mail]] 
>> Sent: 28 September 2000 10:02 
>> To: 'Rajesh Kumar' 
>> Cc: [e-mail] 
>> Subject: RE: Question
>>
>> Hi, 
>>   
>> Minor point, but on the 'c=' line, shouldn't we describe this as being the
>> same syntax as in existing SDP: 
>>   
>> c=<NetworkType> <AddressType> <Address> 
>>   
>> and say that we are just introducing some new values for <AddressType> and
>> associated formats for <Address>. I would like to think that the new
>> <AddressType>s would be valid for all values of <NetworkType> not just 'ATM'
>> (I'm thinking more of future values of <NetworkType> than the existing
>> values.) 
>>   
>> The current description kind of implies that the new Address Types are only
>> used when <NetworkType>=ATM. 
>>   
>> Regards, 
>>   
>> Mark Watson 
>> Nortel Networks 
>>   
>>   
>>  -----Original Message----- 
>> From: Rajesh Kumar [mailto:[e-mail]] 
>> Sent: 26 September 2000 22:04 
>> To: Mackey, Michael; 'Rajesh Kumar' 
>> Cc: Somers, Mark; [e-mail] 
>> Subject: Question
>>
>> Michael, 
>> Yes. h.248 allows "$" for the IP address. Therefore, the same should be OK
>> for the ATM address.
>>
>> My question is: Isn't this semantically the same as the "-"? This is how it
>> is used in h.248. In this case, do we need the "-"? For backwards
>> compatibility, do we want to permit a "$" and a "-" as synonyms for the 'c'
>> line?
>>
>> Rajesh 
>> At 06:13 AM 9/26/00 -0400, Mackey, Michael wrote: 
>>>
>>> Hi Rajesh ... 
>>>     I have a small question about the c= line ... you say in the document
>>> that it can be set to 
>>>   
>>> c=ATM <ATMaddressType> <ATMaddress>  
>>>   
>>> and if they are not known that ATMaddressType and ATMaddress can be set
>>> to   '-' , would I be correct in presuming that the use of $ is also
>>> allowed for this field ... if yes then should it be mentioned in the
>>> document. I know Megaco allows all fields in SDP to be substituted with $
>>> but since you explicitly say it for the vcci maybe it might be better to
>>> add it in. 
>>>   
>>> Michael Mackey, 
>>> Marconi Communications, 
>>> Tel: [phone] 
>>> - <http://www.marconi.com/>www.marconi.com -  
>>> -----Original Message----- 
>>> From: Rajesh Kumar [mailto:[e-mail]] 
>>> Sent: Tuesday, September 26, 2000 12:34 AM 
>>> To: [e-mail]; [e-mail] 
>>> Subject: ATM SDP inputs from Naren and Mahamood
>>>
>>> Mahamood and Naren, 
>>> I have concatenated, below, several of your emails into one to expedite my
>>> response. Hope this clears up the air. Thanks to you  for your latest round
>>> of inputs. These are specially significant to me since your companies
>>> (Trillium and Hughes Software) are actually implementing the draft. 
>>> Here are some responses, in-line. 
>>> At 09:35 AM 9/20/00 +0530, [e-mail] wrote: 
>>> > 
>>> >1. Why does a port number need 32 digits for representation? Won't 32 bits
>>> >suffice? I am not aware of any machine that uses such a large number range
>>> >for its ports. Kindly clarify.
>>>
>>> See http://search.ietf.org/internet-drafts/draft-ietf-ptopomib-mib-05.txt.
>>> It refers to rfc2737 and rfc2233. In brief, it specifies the port
>>> identifier as a variable size octet string of up to 32 octets. Although the
>>> earlier drafts limited port ID to 32 bits (4 octets), it was considered
>>> necessary to extend it to 32. I have a little clean-up to do regarding the
>>> "34 alphanumeric" characters and I'll do it in the next draft which I will
>>> circulate on the mailing list. Basically, I will make it conform to what
>>> the IETF has standardized/recommended so far in its physical topology MIBs.
>>> And, yes, there are implementations in which the port ID is more than 32
>>> bits e.g. cases in which there is a six-byte  IEEE 802 MAC address used as
>>> a physical port ID. 
>>> > 
>>> >2. The draft says ".. to cover all cases, the <portid> can consist of upto
>>> 34 
>>> >alphanumeric charecters. ". My understanding of 'alphanumeric' is strings
>>> like 
>>> >"mhussain_32". If we use such identifiers for a port, is there going to be
>>> some 
>>> >kind of a mapping between the port number and the port identifier? Since
>>> so far 
>>> >as I gather ports are identified only by a 32bit number.
>>>
>>> See comment above.
>>>
>>> > 
>>> >     These are also problems in migrating from the older draft to the
>>> newer 
>>> >one. 
>>> >The older draft qualified vcci, bcg, port id etc as "decimal numbers".
>>> With 
>>> >this 
>>> >new definition of <portid>, code written around the old draft will be
>>> broken 
>>> >:-(. Can we come up with a scheme that extends the old definitions without
>>> >breaking old code?
>>>
>>> I am going to be following Naren's suggestion that: "There are a few places
>>> (NSAP address, IEEE ID etc) where ONLY hex digits can appear. In these
>>> cases I am fine with having no hex prefixes. My only concern was places
>>> where a hex or a decimal may appear." In these cases where decimal or hex
>>> values are permitted, I'll be requiring explicit 0x prefixes to distinguish
>>> decimal from hex. Also, see my comment, above,  about cleaning up the
>>> alphanumeric port ID. I hope this also helps backwards compatibility with
>>> the code that your team wrote around the earlier draft. However, please
>>> note that there is risk associated with writing code around specifications
>>> that are in flux. You should expect minor changes until the document is
>>> ratified. This is just the way things are.
>>>
>>> On another note, I think the consensus, by articulation or silence, in this
>>> group is to disallow the implicit virtualConnectionId naming convention. I
>>> will do that too. This is what Sean Sheedy, Naren Tulpule and you wanted.
>>>
>>> >     Regarding the virtual connection ID for the "m=" line, the current
>>> draft 
>>> >does not explicitly allow/ disallow the sub-parameters to be a dollar. If
>>> I am 
>>> >not wrong, the oldest draft explicitly disallowed bcg from taking on a
>>> dollar. 
>>> >Could such a restriction be included in the draft?
>>>
>>> The older version did not disallow wildcarding the <bcg>. It was omitted as
>>> an oversight. Actually, the <bcg> was added in the description of the
>>> VirtualConnectionId without adding it into the wildcarding description.
>>> That was a typo and not a  feature. Since there is no reason why  <bcg>
>>> wildcarding should be disallowed, I will not be adding the restriction you
>>> requested.
>>>
>>> > 
>>> >Rajesh, could you also consider including a formal grammar specification
>>> for 
>>> >ATM 
>>> >SDP? ABNF might be a good choice of representation. This will help clear
>>> any 
>>> >ambiguities that may arise as the grammar will be the standard of
>>> reference 
>>> >when 
>>> >building a parser or encoder for ATM sdp.
>>>
>>> I do not think I will have a formal ABNF grammar in by the next draft,
>>> which I hope to issue in a few days. Naren has provided me with one to
>>> start with (Thanks!), but it needs some work. I plan to have it in the next
>>> draft after the next.
>>>
>>> > 
>>> > 
>>> >Thanx, 
>>> >Mahamood 
>>> > 
>>> >
>>>
>>>
>>>
>>>
>>>
>>> - 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 
>>> [e-mail]  
>>> ------------------------------------------------------- 
>>>           
>>>   
>>>   
>>>
>>>
>>>
>>>
>>> - 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
>>> [e-mail]  
>>> -------------------------------------------------------
>>>           
>>>  
>>>  
>>
>
>
>
>
> - 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
> [e-mail]  
> -------------------------------------------------------
>           
>  
>