From extest-admin@lists.bell-labs.com Thu Feb 1 06:23:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23555 for ; Thu, 1 Feb 2001 06:23:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 693BE44F34 for ; Thu, 1 Feb 2001 05:08:00 -0500 (EST) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010201100800.693BE44F34@lists.bell-labs.com> Date: Thu, 1 Feb 2001 05:08:00 -0500 (EST) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Tue Feb 6 10:04:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16790 for ; Tue, 6 Feb 2001 10:04:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 553DC4437B; Tue, 6 Feb 2001 09:59:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id 8384C443CB; Tue, 6 Feb 2001 09:52:18 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id JAA10390; Tue, 6 Feb 2001 09:44:13 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569EB.0050F146 ; Tue, 6 Feb 2001 09:44:06 -0500 X-Lotus-FromDomain: TELCORDIA From: "Petros N. Mouchtaris" To: sip@lists.bell-labs.com, megaco@standards.nortelnetworks.com, iptel@lists.bell-labs.com Message-ID: <852569EB.0050F0B6.00@notes949.cc.telcordia.com> Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5" Content-Disposition: inline Subject: [IPTEL] VoIP conference Call for Papers Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 6 Feb 2001 09:43:24 -0500 --0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a call for papers for a VoIP conference. Abstracts are due on February 19. You can check www.spie.org/info/itcom for more details or send me an e-mail if you have any questions. Petros Call for Papers for the Voice over IP (VoIP) Technology Conference Denver, 20-23 August 2001 Part of SPIE's ITComm 2001 - International Symposium and Exhibit on the Convergence of Information Technology and Communication Technologies, 20-24 August 2001, Denver, Colorado. Conference Chair: Petros Mouchtaris, Telcordia Technologies Program Committee: Flemming Andreasen, Cisco Dimitris Kabilafkas, OTE R&D Fuchun (Joe) Lin, Telcordia Technologies Dave McDysan, WorldCom Seshadri Mohan, Comverse Petros Mouchtaris (Chair), Telcordia Technologies Rajesh Talpade, Telcordia Technologies The convergence of information and communication technologies has allowed the use of data networks for offering voice and multimedia services. When Voice over IP (VoIP) was first introduced commercially in the mid-nineties it was marketed as an inexpensive alternative to traditional telephone service. Quality of Service was not a critical issue because users were willing to tolerate low quality because of the low cost of the service. Today, large carriers with a long tradition in offering high quality services are considering deployment of VoIP. Also, VoIP has lost its low cost appeal because prices of traditional telephone services have dropped dramatically. Long term success of VoIP will depend on whether VoIP networks can provide high quality and can be used for offering a wide array of exciting services that cannot be offered by traditional telephone networks. The goal of this conference is to bring together researchers, engineers and users of VoIP technologies, with a focus on how carriers can offer exciting VoIP services that provide high quality of service to users. This conference is part of the ITComm Symposium and Exhibit, which focuses on the convergence of information and communication technologies. The symposium will take place in the beautiful Denver/Boulder area, a fast-moving high technology corridor also called "Silicon Mountain." Authors are invited to submit abstracts in the following and related topics: --0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =B7 VoIP Architectures =B7 Quality of Service =B7 Reliability, Resiliency, and Fault Tolerance =B7 VoIP Services and service APIs =B7 VoIP mobility and integration with wireless networks =B7 Interworking of VoIP with PSTN including Intelligent Networks =B7 Signaling protocols for VoIP =B7 Addressing and numbering approaches for VoIP =B7 VoIP over access technologies (e.g. xDSL, cable) =B7 Deployment experiences and lessons learned Submitted abstracts should be of approximately 250 words. There will b= e a proceedings, published by SPIE, distributed at the conference. Accepte= d papers will be allocated up to 15 pages in the proceedings. = --0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Feb 6 10:10:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17085 for ; Tue, 6 Feb 2001 10:10:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E838443CF; Tue, 6 Feb 2001 09:59:06 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by lists.bell-labs.com (Postfix) with ESMTP id 6368C443CE; Tue, 6 Feb 2001 09:53:41 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with SMTP id JAA02366; Tue, 6 Feb 2001 09:43:07 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569EB.0050D81D ; Tue, 6 Feb 2001 09:43:02 -0500 X-Lotus-FromDomain: TELCORDIA From: "Petros N. Mouchtaris" To: sip@lists.bell-labs.com, megaco@standards.nortelnetworks.com, iptel@lists.bell-labs.com Message-ID: <852569EB.0050D653.00@notes949.cc.telcordia.com> Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=h4V193jFTrUkvmb5kemTQ1gcfPU0GEVUumc05sArdmAZmU5pP0d9oO5x" Content-Disposition: inline Subject: [IPTEL] (no subject) Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 6 Feb 2001 09:42:17 -0500 --0__=h4V193jFTrUkvmb5kemTQ1gcfPU0GEVUumc05sArdmAZmU5pP0d9oO5x Content-type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a call for papers for a VoIP conference. Abstracts are due on February 19. You can check www.spie.org/info/itcom for more details or send me an e-mail if you have any questions. Petros Call for Papers for the Voice over IP (VoIP) Technology Conference Denver, 20-23 August 2001 Part of SPIE's ITComm 2001 - International Symposium and Exhibit on the Convergence of Information Technology and Communication Technologies, 20-24 August 2001, Denver, Colorado. Conference Chair: Petros Mouchtaris, Telcordia Technologies Program Committee: Flemming Andreasen, Cisco Dimitris Kabilafkas, OTE R&D Fuchun (Joe) Lin, Telcordia Technologies Dave McDysan, WorldCom Seshadri Mohan, Comverse Petros Mouchtaris (Chair), Telcordia Technologies Rajesh Talpade, Telcordia Technologies The convergence of information and communication technologies has allowed the use of data networks for offering voice and multimedia services. When Voice over IP (VoIP) was first introduced commercially in the mid-nineties it was marketed as an inexpensive alternative to traditional telephone service. Quality of Service was not a critical issue because users were willing to tolerate low quality because of the low cost of the service. Today, large carriers with a long tradition in offering high quality services are considering deployment of VoIP. Also, VoIP has lost its low cost appeal because prices of traditional telephone services have dropped dramatically. Long term success of VoIP will depend on whether VoIP networks can provide high quality and can be used for offering a wide array of exciting services that cannot be offered by traditional telephone networks. The goal of this conference is to bring together researchers, engineers and users of VoIP technologies, with a focus on how carriers can offer exciting VoIP services that provide high quality of service to users. This conference is part of the ITComm Symposium and Exhibit, which focuses on the convergence of information and communication technologies. The symposium will take place in the beautiful Denver/Boulder area, a fast-moving high technology corridor also called "Silicon Mountain." Authors are invited to submit abstracts in the following and related topics: --0__=h4V193jFTrUkvmb5kemTQ1gcfPU0GEVUumc05sArdmAZmU5pP0d9oO5x Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =B7 VoIP Architectures =B7 Quality of Service =B7 Reliability, Resiliency, and Fault Tolerance =B7 VoIP Services and service APIs =B7 VoIP mobility and integration with wireless networks =B7 Interworking of VoIP with PSTN including Intelligent Networks =B7 Signaling protocols for VoIP =B7 Addressing and numbering approaches for VoIP =B7 VoIP over access technologies (e.g. xDSL, cable) =B7 Deployment experiences and lessons learned Submitted abstracts should be of approximately 250 words. There will b= e a proceedings, published by SPIE, distributed at the conference. Accepte= d papers will be allocated up to 15 pages in the proceedings. = --0__=h4V193jFTrUkvmb5kemTQ1gcfPU0GEVUumc05sArdmAZmU5pP0d9oO5x-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 7 18:30:04 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12292 for ; Wed, 7 Feb 2001 18:30:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34BFA44346; Wed, 7 Feb 2001 18:30:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id 8AE7D44336 for ; Wed, 7 Feb 2001 18:29:28 -0500 (EST) Received: from limingpc (LIMING_PC [192.168.1.120]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CF8WC9CX; Wed, 7 Feb 2001 18:29:59 -0500 From: "Liming Sun" To: Cc: "Dusan Mudric" , "Liming Sun" , "Jianping Jiang" , "Jianli Wang" , "Andre Moskal" , "Anna Cheung" , "Dave Walker" Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [IPTEL] circuitCapacity vs DSPcapacity attributes Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 7 Feb 2001 18:34:48 -0500 Content-Transfer-Encoding: 7bit Good day, all. I'd like to share with you my preliminary understanding of CircuitCapacity and DSPcapacity attributes as defined in Usage of TRIP in Gateways for Exporting Phone Routes (draft-rs-trip-gw-01.txt; dated July 14, 2000; authors:Jonathan Rosenberg at dynamicsoft and Hussein F.Salama at Cisco Systems). It appears that the maximum circuit capacity of a gateway for all telephone routes, which terminate through it, is equivalent to its DSP capacity; as there is a one-to-one relationship between the two. The reason is that the maximum number of circuits that a gateway can handle is proportional to its processor capacity. The higher the processor power, the larger the circuit capacity. For instance, a gateway may handle twice as many circuits as another gateway which has processor power only half of the former. In other words, the DSPcapacity is (or should be) reflected in the circuit capacity. Consider a scenario where a gateway has used up its circuits for a given telephone route (e.g., 613592 prefix) because of, say, channel resource limitation, but it still has processor resources available. A TRIP location server cannot, in this case, send new 613592 calls to that gateway as the latter has reached its circuit limit for that route, even though it may still have enough processor resources to place additional calls. Thus, it appears that a TRIP LS can rely on the circuit capacity of a gateway, but not its DSP capacity, to perform load balancing among different gateways. I appreciate, and thank you for, your comments on this topic. Liming Sun liming@ss8.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 7 19:21:05 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12815 for ; Wed, 7 Feb 2001 19:21:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A1A144354; Wed, 7 Feb 2001 19:21:01 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 0A66544336 for ; Wed, 7 Feb 2001 19:20:24 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 7 Feb 2001 17:07:30 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3HDJP>; Wed, 7 Feb 2001 17:01:29 -0500 Message-ID: From: "Jeff Hinchey" To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09151.85D60C70" X-Orig: Subject: [IPTEL] TRIP question on routing numbers Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 7 Feb 2001 17:01:29 -0500 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_01C09151.85D60C70 Content-Type: text/plain; charset="iso-8859-1" I was reviewing the latest version of the TRIP draft and was a little confused over a statement in section 5.1.1.2, second paragraph, which reads: "The type of Decimal Routing Number (private, local, national, or international) can be deduced from the first few digits of the prefix" How is this accomplished? Telephone numbers only have meaning within the context of a specific number plan. E.164 public numbers and numbers from private number plans can begin with the same digits. Also, there is no way to determine if a public number is local, national or international based on leading digits. There is no reliable way to determine what number plan a number belongs to from only the number itself. Is the intent to include dial plan prefixes in addition to numbering plan addressing information in the routing numbers specified in the TRIP route? If so, how will this work when TRIP information is disseminated between ITADs serving different regions with different dial plans? Jeff Hinchey Succession Network Architecture Nortel Networks 613 763 8007 / 613 765 4881 (fax) 3500 Carling Ave. jhinchey@nortelnetworks.com Nepean, Canada K2H 8E9 ------_=_NextPart_001_01C09151.85D60C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TRIP question on routing numbers

I was reviewing the latest = version of the TRIP draft and was a little confused over a statement in = section 5.1.1.2, second paragraph, which reads:

    "The type of Decimal = Routing Number (private, local, national, or international) can be = deduced from the first few digits of the prefix"

How is this accomplished? = Telephone numbers only have meaning within the context of a specific = number plan. E.164 public numbers and numbers from private number plans = can begin with the same digits. Also, there is no way to determine if a = public number is local, national or international based on leading = digits. There is no reliable way to determine what number plan a number = belongs to from only the number itself.

Is the intent to include dial = plan prefixes in addition to numbering plan addressing information in = the routing numbers specified in the TRIP route? If so, how will this = work when TRIP information is disseminated between ITADs serving = different regions with different dial plans?

Jeff Hinchey
Succession Network = Architecture          =             =      Nortel Networks
613 763 8007 / 613 765 4881 = (fax)           &= nbsp;           3500 = Carling Ave.
jhinchey@nortelnetworks.com     = ;            = ;            = ;  Nepean, Canada  K2H 8E9


------_=_NextPart_001_01C09151.85D60C70-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 7 22:37:04 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16818 for ; Wed, 7 Feb 2001 22:37:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CB4B443ED; Wed, 7 Feb 2001 22:37:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id AEFFC44336 for ; Wed, 7 Feb 2001 22:36:03 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id TAA10870; Wed, 7 Feb 2001 19:36:05 -0800 (PST) Received: from cisco.com (dhcp-128-107-142-74.cisco.com [128.107.142.74]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFY00063 (AUTH hsalama); Wed, 7 Feb 2001 19:36:00 -0800 (PST) Message-ID: <3A821480.C1B7A687@cisco.com> From: "Hussein F. Salama" Reply-To: hsalama@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Jeff Hinchey Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] TRIP question on routing numbers References: Content-Type: multipart/alternative; boundary="------------72999A33CFC075664FD3E02B" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 07 Feb 2001 19:37:36 -0800 --------------72999A33CFC075664FD3E02B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff Hinchey wrote: > > > I was reviewing the latest version of the TRIP draft and was a little > confused over a statement in section 5.1.1.2, second paragraph, which > reads: > > "The type of Decimal Routing Number (private, local, national, or > international) can be deduced from the first few digits of the > prefix" > > How is this accomplished? Telephone numbers only have meaning within > the context of a specific number plan. E.164 public numbers and > numbers from private number plans can begin with the same digits. > Also, there is no way to determine if a public number is local, > national or international based on leading digits. There is no > reliable way to determine what number plan a number belongs to from > only the number itself. > > Is the intent to include dial plan prefixes in addition to numbering > plan addressing information in the routing numbers specified in the > TRIP route? Yes, otherwise how can an LS differentiate between a local prefix, a national prefix, and international prefix? > If so, how will this work when TRIP information is disseminated > between ITADs serving different regions with different dial plans? A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by prependinng/stripping off digits as necessary. Hussein > > > Jeff Hinchey > Succession Network Architecture Nortel > Networks > 613 763 8007 / 613 765 4881 (fax) 3500 Carling > Ave. > jhinchey@nortelnetworks.com Nepean, > Canada K2H 8E9 > -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 --------------72999A33CFC075664FD3E02B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Jeff Hinchey wrote:

 

