RE: Question on ATM SDP draft
"Sophia Scoggins" <scoggins@nortelnetworks.com> Mon, 09 October 2000 13:01 UTC
Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id GAA02107 for confctrl-outgoing; Mon, 9 Oct 2000 06:01:24 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id GAA02102 for <confctrl@zephyr.isi.edu>; Mon, 9 Oct 2000 06:01:22 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id GAA21877 for <confctrl@isi.edu>; Mon, 9 Oct 2000 06:01:32 -0700 (PDT)
Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Mon, 9 Oct 2000 09:00:59 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id <TT34XLVP>; Mon, 9 Oct 2000 09:00:57 -0400
Message-ID: <E7C200FFFF64D211972F0000F8082287C9646E@ztcfd004.ca.nortel.com>
From: Sophia Scoggins <scoggins@nortelnetworks.com>
To: Mark Watson <mwatson@nortelnetworks.com>, "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, "'atmsdp@eng.fore.com'" <atmsdp@eng.fore.com>
Subject: RE: Question on ATM SDP draft
Date: Mon, 09 Oct 2000 09:00:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C031F0.F5A865E0"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk
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: 'confctrl@ISI.EDU'; 'atmsdp@eng.fore.com' Subject: FW: Question on ATM SDP draft Anyone have any opinions on this ? Regards, Mark Watson Nortel Networkd -----Original Message----- From: Watson, Mark [mailto:mwatson@europem01.nt.com] Sent: 28 September 2000 10:02 To: 'Rajesh Kumar' Cc: atmsdp@eng.fore.com 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:rkumar@cisco.com] Sent: 26 September 2000 22:04 To: Mackey, Michael; 'Rajesh Kumar' Cc: Somers, Mark; atmsdp@eng.fore.com 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: +353 1 6638407 - www.marconi.com <http://www.marconi.com/> - -----Original Message----- From: Rajesh Kumar [ mailto:rkumar@cisco.com <mailto:rkumar@cisco.com> ] Sent: Tuesday, September 26, 2000 12:34 AM To: mhussain@hss.hns.com; atmsdp@eng.fore.com 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, mhussain@hss.hns.com 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 rkumar@cisco.com ------------------------------------------------------- - 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 rkumar@cisco.com -------------------------------------------------------
- FW: Question on ATM SDP draft Mark Watson
- RE: Question on ATM SDP draft Sophia Scoggins
- RE: Question on ATM SDP draft Mark Watson
- RE: Question on ATM SDP draft Sophia Scoggins
- RE: Question on ATM SDP draft Rajesh Kumar