RE: Question on ATM SDP draft

["Sophia Scoggins" <[e-mail]>]

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]
- www.marconi.com <http://www.marconi.com/>  - 



-----Original Message----- 

From: Rajesh Kumar [ mailto:[e-mail] <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
<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]  
-------------------------------------------------------