I was reviewing the latest version of the TRIP draft and was a little confused over a statement in section 5.1.1.2, second paragraph, which reads:

    "The type of Decimal Routing Number (private, local, national, or international) can be deduced from the first few digits of the prefix"
How is this accomplished? Telephone numbers only have meaning within the context of a specific number plan. E.164 public numbers and numbers from private number plans can begin with the same digits. Also, there is no way to determine if a public number is local, national or international based on leading digits. There is no reliable way to determine what number plan a number belongs to from only the number itself.

Is the intent to include dial plan prefixes in addition to numbering plan addressing information in the routing numbers specified in the TRIP route?

Yes, otherwise how can an LS differentiate between a local prefix, a national prefix, and international prefix?
If so, how will this work when TRIP information is disseminated between ITADs serving different regions with different dial plans?
A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by prependinng/stripping off digits as necessary.

Hussein
 
 

 

Jeff Hinchey
Succession Network Architecture                           Nortel Networks
613 763 8007 / 613 765 4881 (fax)                       3500 Carling Ave.
jhinchey@nortelnetworks.com                               Nepean, Canada  K2H 8E9
 

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147
  --------------72999A33CFC075664FD3E02B-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Feb 8 02:54:04 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02472 for ; Thu, 8 Feb 2001 02:54:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 087A5443FB; Thu, 8 Feb 2001 02:54:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50]) by lists.bell-labs.com (Postfix) with ESMTP id C6CEE44336 for ; Thu, 8 Feb 2001 02:53:22 -0500 (EST) Received: by EMAIL5 with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 08:53:04 +0100 Message-ID: <337FC70FD51CD411A3500008C70D56F13384C9@IS~EMAIL1> From: Scott Cadzow To: "'Jeff Hinchey'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] TRIP question on routing numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091A4.3064CB70" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 8 Feb 2001 08:53:13 +0100 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_01C091A4.3064CB70 Content-Type: text/plain; charset="iso-8859-1" Is there a confusion between routing number and subscriber (or dialled) number? Conventionally telephone users do not enter a routing number (in real terms an address in numeric form). The dialling plan may however imply certain routing restrictions/rules based upon the dialled number. Scott Cadzow, ETSI -----Original Message----- From: Jeff Hinchey [mailto:jhinchey@nortelnetworks.com] Sent: 07 February 2001 11:01 PM To: 'iptel@lists.bell-labs.com' Subject: [IPTEL] TRIP question on routing numbers I was reviewing the latest version of the TRIP draft and was a little confused over a statement in section 5.1.1.2, second paragraph, which reads: "The type of Decimal Routing Number (private, local, national, or international) can be deduced from the first few digits of the prefix" How is this accomplished? Telephone numbers only have meaning within the context of a specific number plan. E.164 public numbers and numbers from private number plans can begin with the same digits. Also, there is no way to determine if a public number is local, national or international based on leading digits. There is no reliable way to determine what number plan a number belongs to from only the number itself. Is the intent to include dial plan prefixes in addition to numbering plan addressing information in the routing numbers specified in the TRIP route? If so, how will this work when TRIP information is disseminated between ITADs serving different regions with different dial plans? Jeff Hinchey Succession Network Architecture Nortel Networks 613 763 8007 / 613 765 4881 (fax) 3500 Carling Ave. jhinchey@nortelnetworks.com Nepean, Canada K2H 8E9 ------_=_NextPart_001_01C091A4.3064CB70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TRIP question on routing numbers

Is=20 there a confusion between routing number and subscriber (or dialled) = number?=20 Conventionally telephone users do not enter a routing number (in = real terms=20 an address in numeric form). The dialling plan may however imply = certain routing=20 restrictions/rules based upon the dialled number.
 
Scott=20 Cadzow, ETSI
-----Original Message-----
From: Jeff Hinchey=20 [mailto:jhinchey@nortelnetworks.com]
Sent: 07 February 2001 = 11:01=20 PM
To: 'iptel@lists.bell-labs.com'
Subject: = [IPTEL] TRIP=20 question on routing numbers

I was reviewing the latest = version of the=20 TRIP draft and was a little confused over a statement in section = 5.1.1.2,=20 second paragraph, which reads:

    "The type of Decimal Routing = Number=20 (private, local, national, or international) can be deduced from = the first=20 few digits of the prefix"

How is this accomplished? = Telephone numbers=20 only have meaning within the context of a specific number plan. E.164 = public=20 numbers and numbers from private number plans can begin with the same = digits.=20 Also, there is no way to determine if a public number is local, = national or=20 international based on leading digits. There is no reliable way to = determine=20 what number plan a number belongs to from only the number itself. =

Is the intent to include dial = plan prefixes=20 in addition to numbering plan addressing information in the routing = numbers=20 specified in the TRIP route? If so, how will this work when TRIP = information=20 is disseminated between ITADs serving different regions with = different dial=20 plans?

Jeff Hinchey
Succession Network=20 = Architecture          =             =     =20 Nortel Networks
613 763 8007 = / 613 765=20 4881=20 = (fax)           &= nbsp;          =20 3500 Carling Ave.
jhinchey@nortelnetworks.com      =             =             = =20 Nepean, Canada  K2H 8E9 =


------_=_NextPart_001_01C091A4.3064CB70-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Feb 8 17:37:04 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21006 for ; Thu, 8 Feb 2001 17:37:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 860C14433D; Thu, 8 Feb 2001 17:37:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from service1.integratelecom.com (unknown [206.163.82.100]) by lists.bell-labs.com (Postfix) with ESMTP id C11B644336 for ; Thu, 8 Feb 2001 17:36:36 -0500 (EST) Received: from beaexch1.integratelecom.com (fw-1-bvtn.integratelecom.com [206.163.82.5]) by service1.integratelecom.com (8.9.3/8.9.3) with ESMTP id OAA21572; Thu, 8 Feb 2001 14:31:54 -0800 Received: by beaexch1.integratelecom.com with Internet Mail Service (5.5.2650.21) id <1F83YHPQ>; Thu, 8 Feb 2001 14:31:24 -0800 Message-ID: From: "Anderson, Darby" To: "'Scott Cadzow'" , "'Jeff Hinchey'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] TRIP question on routing numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0921E.DE78D001" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 8 Feb 2001 14:31:24 -0800 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_01C0921E.DE78D001 Content-Type: text/plain; charset="iso-8859-1" I know this is kinda off the beaten path of what the current conversation is,but still quazi-related... Is there/Will there be any convention of a ITAD Regestration dirrectory, and if so,where/how will someone be able to view it, and also InLieu of TRIP not yet being a finialized protocol,is there anything similar to a VoIP Gateway Service Provider Dirrectory out there CURRENTLY? -----Original Message----- From: Scott Cadzow [mailto:Scott.Cadzow@etsi.fr] Sent: Thursday, February 08, 2001 12:53 AM To: 'Jeff Hinchey'; 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] TRIP question on routing numbers Is there a confusion between routing number and subscriber (or dialled) number? Conventionally telephone users do not enter a routing number (in real terms an address in numeric form). The dialling plan may however imply certain routing restrictions/rules based upon the dialled number. Scott Cadzow, ETSI -----Original Message----- From: Jeff Hinchey [mailto:jhinchey@nortelnetworks.com] Sent: 07 February 2001 11:01 PM To: 'iptel@lists.bell-labs.com' Subject: [IPTEL] TRIP question on routing numbers I was reviewing the latest version of the TRIP draft and was a little confused over a statement in section 5.1.1.2, second paragraph, which reads: "The type of Decimal Routing Number (private, local, national, or international) can be deduced from the first few digits of the prefix" How is this accomplished? Telephone numbers only have meaning within the context of a specific number plan. E.164 public numbers and numbers from private number plans can begin with the same digits. Also, there is no way to determine if a public number is local, national or international based on leading digits. There is no reliable way to determine what number plan a number belongs to from only the number itself. Is the intent to include dial plan prefixes in addition to numbering plan addressing information in the routing numbers specified in the TRIP route? If so, how will this work when TRIP information is disseminated between ITADs serving different regions with different dial plans? Jeff Hinchey Succession Network Architecture Nortel Networks 613 763 8007 / 613 765 4881 (fax) 3500 Carling Ave. jhinchey@nortelnetworks.com Nepean, Canada K2H 8E9 ------_=_NextPart_001_01C0921E.DE78D001 Content-Type: text/html; charset="iso-8859-1" TRIP question on routing numbers
I know this is kinda off the beaten path of what the current conversation is,but still quazi-related...
 
Is there/Will there be any convention of a ITAD Regestration dirrectory, and if so,where/how will someone be able to view it, and also InLieu of TRIP not yet being a finialized protocol,is there anything similar to a VoIP Gateway Service Provider Dirrectory out there CURRENTLY?
-----Original Message-----
From: Scott Cadzow [mailto:Scott.Cadzow@etsi.fr]
Sent: Thursday, February 08, 2001 12:53 AM
To: 'Jeff Hinchey'; 'iptel@lists.bell-labs.com'
Subject: RE: [IPTEL] TRIP question on routing numbers

Is there a confusion between routing number and subscriber (or dialled) number? Conventionally telephone users do not enter a routing number (in real terms an address in numeric form). The dialling plan may however imply certain routing restrictions/rules based upon the dialled number.
 
Scott Cadzow, ETSI
-----Original Message-----
From: Jeff Hinchey [mailto:jhinchey@nortelnetworks.com]
Sent: 07 February 2001 11:01 PM
To: 'iptel@lists.bell-labs.com'
Subject: [IPTEL] TRIP question on routing numbers

I was reviewing the latest version of the TRIP draft and was a little confused over a statement in section 5.1.1.2, second paragraph, which reads:

    "The type of Decimal Routing Number (private, local, national, or international) can be deduced from the first few digits of the prefix"

How is this accomplished? Telephone numbers only have meaning within the context of a specific number plan. E.164 public numbers and numbers from private number plans can begin with the same digits. Also, there is no way to determine if a public number is local, national or international based on leading digits. There is no reliable way to determine what number plan a number belongs to from only the number itself.

Is the intent to include dial plan prefixes in addition to numbering plan addressing information in the routing numbers specified in the TRIP route? If so, how will this work when TRIP information is disseminated between ITADs serving different regions with different dial plans?

Jeff Hinchey
Succession Network Architecture                           Nortel Networks
613 763 8007 / 613 765 4881 (fax)                       3500 Carling Ave.
jhinchey@nortelnetworks.com                               Nepean, Canada  K2H 8E9


