From owner-iptel-outgoing@lists.research.bell-labs.com Tue May 4 14:38:34 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22737 for ; Tue, 4 May 1999 14:38:34 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id ECAAE52AF; Tue, 4 May 1999 14:33:23 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 604ED52C1; Tue, 4 May 1999 14:33:22 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <372F3D59.EE0E1E39@cisco.com> Date: Tue, 04 May 1999 11:32:57 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Squire Cc: IPTEL IETF Mailing List Subject: Re: Evaluation of Gateway Location proposals References: <3.0.32.19990429134554.0088f100@bl-mail1.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Matt, Please find some comments and questions on your analysis below. Hussein Matt Squire wrote: > > > > >2. Matt raised numerous transport issues (TCP or not TCP). I think its > >fair to say we want to avoid designing a new transport protocol. There > >is work underway elsewhere (sigtran and slums) to do this, which we can > >leverage. It would seem to me that if something new is needed, this > >would also be independent of whether the protocol baseline is BGP or > >SCSP, since presumably one could use this new transport protocol with > >either. > > > > I certainly agree that we don't want a new transport protocol. But well > short of designing a new transport is to design reliability into our > application protocol (ie with acks, timeouts, re-transmissions, etc), just > like most other application protocols. I prefer to view TBGP/GLP as a call routing protocol not as an application protocol. A call routing protocol bears closer resemblance to layer 3 routing protocols than it has to application protocols. In order to scale well and not to overload the network with too much control traffic, routing protocols may have to tolerate a lower level of reliability than some application protocols. > > >3. To me, the MAIN differences between a BGP based approach and SCSP > >based approach are: > > a. how the data is synchronized between peers > > b. the intra-domain topology > > > >I think we are clear on (b), so (a) is the issue to explore. Hussein had > >made reference to a 2-stage exchange only being needed with BGP, while > >its three with SCSP. These are the kind of differences I think we need > >to explore here. I'd invite both authors to comment on the differences > >in how the data is exchanged and updated between peers. Lets stick with > >inter-domain for the moment... > > > > Here's a brief synopsis of the data exchanges for each alternative. In > both cases, the exchanges are just peer-to-peer. > > BGP > *** > > BGP1) OPEN. OPEN messages are exchanged to bring the link up. > Basically, two peers connect and send an open message to the other. A peer > either acks the OPEN with a KEEP-ALIVE, or nacks the OPEN with a > NOTIFICATION. When your OPEN gets ack'd, the peer connection is considered > to be established (ie have bi-directional connectivity). BGP can also > perform version negotiation and capabilities exchanges with the OPEN > messages. > > BGP2) UPDATE. Once a peer connection is established (via ack'd OPENs), > BGP peers exchange UPDATE messages. UPDATE messages are the messages that > contain the routing information. Each UPDATE message may contain a number > of withdrawn routes and a single feasible route. A withdrawn route is a > route that should be removed from the peer's RIB-IN. A withdrawn route is > defined by a address/prefix-length. A feasible route is defined as the > NLRI (network layer reachability information, ie a list of > address/prefix-length combinations) and its attributes. A key mandatory > attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI. > Basically, you send an UPDATE for each possible NEXT-HOP in your routing > database. You are talking here strictly about BGP for layer 3 routing. Even in this case, a single UPDATE message may contain multiple NLRI (destination prefixes) under the condition that they share the same attributes (NEXT_HOP, AS_PATH, ...) . TBGP uses the MP_REACH_NLRI attribute to advertise prefixes. Similar to BGP, the MP_REACH_NLRI contains a list of NLRIs which share the same attributes. The original BGP NEXT_HOP attribute will not be used in call routing. The above discussion brings up the question I had for some time: Does GLP/SCSP define a mechanism for explicitly withdrawing a route and removing it from the call routing databases? > > KEEP-ALIVE messages are periodically going in the background to ensure that > the link is up. > > BGP UPDATE and NOTIFICATION messages are not acknowledged as TCP > acknowledgment is considered sufficient. I'll comment on this further down. > > SCSP > **** > SCSP1) Hello. Peers exchange Hello messages to ensure bi-directional > connectivity between peers. This is equivalent to the BGP OPEN exchanges > but without anything like version negotiation or capabilities exchange. > Hello messages are also periodically exchanged in the background to ensure > the link us still up. > > SCSP2) Cache Aligment. SCSP distinguishes between the state where two > peers have had their databases synchronized and when they have not. When a > peer connection first comes up (via Hello), the peers enter the Cache > Alignment phase where the entire databases must be exchanged. First, there > is a negotiation to determine who is the master and slave of the peering > relationship. Next, the peers exchange summary records with each other, > where a summary record is a short-version of the record - enough to > identify it, but doesn't have the real data. This phase has no parallel in > BGP. And I don't see what advantage call routing can gain from this phase? > > SCSP3) Cache State Update. A server maintiains a list of the records > that it needs to get from its peer (the summary records in the previous > phase). A server requests these records via a Solicit message (ie I need > the full record for these summary records). The response to the the > request is a Update Request message containing some/all of the records. A > server continues to send further Solicit messages for records that it has > not yet received. A server ack's that the records have been received with > an Update Reply containing the summaries of recieved records. The Update > Request messages are similar to the UPDATE messages of BGP. From reading the SCSP spec, I thought that in the Cache State Update phase no CSA Solicit messages are required? Just CSA Request/CSA Reply messages. If a CSA Solicit message is required, this makes SCSP's overhead three messages per update as compared to BGP's one message per update. > > Acknowledgements in SCSP are done per-record (ie requests for a record are > acknowledged by sending the record, record transmissions are acknowledged > by sending a record summary in an Update Reply). > > SOME DIFFERENCES > **************** > > I think Hussein's "2 vs 3" stages are identified above. SCSP has the added > stage of Cache Alignment where database summaries are exchanged. > > BGP uses TCP, SCSP uses X (pick your transport). > > BGP exchanges and message formats are certainly more efficient, SCSP more > generic. In the peer-to-peer case (ie inter-domain), some SCSP header > fields are redundant (example: reciever and sender ID). > > SCSP does per-record acks and requests, which is flexible, but can be a > pain in the ass and inefficient. BGP UPDATE/NOTIFICATION messages are > unacknowledged and assume TCP provides reliability for the application. > BGP does not provide a mechanism to positively Ack UPDATE messages. However the NOTIFICATION message is used to provide a negative Ack in response to errors in the contents of, or in the processing of, an UPDATE message. This may be looked at as a more efficient mechanism for reliability than positive Acks. Since transport reliability is already guaranteed by TCP, error Notification usually indicates fatal problems with the BGP FSM, and therefore is followed by closing the peer connection. I can see situations where, in response to an error in processing an UPDATE message, it should be sufficient to send an error NOTIFICATION and to ignore that UPDATE, but not closing the entire connection. But that's the way BGP works. > SCSP Update Requests can contain many records. BGP UPDATEs contain a > single route (maybe multiple withdrawn routes). I commented on this earlier. > > SCSP bases record identification on record summaries (source identifier, > cache 'key' for record), so to replace a record you keeep the record > summary and replace the data contents. BGP identifies records based on the > contents (ie NLRI), so the data content is examined to determine new vs > replacement. > From discussions with people who implemented IDRP in the past, my understanding is that it relied on a key for record location, which proved to be "difficult to implement with little practical gain." -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue May 4 22:17:45 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29961 for ; Tue, 4 May 1999 22:17:45 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 31F1352C1; Tue, 4 May 1999 22:13:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A25C152C5; Tue, 4 May 1999 22:13:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: blacky@netrd.iii.org.tw To: iptel@lists.research.bell-labs.com Date: Tue, 4 May 1999 22:11:37 -0400 Message-Id: <19990505021306.06E1452C1@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 5 02:19:00 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16102 for ; Wed, 5 May 1999 02:19:00 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id CFC0852B6; Wed, 5 May 1999 01:09:26 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3E09E52C6; Wed, 5 May 1999 01:09:25 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199905050459.BAA20144@postino1.prima.com.ar> X-Mailer: Aureate Group Mail Free Edition From: ninguno To: international Date: Wed, 05 May 1999 02:07:12 -0300 Subject: TELEFONIA INTERNACIONAL VIA INTERNET Reply-To: ip@excite.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Priority: 3 X-MIME-Autoconverted: from 8bit to quoted-printable by postino1.prima.com.ar id BAA20144 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA16102 AHORA USTED PUEDE HABLAR LARGA DISTANCIA comercialmente o en forma particular .....GRATIS!!!!!!.... Llamando a los numeros gratuitos tipo 0-800 del mundo. SI, GRATIS !!!! o con aranceles equivalentes a los u$s 0.10 el minuto llamando a USA, Australia, Inglaterra, Francia, Alemania, Israel, Suiza, etc.... a cualquier hora del dia si restricciones y sin importar si pertenece a cualquiera de las companias telefonicas de Argentina La nueva "interface IP", de INTERNATIONAL PHONE le permiten establecer comunicaciones de VOZ DE ALTA CALIDAD en comunicaciones de telefono analogico comun (con el IP instalado a su PC) a telefono standard en cualquier parte del mundo sin necesidad de intermediar PC alguna en el lugar al que llama. Esta "interface IP" requieren una conexion a Internet y una maquina de requerimientos minimos (desde equipos Pentium) Para más información visite nuestro site www.orbita.starmedia.com/via/~international-phone/ip.html o bien contáctese con nuestros ejecutivos de cuenta y será para nosotros un placer ofrecerle una demostración gratuita. INTERNATIONAL PHONE Depto. de ventas ip-ar@excite.com Tel : (011) 4 786-1857 Sus datos fueron obtenidos de bases publicas de diversas fuentes. Si usted no desea volver a recibir informacion de productos novedosos por favor responda este mail a international-phone@starmedia.com y sera eliminado automaticamente de nuestra base de datos. AHORA USTED PUEDE HABLAR LARGA DISTANCIA comercialmente o en forma particular .....GRATIS!!!!!!.... Llamando a los numeros gratuitos tipo 0-800 del mundo. SI, GRATIS !!!! o con aranceles equivalentes a los u$s 0.10 el minuto llamando a USA, Australia, Inglaterra, Francia, Alemania, Israel, Suiza, etc.... a cualquier hora del dia si restricciones y sin importar si pertenece a cualquiera de las companias telefonicas de Argentina La nueva "interface IP", de INTERNATIONAL PHONE le permiten establecer comunicaciones de VOZ DE ALTA CALIDAD en comunicaciones de telefono analogico comun (con el IP instalado a su PC) a telefono standard en cualquier parte del mundo sin necesidad de intermediar PC alguna en el lugar al que llama. Esta "interface IP" requieren una conexion a Internet y una maquina de requerimientos minimos (desde equipos Pentium) Para más información visite nuestro site www.orbita.starmedia.com/via/~international-phone/ip.html o bien contáctese con nuestros ejecutivos de cuenta y será para nosotros un placer ofrecerle una demostración gratuita. INTERNATIONAL PHONE Depto. de ventas ip-ar@excite.com Tel : (011) 4 786-1857 Sus datos fueron obtenidos de bases publicas de diversas fuentes. Si usted no desea volver a recibir informacion de productos novedosos por favor responda este mail a no-e-mail@excite.com y sera eliminado automaticamente de nuestra base de datos. ---------------------------------------------------------------------- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 5 09:02:04 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19585 for ; Wed, 5 May 1999 09:02:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7C73252C1; Wed, 5 May 1999 08:57:25 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0007152C5; Wed, 5 May 1999 08:57:24 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Jose Costa Requena Message-Id: <19990505155654jose@tct.hut.fi@default> Date: Wed May 05 15:56:54 1999 Content-Type: text/plain;charset=us-ascii To: hsalama@cisco.com, iptel@lists.research.bell-labs.com Subject: Re: Evaluation of Gateway Location proposals X-Mailer: Pronto E-Mail [ver 4.0.2.6] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hussein, >You are talking here strictly about BGP for layer 3 routing. Even in >this case, a single UPDATE message may contain multiple NLRI >(destination prefixes) under the condition that they share the same >attributes (NEXT_HOP, AS_PATH, ...) . TBGP uses the MP_REACH_NLRI >attribute to advertise prefixes. Similar to BGP, the MP_REACH_NLRI >contains a list of NLRIs which share the same attributes. > >The original BGP NEXT_HOP attribute will not be used in call routing. > >The above discussion brings up the question I had for some time: Does >GLP/SCSP define a mechanism for explicitly withdrawing a route and >removing it from the call routing databases? The SCSP itself has a mechanism to notify the databases in the rest of DCSs forming the SG that the server has received a request from a client or User Agent to remove an entry from its cache or routing database.In this case, when the LS which contains the entry that is going to disappear and receive Cache State Update Solicit (CSUS) from other server, this LS will respond copying the CSAS from the CSUS and will set the N bit (described in the CSAS record specification). The N bit signifies that this CSAS Record is actually a Null record and this entry in the database does not exist any longer. I wonder if is that the question that you were asking? and I hope that I have clarified the idea. Best regards. Jose Helsinki University of Technology Laboratory of Telecommunications Technology Jose Costa Requena Research Scientist Room: SG 227B Tel: + 358 9 451 2475 email(internet): jose@tct.hut.fi http://keskus.tct.hut.fi/tutkimus/ipana/pers/jose.shtml --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 5 10:24:28 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22677 for ; Wed, 5 May 1999 10:24:26 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7003D52C4; Wed, 5 May 1999 10:19:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D538252C6; Wed, 5 May 1999 10:19:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Jose Costa Requena Message-Id: <19990505171903jose@tct.hut.fi@default> Date: Wed May 05 17:19:03 1999 Content-Type: text/plain To: hsalama@cisco.com Subject: Re: Evaluation of Gateway Location proposals Cc: iptel@lists.research.bell-labs.com X-Mailer: Pronto E-Mail [ver 4.0.2.6] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hussein, Here is another comment that I couldn't answer in the last mail. Regarding the Cache Alignment state you said: >And I don't see what advantage call routing can gain from this phase? This phase could seems that will be inefficient but the utility appears when one of the connections between a pair of servers is down.The rest of servers in the server Group are continuing their transactions and updating their databases. The FSM which takes care of that pair will check the connection after the Time out has expired(Hello Interval) and it has to restart all the process till it reaches again the bidirectional state. In this moment, the server that was isolated from the SG has to update its database. When the server is again reachable can be long time ago from the last update or it can be after a short interval, anyway in the Cache Alignment State that Server can ask only for the CSA records that have changed since the last time that it was connected. It means that in that state there will be required only the records that are out of date and not the rest. But if the failure was only during a short interval the server does not have to update any record and it transitions immediately to the Cache Update State and it means that the protocol will perform nearly only two phases from the Hello directly to the Cache State Update. Another question is about your comment: >From reading the SCSP spec, I thought that in the Cache State Update >phase no CSA Solicit messages are required? Just CSA Request/CSA Reply >messages. If a CSA Solicit message is required, this makes SCSP's overhead >three messages per update as compared to BGP's one message per update. In this case, the CSUS are required for specific situations, one example could be the moment that the entry that the server is asking for is no longer in the database.As I comment in the last mail in that situation the Server will receive the same CSAS that it sent in the CSUS but with the N bit on. In this case we get the benefit of not sending and receiving all the record, only the notification saying that it was a null entry. I guess that in this and other cases is useful to send only the summary and compare if it is newest or not, instead of compare all the record. I guess that when the data is quite big is better to send and receive only the summaries. Sorry for so long explanation but I have tried to describe my point of view, maybe I'm wrong and is better only use two phases in the updating and only two kind of messages for that, but I hope some comments about my idea. Thanks very much. Best regards. Jose Helsinki University of Technology Laboratory of Telecommunications Technology Jose Costa Requena Research Scientist Room: SG 227B Tel: + 358 9 451 2475 email(internet): jose@tct.hut.fi http://keskus.tct.hut.fi/tutkimus/ipana/pers/jose.shtml --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 5 19:24:43 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01852 for ; Wed, 5 May 1999 19:24:43 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9153E52C7; Wed, 5 May 1999 19:19:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E3CFD52C8; Wed, 5 May 1999 19:19:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3730D1D7.ED7FEA5E@cisco.com> Date: Wed, 05 May 1999 16:18:48 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jose Costa Requena Cc: iptel@lists.research.bell-labs.com Subject: Re: Evaluation of Gateway Location proposals References: <19990505171903jose@tct.hut.fi@default> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jose Costa Requena wrote: > > Hi Hussein, > > Here is another comment that I couldn't answer in the last mail. > Regarding the Cache Alignment state you said: > > >And I don't see what advantage call routing can gain from this phase? > > This phase could seems that will be inefficient but the utility appears when > one of the connections between a pair of servers is down.The rest of servers > in the server Group are continuing their transactions and updating their > databases. The FSM which takes care of that pair will check the connection > after the Time out has expired(Hello Interval) and it has to restart all the > process till it reaches again the bidirectional state. In this moment, the > server that was isolated from the SG has to update its database. When the > server is again reachable can be long time ago from the last update or it > can be after a short interval, anyway in the Cache Alignment State that > Server can ask only for the CSA records that have changed since the last > time that it was connected. It means that in that state there will be > required only the records that are out of date and not the rest. But if the > failure was only during a short interval the server does not have to update > any record and it transitions immediately to the Cache Update State and it > means that the protocol will perform nearly only two phases from the Hello > directly to the Cache State Update. I think in call routing, when the connection between LS A and LS B is disconnected (due to any reason), LS A should immediately delete any call routes it has previously learned from LS B. As a result, when the connection between LS A and LS B is restored, both LSs will have to exchange their entire call routing databases. For call routing, and layer 3 routing, purposes, I don't think it's wise for an LS A to keep a call route X after LS B, which advertised X to A, disappears. The reason is: how will we A learn about changes to the status of X while B is down? > > Another question is about your comment: > > >From reading the SCSP spec, I thought that in the Cache State Update > >phase no CSA Solicit messages are required? Just CSA Request/CSA Reply > >messages. If a CSA Solicit message is required, this makes SCSP's overhead > >three messages per update as compared to BGP's one message per update. > > In this case, the CSUS are required for specific situations, one example > could be the moment that the entry that the server is asking for is no > longer in the database.As I comment in the last mail in that situation the > Server will receive the same CSAS that it sent in the CSUS but with the N > bit on. In this case we get the benefit of not sending and receiving all the > record, only the notification saying that it was a null entry. I guess that > in this and other cases is useful to send only the summary and compare if it > is newest or not, instead of compare all the record. I guess that when the > data is quite big is better to send and receive only the summaries. Please see my previous message. Hussein > > Sorry for so long explanation but I have tried to describe my point of view, > maybe I'm wrong and is better only use two phases in the updating and only > two kind of messages for that, but I hope some comments about my idea. > Thanks very much. > Best regards. > Jose > > Helsinki University of Technology > Laboratory of Telecommunications Technology > Jose Costa Requena > Research Scientist > Room: SG 227B > Tel: + 358 9 451 2475 > email(internet): jose@tct.hut.fi > http://keskus.tct.hut.fi/tutkimus/ipana/pers/jose.shtml -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 5 20:05:37 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02240 for ; Wed, 5 May 1999 20:05:36 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E382652C5; Wed, 5 May 1999 19:01:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 56BE252C7; Wed, 5 May 1999 19:01:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3730CDDD.81F5F81D@cisco.com> Date: Wed, 05 May 1999 16:01:49 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jose Costa Requena Cc: iptel@lists.research.bell-labs.com Subject: Re: Evaluation of Gateway Location proposals References: <19990505155654jose@tct.hut.fi@default> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jose, Thanks for the clarification. Jose Costa Requena wrote: > > Hi Hussein, > > >You are talking here strictly about BGP for layer 3 routing. Even in > >this case, a single UPDATE message may contain multiple NLRI > >(destination prefixes) under the condition that they share the same > >attributes (NEXT_HOP, AS_PATH, ...) . TBGP uses the MP_REACH_NLRI > >attribute to advertise prefixes. Similar to BGP, the MP_REACH_NLRI > >contains a list of NLRIs which share the same attributes. > > > >The original BGP NEXT_HOP attribute will not be used in call routing. > > > >The above discussion brings up the question I had for some time: Does > >GLP/SCSP define a mechanism for explicitly withdrawing a route and > >removing it from the call routing databases? > > The SCSP itself has a mechanism to notify the databases in the rest of DCSs > forming the SG that the server has received a request from a client or User > Agent to remove an entry from its cache or routing database.In this case, > when the LS which contains the entry that is going to disappear and receive > Cache State Update Solicit (CSUS) from other server, this LS will respond > copying the CSAS from the CSUS and will set the N bit (described in the CSAS > record specification). The N bit signifies that this CSAS Record is actually > a Null record and this entry in the database does not exist any longer. Assume server A advertises a record X to server B. Then, at some later point in time, record X is deleted. Server B won't learn that record X has seized to exist until it solicits an update from server A for that record? This could be a very slow operation. How frequently should B solicit updates from A, in order to minimize the probability of using outdated or deleted records? Advertising route withdrawals to a server which is multiple hops away will be very slow using this mechanism. Let's say every server periodically solicits updates every time interval t. It will take a server, C, n*t time units, in the worst case, to learn that a record has been withdrawn, where n is the number of hops between server C and the server which has withdrawn the record. What's wrong with conventional routing logic: when a server detects a change to the state of a record, it immediately triggers an unsolicited update to its peers. When a peer receives the update, if it causes any changes to that peer's records, it immediately triggers an update to the peer's peers. And so on. Wouldn't that be faster? The SCSP RFC says: "The "N" bit signifies that this CSAS Record is actually a Null record. This bit is only used in a CSAS Record contained in a CSU Request/Reply which is sent in response to a CSUS message." This means that an update advertising a record deletion must be solicited. How about other changes to the attributes of an existing record? Can they trigger an unsolicited update, CSU Request? Hussein > > I wonder if is that the question that you were asking? > and I hope that I have clarified the idea. > > Best regards. > > Jose > > Helsinki University of Technology > Laboratory of Telecommunications Technology > Jose Costa Requena > Research Scientist > Room: SG 227B > Tel: + 358 9 451 2475 > email(internet): jose@tct.hut.fi > http://keskus.tct.hut.fi/tutkimus/ipana/pers/jose.shtml > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 6 03:28:06 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19719 for ; Thu, 6 May 1999 03:28:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 79D9552B6; Thu, 6 May 1999 03:23:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D42FF52C7; Thu, 6 May 1999 03:23:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Jose Costa Requena Message-Id: <19990506102253jose@tct.hut.fi@default> Date: Thu May 06 10:22:53 1999 Content-Type: text/plain;charset=us-ascii To: hsalama@cisco.com, Raimo.Kantola@hut.fi Subject: Re: Evaluation of Gateway Location proposals Cc: iptel@lists.research.bell-labs.com X-Mailer: Pronto E-Mail [ver 4.0.2.6] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Hussein, Thanks for your comments. I have implemented the SCSP and actually I am testing the first version in the Lab., I am glad to receive some comments to change some details and polish the implementation. >Assume server A advertises a record X to server B. Then, at some later >point in time, record X is deleted. Server B won't learn that record X >has seized to exist until it solicits an update from server A for that >record? This could be a very slow operation. How frequently should B >solicit updates from A, in order to minimize the probability of using >outdated or deleted records? You are right, it is a good point because in the case that we fixe a short time out in the cache entry, all the database will be updated in a short interval but the drawback is that it will increase the traffic.Otherwise, if we fixed a long time out it will take a long time to update all the records. Professor Kantola and me are working in the feature provided by the Family Identifier to split the database up in different sections. The part of the routing table that is changing dynamically will be fixed with a shorter time out than the other.Thus, the former part will be updated more frequently. With the Family ID we can distinguish two instances of the same SCSP running in the same Sever Group and maybe that is the key to differentiate a section in the routing table that is more dynamic than another section that is more static and requires less maintenance. >Advertising route withdrawals to a server which is multiple hops away >will be very slow using this mechanism. Let's say every server >periodically solicits updates every time interval t. It will take a >server, C, n*t time units, in the worst case, to learn that a record has >been withdrawn, where n is the number of hops between server C and the >server which has withdrawn the record. >What's wrong with conventional routing logic: when a server detects a >change to the state of a record, it immediately triggers an unsolicited >update to its peers. When a peer receives the update, if it causes any >changes to that peer's records, it immediately triggers an update to the >peer's peers. And so on. Wouldn't that be faster? >The SCSP RFC says: "The "N" bit signifies that this CSAS Record is >actually a Null record. This bit is only used in a CSAS Record >contained in a CSU Request/Reply which is sent in response to a CSUS >message." This means that an update advertising a record deletion must >be solicited. How about other changes to the attributes of an existing >record? Can they trigger an unsolicited update, CSU Request? >Hussein I guess that the conventional routing logic that you mention in the last paragraph is performed by the SCSP on its last phase. When the peer has reached the Cache State Update phase they will perform a mirroring state.It means that when any cache entry has timed out, or it has been modified, this LS will send a CSU Request to each of its DCSs. In this Request we can advertise either that this record is newest or is going to be deleted setting the bit N. Thus, we don't have to wait to Solicit and update message for that record because is just the LS that has the record which is going to be removed who will send the Request to all the DCSs advertising that this record is going to be deleted from the routing table using the N bit. Thanks for your comments, I am looking forward to hear from you about my ideas and what is your opinion. Helsinki University of Technology Laboratory of Telecommunications Technology Jose Costa Requena Research Scientist Room: SG 227B Tel: + 358 9 451 2475 email(internet): jose@tct.hut.fi http://keskus.tct.hut.fi/tutkimus/ipana/pers/jose.shtml --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 6 20:59:55 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06636 for ; Thu, 6 May 1999 20:59:54 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 45F3352B6; Thu, 6 May 1999 20:55:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 97E5B52C1; Thu, 6 May 1999 20:55:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.5.32.19990506175059.00aa1290@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 May 1999 17:50:59 -0700 To: iptel@lists.research.bell-labs.com From: Marty Bickford Subject: Quality of Service Forum Reception and Network Demo Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by ziggy.stardust.com id RAA16570 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA06636 The Quality of Service Forum is extending an invitation to join us at the Quality of Service Forum Networking Reception. The highlights of the reception will include the QoS Network Showcase demonstration and a great networking opportunity. QOSF Reception and QoS Network Showcase --------------------------------------- ~ QoS Network Showcase demonstration. We'll demonstrate end-to-end QoS capabilities in an extensive IP network. You'll see the difference between QoS and non-QoS impact on numerous application categories and via empirical measurement tools that graphically show the traffic impact of QoS capabilities. This network reveals current vendor support and interoperability between emerging products which support new QoS protocols. Network: http://www.stardust.com/iband2/network.jpg Description: http://www.stardust.com/iband2/qos-showcase.htm ~ Great networking opportunity to meet with QOSF members and non-members, ISP's, IP network engineers and the press. You'll learn how the Quality of Service Forum is playing an important role in the adoption of QoS. ~ Qosnetics will sponsor the QOSF Reception which will be held in concert with the QOS NetworkShowcase demonstration. You are invited to attend. ~ Participating companies include: 3Com, Abatis, Cisco Systems, Extreme, Fujitsu, IBM, Intel, IP Highway, IPivot, Lucent, Microsoft, Nortel, Novell, Orchestream, Qosnetics, Xedia, and NetCom Systems. Logistics --------- Where: San Francisco Airport Marriott (in coordination with iBAND2). Signs will assist you to the meeting location. When: Sunday May 23, 1999 from 6:30pm - 7:30pm RSVP: Please RSVP to Sherryl Alameda by May 19th. sherryla@stardust.com iBAND2 - May 23-25, 1999. San Francisco --------------------------------------- The Quality of Service Forum is an Association Sponsor of iBAND2. iBAND2 is targeted at IP Network Professionals in enterprise, service provider and carrier organizations. At the heart of the event is a 3-track conference in which the industry’s leading technologists and business pioneers give leading edge sessions on the technology, deployment and business of smart bandwidth solutions. We encourage you to sign-up today at http://www.stardust.com/iband2/ Nortel Networks is the Platinum Sponsor, Intel and NetCom Systems are Gold Sponsors, the IP Multicast Initiative & the Quality of Service Forum are Alliance Sponsors, and America's Network, Data Communications, InternetWeek and tele.com are Publication Sponsors of iBAND2. Sincerely, Marty --- Marty Bickford - 408.879.8080 (8081-fax) Stardust Forums - http://www.stardust.com iBAND2(sm) - The Internet Bandwidth Management Summit --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 12 14:05:56 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06713 for ; Wed, 12 May 1999 14:05:56 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6010352BB; Wed, 12 May 1999 13:59:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CAB4A52D5; Wed, 12 May 1999 13:59:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19990512134812.008c2920@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 May 1999 13:48:14 -0400 To: hsalama@cisco.com From: Matt Squire Subject: Re: Evaluation of Gateway Location proposals Cc: IPTEL IETF Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hussein - I included answers/comments interspersed with the original message. I tried to delete anything not relevant to your comments. - Matt >In >order to scale well and not to overload the network with too much >control traffic, routing protocols may have to tolerate a lower level of >reliability than some application protocols. > I'm not sure what you mean by a "lower level of reliability". If the routing information is not transmitted reliably, then routing loops can occur. All peers in a BGP administrative domain must have the same view of the network. Otherwise they can make independent decisions that cause loops. Reliability is a requirement, the question is where reliability comes from. >> Each UPDATE message may contain a number >> of withdrawn routes and a single feasible route. A withdrawn route is a >> route that should be removed from the peer's RIB-IN. A withdrawn route is >> defined by a address/prefix-length. A feasible route is defined as the >> NLRI (network layer reachability information, ie a list of >> address/prefix-length combinations) and its attributes. A key mandatory >> attribute is the NEXT-HOP attribute which gives the next-hop for the NLRI. >> Basically, you send an UPDATE for each possible NEXT-HOP in your routing >> database. > >You are talking here strictly about BGP for layer 3 routing. Even in >this case, a single UPDATE message may contain multiple NLRI >(destination prefixes) under the condition that they share the same >attributes (NEXT_HOP, AS_PATH, ...) . I think I said that. > TBGP uses the MP_REACH_NLRI >attribute to advertise prefixes. Similar to BGP, the MP_REACH_NLRI >contains a list of NLRIs which share the same attributes. > >The original BGP NEXT_HOP attribute will not be used in call routing. Right, but the restriction is the same, one next-hop per message. There is a list of addr prefixes with each next-hop. > >>From reading the SCSP spec, I thought that in the Cache State Update >phase no CSA >Solicit messages are required? Just CSA Request/CSA Reply messages. If a >CSA Solicit message is required, this makes SCSP's overhead three >messages per update as compared to BGP's one message per update. > The solicit messages are used in recovery and link activation. When a link comes up between two peers, the peers exchange summaries of all of their data. If they need the full record then they ask for it via a solicit. Suppose you have the servers A-B-C all synchronized, with A-B being peers, and B-C being peers. Then a link is brought up between A and C. The servers exchange summaries, realize that they already have all of the records that the other guy has, and are synchronized without ever synchronizing the real data. When restricted to two peers, the solicit adds an extra message during the initial synchronization. Solicits are not used after things are up. In steady state (after the peers are synchronized), the local server sends requests to the peer containing the data, and the peer acknowledges via a reply. So the general sequence is information followed by ack. Data is not solicited. > >BGP does not provide a mechanism to positively Ack UPDATE messages. >However the NOTIFICATION message is used to provide a negative Ack in >response to errors in the contents of, or in the processing of, an >UPDATE message. This may be looked at as a more efficient mechanism for >reliability than positive Acks. Since transport reliability is already >guaranteed by TCP, error Notification usually indicates fatal problems >with the BGP FSM, and therefore is followed by closing the peer >connection. I can see situations where, in response to an error in >processing an UPDATE message, it should be sufficient to send an error >NOTIFICATION and to ignore that UPDATE, but not closing the entire >connection. But that's the way BGP works. > And if the route process is busy or its queues are full or for some reason it just can't take the socket upcall from the TCP layer at this time, then the information is lost. And that is a problem. Hence one has to hack the TCP stack and the OS to ensure this never happens. > >>From discussions with people who implemented IDRP in the past, my >understanding is that >it relied on a key for record location, which proved to be "difficult to >implement with little practical gain." > When the "uniqueness" information in a record is an 4-byte IP address, then a key is useless. When the uniqueness information is more (ie an IPv6 addr or an E164 addr), then there is benefit from using a short key. What is so difficult to implement about a key? - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 12 14:16:35 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07052 for ; Wed, 12 May 1999 14:16:34 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 807AB52D5; Wed, 12 May 1999 14:11:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D50AF52DB; Wed, 12 May 1999 14:11:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19990512135935.007acb10@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 May 1999 13:59:36 -0400 To: hsalama@cisco.com, Jose Costa Requena From: Matt Squire Subject: Re: Evaluation of Gateway Location proposals Cc: iptel@lists.research.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk > >Assume server A advertises a record X to server B. Then, at some later >point in time, record X is deleted. Server B won't learn that record X >has seized to exist until it solicits an update from server A for that >record? This could be a very slow operation. How frequently should B >solicit updates from A, in order to minimize the probability of using >outdated or deleted records? > If X is deleted at A, then A sends an request to B indicating the deletion. B acknowledges the deletion. The message from A is unsolicited. Information is solicited only during link activation and initial synchronization. - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 12 14:26:16 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07352 for ; Wed, 12 May 1999 14:26:16 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 30B8B52DC; Wed, 12 May 1999 14:21:23 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 95A6552DB; Wed, 12 May 1999 14:21:22 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19990512140659.008d3ad0@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 12 May 1999 14:07:00 -0400 To: hsalama@cisco.com, Jose Costa Requena From: Matt Squire Subject: Re: Evaluation of Gateway Location proposals Cc: iptel@lists.research.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk >I think in call routing, when the connection between LS A and LS B is >disconnected (due to any reason), LS A should immediately delete any >call routes it has previously learned from LS B. As a result, when the >connection between LS A and LS B is restored, both LSs will have to >exchange their entire call routing databases. > If the next hop on a call route received from B is B, then the route should be deleted when B goes away. But in when the next hop is not B, we might consider having LS A keep the route around for "a little while." Haven't really given this enough thought yet, but it might help with transient failures (ie B is just being rebooted and will be up again in two minutes). Just a thought... - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 12 15:21:04 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08844 for ; Wed, 12 May 1999 15:21:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 555AC52B6; Wed, 12 May 1999 15:15:16 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A70E752DD; Wed, 12 May 1999 15:15:15 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990512191438.28127.rocketmail@send205.yahoomail.com> Date: Wed, 12 May 1999 12:14:38 -0700 (PDT) From: Tom Gray Subject: CPL Features To: iptel@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Has anyone considered what would be the practical maximum feature set that could be programmed by a set of CPL scripts? This would be a set of features that could be programmed to interact in a deterministic manner and whose operation would not be a source of confusion to the user. This bears directly on the customer value of the application. Has any thought gone into asking the calling party about his preferences about the disposition of a call by CPL. For example the calling party could be asked if he wishes to camp on to the called party and wait for him to become free or to forward to voice mail. These options could be set up as both acceptable by the terminating party. _________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 12 23:29:41 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14041 for ; Wed, 12 May 1999 23:29:41 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id D5A5852DD; Wed, 12 May 1999 23:23:25 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4E6B052DE; Wed, 12 May 1999 23:23:25 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <373A45AF.A1F4A14D@dnrc.bell-labs.com> Date: Wed, 12 May 1999 23:23:27 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Tom Gray Cc: iptel@lists.research.bell-labs.com Subject: Re: CPL Features References: <19990512191438.28127.rocketmail@send205.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Tom Gray wrote: > > Has any thought gone into asking the calling party about his > preferences about the disposition of a call by CPL. For example the > calling party could be asked if he wishes to camp on to the called > party and wait for him to become free or to forward to voice mail. > These options could be set up as both acceptable by the terminating > party. Yes. See: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-caller-00.txt This draft proposes defining caller preferences to be included in SIP. The draft does not go so far as defining how the CPL might be structured to explicitly take these into account, though. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 13 12:58:47 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06655 for ; Thu, 13 May 1999 12:58:47 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6B69752DB; Thu, 13 May 1999 11:55:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DE60252DF; Thu, 13 May 1999 11:55:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990513155357.29608.rocketmail@web108.yahoomail.com> Date: Thu, 13 May 1999 08:53:57 -0700 (PDT) From: Tom Gray Subject: Re: CPL Features To: iptel@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --- Jonathan Rosenberg wrote: > Tom Gray wrote: > > > > Has any thought gone into asking the calling party > about his > > preferences about the disposition of a call by > CPL. For example the > > calling party could be asked if he wishes to camp > on to the called > > party and wait for him to become free or to > forward to voice mail. > > These options could be set up as both acceptable > by the terminating > > party. > > Yes. See: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-caller-00.txt > > This draft proposes defining caller preferences to > be included in SIP. > The draft does not go so far as defining how the CPL > might be structured > to explicitly take these into account, though. > The draft is very interesting in its possibilities. In my interpretation of it, the caller is able state his preferences for call handling at the called party end of the call. Are there mechanisms for this to be extended so that the user can indicate his preferences on a call by call basis taking into account iformation from the called party. For example, if the called party could indicate that he could accept the call after a brief delay the caller may wish to camp on (ie queue) rather than go to voice mail or he may indicate a preference for an automatic call back when free. This would best be done during call set up rather than requiring a user to identify all possibiities before the call is attempted. _________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 13 16:18:48 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09177 for ; Thu, 13 May 1999 16:18:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 3428552DE; Thu, 13 May 1999 15:05:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9E71E52E0; Thu, 13 May 1999 15:05:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Thu, 13 May 1999 15:04:07 -0400 (EDT) Message-Id: <199905131904.PAA49013@conrail.cs.columbia.edu> From: Jonathan Lennox To: Tom Gray Cc: iptel@lists.research.bell-labs.com Subject: Re: CPL Features In-Reply-To: <19990512191438.28127.rocketmail@send205.yahoomail.com> References: <19990512191438.28127.rocketmail@send205.yahoomail.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk On Wed, May 12 1999, "Tom Gray" wrote to "iptel@lists.research.bell-labs.com" saying: > Has anyone considered what would be the practical maximum feature set > that could be programmed by a set of CPL scripts? This would be a set > of features that could be programmed to interact in a deterministic > manner and whose operation would not be a source of confusion to the > user. This bears directly on the customer value of the application. Since the point of the CPL is to allow features to be assembled out of CPL scripts, I don't think that a "maximum feature set" is really possible; the whole point of the CPL is that it's extensible. The feature interaction problem is discussed somewhat in the CPL requirements I-D. (This has expired from the I-D archive, by now, but it's available off my web page -- ). I'm planning on issuing an updated version of this document soon, so any comments on it are appreciated. > Has any thought gone into asking the calling party about his > preferences about the disposition of a call by CPL. For example the > calling party could be asked if he wishes to camp on to the called > party and wait for him to become free or to forward to voice mail. > These options could be set up as both acceptable by the terminating > party. Jonathan Rosenberg mentioned his caller-preferences draft. There are two places where this interacts with the CPL -- potentially honoring caller preferences in a called-party-side CPL script, and adding caller preferences in a caller-side CPL script. Both of these are issues I want to look at in a future revision of the CPL. -- Jonathan Lennox lennox@cs.columbia.edu --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 13 17:11:11 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09615 for ; Thu, 13 May 1999 17:11:10 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 28E8E52E0; Thu, 13 May 1999 17:05:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9078252E1; Thu, 13 May 1999 17:05:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <638EC1B28663D211AC3E00A0C96B78A801E7852C@orsmsx40.jf.intel.com> From: "Puthenkulam, Jose P" To: iptel@lists.research.bell-labs.com Subject: XML parser Date: Thu, 13 May 1999 14:04:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Does anybody know any web sites where public domain XML parser source code is available. thanks, Jose Puthenkulam Senior Software Engineer, Broadband and IP Telephony Labs, Intel Architecture Labs. Hillsboro, OR 97124 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 13 17:24:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09664 for ; Thu, 13 May 1999 17:24:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 129D952E1; Thu, 13 May 1999 17:19:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6FAB252E2; Thu, 13 May 1999 17:19:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Thu, 13 May 1999 17:15:35 -0400 (EDT) Message-Id: <199905132115.RAA54291@conrail.cs.columbia.edu> From: Jonathan Lennox To: "Puthenkulam, Jose P" Cc: iptel@lists.research.bell-labs.com Subject: Re: XML parser In-Reply-To: <638EC1B28663D211AC3E00A0C96B78A801E7852C@orsmsx40.jf.intel.com> References: <638EC1B28663D211AC3E00A0C96B78A801E7852C@orsmsx40.jf.intel.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk On Thu, May 13 1999, "Jose P. Puthenkulam" wrote to "iptel@lists.research.bell-labs.com" saying: > Does anybody know any web sites where public domain XML parser source code > is available. There are a number of freely-available parsers listed at . If you're programming in C, expat is certainly the one to use. In Java, I used IBM's xml4j to develop the CPL DTD and validate the sample scripts. (I assume the CPL is why you're asking about XML on the IPtel list?) -- Jonathan Lennox lennox@cs.columbia.edu --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 13 17:34:40 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09753 for ; Thu, 13 May 1999 17:34:38 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8C3C552E3; Thu, 13 May 1999 17:29:21 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 025E352E2; Thu, 13 May 1999 17:29:20 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Content-return: allowed Date: Thu, 13 May 1999 21:15:08 +0000 From: "Hoefelmeyer, Ralph" Subject: RE: XML parser To: "'Puthenkulam, Jose P'" , iptel@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01BE9D85.ADDC1348" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE9D85.ADDC1348 Content-Type: text/plain go look at http://tecfa2.unige.ch/guides/xml/pointers.html maybe something there Ralph > -----Original Message----- > From: Puthenkulam, Jose P [SMTP:jose.p.puthenkulam@intel.com] > Sent: Thursday, May 13, 1999 3:04 PM > To: iptel@lists.research.bell-labs.com > Subject: XML parser > > Does anybody know any web sites where public domain XML parser source code > > is available. > > thanks, > Jose Puthenkulam > Senior Software Engineer, > Broadband and IP Telephony Labs, > Intel Architecture Labs. > Hillsboro, OR 97124 > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. ------_=_NextPart_001_01BE9D85.ADDC1348 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: XML parser

go look at
http://tecfa2.unige.ch/guides/xml/pointers.html
maybe something there

Ralph

    -----Original Message-----
    From:   Puthenkulam, Jose P = [SMTP:jose.p.puthenkulam@intel.com]
    Sent:   Thursday, May 13, 1999 3:04 PM
    To:     iptel@lists.research.bell-labs.com
    Subject:       = XML parser

    Does anybody know any web sites = where public domain XML parser source code
    is available.

    thanks,
    Jose Puthenkulam
    Senior Software = Engineer,
    Broadband and IP Telephony = Labs,
    Intel Architecture Labs.
    Hillsboro, OR 97124


    ---------
    This message came from the IETF = IPTEL Working Group Mailing List.

------_=_NextPart_001_01BE9D85.ADDC1348-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 13 17:58:06 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09972 for ; Thu, 13 May 1999 17:58:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0A4AB52DF; Thu, 13 May 1999 17:53:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 79EC052E4; Thu, 13 May 1999 17:53:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990513215155.7031.rocketmail@web107.yahoomail.com> Date: Thu, 13 May 1999 14:51:55 -0700 (PDT) From: Tom Gray Subject: Re: CPL Features To: Jonathan Lennox Cc: iptel@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --- Jonathan Lennox wrote: > On Wed, May 12 1999, "Tom Gray" wrote to > "iptel@lists.research.bell-labs.com" saying: > > > Has anyone considered what would be the practical > maximum feature set ... > > Since the point of the CPL is to allow features to > be assembled out of CPL > scripts, I don't think that a "maximum feature set" > is really possible; the > whole point of the CPL is that it's extensible. The > feature interaction > problem is discussed somewhat in the CPL > requirements I-D. (This has > expired from the I-D archive, by now, but it's > available off my web page -- > ). I'm > planning on issuing an updated > version of this document soon, so any comments on it > are appreciated. > The issue as I see it is the practical maximum extensibility of the system. This would be the number and type of features that could be made to work in a determinsitic manner. This is the feature ineteraction problem and any call control system should be assessed against its ability to handle this problem. This is especially true in a system in which it is intended that the end user will be able to add features at will. I suppose what I am saying is that the feature set which will be enabled or made possible by CPL should be identified. It is not clear to me that some useful features of current systems are possible with the SIP/CPL combination. This may be only the refelction of my lack of familiarity with this system. I have read the specifications for CPL but the connection to SIP and the rationale of how features are created do not seem to be spelled out clearly in these documents. _________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Thu May 13 21:47:48 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12579 for ; Thu, 13 May 1999 21:47:47 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E9F7A52E4; Thu, 13 May 1999 21:42:24 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4A4E552E5; Thu, 13 May 1999 21:42:23 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <373B7F7F.53ECC788@dnrc.bell-labs.com> Date: Thu, 13 May 1999 21:42:23 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Tom Gray Cc: Jonathan Lennox , iptel@lists.research.bell-labs.com Subject: Re: CPL Features References: <19990513215155.7031.rocketmail@web107.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Tom Gray wrote: > > The issue as I see it is the practical maximum extensibility of the > system. This would be the number and type of features that could be > made to work in a determinsitic manner. This is the feature > ineteraction problem and any call control system should be assessed > against its ability to handle this problem. This is especially true in > a system in which it is intended that the end user will be able to add > features at will. I suppose what I am saying is that the feature set > which will be enabled or made possible by CPL should be identified. It > is not clear to me that some useful features of current systems are > possible with the SIP/CPL combination. CPL definitely does not handle certain features - call waiting, for example. In particular, features which require user input after the call is established, or features which require call state, are not possible. In an IP telephony context, many, if not all, of these features are most easily supported in end systems. CPL is best at providing call routing related services; the infinite flavors of forwarding, follow-me, screening, and so on. These are services which require network support, often since the user may not be logged in or otherwise available. I don't think we can enumerate them all. If we could, may as well number them, do away with CPL, and have users select a service by number. But, after all, CPL is a scripting language of sorts, and the point is we can use it to develop new services (at least those supportable within the primitives CPL provides. Its not Turing complete, so everything is not possible). This more restricted scope helps mitigate many feature interaction problems. There are some we know of (the call forward/call screening interaction), and these are documented in the framework. If you know of any other interactions you see, please post them. It would also be helpful if you could point out particular features you feel are useful yet not supported by CPL. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri May 14 13:44:09 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06351 for ; Fri, 14 May 1999 13:44:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 17C6152E0; Fri, 14 May 1999 13:39:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 79E7052E2; Fri, 14 May 1999 13:39:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <19990514174245.25993.rocketmail@web121.yahoomail.com> Date: Fri, 14 May 1999 10:42:45 -0700 (PDT) From: Tom Gray Subject: Re: CPL Features To: Jonathan Rosenberg Cc: Jonathan Lennox , iptel@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --- Jonathan Rosenberg wrote: > > CPL definitely does not handle certain features - > call waiting, for > example. In particular, features which require user > input after the call > is established, or features which require call > state, are not possible. > In an IP telephony context, many, if not all, of > these features are most > easily supported in end systems. CPL is best at > providing call routing > related services; the infinite flavors of > forwarding, follow-me, > screening, and so on. These are services which > require network support, > often since the user may not be logged in or > otherwise available. I > don't think we can enumerate them all. If we could, > may as well number > them, do away with CPL, and have users select a > service by number. But, > after all, CPL is a scripting language of sorts, and > the point is we can > use it to develop new services (at least those > supportable within the > primitives CPL provides. Its not Turing complete, so > everything is not > possible). > > This more restricted scope helps mitigate many > feature interaction > problems. There are some we know of (the call > forward/call screening > interaction), and these are documented in the > framework. If you know of > any other interactions you see, please post them. > > It would also be helpful if you could point out > particular features you > feel are useful yet not supported by CPL. > The CPL documents describe features like Call Forward Busy, Call Forward No Answer and the refusal of anonymous calls. These certainly are features that have meaning only if the user is present. Additionally a useful feature to have is the ability to set an automatic call back on a user who is not registered or present and another is to camp on to a busy line (ie queue till the user becomes free. These are features that would interact with the call forwarding features. The resolution of these interactions is something that a user would like to decide upon during a call with the knowledge that he has at the time. It is not something that he could set up in a preference table. _________________________________________________________ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri May 14 15:41:15 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07266 for ; Fri, 14 May 1999 15:41:15 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5A42E52E1; Fri, 14 May 1999 15:35:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C4ECF52E2; Fri, 14 May 1999 15:35:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <373C7B1C.FCBAE1F5@cisco.com> Date: Fri, 14 May 1999 12:35:56 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Squire Cc: IPTEL IETF Mailing List Subject: Re: Evaluation of Gateway Location proposals References: <3.0.32.19990512134812.008c2920@bl-mail1.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Matt Squire wrote: ...... > > > >BGP does not provide a mechanism to positively Ack UPDATE messages. > >However the NOTIFICATION message is used to provide a negative Ack in > >response to errors in the contents of, or in the processing of, an > >UPDATE message. This may be looked at as a more efficient mechanism for > >reliability than positive Acks. Since transport reliability is already > >guaranteed by TCP, error Notification usually indicates fatal problems > >with the BGP FSM, and therefore is followed by closing the peer > >connection. I can see situations where, in response to an error in > >processing an UPDATE message, it should be sufficient to send an error > >NOTIFICATION and to ignore that UPDATE, but not closing the entire > >connection. But that's the way BGP works. > > > > And if the route process is busy or its queues are full or for some reason > it just can't take the socket upcall from the TCP layer at this time, then > the information is lost. And that is a problem. Hence one has to hack the > TCP stack and the OS to ensure this never happens. > I'd appreciate pointers to specific implementations where the OS and the TCP stack has been hacked. I am not aware of any. Please also check the the NSFNET backbone (phase II) for BGP implementations on standard OSes and TCP stacks. And what about the Gated implementation? > > > >>From discussions with people who implemented IDRP in the past, my > >understanding is that > >it relied on a key for record location, which proved to be "difficult to > >implement with little practical gain." > > > > When the "uniqueness" information in a record is an 4-byte IP address, then > a key is useless. When the uniqueness information is more (ie an IPv6 addr > or an E164 addr), then there is benefit from using a short key. What is so > difficult to implement about a key? > A cache key's benefits will be quite limited, I think. True, it may simplify the search for an older version of the same record received in an Update message. However, a routing/call routing protocol does not just search for older versions of the same record. It also searches for other existing records having the same destination prefix, in order to do route selection amongst them. So a prefix-based search is needed anyways, because this can't be done using the cache key. Hussein > - Matt > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri May 14 16:13:25 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07463 for ; Fri, 14 May 1999 16:13:25 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 493C552E5; Fri, 14 May 1999 16:07:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9E55252E6; Fri, 14 May 1999 16:07:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <373C8235.259942B1@cisco.com> Date: Fri, 14 May 1999 13:06:13 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Squire Cc: Jose Costa Requena , iptel@lists.research.bell-labs.com Subject: Re: Evaluation of Gateway Location proposals References: <3.0.32.19990512140659.008d3ad0@bl-mail1.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Matt Squire wrote: > > >I think in call routing, when the connection between LS A and LS B is > >disconnected (due to any reason), LS A should immediately delete any > >call routes it has previously learned from LS B. As a result, when the > >connection between LS A and LS B is restored, both LSs will have to > >exchange their entire call routing databases. > > > > If the next hop on a call route received from B is B, then the route should > be deleted when B goes away. But in when the next hop is not B, we might > consider having LS A keep the route around for "a little while." Haven't > really given this enough thought yet, but it might help with transient > failures (ie B is just being rebooted and will be up again in two minutes). What if B advertises the addresses of the gateways in its domain as the next hops, not its own address. When B goes away, there will be no way to advertise to other domains updated information about these gateways and the prefixes they can reach (assuming B is the only LS in that domain). This is an issue where we can present good examples for both approaches. I think deleting all call routes learned from B immediately when B is disconnected is the safer approach. We will probably re-learn the routes which are still valied through alternate paths. Hussein > > Just a thought... > > - Matt > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri May 14 16:45:30 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07617 for ; Fri, 14 May 1999 16:45:30 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 51B4152E2; Fri, 14 May 1999 15:51:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A663752E5; Fri, 14 May 1999 15:51:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <373C7EBD.7EBAD168@cisco.com> Date: Fri, 14 May 1999 12:51:25 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Squire Cc: Jose Costa Requena , iptel@lists.research.bell-labs.com Subject: Re: Evaluation of Gateway Location proposals References: <3.0.32.19990512135935.007acb10@bl-mail1.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Matt Squire wrote: > > > > >Assume server A advertises a record X to server B. Then, at some later > >point in time, record X is deleted. Server B won't learn that record X > >has seized to exist until it solicits an update from server A for that > >record? This could be a very slow operation. How frequently should B > >solicit updates from A, in order to minimize the probability of using > >outdated or deleted records? > > > > If X is deleted at A, then A sends an request to B indicating the deletion. > B acknowledges the deletion. The message from A is unsolicited. > > Information is solicited only during link activation and initial > synchronization. Since I am no expert on SCSP, I'll accept your statement. However, the description provided in Appendix B.2.0.2 of the SCSP RFC about the usage of the "N" bit in the CSAS record is quite confusing. The "N" bit is the way to indicate a record deletion. Appendix B.2.0.2 of the SCSP RFC says: "The "N" bit signifies that this CSAS Record is actually a Null record. This bit is only used in a CSAS Record contained in a CSU Request/Reply which is sent in response to a CSUS message. ....." There was no mention of phases. So I assumed the above statement applies to both phases (cache alignment and cache state update), not just to the cache alignment phase. Hussein > > - Matt > > --------- > This message came from the IETF IPTEL Working Group Mailing List. -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat May 15 08:45:43 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26578 for ; Sat, 15 May 1999 08:45:42 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2374F52DF; Sat, 15 May 1999 08:39:20 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 82DD552E6; Sat, 15 May 1999 08:39:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Reply-To: From: "Francois Menard" To: "Puthenkulam, Jose P" Cc: Subject: RE: XML parser Date: Sat, 15 May 1999 08:37:39 -0400 Message-ID: <002901be9ecf$b7d41120$fdd365cc@nyquist.bellglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <638EC1B28663D211AC3E00A0C96B78A801E7852C@orsmsx40.jf.intel.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit That's probably the best one. http://www.alphaworks.ibm.com/tech/xml4c -=Francois=- > -----Original Message----- > From: owner-iptel@lists.research.bell-labs.com > [mailto:owner-iptel@lists.research.bell-labs.com]On Behalf Of > Puthenkulam, Jose P > Sent: May 13, 1999 5:04 PM > To: iptel@lists.research.bell-labs.com > Subject: XML parser > > > Does anybody know any web sites where public domain XML parser > source code > is available. > > thanks, > Jose Puthenkulam > Senior Software Engineer, > Broadband and IP Telephony Labs, > Intel Architecture Labs. > Hillsboro, OR 97124 > > > --------- > This message came from the IETF IPTEL Working Group Mailing List. > --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat May 15 11:04:08 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27240 for ; Sat, 15 May 1999 11:04:08 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 4F3F452E6; Sat, 15 May 1999 10:59:24 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B5C9A52E7; Sat, 15 May 1999 10:59:23 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: Jose Costa Requena Message-Id: <19990515175825jose@tct.hut.fi@default> Date: Sat May 15 17:58:25 1999 Content-Type: text/plain To: hsalama@cisco.com, msquire@nortelnetworks.com Subject: Re: Evaluation of Gateway Location proposals Cc: iptel@lists.research.bell-labs.com X-Mailer: Pronto E-Mail [ver 4.0.2.6] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, > Matt Squire wrote: > > > > >I think in call routing, when the connection between LS A and LS B is > > >disconnected (due to any reason), LS A should immediately delete any > > >call routes it has previously learned from LS B. As a result, when > the > > >connection between LS A and LS B is restored, both LSs will have to > > >exchange their entire call routing databases. > > > > > > > If the next hop on a call route received from B is B, then the route > should > > be deleted when B goes away. But in when the next hop is not B, we > might > > consider having LS A keep the route around for "a little while." > Haven't > > really given this enough thought yet, but it might help with transient > > failures (ie B is just being rebooted and will be up again in two > minutes). > > What if B advertises the addresses of the gateways in its domain as the > next hops, not its own address. When B goes away, there will be no way > to advertise to other domains updated information about these gateways > and the prefixes they can reach (assuming B is the only LS in that > domain). > > This is an issue where we can present good examples for both approaches. > I think deleting all call routes learned from B immediately when B is > disconnected is the safer approach. We will probably re-learn the routes > which are still valied through alternate paths. > > Hussein > There are something that I cannot understand: If the LS B is the unique server in that domain which can advertise about the gateways in its domain as the next hops, then if it goes down there will be no other way to advertise about the gateways of that domain. If I'm right in that supposition we cannot re-learn the routes, that are still valid, but they cannot be advertised through the B LS because actually it is down. I think that it would be wiser if the last updates from the B LS are maintained until they will be updated from other paths, because as Matt wrote it could be either a transient failure of the B LS or maybe the connection to this domain through the B server is going to be replaced with another path or LS which will advertise about the same gateways that was done by the B before. Best Regards. Jose ******************************************************* Jose Costa Requena Research Scientist Helsinki University of Technology Laboratory of Telecommunications Technology Room: SG 227B, Tel: + 358 9 451 2475 email(internet): jose@tct.hut.fi http://keskus.tct.hut.fi/tutkimus/ipana/pers/jose.shtml --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue May 18 00:56:47 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09423 for ; Tue, 18 May 1999 00:56:47 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5FF9B52BB; Tue, 18 May 1999 00:49:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B001452D5; Tue, 18 May 1999 00:49:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Mon, 17 May 1999 23:53:41 -0400 From: Hans Viens Subject: SIP encryption X-Sender: 94298898@hermes.usherb.ca To: iptel@lists.research.bell-labs.com Message-id: <4.2.0.37.19990517234613.00a533f0@hermes.usherb.ca> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Content-type: text/plain; format=flowed; charset=us-ascii Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hi Folk! I have few questions concerning SIP implementation. 1. Is SIP "HAS" to be implement PGP-based to be compatible with other SIP engine ? 2. If SIP has to be PGP-based, am I right to assume the Public-key encryption has been made using RSA algorithm ? 3. Is SIP use symmetric encryption PGP's IDEA algorithm ? It's clear in the RFC that the signature could be make by MD5 or SHA.1 algorithm, but I must admit that I feel confuse about the rest! Somebody could help me ? Hans... --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue May 18 01:15:00 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11006 for ; Tue, 18 May 1999 01:14:57 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6251F52DC; Tue, 18 May 1999 01:06:57 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 81D1252D5; Tue, 18 May 1999 01:06:56 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <3740F56C.59A0BA45@dnrc.bell-labs.com> Date: Tue, 18 May 1999 01:06:52 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: confctrl@isi.edu, vieh01@gel.usherb.ca, list iptel Subject: [Fwd: SIP encryption] Content-Type: multipart/mixed; boundary="------------6611EBEE8E74B37658DF0861" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------6611EBEE8E74B37658DF0861 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This post belongs on confctrl, not iptel. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------------6611EBEE8E74B37658DF0861 Content-Type: message/rfc822 Content-Disposition: inline Received: from chair.dnrc.bell-labs.com (chair [135.180.161.201]) by nova.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA27184; Tue, 18 May 1999 00:52:04 -0400 (EDT) Received: from lists.research.bell-labs.com (paperless [135.180.161.172]) by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id AAA01923; Tue, 18 May 1999 00:52:01 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 5FF9B52BB; Tue, 18 May 1999 00:49:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B001452D5; Tue, 18 May 1999 00:49:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Date: Mon, 17 May 1999 23:53:41 -0400 From: Hans Viens Subject: SIP encryption X-Sender: 94298898@hermes.usherb.ca To: iptel@lists.research.bell-labs.com Message-id: <4.2.0.37.19990517234613.00a533f0@hermes.usherb.ca> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.37 (Beta) Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Type: text/plain; format=flowed; charset=us-ascii Hi Folk! I have few questions concerning SIP implementation. 1. Is SIP "HAS" to be implement PGP-based to be compatible with other SIP engine ? 2. If SIP has to be PGP-based, am I right to assume the Public-key encryption has been made using RSA algorithm ? 3. Is SIP use symmetric encryption PGP's IDEA algorithm ? It's clear in the RFC that the signature could be make by MD5 or SHA.1 algorithm, but I must admit that I feel confuse about the rest! Somebody could help me ? Hans... --------- This message came from the IETF IPTEL Working Group Mailing List. --------------6611EBEE8E74B37658DF0861-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Tue May 18 09:14:24 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29241 for ; Tue, 18 May 1999 09:14:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id DE33152D5; Tue, 18 May 1999 09:09:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 363B552DD; Tue, 18 May 1999 09:09:19 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <3.0.32.19990518090521.008edaa0@bl-mail1.corpeast.baynetworks.com> X-Sender: msquire@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 May 1999 09:05:26 -0400 To: hsalama@cisco.com From: Matt Squire Subject: Re: Evaluation of Gateway Location proposals Cc: IPTEL IETF Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk >> >> And if the route process is busy or its queues are full or for some reason >> it just can't take the socket upcall from the TCP layer at this time, then >> the information is lost. And that is a problem. Hence one has to hack the >> TCP stack and the OS to ensure this never happens. >> > >I'd appreciate pointers to specific implementations where the OS and the >TCP stack has been hacked. I am not aware of any. Please also check the >the NSFNET backbone (phase II) for BGP implementations on standard OSes >and TCP stacks. And what about the Gated implementation? > I'm aware of these implementations. In routers, the routing process is the highest priority process in the box, because you can't forward the packets without the control. But in call routing, GLP may not be the most important thing in the box. Call routing is a different problem. Many devices are going to handle media, call routing (SIP/323), GLP, and more. In this case, existing media connections have to have the highest priority. When resources are tight, existing media streams have to get whats available so that already accepted calls get the quality they need. Other things going on in the device may also have precedence over GLP. When a protocol is not the most important thing going on in a device, things can happen inside the device so that TCP acks something but the information doesn't get processed by its application. Queues fill up, you run out of memory, etc. It happens all of the time. Reliability (timeouts, retries, etc.) is just a good thing to build into a protocol, regardless of its transport. - Matt --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri May 21 13:34:17 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03870 for ; Fri, 21 May 1999 13:34:17 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 1FEBE52BB; Fri, 21 May 1999 13:29:17 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8666152D5; Fri, 21 May 1999 13:29:16 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com To: From: Subject: Hay nuevas fotos en mi pagina!!! Date: Vie, 21 May 1999 10:49:45 Message-Id: <19990521172905.DEC2852BB@lists.research.bell-labs.com> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Hola, Hay nuevas fotos en mi pagina!!! Puedes visitarla en: http://209.3.241.176/ Espero que te gusten!! Diana --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Sat May 22 02:18:32 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26416 for ; Sat, 22 May 1999 02:18:31 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 7E0E052B6; Sat, 22 May 1999 02:13:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D2EF052DB; Sat, 22 May 1999 02:13:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-Id: <199905220609.DAA16054@postino2.prima.com.ar> X-Mailer: Aureate Group Mail Free Edition From: CAMAS REBATIBLES To: Solucionar problemas de espacio Date: Sat, 22 May 1999 03:12:33 -0300 Reply-To: info@camasrebatibles.com.ar MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Priority: 3 X-MIME-Autoconverted: from 8bit to quoted-printable by postino2.prima.com.ar id DAA16054 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA26416 Desde hace mas de veinte años estamos en la industria de las CAMAS REBATIBLES y sus muebles asociados. Conocemos el valor del espacio. Usted sabe, el mayor obstaculo para usar el ambiente para cualquier otra cosa, como una oficina o para hacer ejercicios o para que sus hijos jueguen o para recibir amigos o simplemente para sentirse comodo, es la CAMA. No importa si es de una o dos plazas, cualquier CAMA domina el ambiente y limita la funcionalidad y la decoracion. Podra obtener mayor informacion en nuestro sitio en INTERNET www.camasrebatibles.com.ar Si este mensaje no es de su interes, disculpe la molestia. Si nos envia un e-mail a info@camasrebatibles.com.ar colocando en subject(asunto):borrar, su direccion sera borrada de nuestra base de datos. atte, CAMAS REBATIBLES ---------------------------------------------------------------------- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 26 05:28:26 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19903 for ; Wed, 26 May 1999 05:28:26 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A2D6B52BB; Wed, 26 May 1999 05:21:25 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 08E8F52D5; Wed, 26 May 1999 05:21:24 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com From: tecnosi@datamarkets.com.ar To: iptel@lists.research.bell-labs.com Date: Wed, 26 May 1999 05:20:49 -0400 Message-Id: <199905260919.GAA08693@mercurio.datamarkets.com.ar> Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk To: From: Date: Wed, 26 May 1999 06:20:59 Subject: CURSOS DE INGLES INVIERTA EN CAPACITACION O PAGUE EL COSTO DE LA IGNORANCIA SI NO AHORA, ¿CUANDO? ¿Por que elegirnos para la Capacitación en Inglés? 1. FLEXIBILIDAD: Ajustamos el contenido de los cursos a las Necesidades propias de la Empresa y de su gente, siendo el principal objetivo la Integración del Idioma con la actividad de cada participante. 2. PROFESIONALISMO: Nuestro Equipo Docente esta integrado por Profesores con Título Nacional y Nativos, con amplia Experiencia en Capacitación Empresaria. 3. RESULTADOS: Realizamos Evaluaciones de Nivel antes de comenzar el curso, para determinar la distribución de los alumnos en grupos homogéneos conforme su nivel de idioma. Realizamos Evaluaciones y un Informe Personal Trimestral, lo cual le permite medir los Resultados de la Capacitación. 4. CONVENIENCIA: Dictamos los cursos en su Empresa, en forma individual o grupal, y en el Horario de su Conveniencia. Aconsejamos una frecuencia mínima de 2 clases semanales de una hora y media. 5. ARANCELES: El arancel por hora y por grupo, se calcula según la cantidad de integrantes del mismo, siendo de $ 25.- para un participante, y un adicional de $ 5.- por cada participante que se integre al mismo grupo. Participantes por grupo: 1 2 3 4 Arancel por hora y por grupo: $25 $30 $35 $40 Los precios no incluyen IVA. ESPERAMOS SU LLAMADO AL 15-4975-0797 ENGLISH SKILLS Si este mensaje no es de su interés, disculpe la molestia. --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 26 06:02:53 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20167 for ; Wed, 26 May 1999 06:02:52 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id E473652B6; Wed, 26 May 1999 05:57:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3D9FB52DE; Wed, 26 May 1999 05:57:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <374BC5B4.F3C11BB7@seeyes.co.in> Date: Wed, 26 May 1999 15:28:13 +0530 From: Venkata Narasimha Murthy Nanduri X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Subject: Reg. Real time Transport Protocol Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hai, 1) How can we know whether an RTP packet is encapsulated in the UDP data field? 2) If it is based on the UDP port numbers, then are there any standard UDP port numbers that will be used for RTP? Thanks in Advance Murthy NVN --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Wed May 26 06:25:00 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20281 for ; Wed, 26 May 1999 06:25:00 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 8477152DE; Wed, 26 May 1999 06:19:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D353E52DF; Wed, 26 May 1999 06:19:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com To: Venkata Narasimha Murthy Nanduri Cc: iptel@lists.research.bell-labs.com Subject: Re: Reg. Real time Transport Protocol In-reply-to: Your message of "Wed, 26 May 1999 15:28:13 +0530." <374BC5B4.F3C11BB7@seeyes.co.in> Date: Wed, 26 May 1999 11:17:10 +0100 Message-ID: <798.927713830@cs.ucl.ac.uk> From: Colin Perkins Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk --> Venkata Narasimha Murthy Nanduri writes: >1) How can we know whether an RTP packet is encapsulated in the UDP data >field? The RTP spec contains code to validate a packet, to ensure that it is RTP data. >2) If it is based on the UDP port numbers, then are there any standard >UDP port numbers that will be used for RTP? The ports used for RTP traffic are signalled out of band using your favourite control protocol (SIP, SAP, RTSP, H.whatever, etc...). There are no standard UDP ports for RTP traffic. Colin --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri May 28 03:49:23 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23491 for ; Fri, 28 May 1999 03:49:23 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 23F4A52B6; Fri, 28 May 1999 02:46:46 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 70AF552D5; Fri, 28 May 1999 02:46:45 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <374E3BDE.D06831FE@dnrc.bell-labs.com> Date: Fri, 28 May 1999 02:46:54 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Tom Gray Cc: Jonathan Lennox , iptel@lists.research.bell-labs.com Subject: Re: CPL Features References: <19990514174245.25993.rocketmail@web121.yahoomail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sorry for the very late reply... forgot I didn't respond to this. Tom Gray wrote: > > --- Jonathan Rosenberg wrote: > > > > > CPL definitely does not handle certain features - > > call waiting, for > > example. In particular, features which require user > > input after the call > > is established, or features which require call > > state, are not possible. > > In an IP telephony context, many, if not all, of > > these features are most > > easily supported in end systems. CPL is best at > > providing call routing > > related services; the infinite flavors of > > forwarding, follow-me, > > screening, and so on. These are services which > > require network support, > > often since the user may not be logged in or > > otherwise available. I > > don't think we can enumerate them all. If we could, > > may as well number > > them, do away with CPL, and have users select a > > service by number. But, > > after all, CPL is a scripting language of sorts, and > > the point is we can > > use it to develop new services (at least those > > supportable within the > > primitives CPL provides. Its not Turing complete, so > > everything is not > > possible). > > > > This more restricted scope helps mitigate many > > feature interaction > > problems. There are some we know of (the call > > forward/call screening > > interaction), and these are documented in the > > framework. If you know of > > any other interactions you see, please post them. > > > > It would also be helpful if you could point out > > particular features you > > feel are useful yet not supported by CPL. > > > > The CPL documents describe features like Call Forward Busy, Call > Forward No Answer and the refusal of anonymous calls. These certainly > are features that have meaning only if the user is present. Call forward no answer only takes place when the user is *not* present. > Additionally a useful feature to have is the ability to set an > automatic call back on a user who is not registered or present and > another is to camp on to a busy line (ie queue till the user becomes > free. The first one (callback) is not one I think CPL is good at doing. The problem is that in the callback case, the called party calls back the calling party when available. This is easily done in a user agent (assuming it has access to call logs when it logs in), but harder in a SIP server since the SIP server doesn't usually initiate calls or maintain call state. None of the features we're targeting for CPLv1 require call state or having the server initiate calls, bridge calls, etc. The second service is not something I think that we would do in the first version (it requires call state in the SIP server), but possibly a later one. In that case, the CPL might look something like: and for forwarding: So, if the called party specifies the service ala CPL, there would be no feature interaction between forwarding and camp-on since they CANNOT represent both at the same time in the same place in CPL. Interactions do arise if the called party specifies one of them (say camp-on on busy) and the calling party tries to specify a different one (forward on busy). This is not strictly a CPL issue, since somehow there is here a way for the caller to ask for this feature for this call (the caller preferences document is the general mechanism for this). In that document, we mention that there is this generally hard interaction problem. I don't have an easy answer for how its done, nor do I think there is one right way. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Fri May 28 23:50:09 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06824 for ; Fri, 28 May 1999 23:50:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 62DE652B6; Fri, 28 May 1999 22:41:19 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D2C6C52D5; Fri, 28 May 1999 22:41:18 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <006901bea97c$725a1e20$2a8960d2@QuakeCom.co.kr> From: "YongSung Lee" To: Date: Sat, 29 May 1999 11:39:14 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01BEA9C7.E06BCDA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0066_01BEA9C7.E06BCDA0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_000_0066_01BEA9C7.E06BCDA0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjIwMTQuMjEwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmYmYwPg0KPERJVj4mbmJzcDs8L0RJVj48L0JPRFk+PC9I VE1MPg0K ------=_NextPart_000_0066_01BEA9C7.E06BCDA0-- --------- This message came from the IETF IPTEL Working Group Mailing List. From owner-iptel-outgoing@lists.research.bell-labs.com Mon May 31 19:05:22 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06927 for ; Mon, 31 May 1999 19:05:21 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 6682E52DB; Mon, 31 May 1999 18:59:18 -0400 (EDT) Delivered-To: iptel-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CB49C52DE; Mon, 31 May 1999 18:59:17 -0400 (EDT) Delivered-To: iptel-local@paperless.dnrc.bell-labs.com Message-ID: <37531225.6DD9@iptel.de> Date: Tue, 01 Jun 1999 00:50:13 +0200 From: Pascal Merle Organization: PAM Software GmbH X-Mailer: Mozilla 3.04 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: iptel@lists.research.bell-labs.com Subject: iptel trademark Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-iptel@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi! Did anybody register "iptel" as a trademark for the standards developed by the working group? We are currently having problems with our domain "iptel.de": A company named "tiptel" wants to forbid us the use of "iptel" because they registered the almost similar "tiptel" as a trademark. Thanks for your help, Pascal -- Phone : +49 6131 41537 PAM Software GmbH Fax : +49 6131 466138 Zur Oberlache 5 Mobile : +49 171 7029415 D-55124 Mainz, Germany Video : callto:ils.uni-mainz.de/Pascal.Merle@iptel.de Look at our new Telephony Soundcard at http://www.iptel.de --------- This message came from the IETF IPTEL Working Group Mailing List.