------_=_NextPart_001_01C0921E.DE78D001-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Feb 9 02:20:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11950 for ; Fri, 9 Feb 2001 02:20:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9029444353; Fri, 9 Feb 2001 02:20:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 452D644336 for ; Fri, 9 Feb 2001 02:19:53 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA16082; Thu, 8 Feb 2001 23:20:09 -0800 (PST) Received: from cisco.com ([10.19.104.244]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFZ06072 (AUTH hsalama); Thu, 8 Feb 2001 23:19:31 -0800 (PST) Message-ID: <3A839A62.BF41834F@cisco.com> From: "Hussein F. Salama" Reply-To: hsalama@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Philip Mart Cc: Jeff Hinchey , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] TRIP question on routing numbers References: <802569ED.004657BB.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 08 Feb 2001 23:21:07 -0800 Content-Transfer-Encoding: 7bit Philip Mart wrote: > Hussein, > > If prefixes are to be included where are they specified so that implementations > may interoperate? Not in TRIP. TRIP's specification of the address families is loose, on purpose, to maximize the utility of the protocol with different number plans. > I guess I should also ask why a "Nature of Address" field > wasn't included instead of the unspecified prefixes? We, TRIP's authors, had a long discussion about the NoA field a few months ago. At the end, we decided , we don't need an NoA field, because when an administrator places an LS in a certain domain, it will definitely know the meaning of the prefixes used in that domain. So the NoA can be inferred from the prefix. This is identical to the case with IP routing. A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by prependinng/stripping off digits as necessary before forwarding an UPDATE to its inter-domain peer in order to accommodate the prefix conventions in that peer's ITAD. Hussein > This would have the > advantage of not mandating a particular national, local or even hypothetical > dialling plan which may in any case conflict with interconnect arrangements. > > Phil Mart > > "Hussein F. Salama" on 08/02/2001 03:37:36 > > Please respond to hsalama@cisco.com > > > > > > > > To: Jeff Hinchey > > cc: "'iptel@lists.bell-labs.com'" > (bcc: Philip > Mart/MAIN/MC1) > > > > Subject: Re: [IPTEL] TRIP question on routing numbers > > > Jeff Hinchey wrote: > > > > > > > I was reviewing the latest version of the TRIP draft and was a little > > confused over a statement in section 5.1.1.2, second paragraph, which > > reads: > > > > "The type of Decimal Routing Number (private, local, national, or > > international) can be deduced from the first few digits of the > > prefix" > > > > How is this accomplished? Telephone numbers only have meaning within > > the context of a specific number plan. E.164 public numbers and > > numbers from private number plans can begin with the same digits. > > Also, there is no way to determine if a public number is local, > > national or international based on leading digits. There is no > > reliable way to determine what number plan a number belongs to from > > only the number itself. > > > > Is the intent to include dial plan prefixes in addition to numbering > > plan addressing information in the routing numbers specified in the > > TRIP route? > > Yes, otherwise how can an LS differentiate between a local prefix, a > national prefix, and international prefix? > > > If so, how will this work when TRIP information is disseminated > > between ITADs serving different regions with different dial plans? > > A TRIP LS located at the egress from an ITAD may have to manipulate the > prefix by prependinng/stripping off digits as necessary. > > Hussein > > > > > > > Jeff Hinchey > > Succession Network Architecture Nortel > > Networks > > 613 763 8007 / 613 765 4881 (fax) 3500 Carling > > Ave. > > jhinchey@nortelnetworks.com Nepean, > > Canada K2H 8E9 > > > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Feb 12 16:04:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21511 for ; Mon, 12 Feb 2001 16:04:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52E7F44338; Mon, 12 Feb 2001 16:04:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 4CE0744337 for ; Mon, 12 Feb 2001 16:03:30 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 12 Feb 2001 15:57:12 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3JNZ6>; Mon, 12 Feb 2001 15:36:56 -0500 Message-ID: From: "Jeff Hinchey" To: hsalama@cisco.com Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] TRIP question on routing numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09533.88928BB0" X-Orig: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 12 Feb 2001 15:36:53 -0500 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_01C09533.88928BB0 Content-Type: text/plain; charset="iso-8859-1" Hussein, I'm trying to envision how the exchange of TRIP routing numbers will be managed given they include dial plan prefixes. I see this being very complex and error prone. You suggest that an LS can manipulate the prefixes used with the routing numbers forwarded in UPDATE messages into a format understandable by peer LSs. This implies that for ITADs which serve multiple regions with differing dial plans and ITADs with peering relationships with other ITADs serving regions with differing dial plans, UPDATEs between peers will need to be manipulated potentially on a per peer basis. Routing numbers in UPDATEs must be formatted according to the LS to which they are being sent. - How are these LS-LS prefix mapping relationships established, how are they kept in sync? I understand this is outside the scope of TRIP, but will necessary in order for TRIP to be useful. If too complex to manage, TRIP loses its utility. - How is route selection performed? Again, outside the scope of TRIP but directly impacted by the way route information is communicated in TRIP. For example, a route may be selected in ITAD A based on matching routing number information with dial plan prefix X that directs call signaling to a NextHopServer in ITAD B. The ITAD B server then queries its own LS to determine its preferred route and the next NextHopServer. Given ITAD B uses different prefixes than ITAD A, the called number information in the call signaling will need to be manipulated into ITAD B's routing number prefix format in order to correctly query ITAD B's LS. - If the same route can be represented with different routing number information (different prefixes) in different ITADs/LSs, how is route aggregation performed? What is the impact to flooding within an ITAD and routing loop detection? - This approach implies that a single LS can only represent routes from a single region delimited by dial plan. There may be instances where a single LS could serve many regions if not for this restriction. I suggest it would be much simpler if TRIP routing numbers where based on numbering plans (endpoint address/alias, fixed, independent of regional dial plan) rather than dialing plans (method by which the numbering plan is used, varies from region to region). Within the context of a given number plan, each number/address/alias is unique. Routing numbers and associated number plan can be passed around in UPDATEs and used independent of regional dial plan without the need to manipulate prefix digits. The existing E.164 standard provides for fully qualified numbers which are globally unique within the public numbering plan. Although there are no specific standards, the same concept applies to private number plans. The combination of a numbering plan identifier and fully qualified number can be used to uniquely identify an endpoint (and number ranges used to identify routes to endpoints) independent of region and dial plan. Public routing numbers expressed in and identified as E.164 format can be exchanged within and between ITADs without requiring any conversion/manipulation of numbers between LSs. Within an ITAD, private numbering plan identifiers (VPNs) can be easily standardized to accomplish the same. I can't think of a scenario requiring private routing numbers to be exchanged between ITADs as all ITADs except for the ITAD serving the VPN would route calls based on an E.164 number associated with the private network. If a private network was served by multiple ITADs, then a private numbering plan identifier would need to be agreed upon between the ITADs. With this approach, the responsibility for understanding dial plans is pushed to the access devices and/or associated call servers which already have this knowledge in order to parse end user input to determine call intent. Using this knowledge, the originating access device/call server can interpret dialed digits in the context of the appropriate regional dial plan to extract called number information and create a fully qualified number. The fully qualified number and its numbering plan identifier can then be used to query an LS for routing information. This approach removes the need for TRIP implementations and administrators to deal with dialing plans and as such regional variations in dialing plan formats/prefix digits. Feedback welcome. -----Original Message----- From: Hussein F. Salama [mailto:hsalama@cisco.com] Sent: February 9, 2001 2:21 AM To: Philip Mart Cc: Hinchey, Jeff [CAR:VS00-M:EXCH]; 'iptel@lists.bell-labs.com' Subject: Re: [IPTEL] TRIP question on routing numbers Philip Mart wrote: > Hussein, > > If prefixes are to be included where are they specified so that implementations > may interoperate? Not in TRIP. TRIP's specification of the address families is loose, on purpose, to maximize the utility of the protocol with different number plans. > I guess I should also ask why a "Nature of Address" field > wasn't included instead of the unspecified prefixes? We, TRIP's authors, had a long discussion about the NoA field a few months ago. At the end, we decided , we don't need an NoA field, because when an administrator places an LS in a certain domain, it will definitely know the meaning of the prefixes used in that domain. So the NoA can be inferred from the prefix. This is identical to the case with IP routing. A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by prependinng/stripping off digits as necessary before forwarding an UPDATE to its inter-domain peer in order to accommodate the prefix conventions in that peer's ITAD. Hussein > This would have the > advantage of not mandating a particular national, local or even hypothetical > dialling plan which may in any case conflict with interconnect arrangements. > > Phil Mart > > "Hussein F. Salama" on 08/02/2001 03:37:36 > > Please respond to hsalama@cisco.com > > > > > > > > To: Jeff Hinchey > > cc: "'iptel@lists.bell-labs.com'" > (bcc: Philip > Mart/MAIN/MC1) > > > > Subject: Re: [IPTEL] TRIP question on routing numbers > > > Jeff Hinchey wrote: > > > > > > > I was reviewing the latest version of the TRIP draft and was a little > > confused over a statement in section 5.1.1.2, second paragraph, which > > reads: > > > > "The type of Decimal Routing Number (private, local, national, or > > international) can be deduced from the first few digits of the > > prefix" > > > > How is this accomplished? Telephone numbers only have meaning within > > the context of a specific number plan. E.164 public numbers and > > numbers from private number plans can begin with the same digits. > > Also, there is no way to determine if a public number is local, > > national or international based on leading digits. There is no > > reliable way to determine what number plan a number belongs to from > > only the number itself. > > > > Is the intent to include dial plan prefixes in addition to numbering > > plan addressing information in the routing numbers specified in the > > TRIP route? > > Yes, otherwise how can an LS differentiate between a local prefix, a > national prefix, and international prefix? > > > If so, how will this work when TRIP information is disseminated > > between ITADs serving different regions with different dial plans? > > A TRIP LS located at the egress from an ITAD may have to manipulate the > prefix by prependinng/stripping off digits as necessary. > > Hussein > > > > > > > Jeff Hinchey > > Succession Network Architecture Nortel > > Networks > > 613 763 8007 / 613 765 4881 (fax) 3500 Carling > > Ave. > > jhinchey@nortelnetworks.com Nepean, > > Canada K2H 8E9 > > > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel ------_=_NextPart_001_01C09533.88928BB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IPTEL] TRIP question on routing numbers

Hussein,

I'm trying to envision how the exchange of TRIP = routing numbers will be managed given they include dial plan prefixes. = I see this being very complex and error prone.

You suggest that an LS can manipulate the prefixes = used with the routing numbers forwarded in UPDATE messages into a = format understandable by peer LSs. This implies that for ITADs which = serve multiple regions with differing dial plans and ITADs with peering = relationships with other ITADs serving regions with differing dial = plans, UPDATEs between peers will need to be manipulated potentially on = a per peer basis. Routing numbers in UPDATEs must be formatted = according to the LS to which they are being sent.

- How are these LS-LS prefix mapping relationships = established, how are they kept in sync? I understand this is outside = the scope of TRIP, but will necessary in order for TRIP to be useful. = If too complex to manage, TRIP loses its utility.

- How is route selection performed? Again, outside = the scope of TRIP but directly impacted by the way route information is = communicated in TRIP. For example, a route may be selected in ITAD A = based on matching routing number information with dial plan prefix X = that directs call signaling to a NextHopServer in ITAD B. The ITAD B = server then queries its own LS to determine its preferred route and the = next NextHopServer. Given ITAD B uses different prefixes than ITAD A, = the called number information in the call signaling will need to be = manipulated into ITAD B's routing number prefix format in order to = correctly query ITAD B's LS.

- If the same route can be represented with different = routing number information (different prefixes) in different ITADs/LSs, = how is route aggregation performed? What is the impact to flooding = within an ITAD and routing loop detection?

- This approach implies that a single LS can only = represent routes from a single region delimited by dial plan. There may = be instances where a single LS could serve many regions if not for this = restriction.

 

I suggest it would be much simpler if TRIP routing = numbers where based on numbering plans (endpoint address/alias, fixed, = independent of regional dial plan) rather than dialing plans (method by = which the numbering plan is used, varies from region to region). Within = the context of a given number plan, each number/address/alias is = unique. Routing numbers and associated number plan can be passed around = in UPDATEs and used independent of regional dial plan without the need = to manipulate prefix digits.

The existing E.164 standard provides for fully = qualified numbers which are globally unique within the public numbering = plan. Although there are no specific standards, the same concept = applies to private number plans. The combination of a numbering plan = identifier and fully qualified number can be used to uniquely identify = an endpoint (and number ranges used to identify routes to endpoints) = independent of region and dial plan.

Public routing numbers expressed in and identified as = E.164 format can be exchanged within and between ITADs without = requiring any conversion/manipulation of numbers between LSs. Within an = ITAD, private numbering plan identifiers (VPNs) can be easily = standardized to accomplish the same. I can't think of a scenario = requiring private routing numbers to be exchanged between ITADs as all = ITADs except for the ITAD serving the VPN would route calls based on an = E.164 number associated with the private network. If a private network = was served by multiple ITADs, then a private numbering plan identifier = would need to be agreed upon between the ITADs.

With this approach, the responsibility for = understanding dial plans is pushed to the access devices and/or = associated call servers which already have this knowledge in order to = parse end user input to determine call intent. Using this knowledge, = the originating access device/call server can interpret dialed digits = in the context of the appropriate regional dial plan to extract called = number information and create a fully qualified number. The fully = qualified number and its numbering plan identifier can then be used to = query an LS for routing information. This approach removes the need for = TRIP implementations and administrators to deal with dialing plans and = as such regional variations in dialing plan formats/prefix = digits.


Feedback welcome.


-----Original Message-----
From: Hussein F. Salama [mailto:hsalama@cisco.com]
Sent: February 9, 2001 2:21 AM
To: Philip Mart
Cc: Hinchey, Jeff [CAR:VS00-M:EXCH]; = 'iptel@lists.bell-labs.com'
Subject: Re: [IPTEL] TRIP question on routing = numbers

Philip Mart wrote:

> Hussein,
>
> If prefixes are to be included where are they = specified so that implementations
> may interoperate?

Not in TRIP. TRIP's specification of the address = families is loose, on purpose, to
maximize the utility of the protocol with different = number plans.


> I guess I should also ask why a "Nature of = Address" field
> wasn't included instead of the unspecified = prefixes?

We, TRIP's authors, had a long discussion about the = NoA field a few months ago. At
the end, we decided , we don't need an NoA field, = because when an administrator
places an LS in a certain domain, it will definitely = know the meaning of the
prefixes used in that domain. So the NoA can be = inferred from the prefix. This is
identical to the case with IP routing.

A TRIP LS located at the egress from an ITAD may have = to manipulate the prefix by
prependinng/stripping off digits as necessary before = forwarding an UPDATE to its
inter-domain peer in order to accommodate the prefix = conventions in that peer's
ITAD.

Hussein

> This would have the
> advantage of not mandating a particular = national, local or even hypothetical
> dialling plan which may in any case conflict = with interconnect arrangements.
>
> Phil Mart
>
> "Hussein F. Salama" = <hsalama@cisco.com> on 08/02/2001 03:37:36
>
> Please respond to hsalama@cisco.com
>
>
>
>
>
>
>
>  To:      Jeff = Hinchey <jhinchey@nortelnetworks.com>
>
>  cc:      = "'iptel@lists.bell-labs.com'"
>        &= nbsp;  <iptel@lists.bell-labs.com>(bcc: Philip
>          = ; Mart/MAIN/MC1)
>
>
>
>  Subject: Re: [IPTEL] TRIP question on = routing numbers
>
>
> Jeff Hinchey wrote:
>
> >
> >
> > I was reviewing the latest version of the = TRIP draft and was a little
> > confused over a statement in section = 5.1.1.2, second paragraph, which
> > reads:
> >
> >      "The = type of Decimal Routing Number (private, local, national, or
> >      = international) can be deduced from the first few digits of the
> >      = prefix"
> >
> > How is this accomplished? Telephone = numbers only have meaning within
> > the context of a specific number plan. = E.164 public numbers and
> > numbers from private number plans can = begin with the same digits.
> > Also, there is no way to determine if a = public number is local,
> > national or international based on leading = digits. There is no
> > reliable way to determine what number plan = a number belongs to from
> > only the number itself.
> >
> > Is the intent to include dial plan = prefixes in addition to numbering
> > plan addressing information in the routing = numbers specified in the
> > TRIP route?
>
> Yes, otherwise how can an LS differentiate = between a local prefix, a
> national prefix, and international = prefix?
>
> > If so, how will this work when TRIP = information is disseminated
> > between ITADs serving different regions = with different dial plans?
>
> A TRIP LS located at the egress from an ITAD = may have to manipulate the
> prefix by prependinng/stripping off digits as = necessary.
>
> Hussein
>
> >
> >
> > Jeff Hinchey
> > Succession Network = Architecture          =             =      Nortel
> > Networks
> > 613 763 8007 / 613 765 4881 = (fax)           &= nbsp;           3500 = Carling
> > Ave.
> > = jhinchey@nortelnetworks.com       &nb= sp;           &nb= sp;           = Nepean,
> > Canada  K2H 8E9
> >
>
> --
> Hussein F. Salama
> Cisco Systems
> Mail Stop SJC-21/3, 170 W. Tasman Drive, San = Jose, CA 95134
> Voice: +1 (408) 527-7147, Fax: +1 (408) = 527-7147
>
>   = ------------------------------------------------------------------------=
>          = ;         Name: att1.htm
>    = att1.htm       Type: Hypertext Markup = Language (text/html)
>          = ;     Encoding: base64
>          = ;  Description: Internet HTML

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, = CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) = 527-7147



_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel<= /FONT>

------_=_NextPart_001_01C09533.88928BB0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Feb 13 16:32:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00731 for ; Tue, 13 Feb 2001 16:32:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F2CA4435A; Tue, 13 Feb 2001 16:32:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 8943344337 for ; Tue, 13 Feb 2001 16:31:45 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA19760; Tue, 13 Feb 2001 13:31:59 -0800 (PST) Received: from cisco.com (dhcp-128-107-142-74.cisco.com [128.107.142.74]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AGC09014 (AUTH hsalama); Tue, 13 Feb 2001 13:31:40 -0800 (PST) Message-ID: <3A899B4C.8F4CDFD1@cisco.com> From: "Hussein F. Salama" Reply-To: hsalama@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Jeff Hinchey Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] TRIP question on routing numbers References: Content-Type: multipart/alternative; boundary="------------BEE46717270EE564A6CAF58E" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 13 Feb 2001 12:38:36 -0800 --------------BEE46717270EE564A6CAF58E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff Hinchey wrote: > > > Hussein, > > I'm trying to envision how the exchange of TRIP routing numbers will > be managed given they include dial plan prefixes. I see this being > very complex and error prone. > > You suggest that an LS can manipulate the prefixes used with the > routing numbers forwarded in UPDATE messages into a format > understandable by peer LSs. This implies that for ITADs which serve > multiple regions with differing dial plans and ITADs with peering > relationships with other ITADs serving regions with differing dial > plans, UPDATEs between peers will need to be manipulated potentially > on a per peer basis. Routing numbers in UPDATEs must be formatted > according to the LS to which they are being sent. > > - How are these LS-LS prefix mapping relationships established, how > are they kept in sync? I understand this is outside the scope of TRIP, > but will necessary in order for TRIP to be useful. If too complex to > manage, TRIP loses its utility. > > - How is route selection performed? Again, outside the scope of TRIP > but directly impacted by the way route information is communicated in > TRIP. For example, a route may be selected in ITAD A based on matching > routing number information with dial plan prefix X that directs call > signaling to a NextHopServer in ITAD B. The ITAD B server then queries > its own LS to determine its preferred route and the next > NextHopServer. Given ITAD B uses different prefixes than ITAD A, the > called number information in the call signaling will need to be > manipulated into ITAD B's routing number prefix format in order to > correctly query ITAD B's LS. > > - If the same route can be represented with different routing number > information (different prefixes) in different ITADs/LSs, how is route > aggregation performed? What is the impact to flooding within an ITAD > and routing loop detection? > > - This approach implies that a single LS can only represent routes > from a single region delimited by dial plan. There may be instances > where a single LS could serve many regions if not for this > restriction. > > > > I suggest it would be much simpler if TRIP routing numbers where based > on numbering plans (endpoint address/alias, fixed, independent of > regional dial plan) rather than dialing plans (method by which the > numbering plan is used, varies from region to region). Within the > context of a given number plan, each number/address/alias is unique. > Routing numbers and associated number plan can be passed around in > UPDATEs and used independent of regional dial plan without the need to > manipulate prefix digits. Can the number plan identifier be translated by an LS at the egress of an ITAD? Otherwise certain number plans will be confined to the their local domains. For example what will happen to a few local routes when they reach an LS at the egress of that local ITAD? Will they be simply dropped and nothing else? I think the LS should aggregate these local routes, prepend the appropriate area code, translate the number plan identifier, then advertise outside the ITAD. But since it has to prepend the area code anyways, what's the need for the number plan identifier? Hussein > > > The existing E.164 standard provides for fully qualified numbers which > are globally unique within the public numbering plan. Although there > are no specific standards, the same concept applies to private number > plans. The combination of a numbering plan identifier and fully > qualified number can be used to uniquely identify an endpoint (and > number ranges used to identify routes to endpoints) independent of > region and dial plan. > > Public routing numbers expressed in and identified as E.164 format can > be exchanged within and between ITADs without requiring any > conversion/manipulation of numbers between LSs. Within an ITAD, > private numbering plan identifiers (VPNs) can be easily standardized > to accomplish the same. I can't think of a scenario requiring private > routing numbers to be exchanged between ITADs as all ITADs except for > the ITAD serving the VPN would route calls based on an E.164 number > associated with the private network. If a private network was served > by multiple ITADs, then a private numbering plan identifier would need > to be agreed upon between the ITADs. > > With this approach, the responsibility for understanding dial plans is > pushed to the access devices and/or associated call servers which > already have this knowledge in order to parse end user input to > determine call intent. Using this knowledge, the originating access > device/call server can interpret dialed digits in the context of the > appropriate regional dial plan to extract called number information > and create a fully qualified number. The fully qualified number and > its numbering plan identifier can then be used to query an LS for > routing information. This approach removes the need for TRIP > implementations and administrators to deal with dialing plans and as > such regional variations in dialing plan formats/prefix digits. > > > Feedback welcome. > > -----Original Message----- > From: Hussein F. Salama [mailto:hsalama@cisco.com] > Sent: February 9, 2001 2:21 AM > To: Philip Mart > Cc: Hinchey, Jeff [CAR:VS00-M:EXCH]; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] TRIP question on routing numbers > > Philip Mart wrote: > > > Hussein, > > > > If prefixes are to be included where are they specified so that > implementations > > may interoperate? > > Not in TRIP. TRIP's specification of the address families is loose, on > purpose, to > maximize the utility of the protocol with different number plans. > > > I guess I should also ask why a "Nature of Address" field > > wasn't included instead of the unspecified prefixes? > > We, TRIP's authors, had a long discussion about the NoA field a few > months ago. At > the end, we decided , we don't need an NoA field, because when an > administrator > places an LS in a certain domain, it will definitely know the meaning > of the > prefixes used in that domain. So the NoA can be inferred from the > prefix. This is > identical to the case with IP routing. > > A TRIP LS located at the egress from an ITAD may have to manipulate > the prefix by > prependinng/stripping off digits as necessary before forwarding an > UPDATE to its > inter-domain peer in order to accommodate the prefix conventions in > that peer's > ITAD. > > Hussein > > > This would have the > > advantage of not mandating a particular national, local or even > hypothetical > > dialling plan which may in any case conflict with interconnect > arrangements. > > > > Phil Mart > > > > "Hussein F. Salama" on 08/02/2001 03:37:36 > > > > Please respond to hsalama@cisco.com > > > > > > > > > > > > > > > > To: Jeff Hinchey > > > > cc: "'iptel@lists.bell-labs.com'" > > (bcc: Philip > > Mart/MAIN/MC1) > > > > > > > > Subject: Re: [IPTEL] TRIP question on routing numbers > > > > > > Jeff Hinchey wrote: > > > > > > > > > > > I was reviewing the latest version of the TRIP draft and was a > little > > > confused over a statement in section 5.1.1.2, second paragraph, > which > > > reads: > > > > > > "The type of Decimal Routing Number (private, local, > national, or > > > international) can be deduced from the first few digits of > the > > > prefix" > > > > > > How is this accomplished? Telephone numbers only have meaning > within > > > the context of a specific number plan. E.164 public numbers and > > > numbers from private number plans can begin with the same digits. > > > Also, there is no way to determine if a public number is local, > > > national or international based on leading digits. There is no > > > reliable way to determine what number plan a number belongs to > from > > > only the number itself. > > > > > > Is the intent to include dial plan prefixes in addition to > numbering > > > plan addressing information in the routing numbers specified in > the > > > TRIP route? > > > > Yes, otherwise how can an LS differentiate between a local prefix, a > > > national prefix, and international prefix? > > > > > If so, how will this work when TRIP information is disseminated > > > between ITADs serving different regions with different dial plans? > > > > > A TRIP LS located at the egress from an ITAD may have to manipulate > the > > prefix by prependinng/stripping off digits as necessary. > > > > Hussein > > > > > > > > > > > Jeff Hinchey > > > Succession Network Architecture Nortel > > > Networks > > > 613 763 8007 / 613 765 4881 (fax) 3500 > Carling > > > Ave. > > > jhinchey@nortelnetworks.com Nepean, > > > Canada K2H 8E9 > > > > > > > -- > > Hussein F. Salama > > Cisco Systems > > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > > > ------------------------------------------------------------------------ > > > Name: att1.htm > > att1.htm Type: Hypertext Markup Language (text/html) > > Encoding: base64 > > Description: Internet HTML > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 --------------BEE46717270EE564A6CAF58E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Jeff Hinchey wrote:

 

Hussein,

I'm trying to envision how the exchange of TRIP routing numbers will be managed given they include dial plan prefixes. I see this being very complex and error prone.

You suggest that an LS can manipulate the prefixes used with the routing numbers forwarded in UPDATE messages into a format understandable by peer LSs. This implies that for ITADs which serve multiple regions with differing dial plans and ITADs with peering relationships with other ITADs serving regions with differing dial plans, UPDATEs between peers will need to be manipulated potentially on a per peer basis. Routing numbers in UPDATEs must be formatted according to the LS to which they are being sent.

- How are these LS-LS prefix mapping relationships established, how are they kept in sync? I understand this is outside the scope of TRIP, but will necessary in order for TRIP to be useful. If too complex to manage, TRIP loses its utility.

- How is route selection performed? Again, outside the scope of TRIP but directly impacted by the way route information is communicated in TRIP. For example, a route may be selected in ITAD A based on matching routing number information with dial plan prefix X that directs call signaling to a NextHopServer in ITAD B. The ITAD B server then queries its own LS to determine its preferred route and the next NextHopServer. Given ITAD B uses different prefixes than ITAD A, the called number information in the call signaling will need to be manipulated into ITAD B's routing number prefix format in order to correctly query ITAD B's LS.

- If the same route can be represented with different routing number information (different prefixes) in different ITADs/LSs, how is route aggregation performed? What is the impact to flooding within an ITAD and routing loop detection?

- This approach implies that a single LS can only represent routes from a single region delimited by dial plan. There may be instances where a single LS could serve many regions if not for this restriction.
 
 

I suggest it would be much simpler if TRIP routing numbers where based on numbering plans (endpoint address/alias, fixed, independent of regional dial plan) rather than dialing plans (method by which the numbering plan is used, varies from region to region). Within the context of a given number plan, each number/address/alias is unique. Routing numbers and associated number plan can be passed around in UPDATEs and used independent of regional dial plan without the need to manipulate prefix digits.

Can the number plan identifier be translated by an LS at the egress of an ITAD?  Otherwise certain number plans will be confined to the their local domains. For example what will happen to a few local routes when they reach an LS at the egress of that local ITAD? Will they be simply dropped and nothing else? I think the LS should aggregate these local routes, prepend the appropriate area code, translate the number plan identifier, then advertise outside the ITAD. But since it has to prepend the area code anyways, what's the need for the number plan identifier?

Hussein
 

 

The existing E.164 standard provides for fully qualified numbers which are globally unique within the public numbering plan. Although there are no specific standards, the same concept applies to private number plans. The combination of a numbering plan identifier and fully qualified number can be used to uniquely identify an endpoint (and number ranges used to identify routes to endpoints) independent of region and dial plan.

Public routing numbers expressed in and identified as E.164 format can be exchanged within and between ITADs without requiring any conversion/manipulation of numbers between LSs. Within an ITAD, private numbering plan identifiers (VPNs) can be easily standardized to accomplish the same. I can't think of a scenario requiring private routing numbers to be exchanged between ITADs as all ITADs except for the ITAD serving the VPN would route calls based on an E.164 number associated with the private network. If a private network was served by multiple ITADs, then a private numbering plan identifier would need to be agreed upon between the ITADs.

With this approach, the responsibility for understanding dial plans is pushed to the access devices and/or associated call servers which already have this knowledge in order to parse end user input to determine call intent. Using this knowledge, the originating access device/call server can interpret dialed digits in the context of the appropriate regional dial plan to extract called number information and create a fully qualified number. The fully qualified number and its numbering plan identifier can then be used to query an LS for routing information. This approach removes the need for TRIP implementations and administrators to deal with dialing plans and as such regional variations in dialing plan formats/prefix digits.

 

Feedback welcome.

-----Original Message-----
From: Hussein F. Salama [mailto:hsalama@cisco.com]
Sent: February 9, 2001 2:21 AM
To: Philip Mart
Cc: Hinchey, Jeff [CAR:VS00-M:EXCH]; 'iptel@lists.bell-labs.com'
Subject: Re: [IPTEL] TRIP question on routing numbers

Philip Mart wrote:

> Hussein,
>
> If prefixes are to be included where are they specified so that implementations
> may interoperate?

Not in TRIP. TRIP's specification of the address families is loose, on purpose, to
maximize the utility of the protocol with different number plans.

> I guess I should also ask why a "Nature of Address" field
> wasn't included instead of the unspecified prefixes?

We, TRIP's authors, had a long discussion about the NoA field a few months ago. At
the end, we decided , we don't need an NoA field, because when an administrator
places an LS in a certain domain, it will definitely know the meaning of the
prefixes used in that domain. So the NoA can be inferred from the prefix. This is
identical to the case with IP routing.

A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by
prependinng/stripping off digits as necessary before forwarding an UPDATE to its
inter-domain peer in order to accommodate the prefix conventions in that peer's
ITAD.

Hussein

> This would have the
> advantage of not mandating a particular national, local or even hypothetical
> dialling plan which may in any case conflict with interconnect arrangements.
>
> Phil Mart
>
> "Hussein F. Salama" <hsalama@cisco.com> on 08/02/2001 03:37:36
>
> Please respond to hsalama@cisco.com
>
>
>
>
>
>
>
>  To:      Jeff Hinchey <jhinchey@nortelnetworks.com>
>
>  cc:      "'iptel@lists.bell-labs.com'"
>           <iptel@lists.bell-labs.com>(bcc: Philip
>           Mart/MAIN/MC1)
>
>
>
>  Subject: Re: [IPTEL] TRIP question on routing numbers
>
>
> Jeff Hinchey wrote:
>
> >
> >
> > I was reviewing the latest version of the TRIP draft and was a little
> > confused over a statement in section 5.1.1.2, second paragraph, which
> > reads:
> >
> >      "The type of Decimal Routing Number (private, local, national, or
> >      international) can be deduced from the first few digits of the
> >      prefix"
> >
> > How is this accomplished? Telephone numbers only have meaning within
> > the context of a specific number plan. E.164 public numbers and
> > numbers from private number plans can begin with the same digits.
> > Also, there is no way to determine if a public number is local,
> > national or international based on leading digits. There is no
> > reliable way to determine what number plan a number belongs to from
> > only the number itself.
> >
> > Is the intent to include dial plan prefixes in addition to numbering
> > plan addressing information in the routing numbers specified in the
> > TRIP route?
>
> Yes, otherwise how can an LS differentiate between a local prefix, a
> national prefix, and international prefix?
>
> > If so, how will this work when TRIP information is disseminated
> > between ITADs serving different regions with different dial plans?
>
> A TRIP LS located at the egress from an ITAD may have to manipulate the
> prefix by prependinng/stripping off digits as necessary.
>
> Hussein
>
> >
> >
> > Jeff Hinchey
> > Succession Network Architecture                           Nortel
> > Networks
> > 613 763 8007 / 613 765 4881 (fax)                       3500 Carling
> > Ave.
> > jhinchey@nortelnetworks.com                               Nepean,
> > Canada  K2H 8E9
> >
>
> --
> Hussein F. Salama
> Cisco Systems
> Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134
> Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147
>
>   ------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: base64
>            Description: Internet HTML

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147
 

_______________________________________________
IPTEL mailing list
IPTEL@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/iptel

--
Hussein F. Salama
Cisco Systems
Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147
  --------------BEE46717270EE564A6CAF58E-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Feb 15 18:09:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02162 for ; Thu, 15 Feb 2001 18:09:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8CBD44357; Thu, 15 Feb 2001 18:09:01 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id BDB3944337 for ; Thu, 15 Feb 2001 18:08:06 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA19029; Thu, 15 Feb 2001 15:08:21 -0800 (PST) Received: from cisco.com (dhcp-128-107-142-74.cisco.com [128.107.142.74]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AGN06137 (AUTH hsalama); Thu, 15 Feb 2001 15:08:04 -0800 (PST) Message-ID: <3A8C61AA.7CB66AF7@cisco.com> From: "Hussein F. Salama" Reply-To: hsalama@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] ITAD Topology Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 15 Feb 2001 15:09:31 -0800 Content-Transfer-Encoding: 7bit I got a comment from a developer who doesn't like the use of the ITAD-Topology attribute in the UPDATE message. They strongly believe that we should define a new message dedicated to topology flooding, because many times an LS would like to update the the topology without having new ReachableRoutes or WithdrawnRoutes to advertise. And in link-state protocols, there are usually separate message for advertising the topology and others for advertising the routes. I can think of the following choices: 1. Define a new message for ITAD-Topology 2. Keep the attribute as it is today and specify how to fill in the mandatory arttributes (ReachableRoutes, WithdrawnRoutes, LocalPref, AdvertisementPath, ...) if there';s nothing to put in them. 3. Do nothing (may be give some guidelines in the BCP draft) I think the #1 is the right thing to do. What do you think? Hussein -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Feb 16 17:11:04 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10581 for ; Fri, 16 Feb 2001 17:11:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CC8B4433A; Fri, 16 Feb 2001 17:11:01 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by lists.bell-labs.com (Postfix) with ESMTP id 2FCAD44337 for ; Fri, 16 Feb 2001 17:10:25 -0500 (EST) Received: from Zoil [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A4E535A011A; Fri, 16 Feb 2001 17:08:37 -0500 Message-ID: <001d01c09865$a023e640$0f00000a@Zoil> From: "Bob Penfield" To: , References: <3A8C61AA.7CB66AF7@cisco.com> Subject: Re: [IPTEL] ITAD Topology MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 16 Feb 2001 17:13:01 -0500 Content-Transfer-Encoding: 7bit Assuming it is legal to include an empty ReachableRoutes or WithdrawnRoutes attribute by setting the Attr. Length field to 0, the spec could be modified to describe how to make an UPDATE message for just the ITAD-Topology (option 2). Is there any corollary in BGP? Considering a variation of option 1, since TRIP has not reached RFC yet, would it be possible to change it so that ReachableRoutes and Withdrawn Routes are not mandatory? Would it be possible to mandate that at least one of those attributes (ReachableRoutes, WithdrawnRoutes, or ITADTopology) be in an UPDATE? ----- Original Message ----- From: "Hussein F. Salama" To: Sent: Thursday, February 15, 2001 6:09 PM Subject: [IPTEL] ITAD Topology > > I got a comment from a developer who doesn't like the use of the > ITAD-Topology attribute in the UPDATE message. They strongly believe > that we should define a new message dedicated to topology flooding, > because many times an LS would like to update the the topology without > having new ReachableRoutes or WithdrawnRoutes to advertise. And in > link-state protocols, there are usually separate message for advertising > the topology and others for advertising the routes. > > I can think of the following choices: > 1. Define a new message for ITAD-Topology > 2. Keep the attribute as it is today and specify how to fill in the > mandatory arttributes (ReachableRoutes, WithdrawnRoutes, LocalPref, > AdvertisementPath, ...) if there';s nothing to put in them. > 3. Do nothing (may be give some guidelines in the BCP draft) > > I think the #1 is the right thing to do. What do you think? > > Hussein > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Feb 16 21:18:05 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13121 for ; Fri, 16 Feb 2001 21:18:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9045B44351; Fri, 16 Feb 2001 21:18:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 4D3EA44336 for ; Fri, 16 Feb 2001 21:17:52 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA01017; Fri, 16 Feb 2001 18:17:54 -0800 (PST) Received: from cisco.com (dhcp-128-107-142-74.cisco.com [128.107.142.74]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AHE01212 (AUTH hsalama); Fri, 16 Feb 2001 18:17:49 -0800 (PST) Message-ID: <3A8DDFA2.4CFD58E@cisco.com> From: "Hussein F. Salama" Reply-To: hsalama@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: drwalker@ss8.com Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] ITAD Topology References: <3A8C61AA.7CB66AF7@cisco.com> <3A8D53D9.9321D851@ss8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 16 Feb 2001 18:19:14 -0800 Content-Transfer-Encoding: 7bit Dave Walker wrote: > Here's a bit of discussion mostly on option 1 (without actually endorsing > either option). > > The draft already describes zero length Withdrawn and Reachable Route > attributes. I didn't see anything in the draft about it, but there > should be an explanation of what to do if both have length zero. If > this is allowed, I'd expect that the other mandatory attributes (NHS, > AdPath, and RoutedPath) would also have length zero (not described in > the draft). If at least one of the Route attributes must have non-zero > length, then a) it's an error if both are zero, and b) the other > mandatory attributes must not have length zero. > > My next question is why are these attributes mandatory in the first > place? My feeling about the UPDATE message is that it's basically > used to convey a description of changes in an LS's view of the network. > This may include adding routes, and/or deleting routes, and/or > changes in topology. Is it of great benefit to include zero length > attributes if there's nothing to say? Shouldn't the rule for these > attributes be something like: "if you have a ReachableRoute, then you > must also include NHS and the Path attributes"? If this were the case, > then UPDATE could be used for ITAD Topology without including other > (currently mandatory) attributes which aren't applicable. Further > degenerating this idea, the KEEPALIVE could be replaced by an UPDATE > that contains nothing at all. So that's a fourth proposal. to get rid of the "mandatory" requirement altogether, i.e. no more mandatory attributes. and the presence of some attributes will be conditional on the presence of others. For example, and AdvertisementPath must be present if a ReachableRoutes and/or WithdrawnRoutes is present. Hussein > > > Dave Walker > SS8 Networks > Ottawa, Canada > > "Hussein F. Salama" wrote: > > > > I got a comment from a developer who doesn't like the use of the > > ITAD-Topology attribute in the UPDATE message. They strongly believe > > that we should define a new message dedicated to topology flooding, > > because many times an LS would like to update the the topology without > > having new ReachableRoutes or WithdrawnRoutes to advertise. And in > > link-state protocols, there are usually separate message for advertising > > the topology and others for advertising the routes. > > > > I can think of the following choices: > > 1. Define a new message for ITAD-Topology > > 2. Keep the attribute as it is today and specify how to fill in the > > mandatory arttributes (ReachableRoutes, WithdrawnRoutes, LocalPref, > > AdvertisementPath, ...) if there';s nothing to put in them. > > 3. Do nothing (may be give some guidelines in the BCP draft) > > > > I think the #1 is the right thing to do. What do you think? > > > > Hussein > > > > -- > > Hussein F. Salama > > Cisco Systems > > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Feb 20 12:01:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16509 for ; Tue, 20 Feb 2001 12:01:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0AA314436E; Tue, 20 Feb 2001 12:01:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by lists.bell-labs.com (Postfix) with ESMTP id 74D1144352 for ; Tue, 20 Feb 2001 12:00:22 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Tue, 20 Feb 2001 11:54:10 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Feb 2001 11:54:10 -0500 Message-ID: From: "Jeff Hinchey" To: hsalama@cisco.com Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] TRIP question on routing numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B5D.A2056420" X-Orig: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 20 Feb 2001 11:53:21 -0500 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_01C09B5D.A2056420 Content-Type: text/plain; charset="iso-8859-1" Sorry for not responding sooner, I've been busied out since mid last week. Please see my response to your questions in line below. -----Original Message----- From: Hussein F. Salama [mailto:hsalama@cisco.com] Sent: February 13, 2001 3:39 PM To: Hinchey, Jeff [CAR:VS00-M:EXCH] Cc: 'iptel@lists.bell-labs.com' Subject: Re: [IPTEL] TRIP question on routing numbers Jeff Hinchey wrote: Hussein, I'm trying to envision how the exchange of TRIP routing numbers will be managed given they include dial plan prefixes. I see this being very complex and error prone. You suggest that an LS can manipulate the prefixes used with the routing numbers forwarded in UPDATE messages into a format understandable by peer LSs. This implies that for ITADs which serve multiple regions with differing dial plans and ITADs with peering relationships with other ITADs serving regions with differing dial plans, UPDATEs between peers will need to be manipulated potentially on a per peer basis. Routing numbers in UPDATEs must be formatted according to the LS to which they are being sent. - How are these LS-LS prefix mapping relationships established, how are they kept in sync? I understand this is outside the scope of TRIP, but will necessary in order for TRIP to be useful. If too complex to manage, TRIP loses its utility. - How is route selection performed? Again, outside the scope of TRIP but directly impacted by the way route information is communicated in TRIP. For example, a route may be selected in ITAD A based on matching routing number information with dial plan prefix X that directs call signaling to a NextHopServer in ITAD B. The ITAD B server then queries its own LS to determine its preferred route and the next NextHopServer. Given ITAD B uses different prefixes than ITAD A, the called number information in the call signaling will need to be manipulated into ITAD B's routing number prefix format in order to correctly query ITAD B's LS. - If the same route can be represented with different routing number information (different prefixes) in different ITADs/LSs, how is route aggregation performed? What is the impact to flooding within an ITAD and routing loop detection? - This approach implies that a single LS can only represent routes from a single region delimited by dial plan. There may be instances where a single LS could serve many regions if not for this restriction. I suggest it would be much simpler if TRIP routing numbers where based on numbering plans (endpoint address/alias, fixed, independent of regional dial plan) rather than dialing plans (method by which the numbering plan is used, varies from region to region). Within the context of a given number plan, each number/address/alias is unique. Routing numbers and associated number plan can be passed around in UPDATEs and used independent of regional dial plan without the need to manipulate prefix digits. Can the number plan identifier be translated by an LS at the egress of an ITAD? Otherwise certain number plans will be confined to the their local domains. [JH] Let expand on my original notes to clarify. Public numbering plan: There is only one public number plan, E.164. A single, predefined number plan id can be assigned for use with E.164 public routes within and between all ITADs, therefore no need to translate/map the number plan id. All public routes are expressed in E.164 format (fully qualified number or a prefix of a fully qualified number range), therefore no need to manipulate routes when exchanged in UPDATEs between LSs and ITADs. Private numbering plans: A private numbering plan is established and administered by a private Enterprise or by a service providers on behalf of an Enterprise. An ITAD being a service provider for an Enterprise defines the numbering plan and associated private routes (the VPN). Typically an Enterprise VPN is served by a single service provider, and there is no need to exchange the private route information outside of the ITAD. If an Enterprise VPN is served by more than one service provider, then the ITADs must agree on a common private number plan id or map at the egress LSs which exchange private route info (your point above). Within the private numbering plan, routes are expressed in fully qualified format as with public routes, therefore no need to manipulate routes when exchanged in UPDATEs between LSs (or ITADs if multiple serve the VPN). For example what will happen to a few local routes when they reach an LS at the egress of that local ITAD? Will they be simply dropped and nothing else? I think the LS should aggregate these local routes, prepend the appropriate area code, translate the number plan identifier, then advertise outside the ITAD. But since it has to prepend the area code anyways, what's the need for the number plan identifier? Hussein [JH] The key here is to separate dialing and numbering plans, express routes in a fully qualified number format and avoid configuring and mapping between routes which are local, national or international in the context of regional dial plans. For example, my office phone is associated with the fully qualified public E.164 number of 16137638007 (where CC=1, NDC=613, STN=7638007) and a fully qualified private Nortel Networks number 3938007. Consider the following use cases: Originating Dial Plan Dialed Digits Note Ottawa public 7638007 local abbreviated dialing New York public 16137638007 leading 1 is the toll prefix, not CC UK public 0016137638007 Intl prefix plus fully qualified E.164 number Ottawa Nortel private 38007 local abbreviated extension dialing UK Nortel private 63938007 inter site prefix plus fully qualified number Consider the Ottawa public case. Somewhere abbreviated dialing formats must be taken into account so that it can be determined that 7638007 implies 16137638007 instead of 18197638007 (Ottawa supports abbreviated 7 digit dialing spanning area codes 613 and 819). Building this knowledge into the routing databases with local, national and international routes will require manipulation of routing info passed between LSs (even within an ITAD), implying LSs must have knowledge of all the dial plan formats associated with the routes they exchange in order to manipulate the routing prefix digits correctly. This also implies that multiple routing databases must be maintained to handle originations to the same number from originators with different regional dial plans. I suggest that digit manipulation should occur upon call origination, at the originating access device and/or host server, which, with knowledge of the local dial plan can extract called number information from the dialed input and convert to a fully qualified format. The originating access device/server must have at least basic knowledge of the local dial plan of the originator in order to determine when enough digits have been collected (otherwise call set up times become excessive) and what type of routing to apply (for example operator assist (not TRIP trip enabled) versus called number (TRIP enabled)) Adding the ability to fully qualified the called number shouldn't be much of a stretch and is also required many cases anyway (for example NA LNP where the number must fully qualified to the national level in order to perform a portability check). To handle routing of public calls to my office phone, the ITAD providing public routes to Nortel Networks in Ottawa would configure an E.164 route as 1613763, a fully qualified number prefix under which all numbers are associated with Nortel Networks. This route information can be exchanged and aggregated with other ITADs in the context of the global E.164 public numbering plan without having to manipulate route info between ITADs. Consider the Ottawa Nortel private case. Again, the dialed number (38007) is abbreviated and can be fully qualified (3938007) in the context of the private dial plan. The ITAD providing VPN/private routes for Nortel Network would configure a corresponding Nortel route as 39 to route to the NextHopServer serving the Ottawa portion of the VPN. This route is applicable to both calls originated in the Ottawa and the UK regions of the VPN. A single routing database can be used for calls originated from any location within the Nortel Networks' VPN. I believe this scheme could be implemented quite easily by introducing a new "Fully Qualified E.164" Address Family to TRIP. A range of Address Families could also be reserved for use with VPNs/private numbering plans within ITADs. Using this approach will drastically reduce the number of TRIP routes that need to administered and remove the need for complex mapping to occur when TRIP routes are exchanged in UPDATE messages. The existing E.164 standard provides for fully qualified numbers which are globally unique within the public numbering plan. Although there are no specific standards, the same concept applies to private number plans. The combination of a numbering plan identifier and fully qualified number can be used to uniquely identify an endpoint (and number ranges used to identify routes to endpoints) independent of region and dial plan. Public routing numbers expressed in and identified as E.164 format can be exchanged within and between ITADs without requiring any conversion/manipulation of numbers between LSs. Within an ITAD, private numbering plan identifiers (VPNs) can be easily standardized to accomplish the same. I can't think of a scenario requiring private routing numbers to be exchanged between ITADs as all ITADs except for the ITAD serving the VPN would route calls based on an E.164 number associated with the private network. If a private network was served by multiple ITADs, then a private numbering plan identifier would need to be agreed upon between the ITADs. With this approach, the responsibility for understanding dial plans is pushed to the access devices and/or associated call servers which already have this knowledge in order to parse end user input to determine call intent. Using this knowledge, the originating access device/call server can interpret dialed digits in the context of the appropriate regional dial plan to extract called number information and create a fully qualified number. The fully qualified number and its numbering plan identifier can then be used to query an LS for routing information. This approach removes the need for TRIP implementations and administrators to deal with dialing plans and as such regional variations in dialing plan formats/prefix digits. Feedback welcome. -----Original Message----- From: Hussein F. Salama [ mailto:hsalama@cisco.com ] Sent: February 9, 2001 2:21 AM To: Philip Mart Cc: Hinchey, Jeff [CAR:VS00-M:EXCH]; 'iptel@lists.bell-labs.com' Subject: Re: [IPTEL] TRIP question on routing numbers Philip Mart wrote: > Hussein, > > If prefixes are to be included where are they specified so that implementations > may interoperate? Not in TRIP. TRIP's specification of the address families is loose, on purpose, to maximize the utility of the protocol with different number plans. > I guess I should also ask why a "Nature of Address" field > wasn't included instead of the unspecified prefixes? We, TRIP's authors, had a long discussion about the NoA field a few months ago. At the end, we decided , we don't need an NoA field, because when an administrator places an LS in a certain domain, it will definitely know the meaning of the prefixes used in that domain. So the NoA can be inferred from the prefix. This is identical to the case with IP routing. A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by prependinng/stripping off digits as necessary before forwarding an UPDATE to its inter-domain peer in order to accommodate the prefix conventions in that peer's ITAD. Hussein > This would have the > advantage of not mandating a particular national, local or even hypothetical > dialling plan which may in any case conflict with interconnect arrangements. > > Phil Mart > > "Hussein F. Salama" on 08/02/2001 03:37:36 > > Please respond to hsalama@cisco.com > > To: Jeff Hinchey > cc: "'iptel@lists.bell-labs.com'" > (bcc: Philip > Mart/MAIN/MC1) > Subject: Re: [IPTEL] TRIP question on routing numbers > > Jeff Hinchey wrote: > > > > > I was reviewing the latest version of the TRIP draft and was a little > > confused over a statement in section 5.1.1.2, second paragraph, which > > reads: > > > > "The type of Decimal Routing Number (private, local, national, or > > international) can be deduced from the first few digits of the > > prefix" > > > > How is this accomplished? Telephone numbers only have meaning within > > the context of a specific number plan. E.164 public numbers and > > numbers from private number plans can begin with the same digits. > > Also, there is no way to determine if a public number is local, > > national or international based on leading digits. There is no > > reliable way to determine what number plan a number belongs to from > > only the number itself. > > > > Is the intent to include dial plan prefixes in addition to numbering > > plan addressing information in the routing numbers specified in the > > TRIP route? > > Yes, otherwise how can an LS differentiate between a local prefix, a > national prefix, and international prefix? > > > If so, how will this work when TRIP information is disseminated > > between ITADs serving different regions with different dial plans? > > A TRIP LS located at the egress from an ITAD may have to manipulate the > prefix by prependinng/stripping off digits as necessary. > > Hussein ------_=_NextPart_001_01C09B5D.A2056420 Content-Type: text/html; charset="iso-8859-1"

Sorry for not responding sooner, I've been busied out since mid last week. Please see my response to your questions in line below.
 
-----Original Message-----
From: Hussein F. Salama [mailto:hsalama@cisco.com]
Sent: February 13, 2001 3:39 PM
To: Hinchey, Jeff [CAR:VS00-M:EXCH]
Cc: 'iptel@lists.bell-labs.com'
Subject: Re: [IPTEL] TRIP question on routing numbers

Jeff Hinchey wrote:

Hussein,

I'm trying to envision how the exchange of TRIP routing numbers will be managed given they include dial plan prefixes. I see this being very complex and error prone.

You suggest that an LS can manipulate the prefixes used with the routing numbers forwarded in UPDATE messages into a format understandable by peer LSs. This implies that for ITADs which serve multiple regions with differing dial plans and ITADs with peering relationships with other ITADs serving regions with differing dial plans, UPDATEs between peers will need to be manipulated potentially on a per peer basis. Routing numbers in UPDATEs must be formatted according to the LS to which they are being sent.

- How are these LS-LS prefix mapping relationships established, how are they kept in sync? I understand this is outside the scope of TRIP, but will necessary in order for TRIP to be useful. If too complex to manage, TRIP loses its utility.

- How is route selection performed? Again, outside the scope of TRIP but directly impacted by the way route information is communicated in TRIP. For example, a route may be selected in ITAD A based on matching routing number information with dial plan prefix X that directs call signaling to a NextHopServer in ITAD B. The ITAD B server then queries its own LS to determine its preferred route and the next NextHopServer. Given ITAD B uses different prefixes than ITAD A, the called number information in the call signaling will need to be manipulated into ITAD B's routing number prefix format in order to correctly query ITAD B's LS.

- If the same route can be represented with different routing number information (different prefixes) in different ITADs/LSs, how is route aggregation performed? What is the impact to flooding within an ITAD and routing loop detection?

- This approach implies that a single LS can only represent routes from a single region delimited by dial plan. There may be instances where a single LS could serve many regions if not for this restriction. 

I suggest it would be much simpler if TRIP routing numbers where based on numbering plans (endpoint address/alias, fixed, independent of regional dial plan) rather than dialing plans (method by which the numbering plan is used, varies from region to region). Within the context of a given number plan, each number/address/alias is unique. Routing numbers and associated number plan can be passed around in UPDATEs and used independent of regional dial plan without the need to manipulate prefix digits.

Can the number plan identifier be translated by an LS at the egress of an ITAD?  Otherwise certain number plans will be confined to the their local domains.
[JH] Let expand on my original notes to clarify.
 
Public numbering plan:
 
There is only one public number plan, E.164. A single, predefined number plan id can be assigned for use with E.164 public routes within and between all ITADs, therefore no need to translate/map the number plan id. All public routes are expressed in E.164 format (fully qualified number or a prefix of a fully qualified number range), therefore no need to manipulate routes when exchanged in UPDATEs between LSs and ITADs.
 
Private numbering plans:
 
A private numbering plan is established and administered by a private Enterprise or by a service providers on behalf of an Enterprise. An ITAD being a service provider for an Enterprise defines the numbering plan and associated private routes (the VPN).
 
Typically an Enterprise VPN is served by a single service provider, and there is no need to exchange the private route information outside of the ITAD. If an Enterprise VPN is served by more than one service provider, then the ITADs must agree on a common private number plan id or map at the egress LSs which exchange private route info (your point above).
 
Within the private numbering plan, routes are expressed in fully qualified format as with public routes, therefore no need to manipulate routes when exchanged in UPDATEs between LSs (or ITADs if multiple serve the VPN).
 
 For example what will happen to a few local routes when they reach an LS at the egress of that local ITAD? Will they be simply dropped and nothing else? I think the LS should aggregate these local routes, prepend the appropriate area code, translate the number plan identifier, then advertise outside the ITAD. But since it has to prepend the area code anyways, what's the need for the number plan identifier?

Hussein

[JH] The key here is to separate dialing and numbering plans, express routes in a fully qualified number format and avoid configuring and mapping between routes which are local, national or international in the context of regional dial plans. For example, my office phone is associated with the fully qualified public E.164 number of 16137638007 (where CC=1, NDC=613, STN=7638007) and a fully qualified private Nortel Networks number 3938007. Consider the following use cases:

Originating Dial Plan    Dialed Digits   Note

Ottawa public            7638007         local abbreviated dialing

New York public          16137638007     leading 1 is the toll prefix, not CC

UK public                0016137638007   Intl prefix plus fully qualified E.164 number

Ottawa Nortel private    38007           local abbreviated extension dialing

UK Nortel private        63938007        inter site prefix plus fully qualified number

Consider the Ottawa public case. Somewhere abbreviated dialing formats must be taken into account so that it can be determined that 7638007 implies 16137638007 instead of 18197638007 (Ottawa supports abbreviated 7 digit dialing spanning area codes 613 and 819). Building this knowledge into the routing databases with local, national and international routes will require manipulation of routing info passed between LSs (even within an ITAD), implying LSs must have knowledge of all the dial plan formats associated with the routes they exchange in order to manipulate the routing prefix digits correctly. This also implies that multiple routing databases must be maintained to handle originations to the same number from originators with different regional dial plans.

I suggest that digit manipulation should occur upon call origination, at the originating access device and/or host server, which, with knowledge of the local dial plan can extract called number information from the dialed input and convert to a fully qualified format. The originating access device/server must have at least basic knowledge of the local dial plan of the originator in order to determine when enough digits have been collected (otherwise call set up times become excessive) and what type of routing to apply (for example operator assist (not TRIP trip enabled) versus called number (TRIP enabled)) Adding the ability to fully qualified the called number shouldn't be much of a stretch and is also required many cases anyway (for example NA LNP where the number must fully qualified to the national level in order to perform a portability check).

To handle routing of public calls to my office phone, the ITAD providing public routes to Nortel Networks in Ottawa would configure an E.164 route as 1613763, a fully qualified number prefix under which all numbers are associated with Nortel Networks. This route information can be exchanged and aggregated with other ITADs in the context of the global E.164 public numbering plan without having to manipulate route info between ITADs.

Consider the Ottawa Nortel private case. Again, the dialed number (38007) is abbreviated and can be fully qualified (3938007) in the context of the private dial plan. The ITAD providing VPN/private routes for Nortel Network would configure a corresponding Nortel route as 39 to route to the NextHopServer serving the Ottawa portion of the VPN. This route is applicable to both calls originated in the Ottawa and the UK regions of the VPN. A single routing database can be used for calls originated from any location within the Nortel Networks' VPN.

I believe this scheme could be implemented quite easily by introducing a new "Fully Qualified E.164" Address Family to TRIP. A range of Address Families could also be reserved for use with VPNs/private numbering plans within ITADs.

Using this approach will drastically reduce the number of TRIP routes that need to administered and remove the need for complex mapping to occur when TRIP routes are exchanged in UPDATE messages.

The existing E.164 standard provides for fully qualified numbers which are globally unique within the public numbering plan. Although there are no specific standards, the same concept applies to private number plans. The combination of a numbering plan identifier and fully qualified number can be used to uniquely identify an endpoint (and number ranges used to identify routes to endpoints) independent of region and dial plan.

Public routing numbers expressed in and identified as E.164 format can be exchanged within and between ITADs without requiring any conversion/manipulation of numbers between LSs. Within an ITAD, private numbering plan identifiers (VPNs) can be easily standardized to accomplish the same. I can't think of a scenario requiring private routing numbers to be exchanged between ITADs as all ITADs except for the ITAD serving the VPN would route calls based on an E.164 number associated with the private network. If a private network was served by multiple ITADs, then a private numbering plan identifier would need to be agreed upon between the ITADs.

With this approach, the responsibility for understanding dial plans is pushed to the access devices and/or associated call servers which already have this knowledge in order to parse end user input to determine call intent. Using this knowledge, the originating access device/call server can interpret dialed digits in the context of the appropriate regional dial plan to extract called number information and create a fully qualified number. The fully qualified number and its numbering plan identifier can then be used to query an LS for routing information. This approach removes the need for TRIP implementations and administrators to deal with dialing plans and as such regional variations in dialing plan formats/prefix digits.

 Feedback welcome.

-----Original Message-----
From: Hussein F. Salama [mailto:hsalama@cisco.com]
Sent: February 9, 2001 2:21 AM
To: Philip Mart
Cc: Hinchey, Jeff [CAR:VS00-M:EXCH]; 'iptel@lists.bell-labs.com'
Subject: Re: [IPTEL] TRIP question on routing numbers

Philip Mart wrote:

> Hussein,
>
> If prefixes are to be included where are they specified so that implementations
> may interoperate?

Not in TRIP. TRIP's specification of the address families is loose, on purpose, to
maximize the utility of the protocol with different number plans.

> I guess I should also ask why a "Nature of Address" field
> wasn't included instead of the unspecified prefixes?

We, TRIP's authors, had a long discussion about the NoA field a few months ago. At
the end, we decided , we don't need an NoA field, because when an administrator
places an LS in a certain domain, it will definitely know the meaning of the
prefixes used in that domain. So the NoA can be inferred from the prefix. This is
identical to the case with IP routing.

A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by
prependinng/stripping off digits as necessary before forwarding an UPDATE to its
inter-domain peer in order to accommodate the prefix conventions in that peer's
ITAD.

Hussein

> This would have the
> advantage of not mandating a particular national, local or even hypothetical
> dialling plan which may in any case conflict with interconnect arrangements.
>
> Phil Mart
>
> "Hussein F. Salama" <hsalama@cisco.com> on 08/02/2001 03:37:36
>
> Please respond to hsalama@cisco.com
>
>  To:      Jeff Hinchey <jhinchey@nortelnetworks.com>
>  cc:      "'iptel@lists.bell-labs.com'"
>           <iptel@lists.bell-labs.com>(bcc: Philip
>           Mart/MAIN/MC1)
>  Subject: Re: [IPTEL] TRIP question on routing numbers
>
> Jeff Hinchey wrote:
>
> >
> > I was reviewing the latest version of the TRIP draft and was a little
> > confused over a statement in section 5.1.1.2, second paragraph, which
> > reads:
> >
> >      "The type of Decimal Routing Number (private, local, national, or
> >      international) can be deduced from the first few digits of the
> >      prefix"
> >
> > How is this accomplished? Telephone numbers only have meaning within
> > the context of a specific number plan. E.164 public numbers and
> > numbers from private number plans can begin with the same digits.
> > Also, there is no way to determine if a public number is local,
> > national or international based on leading digits. There is no
> > reliable way to determine what number plan a number belongs to from
> > only the number itself.
> >
> > Is the intent to include dial plan prefixes in addition to numbering
> > plan addressing information in the routing numbers specified in the
> > TRIP route?
>
> Yes, otherwise how can an LS differentiate between a local prefix, a
> national prefix, and international prefix?
>
> > If so, how will this work when TRIP information is disseminated
> > between ITADs serving different regions with different dial plans?
>
> A TRIP LS located at the egress from an ITAD may have to manipulate the
> prefix by prependinng/stripping off digits as necessary.
>
> Hussein  

------_=_NextPart_001_01C09B5D.A2056420-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 21 09:07:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26669 for ; Wed, 21 Feb 2001 09:07:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E2474433C; Wed, 21 Feb 2001 09:07:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54]) by lists.bell-labs.com (Postfix) with ESMTP id C29E744336 for ; Thu, 8 Feb 2001 07:49:04 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 8 Feb 2001 12:49:29 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id MAA21073; Thu, 8 Feb 2001 12:49:01 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569ED.0046593D ; Thu, 8 Feb 2001 12:48:23 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Philip Mart" To: hsalama@cisco.com Cc: Jeff Hinchey , "'iptel@lists.bell-labs.com'" Message-ID: <802569ED.004657BB.00@marconicomms.com> Subject: Re: [IPTEL] TRIP question on routing numbers Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=OGEL968GL1IbEbwGs0UzHUQ96JdpQFTra6wjE6ToB0wp23etPirVqMOd" Content-Disposition: inline Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 8 Feb 2001 12:52:07 +0000 --0__=OGEL968GL1IbEbwGs0UzHUQ96JdpQFTra6wjE6ToB0wp23etPirVqMOd Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hussein, If prefixes are to be included where are they specified so that implementations may interoperate? I guess I should also ask why a "Nature of Address" field wasn't included instead of the unspecified prefixes? This would have the advantage of not mandating a particular national, local or even hypothetical dialling plan which may in any case conflict with interconnect arrangements. Phil Mart "Hussein F. Salama" on 08/02/2001 03:37:36 Please respond to hsalama@cisco.com To: Jeff Hinchey cc: "'iptel@lists.bell-labs.com'" (bcc: Philip Mart/MAIN/MC1) Subject: Re: [IPTEL] TRIP question on routing numbers Jeff Hinchey wrote: > > > I was reviewing the latest version of the TRIP draft and was a little > confused over a statement in section 5.1.1.2, second paragraph, which > reads: > > "The type of Decimal Routing Number (private, local, national, or > international) can be deduced from the first few digits of the > prefix" > > How is this accomplished? Telephone numbers only have meaning within > the context of a specific number plan. E.164 public numbers and > numbers from private number plans can begin with the same digits. > Also, there is no way to determine if a public number is local, > national or international based on leading digits. There is no > reliable way to determine what number plan a number belongs to from > only the number itself. > > Is the intent to include dial plan prefixes in addition to numbering > plan addressing information in the routing numbers specified in the > TRIP route? Yes, otherwise how can an LS differentiate between a local prefix, a national prefix, and international prefix? > If so, how will this work when TRIP information is disseminated > between ITADs serving different regions with different dial plans? A TRIP LS located at the egress from an ITAD may have to manipulate the prefix by prependinng/stripping off digits as necessary. Hussein > > > Jeff Hinchey > Succession Network Architecture Nortel > Networks > 613 763 8007 / 613 765 4881 (fax) 3500 Carling > Ave. > jhinchey@nortelnetworks.com Nepean, > Canada K2H 8E9 > -- Hussein F. Salama Cisco Systems Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 --0__=OGEL968GL1IbEbwGs0UzHUQ96JdpQFTra6wjE6ToB0wp23etPirVqMOd Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KJm5ic3A7DQo8cD5KZWZmIEhpbmNoZXkgd3JvdGU6DQo8YmxvY2txdW90 ZSBUWVBFPUNJVEU+Jm5ic3A7DQo8cD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+PGZvbnQgc2l6 ZT0tMT5JIHdhcyByZXZpZXdpbmcgdGhlIGxhdGVzdCB2ZXJzaW9uDQpvZiB0aGUgVFJJUCBkcmFm dCBhbmQgd2FzIGEgbGl0dGxlIGNvbmZ1c2VkIG92ZXIgYSBzdGF0ZW1lbnQgaW4gc2VjdGlvbg0K NS4xLjEuMiwgc2Vjb25kIHBhcmFncmFwaCwgd2hpY2ggcmVhZHM6PC9mb250PjwvZm9udD4NCjx1 bD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+PGZvbnQgc2l6ZT0tMT4iVGhlIHR5cGUgb2YgRGVj aW1hbCBSb3V0aW5nDQpOdW1iZXIgKHByaXZhdGUsIGxvY2FsLCBuYXRpb25hbCwgb3IgaW50ZXJu YXRpb25hbCkgY2FuIGJlIGRlZHVjZWQgZnJvbQ0KdGhlIGZpcnN0IGZldyBkaWdpdHMgb2YgdGhl IHByZWZpeCI8L2ZvbnQ+PC9mb250PjwvdWw+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+PGZv bnQgc2l6ZT0tMT5Ib3cgaXMgdGhpcyBhY2NvbXBsaXNoZWQ/IFRlbGVwaG9uZQ0KbnVtYmVycyBv bmx5IGhhdmUgbWVhbmluZyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgYSBzcGVjaWZpYyBudW1iZXIg cGxhbi4NCkUuMTY0IHB1YmxpYyBudW1iZXJzIGFuZCBudW1iZXJzIGZyb20gcHJpdmF0ZSBudW1i ZXIgcGxhbnMgY2FuIGJlZ2luIHdpdGgNCnRoZSBzYW1lIGRpZ2l0cy4gQWxzbywgdGhlcmUgaXMg bm8gd2F5IHRvIGRldGVybWluZSBpZiBhIHB1YmxpYyBudW1iZXINCmlzIGxvY2FsLCBuYXRpb25h bCBvciBpbnRlcm5hdGlvbmFsIGJhc2VkIG9uIGxlYWRpbmcgZGlnaXRzLiBUaGVyZSBpcyBubw0K cmVsaWFibGUgd2F5IHRvIGRldGVybWluZSB3aGF0IG51bWJlciBwbGFuIGEgbnVtYmVyIGJlbG9u Z3MgdG8gZnJvbSBvbmx5DQp0aGUgbnVtYmVyIGl0c2VsZi48L2ZvbnQ+PC9mb250Pg0KPHA+PGZv bnQgZmFjZT0iQ291cmllciBOZXciPjxmb250IHNpemU9LTE+SXMgdGhlIGludGVudCB0byBpbmNs dWRlIGRpYWwNCnBsYW4gcHJlZml4ZXMgaW4gYWRkaXRpb24gdG8gbnVtYmVyaW5nIHBsYW4gYWRk cmVzc2luZyBpbmZvcm1hdGlvbiBpbiB0aGUNCnJvdXRpbmcgbnVtYmVycyBzcGVjaWZpZWQgaW4g dGhlIFRSSVAgcm91dGU/PC9mb250PjwvZm9udD48L2Jsb2NrcXVvdGU+DQpZZXMsIG90aGVyd2lz ZSBob3cgY2FuIGFuIExTIGRpZmZlcmVudGlhdGUgYmV0d2VlbiBhIGxvY2FsIHByZWZpeCwgYSBu YXRpb25hbA0KcHJlZml4LCBhbmQgaW50ZXJuYXRpb25hbCBwcmVmaXg/DQo8YmxvY2txdW90ZSBU WVBFPUNJVEU+PGZvbnQgZmFjZT0iQ291cmllciBOZXciPjxmb250IHNpemU9LTE+SWYgc28sIGhv dw0Kd2lsbCB0aGlzIHdvcmsgd2hlbiBUUklQIGluZm9ybWF0aW9uIGlzIGRpc3NlbWluYXRlZCBi ZXR3ZWVuIElUQURzIHNlcnZpbmcNCmRpZmZlcmVudCByZWdpb25zIHdpdGggZGlmZmVyZW50IGRp YWwgcGxhbnM/PC9mb250PjwvZm9udD48L2Jsb2NrcXVvdGU+DQpBIFRSSVAgTFMgbG9jYXRlZCBh dCB0aGUgZWdyZXNzIGZyb20gYW4gSVRBRCBtYXkgaGF2ZSB0byBtYW5pcHVsYXRlIHRoZQ0KcHJl Zml4IGJ5IHByZXBlbmRpbm5nL3N0cmlwcGluZyBvZmYgZGlnaXRzIGFzIG5lY2Vzc2FyeS4NCjxw Pkh1c3NlaW4NCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxibG9ja3F1b3RlIFRZUEU9Q0lURT48 Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+PGZvbnQgc2l6ZT0tMT48L2ZvbnQ+PC9mb250PiZuYnNw Ow0KPHA+PGZvbnQgZmFjZT0iVGFob21hIj48Zm9udCBzaXplPS0xPkplZmYgSGluY2hleTwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iVGFob21hIj48Zm9udCBzaXplPS0xPlN1Y2Nlc3Np b24gTmV0d29yayBBcmNoaXRlY3R1cmUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCk5vcnRlbCBOZXR3b3JrczwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0i VGFob21hIj48Zm9udCBzaXplPS0xPjYxMyA3NjMgODAwNyAvIDYxMyA3NjUgNDg4MSAoZmF4KSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KMzUwMCBDYXJsaW5nIEF2ZS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxm b250IGZhY2U9IlRhaG9tYSI+PGZvbnQgc2l6ZT0tMT5qaGluY2hleUBub3J0ZWxuZXR3b3Jrcy5j b20mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCk5lcGVhbiwgQ2FuYWRhJm5ic3A7IEsySCA4RTk8L2ZvbnQ+PC9mb250Pg0K PGJyPiZuYnNwOzwvYmxvY2txdW90ZT4NCg0KPHA+LS0NCjxicj5IdXNzZWluIEYuIFNhbGFtYQ0K PGJyPkNpc2NvIFN5c3RlbXMNCjxicj5NYWlsIFN0b3AgU0pDLTIxLzMsIDE3MCBXLiBUYXNtYW4g RHJpdmUsIFNhbiBKb3NlLCBDQSA5NTEzNA0KPGJyPlZvaWNlOiArMSAoNDA4KSA1MjctNzE0Nywg RmF4OiArMSAoNDA4KSA1MjctNzE0Nw0KPGJyPiZuYnNwOzwvaHRtbD4NCg0K --0__=OGEL968GL1IbEbwGs0UzHUQ96JdpQFTra6wjE6ToB0wp23etPirVqMOd-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 21 09:09:28 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26920 for ; Wed, 21 Feb 2001 09:09:27 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D53234434B; Wed, 21 Feb 2001 09:07:06 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 92CF944336; Mon, 12 Feb 2001 07:22:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04149; Mon, 12 Feb 2001 07:21:51 -0500 (EST) Message-Id: <200102121221.HAA04149@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com, iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-yu-tel-url-02.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 12 Feb 2001 07:21:51 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the 'tel' and 'fax' URLs to Support Number Portability and Freephone Service Author(s) : J. Yu Filename : draft-yu-tel-url-02.txt Pages : 12 Date : 09-Feb-01 This document proposes some extensions to the 'tel' and 'fax' Uniform Resource Locators (URLs) for supporting number portability (NP) and freephone service. Those proposed extensions allow the Session Initiation Protocol (SIP) to carry those URLs or to convert those URLs to the SIP URL so as to support NP and freephone service. The proposed extensions allow the SIP protocol to be used to derive the routing number for the ported geographical numbers, identify the freephone service provider/carrier or the Plain Old Telephone Service (POTS) number for a freephone number, and carry the NP- and freephone-related information in the SIP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yu-tel-url-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yu-tel-url-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yu-tel-url-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010209142915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yu-tel-url-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-yu-tel-url-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010209142915.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 21 09:15:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27199 for ; Wed, 21 Feb 2001 09:15:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 288B744355; Wed, 21 Feb 2001 09:07:11 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by lists.bell-labs.com (Postfix) with ESMTP id BC0FB4434E for ; Fri, 16 Feb 2001 11:21:36 -0500 (EST) Received: from ss8.com (DAVEW [192.168.4.238]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1R470ZT9; Fri, 16 Feb 2001 11:22:13 -0500 Message-ID: <3A8D53D9.9321D851@ss8.com> From: Dave Walker Reply-To: drwalker@ss8.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: hsalama@cisco.com Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] ITAD Topology References: <3A8C61AA.7CB66AF7@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 16 Feb 2001 11:22:50 -0500 Content-Transfer-Encoding: 7bit Here's a bit of discussion mostly on option 1 (without actually endorsing either option). The draft already describes zero length Withdrawn and Reachable Route attributes. I didn't see anything in the draft about it, but there should be an explanation of what to do if both have length zero. If this is allowed, I'd expect that the other mandatory attributes (NHS, AdPath, and RoutedPath) would also have length zero (not described in the draft). If at least one of the Route attributes must have non-zero length, then a) it's an error if both are zero, and b) the other mandatory attributes must not have length zero. My next question is why are these attributes mandatory in the first place? My feeling about the UPDATE message is that it's basically used to convey a description of changes in an LS's view of the network. This may include adding routes, and/or deleting routes, and/or changes in topology. Is it of great benefit to include zero length attributes if there's nothing to say? Shouldn't the rule for these attributes be something like: "if you have a ReachableRoute, then you must also include NHS and the Path attributes"? If this were the case, then UPDATE could be used for ITAD Topology without including other (currently mandatory) attributes which aren't applicable. Further degenerating this idea, the KEEPALIVE could be replaced by an UPDATE that contains nothing at all. Dave Walker SS8 Networks Ottawa, Canada "Hussein F. Salama" wrote: > > I got a comment from a developer who doesn't like the use of the > ITAD-Topology attribute in the UPDATE message. They strongly believe > that we should define a new message dedicated to topology flooding, > because many times an LS would like to update the the topology without > having new ReachableRoutes or WithdrawnRoutes to advertise. And in > link-state protocols, there are usually separate message for advertising > the topology and others for advertising the routes. > > I can think of the following choices: > 1. Define a new message for ITAD-Topology > 2. Keep the attribute as it is today and specify how to fill in the > mandatory arttributes (ReachableRoutes, WithdrawnRoutes, LocalPref, > AdvertisementPath, ...) if there';s nothing to put in them. > 3. Do nothing (may be give some guidelines in the BCP draft) > > I think the #1 is the right thing to do. What do you think? > > Hussein > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Feb 25 20:20:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14255 for ; Sun, 25 Feb 2001 20:20:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6893B44357; Sun, 25 Feb 2001 20:20:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 807FC44338 for ; Sun, 25 Feb 2001 20:19:42 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA01712; Sun, 25 Feb 2001 20:22:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Feb 2001 20:22:07 -0500 Message-ID: From: Jonathan Rosenberg To: drwalker@ss8.com, hsalama@cisco.com Cc: iptel@lists.bell-labs.com Subject: RE: [IPTEL] ITAD Topology MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sun, 25 Feb 2001 20:22:06 -0500 I'm inclined to agree with Dave, and that the simplest and cleanest solution is to allow UPDATE to contain ReachableRoutes, WithdrawnRoutes, or ITADTopology, and specify which other attributes need to be present based on which of the above three are there. I definitely do not want to add a new message type, since I think this will require too many changes in other places in the document. Similarly, I do not want to use UPDATE as a keepalive, since this would require very pervasive changes throughout the document. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Dave Walker [mailto:drwalker@ss8.com] > Sent: Friday, February 16, 2001 11:23 AM > To: hsalama@cisco.com > Cc: iptel@lists.bell-labs.com > Subject: Re: [IPTEL] ITAD Topology > > > Here's a bit of discussion mostly on option 1 (without > actually endorsing > either option). > > The draft already describes zero length Withdrawn and Reachable Route > attributes. I didn't see anything in the draft about it, but there > should be an explanation of what to do if both have length zero. If > this is allowed, I'd expect that the other mandatory attributes (NHS, > AdPath, and RoutedPath) would also have length zero (not described in > the draft). If at least one of the Route attributes must > have non-zero > length, then a) it's an error if both are zero, and b) the other > mandatory attributes must not have length zero. > > My next question is why are these attributes mandatory in the first > place? My feeling about the UPDATE message is that it's basically > used to convey a description of changes in an LS's view of > the network. > This may include adding routes, and/or deleting routes, and/or > changes in topology. Is it of great benefit to include zero length > attributes if there's nothing to say? Shouldn't the rule for these > attributes be something like: "if you have a ReachableRoute, then you > must also include NHS and the Path attributes"? If this were > the case, > then UPDATE could be used for ITAD Topology without including other > (currently mandatory) attributes which aren't applicable. Further > degenerating this idea, the KEEPALIVE could be replaced by an UPDATE > that contains nothing at all. > > > Dave Walker > SS8 Networks > Ottawa, Canada > > > "Hussein F. Salama" wrote: > > > > I got a comment from a developer who doesn't like the use of the > > ITAD-Topology attribute in the UPDATE message. They strongly believe > > that we should define a new message dedicated to topology flooding, > > because many times an LS would like to update the the > topology without > > having new ReachableRoutes or WithdrawnRoutes to advertise. And in > > link-state protocols, there are usually separate message > for advertising > > the topology and others for advertising the routes. > > > > I can think of the following choices: > > 1. Define a new message for ITAD-Topology > > 2. Keep the attribute as it is today and specify how to fill in the > > mandatory arttributes (ReachableRoutes, WithdrawnRoutes, LocalPref, > > AdvertisementPath, ...) if there';s nothing to put in them. > > 3. Do nothing (may be give some guidelines in the BCP draft) > > > > I think the #1 is the right thing to do. What do you think? > > > > Hussein > > > > -- > > Hussein F. Salama > > Cisco Systems > > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Feb 25 20:22:41 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14289 for ; Sun, 25 Feb 2001 20:22:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B95A64436B; Sun, 25 Feb 2001 20:20:07 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8A3A444338 for ; Sun, 25 Feb 2001 20:19:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA01699; Sun, 25 Feb 2001 20:22:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Feb 2001 20:22:07 -0500 Message-ID: From: Jonathan Rosenberg To: Philip Mart , hsalama@cisco.com Cc: Jeff Hinchey , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] TRIP question on routing numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sun, 25 Feb 2001 20:22:06 -0500 Let me clarify here, at least based on my understanding. There was never an intention that TRIP would be used to exchange numbers in local dialing plans. This is well known to be frought with problems, as has been pointed out. Numbers represented as E.164 numbers would be exchanged within the decimal address family. However, it has been pointed out that we would like to use TRIP in environments where routing numbers would be used. These, apparently, have a different format, and in particular, they can have letters in some European country. So, these numbers would be exchanged via the penta-decimal address family. What Hussein has been implying is that configuration of the LS would be used to determine whether a peer was sending E.164 numbers, for example, or whether trip was being deployed in some other, more unusual, locale, where some other number type was being exchanged within the decimal address family. THis gives us flexibility to use TRIP in a variety of different applications. Hopefully Hussein, James Yu, and others involved in this decision will correct me or provide additional clarification. I'd like to resolve this quickly (I think its just a misunderstanding), so we can rev trip and then send the revised version to iesg. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Philip Mart [mailto:Philip.Mart@marconi.com] > Sent: Thursday, February 08, 2001 7:52 AM > To: hsalama@cisco.com > Cc: Jeff Hinchey; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] TRIP question on routing numbers > > > > > Hussein, > > If prefixes are to be included where are they specified so > that implementations > may interoperate? I guess I should also ask why a "Nature of > Address" field > wasn't included instead of the unspecified prefixes? This > would have the > advantage of not mandating a particular national, local or > even hypothetical > dialling plan which may in any case conflict with > interconnect arrangements. > > Phil Mart > > > > > > > > "Hussein F. Salama" on 08/02/2001 03:37:36 > > Please respond to hsalama@cisco.com > > > > > > > > > > > > To: Jeff Hinchey > > cc: "'iptel@lists.bell-labs.com'" > (bcc: Philip > Mart/MAIN/MC1) > > > > Subject: Re: [IPTEL] TRIP question on routing numbers > > > > > > > > > > > Jeff Hinchey wrote: > > > > > > > I was reviewing the latest version of the TRIP draft and > was a little > > confused over a statement in section 5.1.1.2, second > paragraph, which > > reads: > > > > "The type of Decimal Routing Number (private, local, > national, or > > international) can be deduced from the first few digits of the > > prefix" > > > > How is this accomplished? Telephone numbers only have meaning within > > the context of a specific number plan. E.164 public numbers and > > numbers from private number plans can begin with the same digits. > > Also, there is no way to determine if a public number is local, > > national or international based on leading digits. There is no > > reliable way to determine what number plan a number belongs to from > > only the number itself. > > > > Is the intent to include dial plan prefixes in addition to numbering > > plan addressing information in the routing numbers specified in the > > TRIP route? > > Yes, otherwise how can an LS differentiate between a local prefix, a > national prefix, and international prefix? > > > If so, how will this work when TRIP information is disseminated > > between ITADs serving different regions with different dial plans? > > A TRIP LS located at the egress from an ITAD may have to > manipulate the > prefix by prependinng/stripping off digits as necessary. > > Hussein > > > > > > > > > Jeff Hinchey > > Succession Network Architecture Nortel > > Networks > > 613 763 8007 / 613 765 4881 (fax) 3500 Carling > > Ave. > > jhinchey@nortelnetworks.com Nepean, > > Canada K2H 8E9 > > > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 28 10:21:50 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09066 for ; Wed, 28 Feb 2001 10:21:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6FDB84437D; Wed, 28 Feb 2001 10:07:01 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 4703444367 for ; Wed, 28 Feb 2001 10:06:29 -0500 (EST) Received: by dnspri.npac.com; id JAA13957; Wed, 28 Feb 2001 09:06:28 -0600 (CST) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma013721; Wed, 28 Feb 01 09:05:49 -0600 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 09:05:30 -0600 Message-ID: From: James Yu To: Jeff Hinchey Cc: "'iptel@lists.bell-labs.com'" , "'Jonathan Rosenberg'" , hsalama@cisco.com Subject: RE: [IPTEL] TRIP question on routing numbers MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 28 Feb 2001 09:00:58 -0600 As Jonathan pointed out, TRIP is used to exchange "routing numbers," which can be decimal or hexadecimal. Normally, international numbers are used; however, national numbers can be used if there is an agreement between two domains. It is not clear when local numbers and private numbers may be used as was pointed out by you. May be Hussein can explain. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, February 25, 2001 8:22 PM > To: Philip Mart; hsalama@cisco.com > Cc: Jeff Hinchey; 'iptel@lists.bell-labs.com' > Subject: RE: [IPTEL] TRIP question on routing numbers > > > Let me clarify here, at least based on my understanding. > > There was never an intention that TRIP would be used to > exchange numbers in > local dialing plans. This is well known to be frought with > problems, as has > been pointed out. Numbers represented as E.164 numbers would > be exchanged > within the decimal address family. > > However, it has been pointed out that we would like to use TRIP in > environments where routing numbers would be used. These, > apparently, have a > different format, and in particular, they can have letters in > some European > country. So, these numbers would be exchanged via the > penta-decimal address > family. > > What Hussein has been implying is that configuration of the > LS would be used > to determine whether a peer was sending E.164 numbers, for example, or > whether trip was being deployed in some other, more unusual, > locale, where > some other number type was being exchanged within the decimal address > family. THis gives us flexibility to use TRIP in a variety of > different > applications. > > Hopefully Hussein, James Yu, and others involved in this decision will > correct me or provide additional clarification. > > I'd like to resolve this quickly (I think its just a > misunderstanding), so > we can rev trip and then send the revised version to iesg. > > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Philip Mart [mailto:Philip.Mart@marconi.com] > > Sent: Thursday, February 08, 2001 7:52 AM > > To: hsalama@cisco.com > > Cc: Jeff Hinchey; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] TRIP question on routing numbers > > > > > > > > > > Hussein, > > > > If prefixes are to be included where are they specified so > > that implementations > > may interoperate? I guess I should also ask why a "Nature of > > Address" field > > wasn't included instead of the unspecified prefixes? This > > would have the > > advantage of not mandating a particular national, local or > > even hypothetical > > dialling plan which may in any case conflict with > > interconnect arrangements. > > > > Phil Mart > > > > > > > > > > > > > > > > "Hussein F. Salama" on 08/02/2001 03:37:36 > > > > Please respond to hsalama@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > To: Jeff Hinchey > > > > cc: "'iptel@lists.bell-labs.com'" > > (bcc: Philip > > Mart/MAIN/MC1) > > > > > > > > Subject: Re: [IPTEL] TRIP question on routing numbers > > > > > > > > > > > > > > > > > > > > > > Jeff Hinchey wrote: > > > > > > > > > > > I was reviewing the latest version of the TRIP draft and > > was a little > > > confused over a statement in section 5.1.1.2, second > > paragraph, which > > > reads: > > > > > > "The type of Decimal Routing Number (private, local, > > national, or > > > international) can be deduced from the first few > digits of the > > > prefix" > > > > > > How is this accomplished? Telephone numbers only have > meaning within > > > the context of a specific number plan. E.164 public numbers and > > > numbers from private number plans can begin with the same digits. > > > Also, there is no way to determine if a public number is local, > > > national or international based on leading digits. There is no > > > reliable way to determine what number plan a number > belongs to from > > > only the number itself. > > > > > > Is the intent to include dial plan prefixes in addition > to numbering > > > plan addressing information in the routing numbers > specified in the > > > TRIP route? > > > > Yes, otherwise how can an LS differentiate between a local prefix, a > > national prefix, and international prefix? > > > > > If so, how will this work when TRIP information is disseminated > > > between ITADs serving different regions with different dial plans? > > > > A TRIP LS located at the egress from an ITAD may have to > > manipulate the > > prefix by prependinng/stripping off digits as necessary. > > > > Hussein > > > > > > > > > > > > > > > Jeff Hinchey > > > Succession Network Architecture Nortel > > > Networks > > > 613 763 8007 / 613 765 4881 (fax) > 3500 Carling > > > Ave. > > > jhinchey@nortelnetworks.com Nepean, > > > Canada K2H 8E9 > > > > > > > -- > > Hussein F. Salama > > Cisco Systems > > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134 > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > > > > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Feb 28 10:37:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09796 for ; Wed, 28 Feb 2001 10:37:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF7324435C; Wed, 28 Feb 2001 10:37:01 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from usc.edu (usc.edu [128.125.253.136]) by lists.bell-labs.com (Postfix) with ESMTP id 4D9D144337 for ; Wed, 28 Feb 2001 10:36:41 -0500 (EST) Received: from aludra.usc.edu (klan@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA17541 for ; Wed, 28 Feb 2001 07:36:40 -0800 (PST) Received: from localhost (klan@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id HAA29506 for ; Wed, 28 Feb 2001 07:36:38 -0800 (PST) From: klan To: iptel@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [IPTEL] traffic model Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 28 Feb 2001 07:36:38 -0800 (PST) Hi everybody, Is there any study that has tried to characterize the ip telephony traffic? If yes, can somebody point me where I can find it? Thanks in advance. Regards, Kun-chan Lan _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel