Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00987; 1 Aug 94 6:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00983; 1 Aug 94 6:12 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02567; 1 Aug 94 6:12 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA199779034; Mon, 1 Aug 1994 01:17:14 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from bells.cs.ucl.ac.uk by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA199609031; Mon, 1 Aug 1994 01:17:11 -0700 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 1 Aug 1994 09:16:26 +0100 To: HUANG FAN Cc: comp.dcom.cell-relay@usenet.ucs.indiana.edu, ip-atm@matmos.hpl.hp.com Subject: Re: one phenomenon on ATM routing In-Reply-To: Your message of "Sun, 31 Jul 94 12:56:24 MDT." Date: Mon, 01 Aug 94 09:16:18 +0100 Message-Id: <530.775728978@cs.ucl.ac.uk> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Crowcroft >We have an ATM network which is configured by two ATM switches(buffalo >and cowboy). Now, I just connect two workstations(SUNSparc5 and SGI Indy) >to buffalo. When I traceroute from buffalo to every ATM network element, >I find a strange phenomenon. The first packet of the first time I >traceroute on needs much more round trip time. Does that mean ATM need more >time to negotiate, comparing to ethernet? Is that reasonable? The following >info is about the traceroute: >to cowboy: >the first time: 402ms, 3ms, 3ms >the second time: 4ms, 3ms, 3ms right - you wouldn't want to be doign transaction processing over such as service would you? :-) its the VC setup time (though why its so large, i don't know - we don;''t see anything like .4 to .9 secs on the switches we use, more like .1 secs) whose switches are you using, and what signalling do they support....? also, if you are using them between routers, why don't you just configure PVCs (while we await ABR standardisation)? but imagine you were a bank with a big ATM (Automatic Teller Machine) account server, processing 10,000s of atm (asynchronous transfer mode) calls per second from remote ATMs - you'd be worried i suppose you'd configure a VC from every ATM over the atm to your server, but if they traversed a pay-for-use net, you'd get concerend over call-time charges, wouldn't you? but then i guess, call-time charges will just have to go:-) jon   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05487; 1 Aug 94 12:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05483; 1 Aug 94 12:22 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11402; 1 Aug 94 12:22 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA242143136; Mon, 1 Aug 1994 07:58:56 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from mail.bellcore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA241973134; Mon, 1 Aug 1994 07:58:54 -0700 Received: from eve (eve.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA07935; Mon, 1 Aug 1994 10:51:49 -0400 Received: from by eve (4.1/4.7) id AB19617; Mon, 1 Aug 94 11:01:43 EDT Date: Mon, 1 Aug 94 11:01:43 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9408011501.AB19617@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cfk@cc.bellcore.com, trf@cc.bellcore.com, pjs1@mail.bellcore.com, dck2@eve.bellcore.com, ecmt1@eve.bellcore.com, shannon@cc.bellcore.com, dlp@cc.bellcore.com, lerman@cc.bellcore.com, kaj@eve.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: one phenomenon on ATM routing Cc: comp.dcom.cell-relay@usenet.ucs.indiana.edu, ip-atm@matmos.hpl.hp.com something interesting from the net. this guy reports elsewhere atm call setup times of 400-900ms kaj ----------------------------------------- >We have an ATM network which is configured by two ATM switches(buffalo >and cowboy). Now, I just connect two workstations(SUNSparc5 and SGI Indy) >to buffalo. When I traceroute from buffalo to every ATM network element, >I find a strange phenomenon. The first packet of the first time I >traceroute on needs much more round trip time. Does that mean ATM need more >time to negotiate, comparing to ethernet? Is that reasonable? The following >info is about the traceroute: >to cowboy: >the first time: 402ms, 3ms, 3ms >the second time: 4ms, 3ms, 3ms right - you wouldn't want to be doign transaction processing over such as service would you? :-) its the VC setup time (though why its so large, i don't know - we don;''t see anything like .4 to .9 secs on the switches we use, more like .1 secs) whose switches are you using, and what signalling do they support....? also, if you are using them between routers, why don't you just configure PVCs (while we await ABR standardisation)? but imagine you were a bank with a big ATM (Automatic Teller Machine) account server, processing 10,000s of atm (asynchronous transfer mode) calls per second from remote ATMs - you'd be worried i suppose you'd configure a VC from every ATM over the atm to your server, but if they traversed a pay-for-use net, you'd get concerend over call-time charges, wouldn't you? but then i guess, call-time charges will just have to go:-) jon _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Kaj Tesink _/ _/ Bellcore _/ _/ - Broadband Data Services & Consulting vmail (908) 758-5254 _/ _/ 331 Newman Springs Rd. email kaj@cc.bellcore.com _/ _/ Red Bank, NJ 07701 faxmail (908) 758-4196 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03680; 2 Aug 94 10:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03676; 2 Aug 94 10:19 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07214; 2 Aug 94 10:19 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA042540616; Tue, 2 Aug 1994 05:30:16 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA042370614; Tue, 2 Aug 1994 05:30:14 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA04884; Tue, 2 Aug 1994 05:16:49 -0700 Received: from dxmint.cern.ch by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA03966; Tue, 2 Aug 1994 05:17:18 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24809; Tue, 2 Aug 1994 14:15:10 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09585; Tue, 2 Aug 1994 14:15:09 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Brian Carpenter CERN-CN Message-Id: <9408021215.AA09585@dxcoms.cern.ch> Subject: What to say to ATM Forum? To: ip-atm@matmos.hpl.hp.com Date: Tue, 2 Aug 1994 14:15:09 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 612 In Toronto, Mark solicited input for the ATM Forum discussions in September. Re their planned BOF on multiprotocol over ATM, I think the main thing is that if they are unhappy with RFC 1483, they should write down why, and refer it back to IETF for follow-up. It would be pretty disastrous if the Forum starts a divergent standards activity in this area. Remember that 1483 is already implemented in running code. Re ATM multicasting, do any IP multicast experts watch this list? If so, please speak up! Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10538; 2 Aug 94 13:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10534; 2 Aug 94 13:59 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12327; 2 Aug 94 13:59 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA067893585; Tue, 2 Aug 1994 09:06:25 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from cs.gmu.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA067723581; Tue, 2 Aug 1994 09:06:21 -0700 Received: from gershwin.cs ([129.174.4.15]) by cs.gmu.edu (4.1/SMI-4.1) id AA24540; Tue, 2 Aug 94 12:06:35 EDT Date: Tue, 2 Aug 94 12:06:35 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Pullen Message-Id: <9408021606.AA24540@cs.gmu.edu> To: Brian.Carpenter@cern.ch Subject: Re: What to say to ATM Forum? Cc: mpullen@matmos.hpl.hp.com, ip-atm@matmos.hpl.hp.com Brian, I'm not sure I qualify as an IP Multicast expert, but I'm very interested in multicasting networks and would like to be involved in discussions of IP-MC over ATM. I believe the IP-ATM WG should put forward a specification (based on at least one working implementation) to the ATM Forum, defining for them how we would like ATM to support multicast. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13597; 2 Aug 94 16:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13593; 2 Aug 94 16:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16495; 2 Aug 94 16:43 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA092604460; Tue, 2 Aug 1994 12:07:40 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA092414443; Tue, 2 Aug 1994 12:07:23 -0700 Date: Tue, 2 Aug 1994 12:07:23 -0700 Message-Id: <199408021907.AA092414443@matmos.hpl.hp.com> To: Brian.Carpenter@cern.ch Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: What to say to ATM Forum? Cc: ip-atm@matmos.hpl.hp.com >Re their planned BOF on multiprotocol over ATM, I think the main >thing is that if they are unhappy with RFC 1483, they should >write down why, and refer it back to IETF for follow-up. It >would be pretty disastrous if the Forum starts a divergent >standards activity in this area. Remember that 1483 is already >implemented in running code. To expand on this further. The hallway discussions on this concluded that what we want to give to our ATM Forum Liaison is a set of slides which details requirements for IPv4 over ATM that we'd like the ATM Forum to consider. The scope of a complete set of slides spans more than just this working group. Andy Malis feels we could combine ROLC and IPATM requirements into the same set. I was just about to post something to the list in a few days to start stimulating thought, but this is good enough a start. The following is where I've gotten mentally so far about requirement slides: IPv4 Encapsulation IPv4 Multicasting IPv4 Security IPv4 Routing All is entirely up for comment. The due date for these is the third week of September (for us). What we really need to do is our homework on the multicast and security. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13945; 2 Aug 94 17:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13940; 2 Aug 94 17:05 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16989; 2 Aug 94 17:05 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA106015251; Tue, 2 Aug 1994 12:20:51 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from diablo.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA105845250; Tue, 2 Aug 1994 12:20:50 -0700 Received: (aalles@localhost) by diablo.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA12822; Tue, 2 Aug 1994 12:23:01 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anthony Alles Message-Id: <199408021923.MAA12822@diablo.cisco.com> Subject: Re: What to say to ATM Forum? To: Brian.Carpenter@cern.ch Date: Tue, 2 Aug 94 12:23:01 PDT Cc: ip-atm@matmos.hpl.hp.com In-Reply-To: <9408021215.AA09585@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Aug 2, 94 2:15 pm X-Mailer: ELM [version 2.3 PL11] Brian, As far as I know, no one in the Forum is unhappy with RFC 1483 and there are no suggestions to revisit encapsulation issues, per se. Rather, some people have expressed some concern about the seemingly slow pace (I'm not passing judgement here) of the ROLC group in solving the single LIS restriction in RFC 1577. Hence the idea was to look at alternative ways of solving this problem - either by moving towards some kind of peer based model or by spurring a faster response from ROLC. This, at least, was one of the original motivations for organizing this BOF. Once the idea of the group was proposed however, some of us got together and talked a little about other things that we could tackle. In particular, we are very interested in using this group to tackle some of the layer 3 VLAN proposals (e.g. CiscoFusion) that some vendors have been discussing. Another topic that I'd be interested in tackling is that of multicast. On this last point, the Forum has often discussed, but never formally specified a *mechanism* for multicasting (mpt-to-mpt data flows). Most of the well know approaches have been raised - multicast servers, overlaid pt-to-mpt trees, VP multicasting etc, but the Forum as a whole has never made a definitive statement one way or the other on a standard ATM multicast mechanism. In the absence of such a statement, the LAN Emulation group, needing such a mechanism, decided to go off and work on defining the operation of a (LANE specific?) multicast server (or BUS as they call it). The other group that really needs a multicast solution, of course, is RFC 1577, since, as I have been saying for some time now, the lack of multicast for IP Over ATM is a crippling weakness for this in comparison to LANE. This group needs to decide, therefore, which of the known multicast mechanisms it wishes to use and then work on ways of specifying this. This group could do what the LANE people did and simply pick and specify a mechanism independently, and/or it could take a proposal to the ATM Forum for ratification. Either way, the most important thing is to move fast - this issue has been left unresolved for far too long and is really a great threat to the viability of IP over ATM. Hope this clarifies things. Anthony > > In Toronto, Mark solicited input for the ATM Forum discussions > in September. > > Re their planned BOF on multiprotocol over ATM, I think the main > thing is that if they are unhappy with RFC 1483, they should > write down why, and refer it back to IETF for follow-up. It > would be pretty disastrous if the Forum starts a divergent > standards activity in this area. Remember that 1483 is already > implemented in running code. > > Re ATM multicasting, do any IP multicast experts watch this list? > If so, please speak up! > > Regards, > Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) > voice +41 22 767 4967, fax +41 22 767 7155 > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14495; 2 Aug 94 17:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14491; 2 Aug 94 17:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18025; 2 Aug 94 17:54 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA125379786; Tue, 2 Aug 1994 13:36:26 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA125209781; Tue, 2 Aug 1994 13:36:21 -0700 Date: Tue, 2 Aug 1994 13:36:21 -0700 Message-Id: <199408022036.AA125209781@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: signaling draft last call IP-ATM'ers: Reminder: the last call for the signaling draft closes at 12PM PDT Saturday, August 6th. I've not seen any comment yet. Have y'all be reading it? (I'll be putting my comments forward by the deadline.) Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15204; 2 Aug 94 19:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15200; 2 Aug 94 19:14 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19634; 2 Aug 94 19:14 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA148445016; Tue, 2 Aug 1994 15:03:36 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA148275005; Tue, 2 Aug 1994 15:03:25 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AB02345 for ip-atm@matmos.hpl.hp.com; Tue, 2 Aug 94 18:02:34 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id PAA01695; Tue, 2 Aug 1994 15:01:37 -0700 Message-Id: <199408022201.PAA01695@aland.bbn.com> To: Brian.Carpenter@cern.ch Cc: ip-atm@matmos.hpl.hp.com Subject: Re: What to say to ATM Forum? In-Reply-To: Your message of Tue, 02 Aug 94 14:15:09 +0200. <9408021215.AA09585@dxcoms.cern.ch> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Tue, 02 Aug 94 15:01:35 -0700 Re ATM multicasting, do any IP multicast experts watch this list? If so, please speak up! I'm not a multicast expert, but I did write one of the multicast RFCs. What was the issue in Toronto? Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26010; 3 Aug 94 1:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26006; 3 Aug 94 1:09 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24740; 3 Aug 94 1:09 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA188945213; Tue, 2 Aug 1994 20:40:13 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from daiduk.kaist.ac.kr by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA188725194; Tue, 2 Aug 1994 20:39:54 -0700 Received: from camars.kaist.ac.kr by daiduk.kaist.ac.kr (4.1/KAISTNet-Relay-3.2) id AA23815; Wed, 3 Aug 94 12:28:54 KST Received: by camars.kaist.ac.kr (4.1/SMI-4.1) id AA11823; Wed, 3 Aug 94 12:38:17 KST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kim Byung Ho Message-Id: <9408030338.AA11823@camars.kaist.ac.kr> Subject: Working together, To: atmpost@matmos.hpl.hp.com Date: Wed, 3 Aug 94 12:38:17 KST Cc: ip-atm@matmos.hpl.hp.com X-Mailer: ELM [version 2.3 PL11] Dear researchers, I'm studying on switching fabric for ATM (or fast packet switching) systems. Recently, I have interested in what a switch architecture is better, how we can measure it, and what is the factor to decide its goodness. First, I'd like to start with scalability. The term of scalability is an important measure in areas of parallel architecture and it has already a common consensus of what is sclability. But, for switch architecture for ATM, I think that the meaning of scalability has to be redefined. Of course, I know that some general meanings of scalability for ATM switch have already discussed in several research papers. However, I think that more serious and analytical model for scalability will be necesary. So, if anyone has interest in this topic, I`d like to study together. I'll appreciate any comments and responses. Thanks in advance, Byungho Kim. bxkim@camars.kaist.ac.kr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11302; 3 Aug 94 15:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11298; 3 Aug 94 15:05 EDT Received: from [15.255.176.33] by CNRI.Reston.VA.US id aa14177; 3 Aug 94 15:05 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA266864552; Wed, 3 Aug 1994 10:22:32 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA266444398; Wed, 3 Aug 1994 10:19:58 -0700 Date: Wed, 3 Aug 1994 10:19:58 -0700 Message-Id: <199408031719.AA266444398@matmos.hpl.hp.com> To: Kim Byung Ho Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: Working together, Cc: ip-atm@matmos.hpl.hp.com > So, if anyone has interest in this topic, > I`d like to study together. > I'll appreciate any comments and responses. > > Byungho Kim. > bxkim@camars.kaist.ac.kr This is a good discussion topic for the comp.dcom.cell-relay newsgroup. Here we are not so much concerned with ATM fabrics themselves, rather what we do for IP over ATM given that an ATM fabric (of any type) exists. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11393; 3 Aug 94 15:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11389; 3 Aug 94 15:08 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14322; 3 Aug 94 15:08 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA281355600; Wed, 3 Aug 1994 10:40:00 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA281185599; Wed, 3 Aug 1994 10:39:59 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA25859; Wed, 3 Aug 1994 10:39:54 -0700 Received: from sangam.ncst.ernet.in by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA17901; Wed, 3 Aug 1994 10:40:20 -0700 Received: from parcom.UUCP (uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id XAA23903 for ip-atm@hpl.hp.com; Wed, 3 Aug 1994 23:06:36 +0530 Received: from parcom.UUCP by iucaa (4.1/SMI-4.1) id AA08918; Wed, 3 Aug 94 22:59:20+050 Received: by parcom (4.1/SMI-4.1) id AA21827; Wed Aug 3 22:56:18 1994 (GMT + 0530) Date: Wed Aug 3 22:56:18 1994 (GMT + 0530) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shreyas B Shah Message-Id: <9408031726.AA21827@parcom> Organisation: To: ip-atm@hplms2.hpl.hp.com Subject: Subscribe Shreyas B. shah CDAC, Pune University Campus, Pune 411 011 E Mail : shreyas@parcom.ernet.in   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11805; 3 Aug 94 15:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11800; 3 Aug 94 15:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14700; 3 Aug 94 15:23 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA295546623; Wed, 3 Aug 1994 10:57:03 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA295376611; Wed, 3 Aug 1994 10:56:51 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA08463; Wed, 3 Aug 94 13:57:01 EDT Received: from pothole.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA27861; Wed, 3 Aug 94 13:55:13 EDT Received: by pothole.fore.com (4.1/SMI-4.1) id AA00220; Wed, 3 Aug 94 13:54:57 EDT Date: Wed, 3 Aug 94 13:54:57 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fong-Ching Liaw Message-Id: <9408031754.AA00220@pothole.fore.com> To: Brian.Carpenter@cern.ch, aalles@cisco.com Subject: Re: What to say to ATM Forum, multicast Cc: ip-atm@matmos.hpl.hp.com FORE has a contribution (94-685) into ATM Forum in July which would make private ATM network to provide IP style multicasting, of course is it connection-oriented. I am in the middle of revising the contribution to reflect the result from July ATMF signaling group. Although targeted for UNI 4.0, I think we should make use of this capability for IP style multicast, and maybe either get this requirement into phase 1 P-NNI group (if this is to happen, I think a sub-working group or ad-hoc group should be formed to address the P-NNI multicast, i.e proceed multicast P-NNI in parallel to P-NNI unicast routing), or we (IP over ATM) specify an interim requirement which uses "servers" but do not try to optimize the performance as L-EMU does. In this way, we do not put our energy into less optimal solutions. I prefer we try to make this work into P-NNI phase 1 with the understanding that more people has to be involved to get the specification out (and multicast will be based on unicast routing etc.) comments ? -Fong p.s. I will make the revised contribution (for next meeting available) as soon as it is ready, but 94-685 gives fairly good description of what is proposed and accepted. > From atmpost@matmos.hpl.hp.com Tue Aug 2 16:08:49 1994 > Sender: atmpost@matmos.hpl.hp.com > X-Info: Submissions to ip-atm@matmos.hpl.hp.com > X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com > X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm > X-Loop: ATM CLP.bit ON > From: Anthony Alles > Subject: Re: What to say to ATM Forum? > To: Brian.Carpenter@cern.ch > Date: Tue, 2 Aug 94 12:23:01 PDT > Cc: ip-atm@matmos.hpl.hp.com > X-Mailer: ELM [version 2.3 PL11] > > Brian, > > As far as I know, no one in the Forum is unhappy with RFC 1483 and there are no suggestions to revisit encapsulation issues, per se. Rather, some people have expressed some concern about the seemingly slow pace (I'm not passing judgement here) of the ROLC group in solving the single LIS restriction in RFC 1577. > > Hence the idea was to look at alternative ways of solving this problem - either by moving towards some kind of peer based model or by spurring a faster response from ROLC. This, at least, was one of the original motivations for organizing this BOF. > > Once the idea of the group was proposed however, some of us got together and talked a little about other things that we could tackle. In particular, we are very interested in using this group to tackle some of the layer 3 VLAN proposals (e.g. CiscoFusion) that some vendors have been discussing. Another topic that I'd be interested in tackling is that of multicast. > > On this last point, the Forum has often discussed, but never formally specified a *mechanism* for multicasting (mpt-to-mpt data flows). Most of the well know approaches have been raised - multicast servers, overlaid pt-to-mpt trees, VP multicasting etc, but the Forum as a whole has never made a definitive statement one way or the other on a standard ATM multicast mechanism. In the absence of such a statement, the LAN Emulation group, needing such a mechanism, decided to go off and work on defining the operation of a (LANE specific?) multicast server (or BUS as they call it). > > The other group that really needs a multicast solution, of course, is RFC 1577, since, as I have been saying for some time now, the lack of multicast for IP Over ATM is a crippling weakness for this in comparison to LANE. This group needs to decide, therefore, which of the known multicast mechanisms it wishes to use and then work on ways of specifying this. This group could do what the LANE people did and simply pick and specify a mechanism independently, and/or it could take a proposal to the ATM Forum for ratification. Either way, the most important thing is to move fast - this issue has been left unresolved for far too long and is really a great threat to the viability of IP over ATM. > > Hope this clarifies things. > > Anthony > > > > > In Toronto, Mark solicited input for the ATM Forum discussions > > in September. > > > > Re their planned BOF on multiprotocol over ATM, I think the main > > thing is that if they are unhappy with RFC 1483, they should > > write down why, and refer it back to IETF for follow-up. It > > would be pretty disastrous if the Forum starts a divergent > > standards activity in this area. Remember that 1483 is already > > implemented in running code. > > > > Re ATM multicasting, do any IP multicast experts watch this list? > > If so, please speak up! > > > > Regards, > > Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) > > voice +41 22 767 4967, fax +41 22 767 7155 > > > > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12103; 3 Aug 94 15:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12099; 3 Aug 94 15:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15198; 3 Aug 94 15:36 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA011577849; Wed, 3 Aug 1994 11:17:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA011407848; Wed, 3 Aug 1994 11:17:28 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA27552; Wed, 3 Aug 1994 11:17:27 -0700 Received: from unet.Net.COM by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA18383; Wed, 3 Aug 1994 11:17:54 -0700 Received: from mac.net.com by unet.net.com (5.0/SMI-SVR4) id AA20077; Wed, 3 Aug 1994 11:08:41 +0800 Message-Id: <9408031808.AA20077@unet.net.com> Date: 3 Aug 1994 14:07:39 U Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Adam Gouda Subject: unsubscribe To: ip-atm Content-Length: 163 Subject: Time:2:07 PM OFFICE MEMO unsubscribe Date:8/3/94 unsubscribe   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13235; 3 Aug 94 16:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13231; 3 Aug 94 16:31 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16557; 3 Aug 94 16:31 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA031401669; Wed, 3 Aug 1994 12:21:09 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA031131648; Wed, 3 Aug 1994 12:20:48 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA27359 for ip-atm@matmos.hpl.hp.com; Wed, 3 Aug 94 15:20:01 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id MAA03111; Wed, 3 Aug 1994 12:19:27 -0700 Message-Id: <199408031919.MAA03111@aland.bbn.com> To: Fong-Ching Liaw Cc: Brian.Carpenter@cern.ch, aalles@cisco.com, ip-atm@matmos.hpl.hp.com Subject: Re: What to say to ATM Forum, multicast In-Reply-To: Your message of Wed, 03 Aug 94 13:54:57 -0400. <9408031754.AA00220@pothole.fore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Wed, 03 Aug 94 12:19:24 -0700 Fong: Could you put 94-685 on-line for anonymous FTP so we can read it? Thanks! Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15522; 3 Aug 94 19:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15518; 3 Aug 94 19:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20721; 3 Aug 94 19:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA054766766; Wed, 3 Aug 1994 13:46:06 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA054496742; Wed, 3 Aug 1994 13:45:42 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA09242; Wed, 3 Aug 94 16:46:09 EDT Received: from pothole.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA13102; Wed, 3 Aug 94 16:44:18 EDT Received: by pothole.fore.com (4.1/SMI-4.1) id AA00315; Wed, 3 Aug 94 16:43:58 EDT Date: Wed, 3 Aug 94 16:43:58 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fong-Ching Liaw Message-Id: <9408032043.AA00315@pothole.fore.com> To: fong@fore.com, craig@aland.bbn.com Subject: Re: What to say to ATM Forum, multicast Cc: Brian.Carpenter@cern.ch, ip-atm@matmos.hpl.hp.com, dmarlow@relay.nswc.navy.mil, samir@arch4.att.com Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 12 Here is the revised contribution. It has not gone through review (both internal and ATMF Sig WG), but I post it here anyway since this tells the result of July meeting. People have access to SIG working group minutes please speak up if I did not got the results right. Feedback on the open issues, new problems, and proposed mechanisms are extremely welcome. Thanks. -Fong ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: atm94-0685R1 X-Sun-Content-Lines: 587 *************************************************************************** ATM FORUM: Signaling Sub-Working Group ATM Forum/94-0685R1 (Draft send to ip-atm) *************************************************************************** TITLE: UNI Procedures and ATM Group Addresses *************************************************************************** SOURCE: Fong-Ching Liaw fong@fore.com Drew Perkins ddp@fore.com FORE Systems, Inc. 174 Thorn Hill Road, Warrendale, Pennsylvania 15086 *************************************************************************** DATE: September 26-29 1994 *************************************************************************** ABSTRACT: ATM Group addresses were proposed as a Phase II signalling requirement in ATMF 93-0889 and were subsequently accepted (ATMF 94-0014, 94-0139, 94-0351). This contribution clarifies the services provided by ATM group addresses and provides a basis for agreement on procedures at the UNI. This revision reflects the results from Irvin 94 ATM Forum Signaling Working Group meeting. The main change to the proposed capability set are : (1) support of this capability is optional in private networks. (2) support of this capability is for further study in public networks. (3) allow members to indicate whether to participate in established connection when join. (4) remove the guarantee of one data stream at the user-network interface. Open issues identified by the group are listed as well. The later sections of this contribution then draft the specification text as if it is written in UNI 4.0 specification. *************************************************************************** DISTRIBUTION TO: ATM Forum Technical Working Group Members *************************************************************************** NOTICE This contribution has been prepared to assist the ATM Forum. This document is offered to the Forum as a basis for discussion and is not a binding proposal on FORE Systems, Inc. The requirements are subject to change in form and numerical value after more study. We specifically reserves the right to add to, amend, or withdraw the statements contained herein. I. Introduction ATM Group addresses were proposed as a Phase II signalling requirement in ATMF 93-0889 and were subsequently accepted (ATMF 94-0014, 94-0139, 94-0351, 94-0685). In July Irvin meeting, signaling working group has accepted the following as drafting guidelines to the UNI 4.0 specification: I.1 July meeting agreements (1) Support of group address capability is optional in private networks, and is for furthur study in public networks. (2) Accept the capability set of ATM Group addresses as modified by the group (this is reflected in section 1.1) (3) Adopt OSI NSAP group address format as ATM group address format (4) Accept use of UNI 3.1, UNI 4.0 Leaf Initiated Join Procedures, and ILMI procedure as bases to manage ATM groups and connections to groups. I.2 July meeting open issues 1. Scoping of ATM group membership distribution and connection reachability is FFS. Looking for requirement contribution to address this issue. The requirement contribution shall be discussed in P-NNI WG. 2. The procedure needs to address failure scenario when connecting to group members failed due to resources constraints. This issue is addressed in this contribution using the following guideline : (a) The network shall re-establish (reroute or not) if the connection to a member failed due to temporary network outage, or resource shortages. This related to NNI procedures and is out of this specification's scope. (b) The network shall re-establish if the members fail to respond to the call arrival indication (i.e. SETUP or ADD PARTY from network). This specification addresses this situation by retransmitting SETUP or ADD PARTY message infinite number of times. 3. Network returning list of existing connections in ILMI group address registration procedure is FFS. Looking for requirement statement. This draft text does not address this procedure. I.3 New open issues 1. Need of well-known group addresses. Look for requirement contributions. The implication of this requirement is the need to identify well-known group address assigning authority as well as obtaining well-known group address prefixes. The draft text does not address this issue. 2. Can we assign group addresses and individual addresses inside an delegated authority using rules different from ISO's (i.e. pairing). The draft text assumes address assigning inside individual organization is not in pair. 3. Shall we allow de-registration of a group address with different value of scope and/or call offering object without de-register ? The text assumes it is not allowed. 4. Shall we allow specifying transit network selection (which specifies provider such as AT&T, MCI, etc.) when the called party address is an ATM Group address ? The draft text does not allow requesting transit network selection in a call to ATM Group address. 5. Called party address remains as ATM Group Address at destination's user-network interface. I.4 Capabilities Supported by ATM Group Addresses (as of July 94) This section reflects the results from July Irvin meeting, items marked by (*) are either new or changed to reflect the result. These capabilities are drafted into *0. Support of ATM Group Address is optional for private networks. Public network's support is FFS. 1. ATM Group Addresses identify ATM Groups. 2. ATM Groups include a set of zero or more ATM endpoints called group Members. 3. Group membership is dynamic. Members may come and go at any time. 4. At any time, an ATM endpoint may be a Member of zero or more ATM Groups identified by their corresponding ATM Group Addresses. *5. ATM endpoints must join the ATM Groups for which they wish to receive connections from the network. Group Members may leave the group at anytime. When a member leaves, existing connections are not cleared the by network, but the network shall not offer new connections to the exiting member. (Note, whether to disconnect existing connection when member leaves is flagged by Mr. Cherukuri of IBM. This contribution retains the original proposal to maintain consistency with procedures of individual and anycast addresses.) 6. An ATM Group Address may be used in a Called Party Number or Called Party Subaddress Information Element of both SETUP and ADD_PARTY messages. Calling Parties use existing call control procedures (ATM Forum UNI 3.1) to establish connection(s) with Group Members. 7. Calling Parties do not have to be Members of the ATM Group to which they are calling. 8. Zero or more parties may establish Group Connections to an ATM Group Address simultaneously. *9. ATM endpoints use the existing address registration procedures (ILMI address registration) to join and leave groups. Members may indicate willingness to receive existing connections in the registration procedure. The time between a member register their group address and receive indication to existing connection is as soon as practical. *10. The connection configuration (in the Bearer Capability IE) of a group connection shall be restricted to point-to-multipoint. In this configuration, the network shall indicate the arrival of the point-to-multipoint connection to all members of the group. Other connection configuration types are for further study. *11. ATM endpoints may close the connections any time. Optionally, ATM Group members may request to be added back to the connection later. *12. ATM endpoints request to be added back to a previously closed point-to-multipoint connection by executing UNI 4.0 "leaf initiated join" procedures. *13. (Deleted.) II. Service Definitions and Address Format This following text defines the services provided by ATM group addresses, it is a summary statement of the capability set without procedure details. This service definition shall be considered as text for section X.8 in atm94-0625, as well as in the UNI 4.0 specification as labeled in its section head. 5.1.2.15 Support of ATM Group Service Addresses Multicast service is the service whereby data sent by a user are delivered to multiple users. The multicast service provided by ATM networks strives for efficient resource utilization when possible. The ATM group addresses described in this specification provide efficient multicast service where receiving end systems are identified by an ATM group addresses. Support of ATM group addresses in private networks is optional. Support of this capability in public networks are for further study. ATM groups are collection of ATM end systems. ATM group addresses are special typed ATM addresses which identify ATM groups. The ATM groups identified by ATM group addresses are open groups, i.e. they do not have a pre-defined set of members. Unless specified, we do not distinguish "ATM groups" from "ATM groups identified by ATM group addresses" in the remaining of this specification. ATM Group addresses identify end systems, and do not imply any other call control parameters, such as traffic parameter and call screening/security parameters. These call control parameters shall be indicated to the network by explicit call parameters in the call request messages. Membership of an ATM group are dynamic, members may join and leave the group any time. An ATM group may have zero or more members, any ATM end system can be member of zero or more ATM groups at any time. When an end system joins an ATM Group, it may indicate to the network whether it wants to participate in established connections which have the group address as their participant. If the member indicates its intention to participate in the established connections when it joins the group, the network must indicate arrival of all established connections which have the group as their participants to the newly joining member. The arrival of these connections shall be indicated to the new members on the principle of as soon as practical. In addition, the network shall offer all connections, which have a group address as their participant, to all members of the group who join prior to the establishment of the connections. The determination of "prior" and "after" is based on local decision. When an ATM end system wishes to use an ATM group address to send data to the ATM group members, it shall first establish a point-to-multipoint connection before sending any data, therefore, the service is connection-oriented. The calling user of an ATM group address does not have to be a member of the ATM group. The calling user may request the network to inform itself the status (acceptance or rejection of the connection) of individual members. The network shall establish a point-to-multipoint connection according to the requested call parameters, such as traffic and security/screening parameters, and the connection shall reach every member of the group. The calling user may establish the connection passing a "call identifier" in the call request message if it wishes to allow members to close and then reconnect to the connection. In the cases where connection establishment toward some members failed due to network resource constraints or user does not respond to call arrival indication, networks shall indefinitely re-establish the connection toward the failed member if the calling user does not request network to notify it the party status; otherwise networks shall notify the calling user upon these failures and clear the call toward the failed members. A calling user may establish multiple independent point-to-multipoint connections to the same group, and may establish connections to different groups at the same time. An ATM point-to-multipoint connection may have zero or more ATM groups as its participates. There can have zero or more calling users to an ATM group at any time. Members of an ATM group may close a connection any time, and optionally reconnect to the connection if calling user provides a "call identifier" in the connection request message. Finally, when a member leaves an ATM group, the network shall not disconnect established connections whose call states are in active or establishing state at the member's user-network interface prior to the leave. 5.1.3.4 ATM Group Addresses ATM Group Addresses are modeled after the group address adopted by ISO for NSAP [4], which have the same structure as the individual NSAP addresses (which is also the structure of private ATM addresses). In this format, the AFI field, in addition to identifying an address authority, also identifies whether an address is an individual ATM address or a group ATM address. ISO allocated 90 AFI values of each type in a paired fashion. These values are listed in figure 5-1d. If the value of first two digits of the IDP are hexadecimal FF, it indicates the presence of an incomplete group address. The use of incomplete group address is for further study in ATM networks. ATM group addresses shall be 20 octets long. ISO delegates address assigning authority to other organizations for address blocks identified by an AFI. When such a delegation is made, address assigning authority is delegated simultaneously for both individual addresses and their corresponding group addresses. It should be noted that when an end system "owns" an individual ATM address, it does not own the corresponding group address. The allocation and use of group addresses inside an ISO delegated authority depends on individual delegated authority. ATM Group addresses may be used in called party address and called party subaddress in SETUP and ADD PARTY messages of a point-to-multipoint connection. The code points used for ATM Group addresses in Q.2931 called party address (subaddress) information elements shall be the same as those used by private ATM individual addresses. Figure 5-1d - Relationship of AFI Individual and Group Values [note] ----------------------------------------------------------- |Individual Group | Individual Group | Individual Group | ----------------------------------------------------------- | 0x FF | | | | 10 A0 | 40 BE | 70 DC | | 11 A1 | 41 BF | 71 DD | | 12 A2 | 42 C0 | 72 DE | | 13 A3 | 43 C1 | 73 DF | | 14 A4 | 44 C2 | 74 E0 | | 15 A5 | 45 C3 | 75 E1 | | 16 A6 | 46 C4 | 76 E2 | | 17 A7 | 47 C5 | 77 E3 | | 18 A8 | 48 C6 | 78 E4 | | 19 A9 | 49 C7 | 79 E5 | | 20 AA | 50 C8 | 80 E6 | | 21 AB | 51 C9 | 81 E7 | | 22 AC | 52 CA | 82 E8 | | 23 AD | 53 CB | 83 E9 | | 24 AE | 54 CC | 84 EA | | 25 AF | 55 CD | 85 EB | | 26 B0 | 56 CE | 86 EC | | 27 B1 | 57 CF | 87 ED | | 28 B2 | 58 D0 | 88 EE | | 29 B3 | 59 D1 | 89 EF | | 30 B4 | 60 D2 | 90 F0 | | 31 B5 | 61 D3 | 91 F1 | | 32 B6 | 62 D4 | 92 F2 | | 33 B7 | 63 D5 | 93 F3 | | 34 B8 | 64 D6 | 94 F4 | | 35 B9 | 65 D7 | 95 F5 | | 36 BA | 66 D8 | 96 F6 | | 37 BB | 67 D9 | 97 F7 | | 38 BC | 68 DA | 98 F8 | | 39 BD | 69 DB | 99 F9 | ----------------------------------------------------------- [note] use of this table is permitted by Dave Marlow, NRL [4] III. ILMI MIBs The following text provides extensions in ILMI MIBs to support ATM group addresses. The text are labeled by intended section numbers. 5.8.4.2 Address Group [Add the new object to information of the group] . ATM Address Call Offering 5.8.5.1 Network-Side UME [Add the following text for Group and Anycast Address] If the network does not support the referenced address type (such as group or anycast addresses), it shall respond with a Response containing an error code wrongType(7). If the address is currently registered but has different value for its scope object or different value for call offering object, the network shall respond with a Response containing an error code "inconsistentValue(12)". The address remains registered with no change to values of scope and call offering object. If the referenced address is an ATM Group address, and the value of the call offering object is "all(1)", the network shall start the process of connection arrival indication to the user-network interface after it sends back a Response message of noError return code. 5.8.5.2.2 Registration of ATM Group Addresses ATM end systems may join ATM Group Addresses anytime after ascertaining that the network-side's ATM Address table is empty. This is done by reading the first instance of the ATM Address Status object (i.e. issue GetNext request) after sending the ColdStartTrap (this procedure is described in section 5.8.5.2.) For any ATM Group Address G which the user wishes to join, it issues an appropriate SetRequest, e.g.: SetRequest { atmfAddressStatus.port.address=valid(1), atmfAddressCallOffering.port.address=all(1), atmfAddressScope.port.address=scope } The address shall contain the ATM group address G. If the end system does not specify value for atmfAddressCallOffering object, the default value is "all(1)". If the end system does not specify the value for the atmfAddressScope object, the default value for atmfAddressScope object is TBD. To register the same group address with different value for scope object or call offering object, members must first de-register the group address, and re-register again. Connections (including those already established toward the member) may be offered again by the network, therefore, members shall be prepared to cope with multiple data streams from one point-to-multipoint connection. To leave an ATM group and stop receiving connection arrival indications of which the group address is a participant, the user-side UME issues an appropriate SetRequest, e.g., SetRequest { atmfAddressStatus.port.address=invalid(2) } [Note] Deregistration of group addresses shall not cause established connections to be cleared by network. 5.8.6 MIB definition [add/modify as the following] atmfAddressEntry::= SEQUENCE { atmfAddressPort INTEGER, atmfAddressAtmAddress AtmAddress, atmfAddressStatus INTEGER, atmfAddressScope INTEGER, atmfAddressCallOffering INTEGER } atmfAddressCallOffering OBJECT-TYPE SYNTAX INTEGER {all(1), new(2)} ACCESS read-write STATUS mandatory DESCRIPTION "An indication of whether network shall indicate presence of established connections to the registering user. If set to the value all(1), the network shall make such presence indication to the user-netsork interface for all connections which have the referenced group address as its participant. If set to the value new(2), the network shall indicate arrival of connections which are established after the referenced group address is registered." ::= {atmfAddressCallOffering 5 } [note, atmfAddressScope object will be fully specified in ATMF 94-0494] IV. Information Elements Two new information elements, Global Call Identifier (GCID) and Leaf Initiated Join Parameters (LIJP) [defined in 94-0325R1 for Leaf Initiate Join Extensions] may be used by group members and group calling parties to allow group members to reconnect to a previously closed connection. We expect these two IEs will be fully specified in 94-0325R#. 5.4.5.15 Cause [Add the new cause code values to give a better description of the failure.] #001/address "Address type not supported" V. Connection Control Procedure The existing point-to-multipoint procedure is used by Calling Parties and group members to manage connections. The following text documents the necessary call control extensions to support ATM group addresses. 5.5.1.4 Invalid Call/Connection control information [add] If the called party address contains an ATM group address and the network does not support the group address capability, the network shall reject the add party request with cause cause #001/address "Adderss type not supported", 5.5.1.5 Call/Connection proceeding If the network progresses a call establishment toward remote user(s) whose called party address is an ATM Group address, the network shall not change the called party address from group address to individual address at group member's user-network interface. 5.5.1.7 Call/Connection acceptance [add to the end of second paragraph] If the called party address of the SETUP message is an ATM group address, the CONNECT message does not indicate to the calling user that there is actually a connection through the network to all eligible members of the group, instead it indicates to the user that the network is on the process of establishing the connection to all eligible members. 5.5.1.9 Transit networks selection [add or modify the text to describe interaction with group addresses] The network shall clear the call request if the SETUP message contains a transit network selection information element and the called party address is an ATM Group address. 5.5.2.1 Incoming Call/Connection request [add to the end] If the called party address is an ATM Group Address, the network shall retransmit the SETUP message upon the expiration of T303. The number or retransmit shall be infinite. The timer value may be increased upon every expiration of timer T303. 5.6 Call/Connection Control Procedures for Point-to-Multipoint Calls 5.6.1.3 Invalid Call/Connection Control Information or Service Request in the ADD PARTY message [add] If the called party address contains an ATM group address and the network does not support the group address capability, the network shall reject the add party request with cause cause #001/address "Address type not supported". 5.6.1.4 Add Party Received [add to the end] If the network progresses a call establishment toward remote user(s) whose called party address is an ATM Group address, the network shall not change the called party address to individual address at member's user-network interface. 5.6.2.5.3 Call failure Upon expiration of timer T399, the network shall initiate procedures to send an ADD PARTY REJECT message toward the calling user with cause code #18 "no user responding" if party state notification is required; if party state notification is not required and the called party address is an ATM Group address, the network shall retransmit the ADD PARTY message to the user-network interface, and start timer T399. The network may increase value of T399 upon each T399 timer expiry. 5.7 List of timers 5.7.1 Timers in the Network Side [add node to restart timers for group addresses] T303, second expiry - If the called party address is an ATM Group address, and party state notification is not required, timer T303 shall be restarted, and the value may be increased by a configured amount. T399- first expiry & second expiry - If the called party address is an ATM Group address, and party state notificaton is not required, timer T399 shall be restarted, and the timer value may be increased by a configured amount. VI. References [1] "Leaf Initiated Join Extensions," R. Bubenik, ATM Forum 94-0325. [2] "ATM User Network Specification Specification 3.0," ATM Forum. [3] Host Group Extensions for CLNP Multicasting," Dave Marlow, Internet draft, May 1994. [4] Amendments to ISO standards to support CLNP multicast extensions: "ISO 8348 AM5 Amendment to the Network Service to support Group Network Addressing.", International Standard ISO 8348 Amendment 5, ISO/IEC JTL 1, Switzerland 1994. [5] ITU-T Recommendation X.6 "Multicast Service Definition", March 1993   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16510; 3 Aug 94 20:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16504; 3 Aug 94 20:25 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21623; 3 Aug 94 20:25 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA082144692; Wed, 3 Aug 1994 15:58:12 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA081974687; Wed, 3 Aug 1994 15:58:07 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id SAA03512; Wed, 3 Aug 1994 18:57:56 -0400 Message-Id: <199408032257.SAA03512@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: ip-atm@matmos.hpl.hp.com Cc: gja@thumper.bellcore.com Subject: Comments on draft-ietf-ipatm-sig-01.txt Date: Wed, 03 Aug 94 18:57:54 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [..] >>I've not seen any comment yet. Have y'all be reading it? >>(I'll be putting my comments forward by the deadline.) >>Mark Well, I've got some thoughts on the matter, but I must disclaim them first before I proceed. I was working on a Q.2931 and IP-over-ATM implementation at the University of Melbourne, in Australia, between March and June. I'd planned on contributing to this discussion before relocating to Bellcore, unfortunately I didn't. This means (a) my comments have no intentional relationship to Bellcore, (b) sorry for not getting in earlier, and (c) although I raise some questions I admit I'm not sure I have any immediate answers. o A specific comment. In section 5. "Brief Overview of UNI...." the end of the 3rd paragraph reads "If the destination endpoint is able to accept the call, it responds with a CONNECT message; otherwise, it sends a RELEASE COMPLETE message." I believe the Called Party is entitled to issue a CALL PROCEEDING/CONNECT sequence if wishes. This is likely (in fact I'd say essential) in implementations where the called party's Q.2931 entity and AAL Users are decoupled. An arriving SETUP may result in an immediate CALL PROCEEDING response from the Called Party's Q.2931 entity, while it locally queries the called IP-ATM entity to see if the SETUP's conditions are acceptable. The acceptance of the SETUP's conditions would _then_ cause the Q.2931 entity to issue a CONNECT back to the switch. The two possible refusal modes at the Called Party then become: (a) Called Party has _no_ IP-ATM entity resident. Issue RELEASE COMPLETE in response to SETUP. (b) Called Party has a resident IP-ATM entity, so CALL PROCEEDING was issued. The IP-ATM entity rejects the call request, so a RELEASE is issued instead (to be acknowledged by the switch/"network" with RELEASE COMPLETE). o A general issue. On a more general note (i.e. I'm going to 'arm wave' :) I feel uncomfortable with the 'tone' or 'scope' of the draft. In common with other IETF documents I've seen, it gives a reasonably concise overview of the link layer technology we are aiming to use, in this case the operation of the signalling elements and their role in establishing and removing VCs between IP entities. Now usually this is a Good Thing. However, I don't think there is sufficient decoupling of the roles of the ATM signalling entity and the IP-over-ATM entity within the description of the generic 'ATM endpoint supporting IP'. The draft's tight coupling of Q.2931 signalling exchanges to events within the IP-ATM entity seem _almost_ to suggest that the IP-ATM entity is responsible for issuing and receiving Q.2931 messages over its underlying ATM link(s). The difficulty here is obviously that there is no 'well defined' local interface to the black box known as "ATM Signalling" in Figure 1. However, I think it is important we consider writing a generic 'local signalling interface' (LSI, just to create a new TLA), and express the needs and actions of the IP-ATM entity in these terms. The LSI's capabilities will obviously be defined by the needs of protocols such as IP (or an LLC entity providing a termination point for the general VC carrying RFC1483 encapsulated traffic). The decoupling is complete when an appendix is added showing the relationship between LSI signals/indications and Q.2931 signalling activity. As an example, my implementation was based under SunOS4.1.1, using a STREAMs resident AAL. Multiple upper stream connections were established to the AAL driver/module using clone-open mechanism. Each stream carried both data and local signalling requests between AAL Users and the underlying AAL/ATM/Q.2931 service. My IP-ATM module would 'talk' to the local Q.2931 entity when it needed to open or close a VC, and the Q.2931 entity would undertake to communicate to the local switch on its behalf. Incoming VC requests would be fielded by the local Q.2931 entity on behalf of the IP-ATM module, using information supplied when the IP-ATM module 'bound' or 'registered' itself locally. The present draft is a good document for specifying the IEs and their values. Am I the only one who thinks it is tying the IP-ATM entities too closely to actual Q.2931 signalling messages? (Obviously braindead comments on my part will be blamed on jet-lag :-) regards, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17148; 3 Aug 94 21:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17144; 3 Aug 94 21:31 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22549; 3 Aug 94 21:31 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA106199857; Wed, 3 Aug 1994 17:24:17 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA106019852; Wed, 3 Aug 1994 17:24:12 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA04152; Wed, 3 Aug 1994 17:24:10 -0700 Received: from netcom13.netcom.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA22717; Wed, 3 Aug 1994 17:24:41 -0700 Received: by netcom13.netcom.com (8.6.8.1/Netcom) id RAA07386; Wed, 3 Aug 1994 17:21:55 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Semaphore Communications Message-Id: <199408040021.RAA07386@netcom13.netcom.com> Subject: unsubscribe To: majordomo@matoms.hpl.hp.com Date: Wed, 3 Aug 1994 17:21:55 -0700 (PDT) Cc: ip-atm@hplms2.hpl.hp.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 28 unsubscribe scc@netcom.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17168; 3 Aug 94 21:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17164; 3 Aug 94 21:33 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22576; 3 Aug 94 21:33 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA104949781; Wed, 3 Aug 1994 17:23:01 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA104779780; Wed, 3 Aug 1994 17:23:00 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA03583; Wed, 3 Aug 1994 17:22:59 -0700 Received: from netcom13.netcom.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA22711; Wed, 3 Aug 1994 17:23:26 -0700 Received: by netcom13.netcom.com (8.6.8.1/Netcom) id RAA07282; Wed, 3 Aug 1994 17:20:41 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Semaphore Communications Message-Id: <199408040020.RAA07282@netcom13.netcom.com> Subject: unsubscribe To: ip-atm@hplms2.hpl.hp.com Date: Wed, 3 Aug 1994 17:20:40 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 27 unsubscribe scc@netcom.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18916; 3 Aug 94 22:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18912; 3 Aug 94 22:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23767; 3 Aug 94 22:45 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA136222997; Wed, 3 Aug 1994 18:16:37 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA136052995; Wed, 3 Aug 1994 18:16:35 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA03451 for ip-atm@matmos.hpl.hp.com; Wed, 3 Aug 94 21:16:20 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id SAA03501; Wed, 3 Aug 1994 18:15:52 -0700 Message-Id: <199408040115.SAA03501@aland.bbn.com> To: ip-atm@matmos.hpl.hp.com Subject: signalling draft last call (comments) Reply-To: Craig Partridge Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Wed, 03 Aug 94 18:15:50 -0700 Mark et al.: I've taken a few minutes to try to comment on my most serious concerns about the draft (version 01). This comments are rushed and probably a bit raw, but I hope still useful. p. 3 - a policy concern -- examples mention RFC 1490 encapsulation. I believe it is the current IETF policy (which took much work) that there is ONE multiprotocol encapsulation, name RFC 1483 and we should do nothing in the context of an IP over ATM doc to encourage multiple divergent protocol encapsulations. p. 3 - Systems "MUST" add a random increment (we know random-ness in this situation saves from deadlocks -- let's do this right the first time). p. 3 top of page 4. The spec says Private UNIs should monitor both in and out traffic for activity. It says nothing about Public UNIs (in, out, both)? Note that by this point, I concluded that section 4 needs subsections, to wit: VC Establishment Multiprotocol Support on VCs Support for Multiple VCs VC Teardown There's too much going on in this section to read it without subsection headings. p. 5 (section 6) Here I need definitions. Does SHALL = MUST? In any case, at the start of the document, I think the meaning of conformance (and thus the use of SHALL, MUST, SHOULD, MAY) has to be defined (ala the HOST REQUIREMENT RFCs). Also, I prefer the word MUST over the word SHALL in all uses in this document. SHALL admits of more equivocation by implementors. Also, the word "may" in "and may, under certain circumstance[s]..." should be capitalized. [In general, every instance of MAY, SHOULD, MUST has to be in caps -- just run sed over the document. It is very useful for pointing up unintended requirements...] p. 5. Annex A is cited but does not exist and appears to actually be Appendix B. Also, it seems to me that if certain field values are required -- then the appendix should be part of the core document (and we should be saying things like the LLI field must be set to XYZ). p. 5 Section 7.1 -- this paragraph bothered me: The 'mode' field SHOULD be omitted from the AAL Parameters IE. If present it is appropriate to set it to "message" mode, as opposed to "streaming" mode. Nevertheless, it SHALL be ignored by the destination endsystem. It seemed to be equivocating (too many shoulds, shalls, etc). How about The 'mode' field SHOULD be omitted from the AAL Parameters IE and MUST be ignored by the destination end system. p. 5 There's something missing at the transition of page 5 to page 6. The text has a gap. p. 6 top Discusses interworking between ATM and Frame Relay. Dammit, we decided that the answer for interoperation is to do LLC/SNAP. That's why we chose one standard. Let's not reopen it. If folks want to do Frame Relay emulation over ATM, that's great, I'm all for it. But format conversion from Frame Relay/ATM to LLC/SNAP/ATM is a job for routers in the IP architecture. So get rid of this stuff. p 6. middle Typo ALL -> AAL B-LLI MUST specify LLC/SNAP except in experimental circumstances (such as VC multiplexing). That's the standard. p. 7 In 7.2.1 RFC 1483 does not recognize FRSSCS -- it simply says that if one wanted to do it, one can do it this way. (Incidentally, RFC 1483 wasn't supposed to permit nul encaps either but we didn't beat on Juha hard enough). We should not recommend implementation of multiple standards -- recall the decision of the multiproto encaps group -- ONE standard. Rather this text should say, that conformant implemenations MUST implement LLC/SNAP and MAY (at vendor discretion) do VC multiplexing. Frame Relay is out of scope and signalling option (c) should be left out. p. 9/10 Section 8.1 If best effort is available, the VC should include the BEI. This begs the question: * what if the BEI is not present and the network supports BE? Second, I think the handwaving that applications SHOULD know the bandwidth doesn't work. Applications like TELNET & FTP don't tell TCP how much bandwidth they want. They expect TCP to figure it out. So we need some default amount for TCP to negotiate. How about 2 Mb/s at the Private UNI and 64 Kb/s at the public UNI? (Complete handwaving here -- use SHOULD). Ditto handwaving in 8.2 and 8.3 p. 12 Section 8.4 This section completely leaves out a tricky problem. What is the meaning of the selector field in the NSAPAs and E.164 addresses? My understanding is that for IP over ATM purposes the view is that the selector field is irrevlent (i.e. two NSAPAs with different selector fields map to the same IP address), but that folks are assuming that if one runs ATM direct between applications (no IP) then the selector field is used to select the desired application. In other words, there are two ways to use the selector field and we need to write down here the official way to use it when doing IP over ATM. p. 15 Appendix A should be removed -- this is a frame relay problem, not an ATM problem. Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06991; 4 Aug 94 13:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06987; 4 Aug 94 13:11 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09376; 4 Aug 94 13:11 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA236692778; Thu, 4 Aug 1994 08:06:18 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from riker.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA236522777; Thu, 4 Aug 1994 08:06:17 -0700 Received: from localhost (perez@localhost) by riker.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id LAA20745; Thu, 4 Aug 1994 11:06:02 -0400 Message-Id: <199408041506.LAA20745@riker.cmf.nrl.navy.mil> X-Authentication-Warning: riker.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: gja@thumper.bellcore.com Cc: ip-atm@matmos.hpl.hp.com Subject: Re: Comments on draft-ietf-ipatm-sig-01.txt In-Reply-To: Your message of "Wed, 03 Aug 94 18:57:54 EDT." <199408032257.SAA03512@thumper.bellcore.com> Date: Thu, 04 Aug 94 11:06:01 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Maryann Perez Maher Grenville, ] In section 5. "Brief Overview of UNI...." the end of the 3rd paragraph ] reads ] "If ] the destination endpoint is able to accept the call, it responds with ] a CONNECT message; otherwise, it sends a RELEASE COMPLETE message." ] ] I believe the Called Party is entitled to issue a CALL PROCEEDING/CONNECT ] sequence if wishes. This is likely (in fact I'd say essential) in We worded the statement as such because sending the CALL PROCEEDING is optional and only the CONNECT serves as the 'official' indication that a call is accepted. We should probably mention that a CALL PROCEEDING may precede the CONNECT. Nevertheless, I think explaining how/when CALL PROCEEDINGs could be be used is dwelling too deeply into implementation/ architecture issues. ] o A general issue. ] ] However, I don't think there is sufficient decoupling of the ] roles of the ATM signalling entity and the IP-over-ATM entity ] within the description of the generic 'ATM endpoint supporting IP'. ] The draft's tight coupling of Q.2931 signalling exchanges to events ] within the IP-ATM entity seem _almost_ to suggest that the ] IP-ATM entity is responsible for issuing and receiving Q.2931 ] messages over its underlying ATM link(s). In the draft we use phrases like "ATM signaling 'in support of' IP over ATM". Our intention was to make it clear that signaling is a separate entity that can be implemented in a manner to support IP over ATM environments (by setting up VCs with the appropriate characteristics). ] The difficulty here is obviously that there is no 'well defined' ] local interface to the black box known as "ATM Signaling" in ] Figure 1. However, I think it is important we consider writing Right, there is no well defined interface, meaning that there is no defined way for IP to 'tell' signaling what it wants. That is why, as you point out, we are specifying many of these signaling values. However, I believe these interface issues are beyond the scope of this draft and should not be tackled in an appendix. Or are you speaking of a separate document? Maryann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09183; 4 Aug 94 14:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09179; 4 Aug 94 14:39 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11251; 4 Aug 94 14:39 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA259578651; Thu, 4 Aug 1994 09:44:11 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA259408648; Thu, 4 Aug 1994 09:44:08 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id MAA21386; Thu, 4 Aug 1994 12:43:21 -0400 Message-Id: <199408041643.MAA21386@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Maryann Perez Maher Cc: gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: Comments on draft-ietf-ipatm-sig-01.txt In-Reply-To: Your message of Thu, 04 Aug 94 11:06:01 -0400. <199408041506.LAA20745@riker.cmf.nrl.navy.mil> Date: Thu, 04 Aug 94 12:43:20 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [..] >>We worded the statement as such because sending the CALL PROCEEDING is >>optional and only the CONNECT serves as the 'official' indication that >>a call is accepted. Earlier in the same paragraph the response of the network to the calling party is noted to be either CALL PROCEEDING or CONNECT. Just for accuracy and consistency the same should occur for the description of the Called Party's response. I take your point that further detail is probably not warranted, at least in section 5. However, this document explains in reasonable detail the relationship between Q.2931 signalling element exchanges and 'state changes' in the notional IP-ATM interface layer. Given this, I think it is worth noting the possible scenarios where an end system's Q.2931 entity uses CALLPROCEEDING/CONNECT vs CONNECT when fielding a SETUP on behalf of an IP-ATM entity. Where this should be noted, I'm not yet sure. >>] o A general issue. [..] >>In the draft we use phrases like "ATM signaling 'in support of' >>IP over ATM". Our intention was to make it clear that signaling >>is a separate entity that can be implemented in a manner to support >>IP over ATM environments (by setting up VCs with the appropriate >>characteristics). I'm still struggling to decide whether my concerns are phantoms or not, so bear with me a little longer :-) The abstract currently begins " This memo describes how implementations of IP over ATM should use ATM call control signaling procedures to establish and release ATM connections. [...]" This wording bothers me, because in a very real sense IP-ATM implementations will use a _local_ interface to their "ATM signalling" black-box. Yet the wording seems to suggest that an IP-ATM interface actually sends and receives Q.2931 messages, and talks directly to the nearest attached switch ("the network"). My gut feel is that something more like " This memo describes the ATM call control signalling exchanges needed to support IP over ATM implementations." would be a better start. It would then be followed by " ATM endpoints will incorporate ATM signalling services as specified in the ATM Forum User-Network Interface (UNI) Specification Version 3.0 [ATMF93]. IP over ATM implementations utilise the services of local ATM signalling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signalling entities. " and away we go. The rest of the draft's signalling related sections (7,8,9, and 10) would, I think, sit better underneath this introduction. [..] >>Right, there is no well defined interface, [..] >>Or are you speaking of a separate document? If the current draft's introduction were changed, then my concerns are greatly reduced. It would certainly then be 'neater' for a separate document to evolve and describe the local signalling/application interface. regards, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19725; 4 Aug 94 23:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19721; 4 Aug 94 23:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21521; 4 Aug 94 23:18 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA031630829; Thu, 4 Aug 1994 18:40:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from postoffice3.mail.cornell.edu by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA031460828; Thu, 4 Aug 1994 18:40:28 -0700 Received: from [132.236.236.59] (CU-DIALUP-0217.CIT.CORNELL.EDU [132.236.236.59]) by postoffice3.mail.cornell.edu (8.6.5/8.6.5) with SMTP id VAA24930; Thu, 4 Aug 1994 21:38:57 -0400 Message-Id: <199408050138.VAA24930@postoffice3.mail.cornell.edu> X-Sender: swb1@postoffice3.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Aug 1994 21:37:57 -0400 To: Anthony Alles , Brian.Carpenter@cern.ch Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scott W Brim Subject: Re: What to say to ATM Forum? Cc: ip-atm@matmos.hpl.hp.com Anthony, in the last paragraph excerpted below you refer to "this group". Excuse me but I can't quite tell which group you're referring to. Would this be an ATM Forum BOF? Thanks ... Scott At 12:23 8/2/94 -0700, Anthony Alles wrote: >As far as I know, no one in the Forum is unhappy with RFC 1483 and there are no suggestions to revisit encapsulation issues, per se. Rather, some people have expressed some concern about the seemingly slow pace (I'm not passing judgement here) of the ROLC group in solving the single LIS restriction in RFC 1577. > >Hence the idea was to look at alternative ways of solving this problem - either by moving towards some kind of peer based model or by spurring a faster response from ROLC. This, at least, was one of the original motivations for organizing this BOF. > >Once the idea of the group was proposed however, some of us got together and talked a little about other things that we could tackle. In particular, we are very interested in using this group to tackle some of the layer 3 VLAN proposals (e.g. CiscoFusion) that some vendors have been discussing. Another topic that I'd be interested in tackling is that of multicast.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24210; 5 Aug 94 0:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24206; 5 Aug 94 0:55 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23922; 5 Aug 94 0:55 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA067207743; Thu, 4 Aug 1994 20:35:43 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA066877740; Thu, 4 Aug 1994 20:35:40 -0700 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA11166 for ip-atm@matmos.hpl.hp.com; Thu, 4 Aug 94 23:35:27 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id UAA04254; Thu, 4 Aug 1994 20:34:53 -0700 Message-Id: <199408050334.UAA04254@aland.bbn.com> To: ip-atm@matmos.hpl.hp.com Subject: no comments on my comments? Reply-To: Craig Partridge Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Thu, 04 Aug 94 20:34:52 -0700 Hi folks: Am I the only person that got my comments on the signalling draft? I haven't heard any replies back and want to make sure that my comments are recorded before the close of comment period, since I think some of the concerns I raise are sufficient to require another draft. Thanks! Craig E-mail: craig@aland.bbn.com or craig@bbn.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24233; 5 Aug 94 0:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24229; 5 Aug 94 0:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23962; 5 Aug 94 0:58 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA050795769; Thu, 4 Aug 1994 20:02:49 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hubbub.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA050625764; Thu, 4 Aug 1994 20:02:44 -0700 Received: from [198.93.167.63] (dynaserv-d1-dynamic-63.cisco.com [198.93.167.63]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id UAA20924; Thu, 4 Aug 1994 20:02:33 -0700 Message-Id: <199408050302.UAA20924@hubbub.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Aug 1994 20:02:36 -0700 To: Scott W Brim , Brian.Carpenter@cern.ch Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anthony Alles Subject: Re: What to say to ATM Forum? Cc: ip-atm@matmos.hpl.hp.com At 9:37 PM 8/4/1994 -0400, Scott W Brim wrote: >Anthony, in the last paragraph excerpted below you refer to "this >group". Excuse me but I can't quite tell which group you're referring >to. Would this be an ATM Forum BOF? Yes, I meant the ATM Forum multiprotocol over ATM BOF. Anthony > >Thanks ... Scott > >At 12:23 8/2/94 -0700, Anthony Alles wrote: > >As far as I know, no one in the Forum is unhappy with RFC 1483 and there are > no suggestions to revisit encapsulation issues, per se. Rather, some people > have expressed some concern about the seemingly slow pace (I'm not passing > judgement here) of the ROLC group in solving the single LIS restriction in > RFC 1577. > > > >Hence the idea was to look at alternative ways of solving this problem - > either by moving towards some kind of peer based model or by spurring a > faster response from ROLC. This, at least, was one of the original > motivations for organizing this BOF. > > > >Once the idea of the group was proposed however, some of us got together and > talked a little about other things that we could tackle. In particular, we > are very interested in using this group to tackle some of the layer 3 VLAN > proposals (e.g. CiscoFusion) that some vendors have been discussing. Another > topic that I'd be interested in tackling is that of multicast. _____________________________________________________________________ Anthony Alles Cisco Systems Product Manager: ATM Tel: 408-526-5424 email: aalles@cisco.com Fax: 408-526-7666 Mail: 170 West Tasman Drive, San Jose CA 95134-1706, USA. Cisco Location: Building D, San Jose Single Site.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24319; 5 Aug 94 1:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24315; 5 Aug 94 1:20 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24247; 5 Aug 94 1:20 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA094358838; Thu, 4 Aug 1994 20:53:58 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA094028836; Thu, 4 Aug 1994 20:53:56 -0700 Date: Thu, 4 Aug 1994 20:53:56 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <199408050353.AA094028836@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Subject: ip-atm list processing improved IP-ATM'ers: I've added some smarts to the ip-atm distribution list processing. If the subject of the message is either "subscribe" or "unsubscribe" alone on the line or if either of the first two lines of the body of the message being with "subscribe" or "unsubscribe", the message is cheerfully returned to the sender with an informative help message. Hopefully, this will help and cut down on the problems we've been seeing. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24459; 5 Aug 94 1:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24455; 5 Aug 94 1:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24527; 5 Aug 94 1:43 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA112871102; Thu, 4 Aug 1994 21:31:42 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from radegond.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA112541100; Thu, 4 Aug 1994 21:31:40 -0700 Received: from localhost (mankin@localhost) by radegond.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id AAA02385; Fri, 5 Aug 1994 00:31:33 -0400 Message-Id: <199408050431.AAA02385@radegond.cmf.nrl.navy.mil> X-Authentication-Warning: radegond.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: Craig Partridge Subject: Re: no comments on my comments? In-Reply-To: Your message of "Thu, 04 Aug 94 20:34:52 PDT." <199408050334.UAA04254@aland.bbn.com> Cc: ip-atm@matmos.hpl.hp.com Date: Fri, 05 Aug 94 00:31:32 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Allison J Mankin Craig, There will be a full response to your comments soon, but here's a quick one. Between Seattle and Toronto, several of us (the NRL group with concurrence from Mark) tried to make a case to the WG for simply omitting the FR interworking stuff. We got protest in the WG from a number of serious voices. I explored offline among IP network providers and heard that they strongly hoped that there would be clear guidance on FR IWU interoperability with ATM subscribers, because they would evolve their subscriber interconnects away from FR as late as possible. FR is the very useful for their practical traffic engineering (policing a peak data rate from subscriber sites in a reasonably flexible way). This suggests that ATM SVC bandwidth policing is not viewed as soon to arrive in any effective form... I see Appendix A as trying to be a tactful caveat emptor (or caveat provisor) for the FR interworking practice, but it may need to be more clear in this. The WG already agreed to take the list of alternative encapsulations out of the main body of the draft, which will help. The general goal of the draft is to offer a simple and rational way to use ATM SVCs under IP. Unfortunately the problem space doesn't entirely lend itself to simple and rational. Allison / mankin@cmf.nrl.navy.mil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24854; 5 Aug 94 2:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24850; 5 Aug 94 2:40 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25279; 5 Aug 94 2:40 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA136813650; Thu, 4 Aug 1994 22:14:10 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA136493648; Thu, 4 Aug 1994 22:14:08 -0700 Date: Thu, 4 Aug 1994 22:14:08 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <199408050514.AA136493648@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Subject: my comments on signalling draft General Comments: 0. I'm wearing my normal person hat, not the WG Chair one. So these comments are my personal opinions. They are not official opinions. 1. In general this is a good draft. It needs to be brought a little bit more in to line with other RFC formats. I've passed some scripts to Maryann. 2. It needs be made very clear that this is an RFC1577 (and RFC1483) implementaton reference. Issues dealing with RFC1490 and FRSSCS incompatibility issues with call setup should be completely moved to an appendix so as not to confuse implementers. I think the material important enough to be documented, but implementation standards are beyond the scope of this memo and this WG. Also, with the ATM Forum's recent announcement to form a Multiprotocol over ATM BOF, it might be more suited if they tell us how to do it, or folks from this WG work with that effort to help in the definition. We can fix up any solved issues when this draft goes from proposed to draft standard. Mark ------------------------------------------------------------ Specific Comments: 2. Abstract .... Once UNI 3.1 is publicly available, this I-D will be updated to reflect the changes. At the WG meeting, we agreed to focus on UNI3.0 only. I'd suggest moving a comment about UNI3.1 to an issues list at the end. (Like in 1577). 3. Overview ..... This memo describes how the signaling protocol is used in support of IP over ATM, and, in particular, the information exchanged in the signaling protocol to effect this support. This statement conflicts with the abstract, as it said this was also a multiprotocol spec over ATM. Let's pick IP over ATM. A taxonomy of subnet and end-to-end networking models is pro- vided in [COLE94]. The simplest case is the Classical IP over ATM model described in RFC 1577. COLE94 is not a published document and cannot be reference here. I-D's cannot be referenced in RFC's. It is very likely we will not have the framework document published prior to this doc becoming an RFC. 4. Use of protocol procedures ... When two ATM endsystems run multiple protocols, an ATM connection may be shared among two or more datagram protocol entities, as long as the VCC owner allows sharing, as well as if the encapsulation allows proper multiplexing and demultiplexing, (i.e., the LLC/SNAP encapsulation or RFC 1490 over FRSSCS). I would move a comment to the issues list that this version of the document is specifically an RFC1577/1483 implementation document. Although RFC1577 and RFC1483 specify an LLC/SNAP encapsulation, which is inherently a multiprotocol encapsulation, it is beyond to scope of this document to go into any multiprotocol specifications other than to point out some examples (see Appendix x for an example of FRSSCS). Further, at the time of the writing of this draft, the ATM Forum is creating a Multiprotcol over ATM activity which we expect to be developed jointly with the IETF. ... However, if the VCC is shared among several protocol entities, the ATMARP client or server SHALL not disconnect the call as suggested in RFC1577. Comment: IP and ARP are two LLC/SNAP protocol entities. If a VCC to an ATMARP client/server is being used for IP also, the VCC need not be closed. 5. Brief Overview of UNI Call Setup Signaling Procedures and Messages This section provides a summary of point-to-point signaling procedures. Readers are referred to [ATMF93] and [Q2931]. Q2931 has a "to be published" date. This needs to be a real date with a real reference in order to be referenced. 7.1. ATM Adaption Layer Parameters .... The exception will occur in the event that the network provides interworking between ATM and Frame Relay. In this case, the ATM endsystem will receive a SETUP or CONNECT message containing an AAL Parameters IE with the SSCS Type field coded as Frame Relay SSCS. The call SHALL be cleared with cause #93, AAL Parameters not supported unless the ATM endsystem supports RFC 1490 encapsulation over FRSSCS, and a Broadband Low Layer Information IE is coded to indicate RFC 1490 encapsulation (see below). This is very confusing. Is this document requiring that RFC1490 encapsulation be implemented to support cleared calls with cause #93? FRSSCS details should be moved to the appropriate appendix and made clear that this document doesn't require FRSSCS, etc.. If an RFC1577 implementation receives any cleared call with cause #93, the RFC1577/1483 connection just cannot be made. If we find in the future that the multiprotocol over ATM activity in the ATM Forum gives us an acceptable method for dealing with these sorts incompatibilities, then we can roll those specs into this draft when it goes from proposed -> draft status. 7.2. Broadband Low Layer Information ... (c) Use of RFC 1490 over the Frame Relay Service Specific Convergence Sublayer (FRSSCS) Again, (c) can be moved to be part of the appendix. Mentioning it here in the main body is confusing and suggests to implementers that they can support this. RFC 1577 specifies LLC/SNAP as the default encapsulation. Therefore LLC encapsulation SHOULD be indicated in the B-LLI as shown in figure D.3.1 of [ATMF93]. Signaling indication of other encapsulations is discussed in the next section. Signalling indication of VC multiplexing is discussed in the next section. 7.2.1. Encapsulation negotiation ... Nevertheless, RFC 1483 also specifies VC-multiplexing and recognizes use of RFC 1490 over FRSSCS. I would reword: RFC1483 also specifies VC-multiplexing which is detailed in this memo. RFC1490 and FRSSCS details, while not part of this implementatio reference, are discussed in Appendix xx. ... VC-multiplexing SHOULD be implemented to achieve maximum interoperability. I disagree with this statement. LLC/SNAP achieves maxium default interoperability as it supports both IP and ATMARP. VC-mux'ing is protocol specific and does not support ARP. Details relating to the performance details of LLC/SNAP vs VC-mux'ing are beyond the scope of this memo. Implementation of RFC 1490 encapsulation over FRSSCS is also recommended for interworking with Frame Relay networks. Such interworking does have its problems however as discussed later. Drop this paragraph. c) RFC 1490 encapsulation (MLPID multiplexing) over FRSSCS (D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS type of AAL Parameters IE.) Again, drop from main body and move to appendix. Also MLPID -> NLPID. The calling ATM endsystem can only send and receive packets using RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS. Use of RFC 1490 encapsulation presently cannot be negotiated as an alternative to LLC encapsulation or VC-multiplexing (see Appendix B). If the B- LLI IE is encoded to indicate RFC 1490 encapsulation, the SSCS type field of the AAL Parameters IE SHALL coded to indicate FRSSCS. Note that the AAL Parameters IE can not be coded to indicate both NULL and FR-SSCS and neither LLC encapsulation nor VC-multiplexing will be interoperable when used over FR-SSCS. This paragraph should be dropped from the main body and moved to the beginning of the FRSSCS paragraph. It is a good lead-in to the section in describing the problem. 8.3. QoS Parameter .... Note: In UNI 3.1 a new code point of '00' has been added to the coding standard field in the IE header. This code point has been added for compatibility with Q.2931 and is to be used when indicating the Unspecified QoS class (class 0). Therefore, the coding standard field SHALL be set to '00' when indicating QoS class 0, as is suggested for IP. This note goes away as this is a UNI 3.0 implementation only. [COLE94] IP over ATM: A Framework Document Internet Draft Again, RFC's can't reference I-D's. I-D's are temporary documents. [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-Packard Laboratories, December 1993 The actual date is January 1994. [Q.2931] Broadband Integrated Service Digital Network (B-ISDN) Digital Subscriber Signaling System No.2 (DSS2) User Network Interface Layer 3 Specification for Basic Call/Connection Control ITU-T Recommendation Q.2931, (International Telecommunication Union: Geneva, 1994) (to be published March, 1994) Again, when is this draft real? Appendix A. Frame Relay Interworking Suggestion: Let's make this the last appendix. Suggestion: your title here is appendix, but the references in the main body are "annex". Please make them agree. Specification of the SSCS restricts the encapsulation protocol used over it, since RFC 1483 (in addition to applicable ITU standards) requires the use of RFC 1490 encapsulation over the FR-SSCS, and LLC or null encapsulation otherwise. The fact that it is not possible, in the UNI 3.1 signaling specification, to negotiate between the FR- SSCS and null SSCS can result in interoperability restrictions between stations that implement and wish to use the FR-SSCS and those that do not, even though they both are using IP. The guidelines in the following section were developed to decrease the chance that such interoperability restrictions occur. Strike UNI 3.1. True in 3.0 also? Appendix B. Sample Signaling Messages Suggestion: Make this Appendix A. This is important to the main body of this memo.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24951; 5 Aug 94 3:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24947; 5 Aug 94 3:04 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25551; 5 Aug 94 3:04 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA174445647; Thu, 4 Aug 1994 22:47:27 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA174125646; Thu, 4 Aug 1994 22:47:26 -0700 Date: Thu, 4 Aug 1994 22:47:26 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <199408050547.AA174125646@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Subject: minutes submitted FYI IP-ATM'ers: The only change to the minutes was "Bryan" to "Brian". I've submitted the previous minutes as the official ones. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00397; 5 Aug 94 3:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00393; 5 Aug 94 3:55 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00898; 5 Aug 94 3:55 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA208328810; Thu, 4 Aug 1994 23:40:10 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA208008809; Thu, 4 Aug 1994 23:40:09 -0700 Date: Thu, 4 Aug 1994 23:40:09 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Message-Id: <199408050640.AA208008809@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Subject: slight oops on minutes Minor oops, this paragraph was added under the IPng section of the minutes: Also, Brian mentioned that ATM'ers might be well advised to keep an eye on IPng auto-config since it might not cater for an NBMA model unless reminded about this need. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06258; 5 Aug 94 13:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06254; 5 Aug 94 13:01 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11217; 5 Aug 94 13:01 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA002430384; Fri, 5 Aug 1994 08:26:24 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA002080381; Fri, 5 Aug 1994 08:26:21 -0700 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00880 for ip-atm@matmos.hpl.hp.com; Fri, 5 Aug 94 11:26:07 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA04480; Fri, 5 Aug 1994 08:25:04 -0700 Message-Id: <199408051525.IAA04480@aland.bbn.com> To: Allison J Mankin Cc: ip-atm@matmos.hpl.hp.com Subject: Re: no comments on my comments? In-Reply-To: Your message of Fri, 05 Aug 94 00:31:32 -0400. <199408050431.AAA02385@radegond.cmf.nrl.navy.mil> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Fri, 05 Aug 94 08:25:00 -0700 Hi Allison: Thanks for the note. Regarding the Frame Relay issues. I think the right approach is to issue two documents: * how to do signalling for IP over ATM * how to do signalling so that FR systems can interwork with Multiprotocol Encaps systems. I have at least three strong reasons for this suggestion: - First, by having them separate, we clearly distinguish between the minimum required (just Multiprotocol LLC/SNAP) and the larger set of functionality (using FR too). This is nice for folks like me who are doing implementations without FR and don't want to have to keep explaining to folks who see FR mentioned in the document that FR isn't an essential part of the standard. - Second, we can make the language stronger in the FR sections. Right now one has to be careful to keep emphasizing that the FR stuff is optional and that sometimes makes it unclear what exactly FR compatibility requires. It works much better to write a separate document that says, "If you are doing FR-LLC/SNAP interworking, here's how the signalling MUST be done..." (I.e., MUST can return to the writers' vocabulary). - Third, when folks start profiling ATM implementations in RFQs and RFPs (i.e., what features precisely they want), the profiling is easier. Currently, if they cited this document, they'd need to add wording about whether FR compatibility signalling is or is not required. If the docs are separate, there's no ambiguity. If they cite the FR doc, it is required, otherwise it isn't. Thanks! Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11073; 5 Aug 94 16:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11069; 5 Aug 94 16:59 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16741; 5 Aug 94 16:59 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA029137853; Fri, 5 Aug 1994 10:30:53 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA028787823; Fri, 5 Aug 1994 10:30:23 -0700 Date: Fri, 5 Aug 1994 10:30:23 -0700 Message-Id: <199408051730.AA028787823@matmos.hpl.hp.com> To: Craig Partridge Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach X-Sender: laubach@netcom.com (Unverified) Subject: Re: signalling draft last call (comments) Cc: ip-atm@matmos.hpl.hp.com >p. 3 - a policy concern -- examples mention RFC 1490 encapsulation. I > believe it is the current IETF policy (which took much work) that there > is ONE multiprotocol encapsulation, name RFC 1483 and we should do nothing > in the context of an IP over ATM doc to encourage multiple divergent > protocol encapsulations. The WG meeting shared the same concern. As per Allison's note too. The agreement that we had was to make in unambiguous that the main body of the draft followed RFC1577 and RFC1483. Moving the RFC1490 FRSSCS text into the last appendix and noting that it's an issue and a topic for the ATM Forum multiprotocol over ATM BOF is probably a good compromise, but I've given more thought on it - see below. >p. 5 (section 6) > > Here I need definitions. Does SHALL = MUST? In any case, at the > start of the document, I think the meaning of conformance (and thus > the use of SHALL, MUST, SHOULD, MAY) has to be defined (ala the HOST > REQUIREMENT RFCs). Also, I prefer the word MUST over the word > SHALL in all uses in this document. SHALL admits of more equivocation > by implementors. The draft needs the standard conventions section added. I too like to use the words MUST, SHOULD, or MAY in preference to the others. 1. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. > Also, the word "may" in "and may, under certain circumstance[s]..." > should be capitalized. [In general, every instance of MAY, SHOULD, > MUST has to be in caps -- just run sed over the document. It is very > useful for pointing up unintended requirements...] Ditto. > Annex A is cited but does not exist and appears to actually be > Appendix B. Also, it seems to me that if certain field values are > required -- then the appendix should be part of the core document > (and we should be saying things like the LLI field must > be set to XYZ). Maryann, after thinking about this comment from Craig, I agree with him. Please consider moving the coding appendix into the main body of the draft. > But format conversion from Frame Relay/ATM to LLC/SNAP/ATM is a job > for routers in the IP architecture. So get rid of this stuff. Again, this version of the draft took a big step away from the early version. I had talked with Maryann at the meeting and suggested we might want to be cleaner on keeping the body of the draft focused on LLC/SNAP. I made my comment to the draft in that light. > We should not recommend implementation of multiple standards -- recall > the decision of the multiproto encaps group -- ONE standard. I'll leave this to the consensus of the WG. Should this draft specification deal with LLC/SNAP only or is it ok to mention Null Encapsulation. Should VC multiplexing be moved to its own Appendix as a compromise? > Rather this text should say, that conformant implemenations MUST implement > LLC/SNAP and MAY (at vendor discretion) do VC multiplexing. Frame > Relay is out of scope and signalling option (c) should be left out. Nice way of putting it. > Second, I think the handwaving that applications SHOULD know the bandwidth > doesn't work. Applications like TELNET & FTP don't tell TCP how much > bandwidth they want. They expect TCP to figure it out. So we need some > default amount for TCP to negotiate. How about 2 Mb/s at the Private UNI > and 64 Kb/s at the public UNI? (Complete handwaving here -- use SHOULD). I don't think the state of the stack is at a point yet where we can comment on the bandwidth needs of individual above-IP applications. RFC1577 only deals with IP connection between members. > This section completely leaves out a tricky problem. What is the > meaning of the selector field in the NSAPAs and E.164 addresses? > > My understanding is that for IP over ATM purposes the view is that > the selector field is irrevlent (i.e. two NSAPAs with different > selector fields map to the same IP address), but that folks are assuming > that if one runs ATM direct between applications (no IP) then the selector > field is used to select the desired application. In other words, there > are two ways to use the selector field and we need to write down here > the official way to use it when doing IP over ATM. Good point raised. > Appendix A should be removed -- this is a frame relay problem, not > an ATM problem. It looks from what I can tell that multiprotocol interoperability, as viewed from the Forum, will occur via Inter Working Units (IWUs). The IWU will speak one type of protocol on one side, say FRSSCS and another on the other side, say null SSCS. IWU's may be standalone or co-resident in certain boxes. IWUs will be responsible for call setup mapping, encsapsulation translation,etc. The important point about the above is that caller->called binding is symmetrical on either side of the VC. If we agree on this model, then RFC1577 implementations willl never talk to RFC1490 implementations directly, they will go through and IWU. Working with IWUs fall under the multiprotocol work of the ATM Forum and is beyond the scope of what this document. If we, the WG agree, then the suggest appendix should be cut away. If we also agree, a statement about need IWU definitions can be sent as part of the requirements we'll be sending to the Forum. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11231; 5 Aug 94 17:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11227; 5 Aug 94 17:09 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16926; 5 Aug 94 17:09 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA030037859; Fri, 5 Aug 1994 10:30:59 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA029577857; Fri, 5 Aug 1994 10:30:57 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA25809; Fri, 5 Aug 1994 12:30:54 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1) id AA06321; Fri, 5 Aug 1994 12:30:52 -0500 Received: from dbg.dev.cdx.mot.com (dbg.dev.cdx.mot.com [134.33.32.39]) by merlin.dev.cdx.mot.com (8.6.9/8.6.9) with ESMTP id NAA17405; Fri, 5 Aug 1994 13:30:51 -0400 Received: from localhost (localhost [127.0.0.1]) by dbg.dev.cdx.mot.com (8.6.9/8.6.5) with SMTP id NAA23465; Fri, 5 Aug 1994 13:30:50 -0400 Message-Id: <199408051730.NAA23465@dbg.dev.cdx.mot.com> X-Authentication-Warning: dbg.dev.cdx.mot.com: Host localhost didn't use HELO protocol To: Craig Partridge Cc: ip-atm@matmos.hpl.hp.com Subject: Re: no comments on my comments? In-Reply-To: Your message of "Fri, 05 Aug 94 08:25:00 PDT." <199408051525.IAA04480@aland.bbn.com> Date: Fri, 05 Aug 94 13:30:49 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp I had been hoping to stay out of this, having just about washed my hands of the entire document. My original intent was that the FR interworking procedures be mandatory. There was a lot of complaining about that, and thus the current state of the document. The whole issue (IMHO) results from the decision to use different encapsulations in RFC 1483 and RFC 1490, which I always thought was a terrible mistake. Implementations of this I-D will have no a priori way of knowing when interworking will occur, and any implementation that does not support the fallback to FRSSCS will not always work. Also, there is good, consistent flow in this text. Breaking it to refer to an appendix, or, worse yet, to another document, will only serve to create confusion. Please leave the text as it is. On another point, now is a good time to change the reference to UNI 3.1, especially since UNI 3.1 corrects an eggregious typo (inverted bits) in Appendix D, to which this text refers directly.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11819; 5 Aug 94 17:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11815; 5 Aug 94 17:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17887; 5 Aug 94 17:54 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA068069173; Fri, 5 Aug 1994 10:52:53 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA067549164; Fri, 5 Aug 1994 10:52:44 -0700 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02907 for ip-atm@matmos.hpl.hp.com; Fri, 5 Aug 94 13:52:17 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA04843; Fri, 5 Aug 1994 10:51:39 -0700 Message-Id: <199408051751.KAA04843@aland.bbn.com> To: dan@merlin.dev.cdx.mot.com Cc: Craig Partridge , ip-atm@matmos.hpl.hp.com Subject: Re: no comments on my comments? In-Reply-To: Your message of Fri, 05 Aug 94 13:30:49 -0400. <199408051730.NAA23465@dbg.dev.cdx.mot.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Fri, 05 Aug 94 10:51:34 -0700 > The whole issue (IMHO) results from the decision to use > different encapsulations in RFC 1483 and RFC 1490, which I always thought w > as a terrible mistake. Hi Dan: I understand this view. However, it is very very clear from the decision process for RFC 1483 that the IETF wanted to be sure there was only one encapsulation that was mandatory for IP over ATM systems, both to reduce implementation complexity and encourage interoperability. A hard decision had to be made, the implications for Frame Relay interoperability were understood when the decision was made, and let's not refight that decision. I'm pleased to see that there are ways to negotiate interoperability with FRSSCS systems using signalling and I'd like to encourage them. But in so doing, let's not muddy up the initial decision that said there's one IP over ATM encaps. People building IP over ATM into boot EPROMS shouldn't have to deal with multiple framing formats. People building IP over ATM hosts shouldn't have to support multiple encaps, and generally won't anyway -- they'll pick one. By being clear that they must use LLC/SNAP we ensure maximum interoperability. So, I really think we should split FR issues out. One RFC saying here's how to do basic IP over ATM signalling for LLC/SNAP. Another saying that if you want to interoperate with FR, here's how to do it. Part of the reason I like the two RFC approach is that I think everyone can support it, and the message is clear, whereas the one RFC approach causes confusion about the message which leads to bickering. Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12029; 5 Aug 94 18:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12025; 5 Aug 94 18:02 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18111; 5 Aug 94 18:02 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA057228848; Fri, 5 Aug 1994 10:47:28 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA056878838; Fri, 5 Aug 1994 10:47:18 -0700 Date: Fri, 5 Aug 1994 10:47:18 -0700 Message-Id: <199408051747.AA056878838@matmos.hpl.hp.com> To: Craig Partridge Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: no comments on my comments? Cc: ip-atm@matmos.hpl.hp.com > - Third, when folks start profiling ATM implementations in RFQs and RFPs > (i.e., what features precisely they want), the profiling is easier. > Currently, if they cited this document, they'd need to add wording about > whether FR compatibility signalling is or is not required. If the docs are > separate, there's no ambiguity. If they cite the FR doc, it is required, > otherwise it isn't. This is a *very* good point. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12751; 5 Aug 94 19:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12747; 5 Aug 94 19:12 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19702; 5 Aug 94 19:12 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA111688813; Fri, 5 Aug 1994 13:33:33 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA111358810; Fri, 5 Aug 1994 13:33:30 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA21872; Fri, 5 Aug 1994 15:33:28 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1) id AA06660; Fri, 5 Aug 1994 15:33:26 -0500 Received: from dbg.dev.cdx.mot.com (dbg.dev.cdx.mot.com [134.33.32.39]) by merlin.dev.cdx.mot.com (8.6.9/8.6.9) with ESMTP id QAA25146; Fri, 5 Aug 1994 16:33:24 -0400 Received: from localhost (localhost [127.0.0.1]) by dbg.dev.cdx.mot.com (8.6.9/8.6.5) with SMTP id QAA23537; Fri, 5 Aug 1994 16:33:23 -0400 Message-Id: <199408052033.QAA23537@dbg.dev.cdx.mot.com> X-Authentication-Warning: dbg.dev.cdx.mot.com: Host localhost didn't use HELO protocol To: Craig Partridge Cc: ip-atm@matmos.hpl.hp.com Subject: Re: no comments on my comments? In-Reply-To: Your message of "Fri, 05 Aug 94 10:51:34 PDT." <199408051751.KAA04843@aland.bbn.com> Date: Fri, 05 Aug 94 16:33:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp I'm not advocating building three encapsulations into boot proms. I agree that, given the group's other decisions, everybody MUST support SNAP encapsulation. However, I do want to achieve maximum interoperability, which I take in the broader context of not just interoperability with other hosts/routers with ATM interfaces on a single ATM internet, but also with hosts/routers with FR interfaces on a mixed FR/ATM internet. The latter scenario reflects the way the real world is often going to operate for the next few years, given the installed base of FR and the likely rate of migration toward ATM. The present text does not in any way dilute the group's preference for SNAP/LLC. It provides a complete procedure for fall back when operating in a mixed ATM/Frame Relay scenario. If people building IP over ATM hosts don't support the multiple encapsulations, then they can with no significant additional code in their signalling modules clear calls from FR hosts; of course, this means that they will have to deal with the occasional irate customer, but that's not our problem here. I'm failing to see your reasons for wanting to create a new document to contain what is essentially a paragraph or two of incremental material. This additional information does not confuse things for folks that don't want to support FR interworking, and moving/removing it would confuse things greatly for those who do. I would reluctantly be willing to live with some additional weasel words emphasizing the optional nature of this material. This would require no more than a sentence. Again, I object to moving or removing this material.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12761; 5 Aug 94 19:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12757; 5 Aug 94 19:12 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19708; 5 Aug 94 19:12 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA091594907; Fri, 5 Aug 1994 12:28:27 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gateway.mitre.org by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA091264904; Fri, 5 Aug 1994 12:28:24 -0700 Received: from backup.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA11017; Fri, 5 Aug 94 15:28:22 -0400 Date: Fri, 5 Aug 94 15:28:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Susan Symington Full-Name: Susan Symington Message-Id: <9408051928.AA11017@gateway.mitre.org> To: ip-atm@matmos.hpl.hp.com Subject: multicasting Cc: susan@gateway.mitre.org As an attendee of the Toronto IETF IP-over-ATM WG who is interested in IP multicast over ATM, I am taking the liberty of trying to open the discussion of multicast issues on this mailing list on a basic level, so as to encourage as many people as we can to contribute. Mark had indicated at the meeting and in his minutes that we should be trying to compile a list of requirements to submit to the ATM Forum's Multiprotocol BOF. In particular, some of these requirements should be specifically related to multicast. I'm all for this and would like to contribute. It seems, however, that we need to think about and discuss fundamental issues related to running IPmc over ATM multicasting (ATMmc) as a prelude to compiling a list of such requirements. It is my hope that we can get a dialogue going that can lead to progress. I apologize to those of you who may find the following too obvious or basic, but I am trying to put what little discussion we've had on multicast so far into perspective in the attempt to induce more contributors to join in. We've got to start somewhere! One and all, please chime in: It is possible to provide an IPmc service over an underlying ATM unicast service, in which the ATM service is viewed as providing only logical point-to-point links between IPmc routers. This is not what we are interested in. Those of us in the IP-over-ATM WG that are interested in multicasting should have as our focus the definition of an interface across which an IPmc service can be provided using an underlying ATM multicast service, rather than being provided using an underlying ATM unicast service. The definition of such an interface will be a challenging effort. Ideally, the interface will need to reconcile the mismatches between the multicast services provided in current Internet Protocol (IP)-based networks and those services being defined for Asynchronous Transfer Mode (ATM). The design goal of the interface should be to enable as many of the IPmc services as possible to be provided as transparently as possible over an underlying ATMmc service. In addition, for security reasons, we would like for this interface to augment the basic IPmc services by providing an option for sender-initiated (in addition to receiver-initiated) joining of multicast groups. (The need for this sender-initiated group join option is discussed in Internet draft "draft-symington-ipng-model-00.txt", which provides a more complete description of the multicast services required for one major community, that of modeling and simulation.) IPmc provides a very rich and flexible multicasting service. In particular, it provides bidirectional, multipoint-to-multipoint distribution in a receiver-initiated join, open-group (meaning that non-members of the group can send to the group), connectionless environment. Current ATM Forum UNI 3.0 signaling specifications provide for unidirectional, point-to-multipoint signaling within a sender-initiated join, connection-oriented environment, absent of the concept of a multicast "group" (other than that a group would be implicitly defined as the group of endpoints sharing a given point-to- multipoint connection). Some of the issues that we will need to tackle when defining an IPmc/ATMmc interface are: 1) Sender vs. Receiver-initiated joins: Membership in IPmc groups is open to every entity on the network, at that entity's prerogative and initiative. The sender has no control over who may or may not be in a particular multicast group. In fact, the sender is not even necessarily aware of the number or identity of the endpoints of the IPmc transmission. It does not even make sense to say that the sender is or is not notified of group join requests, because with IPmc there is no notion of a group having any particular sender. Anyone can transmit data to a particular multicast group, even entities that are not members of the group. UNI 3.0 ATMmc requires that the originator of a multicast transmission set up a (unidirectional) multicast virtual circuit (VC) from itself to all recipients before any cells can be multicast to the recipients. The sender (root) must be aware of every endpoint that should receive the transmission in order to be able to set up the VC. An entity using UNI 3.0 signaling mechanisms that wishes to "join" a multicast group of recipients by becoming a leaf in a pt-to-mpt VC needs to somehow (out of band) notify the sender (root) of its desire so that the sender can, at its discretion, add this entity to the multicast group by augmenting its existing multicast VC to include this new recipient. The ATM Forum Draft 94-0325R1 by Rick Bubenik and Pete Flugstad (both of ASCOM TIMEPLEX, INC.) attempts to reconcile the sender versus receiver differences between IPmc and ATMmc by providing for mechanisms within ATM signaling that allow leaf initiated Joins (LIJs) as well as sender-initiated joins. This ATM Forum contribution seems to be one that the IETF IP-over-ATM group should study and consider as it generates a list of requirements for mapping IPmc to ATMmc. Not only does it provide the receiver-initiated join option that is required to support IPmc; it also provides for a security option to allow the sender (root) to determine whether or not a leaf requesting to join a group should be permitted. Such a security option improves on the multicasting service provided by IPmc and will be an important feature in support of some user communities. In particular, one potential requirement that the IP-over-ATM WG can send to the ATM Forum is that the ATM forum should either adopt the LIJ (94-0325R1) contribution or something equivalent as part of the UNI 4.0 specification. This may well happen absent of a recommendation from our WG, but it sure couldn't hurt. 2) IPmc-to-ATMmc group address resolution: The ATM Forum Draft 94-0685R1 by Fong-Ching Liaw and Drew Perkins considers the ATM group addressing issue. It seems to work on the very simple but elegant and not immediately apparent (to me, at least) principle of considering ATM groups to be completely independent of any particular point-to-multipoint VCs that may be set up among the various group members. Using this principle, the ATMmc concept of group starts to look very similar to the IPmc concept of group. 94-0865R1 improves on UNI 3.0 signaling specifications by allowing groups to be open (i.e. it allows non-members to send to groups) and by recognizing the concept of the group to be independent of the mechanism used to distribute data among the group members. The benefit of separating the group from the VCs shared among group members is that it allows the mapping from IPmc group addresses to ATMmc group addresses to be straightforward. For group addresses, as with unicast addresses, an ARP and inARP service will be needed to translate between ATM and IP multicast group addresses, but a simple lookup should be sufficient. In fact, it seems almost too simple; I'm sure I must be missing something! Another benefit of separating the group from the VCs shared among the group members is that it makes the group independent of the actual underlying ATM mechanism used to provided multicast distribution of data among the members. It allows this mechanism to be multiple point-to-multipoint VCs (which we could potentially use now) or a multipoint-to-multipoint VC (which has not yet been specified), or some sort of multicast server, or some other mechanism. The mechanisms could be swapped in and out as appropriate or as they become available and it wouldn't affect the group. Yet another benefit is that this concept of group does not require that the source (root) be aware or keep track of all group members; it need only know the group address. This, too, is in keeping with the spirit if IPmc. 3) Multipoint-to-multipoint versus point-to-multipoint data distribution Because of the connectionless nature of IP networks, the service provided is multipoint-to-multipoint in both directions among all group members. Because of the connection-oriented nature of ATM networks, however, transmission among group members is dependent on the type of multicast VCs being used. The ATM Forum has so far defined the signaling specifications for unidirectional, point-to-multipoint VCs only. ("Unidirectional" is used to mean that data can be sent only in the direction from the root to the leaves on the VC; no return bandwidth from the leaves to the root is provided.) No ATM Forum signaling specifications have yet been defined for bidirectional point-to- multipoint VCs or for multipoint-to-multipoint VCs. In fact, the Forum signaling working group has tabled consideration of multipoint-to-multipoint VCs until some indefinite future time. Given that the only multicast VCs that have yet been specified are unidirectional, point-to-multipoint, one tack we could take would be to constrain ourselves to the assumption that the IPmc-over-ATMmc interface will make use of overlaid point-to-multipoint VCs. If we make this assumption and then accept the basic concepts put forth in 94-0685R1, then when an entity joins a group it will be allowed to indicate that it would like to become a leaf on all pt-to-mpt VCs that have the group as their destination address. This would be the option that would have to be chosen in order to support the inherently multipoint-to-multipoint service provided by IPmc. Yet another tack that we could take, which Anthony Alles mentioned in his last correspondence to the group, is that we could "decide which of the known multicast mechanisms we wish to use and then work on ways of specifying this." If we take the tack of using overlaid point-to-multipont VCs, then we will be accepting the limitations of this mechanism (e.g., how well does it scale for large groups?) for the time being, but it does not preclude us from defining an interface to other mechanisms as they may become available in the future. If multiple overlaid pt-to-mpt VCs are used as the mechanism, then there will need to be a mechanism for translating between ATM group addresses and the collection of VCs with those addresses as their destination, and a mechanism for maintaining the state of these connections at appropriate locations, but these would be issues for the ATM Forum, not this group, to be concerned with, I think. CONCLUSION: To summarize, we should be thinking about at least three issues when we try to compile our list of IPmc-over-ATMmc requirements: sender versus receiver- initiated joins; groups and group address resolution; and point-to-multipoint versus multipoint-to-multipoint data flow mechanisms. What other issues are there and what should our requirements be? Mark mentioned that we "have to do our homework" with regard to multicasting and security. I strongly agree, and I suggest that everyone be familiar with IPmc documents and also with the two ATM forum documents that I mention above (94-0685R1, which Fong-Ching Liaw has already emailed to our group, and the Leaf initiated Join contribution, 94-0325R1). What else should we be reading? I anticipate that some of you do not have access to Forum documents and so I have already phoned Rick Bubenik from ASCOM TIMEPLEX and asked him to email a copy of his contribution 94-0325R1 to this group. He graciously agreed to do so. Looking forward to hearing further discussion, -susan ******************************************************************************** Susan Symington The MITRE Corporation (703) 883-7209 susan@gateway.mitre.org ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13526; 5 Aug 94 19:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13522; 5 Aug 94 19:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20498; 5 Aug 94 19:55 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA135052973; Fri, 5 Aug 1994 14:42:53 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA134702963; Fri, 5 Aug 1994 14:42:43 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id RAA28366; Fri, 5 Aug 1994 17:41:23 -0400 Message-Id: <199408052141.RAA28366@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Mark Laubach Cc: Craig Partridge , ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: signalling draft last call (comments) In-Reply-To: Your message of Fri, 05 Aug 94 10:30:23 -0700. <199408051730.AA028787823@matmos.hpl.hp.com> Date: Fri, 05 Aug 94 17:41:21 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [..] >>> We should not recommend implementation of multiple standards -- recall >>> the decision of the multiproto encaps group -- ONE standard. >> >>I'll leave this to the consensus of the WG. Should this draft >>specification deal with >>LLC/SNAP only or is it ok to mention Null Encapsulation. Should VC >>multiplexing be >>moved to its own Appendix as a compromise? I think VC based muxing should still be an accepted way for direct IP entity to IP entity links. It's not so wrong that it is still in RFC1483. Actually, if we ignore VC-based muxing, the general thrust from RFC1483 and this new draft is not 'IP over ATM' but 'LLC/SNAP over ATM'. LLC/SNAP encapsulation quite strongly implies (from an implementation standpoint) that there is an "LLC entity" at each endpoint (the actual "AAL User" from the ATM perspective). The IP layer then becomes a user of the LLC entity's services, further decoupling the direct relationship between an IP layer and underlying ATM services. ATMARP also becomes just another user of the LLC entity's service. Perhaps (and this is just another spin on my earlier concerns) the draft should be writing about how an LLC entity establishes VCs on behalf of the services above it? The current distinctions are not as clear as I think they could be. What have I missed or exploded beyond reason? [..] The references to Frame Relay do seem to confuse the matter. I tend to agree with Craig that the 'IP over emulated FR' world should connet to the 'LLC over ATM' world at routers, and not a lower layer. This places FR related discussion at very least in an information appendix, if not a later document specifically on this interworking case. gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14486; 5 Aug 94 22:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14482; 5 Aug 94 22:08 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22133; 5 Aug 94 22:08 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA166370636; Fri, 5 Aug 1994 16:50:36 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA166040634; Fri, 5 Aug 1994 16:50:34 -0700 Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA12020 for ip-atm@matmos.hpl.hp.com; Fri, 5 Aug 94 19:50:29 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id QAA05429; Fri, 5 Aug 1994 16:49:57 -0700 Message-Id: <199408052349.QAA05429@aland.bbn.com> To: ip-atm@matmos.hpl.hp.com Subject: miscellenous issues on last call Reply-To: Craig Partridge Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Fri, 05 Aug 94 16:49:56 -0700 Hi folks; I've had some e-mail and telephone conversations with folks about the frame relay issues and it sounds like more folks would prefer it as an appendix than a separate document. If that's the concensus, I'm comfortable with it. Just keep FR out of the main document. Also, there seems to be some issues about NSAPA selectors that need to be resolved -- I'll be talking with Maryann and Allison next week and maybe we'll have a paragraph or two to resolve the issues. Craig E-mail: craig@aland.bbn.com or craig@bbn.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01301; 6 Aug 94 8:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01297; 6 Aug 94 8:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03831; 6 Aug 94 8:43 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA249930692; Sat, 6 Aug 1994 03:58:12 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA249600689; Sat, 6 Aug 1994 03:58:09 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.2-14 #2740) id <01HFKW65AYW08Y503V@sys30.timeplex.com>; Sat, 6 Aug 1994 06:56:05 EDT Received: from [134.196.244.1] (gb_dial_usr1.timeplex.com) by maelstrom.timeplex.com (4.1/SMI-4.1) id AA20241; Sat, 6 Aug 94 06:57:29 EDT Date: Sat, 06 Aug 1994 06:57:05 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: What to say to ATM Forum? To: Anthony Alles Cc: ip-atm@matmos.hpl.hp.com, malis@maelstrom.timeplex.com Message-Id: <9408061057.AA20241@maelstrom.timeplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT Anthony, > As far as I know, no one in the Forum is unhappy with RFC 1483 and there > are no suggestions to revisit encapsulation issues, per se. Rather, > some people have expressed some concern about the seemingly slow pace > (I'm not passing judgement here) of the ROLC group in solving the single > LIS restriction in RFC 1577. > Hence the idea was to look at alternative ways of solving this problem - > either by moving towards some kind of peer based model or by spurring a > faster response from ROLC. This, at least, was one of the original > motivations for organizing this BOF. As the ROLC (Routing Over Large Clouds) Working Group chair, I find this VERY interesting, and somewhat disturbing, since this is the first I've heard about this particular motivation for the ATM Forum BOF (and I've already spoken to several of the principals involved). Let me remind you that ROLC is an open working group, and we welcome assistance from any and all that are willing to participate. At last week's ROLC meeting, I counted exactly ONE interested and involved person who also attends the ATM Forum and who took the time to read the current spec and offer detailed comments, and to him I offer thanks. At the end of the meeting, I solicited for other contributors to assist the document editor. PLEASE - if you or others are not happy with the rate of progress of the ROLC group, please contribute to ROLC rather than do duplicate work elsewhere. If you would like to join the ROLC mailing list, just send me email. If you would like to read the current (pre-Toronto) version of the proposal, please read draft-ietf-rolc-nhrp-01.txt, available via anonymous FTP from ds.internic.net, in the internet-drafts/ directory. Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02692; 6 Aug 94 14:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02688; 6 Aug 94 14:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07715; 6 Aug 94 14:18 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA010982253; Sat, 6 Aug 1994 09:57:33 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA010632242; Sat, 6 Aug 1994 09:57:22 -0700 Date: Sat, 6 Aug 1994 09:57:22 -0700 Message-Id: <199408061657.AA010632242@matmos.hpl.hp.com> To: dan@merlin.dev.cdx.mot.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: no comments on my comments? Cc: ip-atm@matmos.hpl.hp.com >However, I do want to achieve maximum interoperability, which I take in the >broader context of not just interoperability with other hosts/routers with ATM >interfaces on a single ATM internet, but also with hosts/routers with FR >interfaces on a mixed FR/ATM internet. The latter scenario reflects the way >the >real world is often going to operate for the next few years, given the >installed >base of FR and the likely rate of migration toward ATM. There was a similar discussion at the ATM Internet NAP meeting at Toronto. I was asked to introduce IP over ATM to the crowd and to be on hand as a consultant. I basically took a back seat as a fly on the wall. The basic consensus was that the NAPs want to use LLC/SNAP and will get there as soon as possible. This means that the two DSU vendors need to add LLC/SNAP into their products so that directly connected hosts and routers can talk to to routers that are connected via a DSU. The DSUs only support RFC1490 encapsulation. ATM native interfaces in the routers are supporting LLC/SNAP only. Yes, the FR vs LLC is a problem, but the crowd settled on getting to LLC as soon as possible and to not have a mixed world. This is just a data point. >I'm failing to see your reasons for wanting to create a new document to >contain >what is essentially a paragraph or two of incremental material. This >additional >information does not confuse things for folks that don't want to support FR >interworking, and moving/removing it would confuse things greatly for those >who >do. I would reluctantly be willing to live with some additional weasel words >emphasizing the optional nature of this material. This would require no more >than a sentence. I think Craig raised a good point earlier. In the procurement process and sales process, saying on the spec sheet or on the bid that RFCXXXX is required/supported should lead to a clear interpretation of what is there. Saying RFC1483 these days is ambiguous. Saying RFC1577 cleaned up the ambiguity. If we produce yet another ambiguous document, I think we are doing the community a dis-service. Personally, I think it would be good to consider having a separate RFC for the FR part. It partitions the issues and allows the FR interoperability to stand on its own merits. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02788; 6 Aug 94 14:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02784; 6 Aug 94 14:38 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07947; 6 Aug 94 14:38 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA026514104; Sat, 6 Aug 1994 10:28:24 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA026184096; Sat, 6 Aug 1994 10:28:16 -0700 Date: Sat, 6 Aug 1994 10:28:16 -0700 Message-Id: <199408061728.AA026184096@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: preliminary last call status X-Attachments: :matmos:1666:signaling last call issues: Last call ends this evening but I won't be around my keyboard tonight so I wanted to send this incomplete list to the WG. The following is a issues lists I've been keeping for the signaling draft last call. I've tried to break the issues into categories. I'll follow up tomorrow (Sunday) evening with any other issues that have been raised since this note. Mark ------------------------------------------------------------ Outstanding Signalling Draft Last Call Issues: Misc Stuff: M1. Conventions section needs to be added. M2. An issues section would be a good section to add M3. Some spelling and other typos M4. SHALL's -> MUST, etc. Capitalize MUST, RECOMMEND, etc. M5. Section titles need to be added in the long sections. Stuff that can be fixed with easy paragraph tuning and reviewing: E1. Some statement needs to be made about NSAPAs and selectors. A paragraph is forthcoming after Craig visits the NRL folks next week. E2. There's an issue to resolve regarding whether VC-muxing should be listed in the main body. More significant word moving and smithing: I1. RFC1490 and FRSSCS needs to be more cleanly moved from the main body and moved to an appendix (consistent with WG meeting consensus) and labeled appropriately. I3. Coding appendix moved to main body so it is clearly part of the proposed standard. Comments from the authors are still needed on the following before we can determine effect on the draft: C1. CALL PROCEEDING/CONNECT issued that was raised by Grenville Armitage C2. Local signalling interface issue that was raised by Grenville. C3. Issue about LLC entity coding raised by Grenville.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05209; 6 Aug 94 17:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05205; 6 Aug 94 17:51 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10206; 6 Aug 94 17:51 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA060325941; Sat, 6 Aug 1994 13:45:41 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sundance.itd.nrl.navy.mil by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA059995939; Sat, 6 Aug 1994 13:45:39 -0700 To: ip-atm@matmos.hpl.hp.com Subject: IP multicast & security Date: Sat, 6 Aug 94 21:45:32 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ran Atkinson Message-Id: <9408062145.aa21305@sundance.itd.nrl.navy.mil> Just a quick note to say that receiver-initiated multicast does NOT make security any harder than with sender-initiated multicast. Some ATM folks have alleged that receiver-initiated is harder to secure, but it just is not so. Folks interested in this topic might want to read parts of the discussion in the current CBT drafts. There is good work in progress on multicast security issues at several places, including UCL. Ran atkinson@itd.nrl.navy.mil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06008; 6 Aug 94 19:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06004; 6 Aug 94 19:34 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11349; 6 Aug 94 19:34 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA085061917; Sat, 6 Aug 1994 15:25:17 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA084731913; Sat, 6 Aug 1994 15:25:13 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA17370; Sat, 6 Aug 94 18:27:01 EDT Received: from pothole.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA10638; Sat, 6 Aug 94 18:25:02 EDT Received: by pothole.fore.com (4.1/SMI-4.1) id AA00907; Sat, 6 Aug 94 18:24:46 EDT Date: Sat, 6 Aug 94 18:24:46 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fong-Ching Liaw Message-Id: <9408062224.AA00907@pothole.fore.com> To: ip-atm@matmos.hpl.hp.com, susan@gateway.mitre.org Subject: Re: multicasting Susan It is not coincidental that the ATM group addresses look and smell just like IP mulitcast. It is designed using the same idea. Also, because the ATM call parameters are expressed explicitly in ATM messages (such as SETUP and ADD PARTY), security options such as specified in atm94-0325R1 are also available to ATM groups. Actually, depends on how sender specify his leaf-initiated option, sender may or may not be informed of receiver's join. It should be straigtforward to map IPmc address to ATM group address since ATM group addresses space is so big, so you are not missing anything :-) I think this group (maybe in conjuction with tuba group ?) should recommend to ATM Forum's multiprotocol BOF/WG an algorithm mapping between these two, otherwise there is no hope for IP to run any automatical operation over ATM. Please, NO ARP or INARP. The leaf initiated join comes useful when receiver know the "call identifier" it want to join. So, it is perfect tool to allow receivers to "reconnect" to connections, but it does not help to form the group. As you pointed out, the call parameter is separated from the group, it is possible to indicate many-to-many when it's available. To get around the scalibility problem in large number of senders, we may want to separate IPmc addresses into space for low-load, delay insensitive many-to-many groups and high-load few-to-many groups. Some optimization is then possible (such as using mc server for first case, and ATM group for the latter.) This is a half baked idea. A strong statement into ATM Forum to support both Leaf-Init and Group address will not only make the Forum spec. provides such functionality, it also signals to ITU-T and therefore an international standard on public networks is possible. Thanks, -Fong   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01816; 7 Aug 94 11:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01812; 7 Aug 94 11:51 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05781; 7 Aug 94 11:51 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA219989895; Sun, 7 Aug 1994 07:31:35 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA219659889; Sun, 7 Aug 1994 07:31:29 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA05980; Sun, 7 Aug 1994 05:51:29 -0700 Received: from bells.cs.ucl.ac.uk by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA03063; Sun, 7 Aug 1994 05:51:27 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 7 Aug 1994 13:50:54 +0100 To: Susan Symington Cc: ip-atm@matmos.hpl.hp.com Subject: Re: multicasting In-Reply-To: Your message of "Fri, 05 Aug 94 15:28:22 EDT." <9408051928.AA11017@gateway.mitre.org> Date: Sun, 07 Aug 94 13:50:46 +0100 Message-Id: <1466.776263846@cs.ucl.ac.uk> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Crowcroft ..... >CONCLUSION: >To summarize, we should be thinking about at least three issues when we try >to compile our list of IPmc-over-ATMmc requirements: sender versus receiver- >initiated joins; groups and group address resolution; and point-to-multipoint >versus multipoint-to-multipoint data flow mechanisms. What other issues are >there and what should our requirements be? 1 major other issue is QoS: You may want: a) differnt QoS on different branches/leaves of a multicast distribution tree b) you may want to cjhange the QoS (or even the membership) as things change c) you want to think quite hard abouut congestion control - most the ABR congestion control schemes have RM cells comeing back from sinks towards the source. This clearly fails completly in a multicast (point to multipoint) scenario....unless you are smart about aggregating congestion information .... that'll do to be getting on with:-) thanks for raising this - it is something that must be sorted before ATM is going to be much use to the IP community jon   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04729; 7 Aug 94 18:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04725; 7 Aug 94 18:51 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12278; 7 Aug 94 18:51 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA274534444; Sun, 7 Aug 1994 14:20:44 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from Kahului.Stanford.EDU by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA274204442; Sun, 7 Aug 1994 14:20:42 -0700 Received: (from jonathan@localhost) by Kahului.Stanford.EDU (8.6.9/8.6.9) id OAA13914; Sun, 7 Aug 1994 14:20:34 -0700 Date: Sun, 7 Aug 1994 14:20:34 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jonathan Stone Message-Id: <199408072120.OAA13914@Kahului.Stanford.EDU> To: Susan Symington Cc: ip-atm@matmos.hpl.hp.com Subject: Re: multicasting >To summarize, we should be thinking about at least three issues when we try >to compile our list of IPmc-over-ATMmc requirements: sender versus receiver- >initiated joins; groups and group address resolution; and point-to-multipoint >versus multipoint-to-multipoint data flow mechanisms. What other issues are >there and what should our requirements be? Another issue you might wish to consider is to go beyond supporting IPmc-over-ATMmc, and having ATMmc support IPmc *routing*. I'm thinking of scenarios like this: multiple multicast senders, where some senders are ATM-connected and some are not; multiple multicast recievers, where some recievers are ATM-connected and some are not. And there might not even be direct ATM connectivity between all the ATM-connected participants in a single group. The issue here is providing enough information to the IPmc routing and resource-allocation mechanisms to allow them to make sensible decisions about mc group members in the ATM-connected cloud(s). Providing that information may require more information from ATMmc than ATMmc would otherwise give to recievers. (If I understand ATMmc, the signalling protocols and the ATM net are doing what's done explicitly via IPmc routing; and unlike IPmc, that information isn't being passed via mc to any host that wants to hear it.) It's not clear whether the original message was intended to address this particular issue, or whether it was limited in scope to suppporting IPmc over some IPmc group connected via a single ATM-connected graph.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05435; 7 Aug 94 19:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05430; 7 Aug 94 19:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12979; 7 Aug 94 19:36 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA293137342; Sun, 7 Aug 1994 15:09:02 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hubbub.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA292807341; Sun, 7 Aug 1994 15:09:01 -0700 Received: from [198.93.167.110] (dynaserv-d1-dynamic-110.cisco.com [198.93.167.110]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id PAA00692; Sun, 7 Aug 1994 15:08:48 -0700 Message-Id: <199408072208.PAA00692@hubbub.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 7 Aug 1994 15:08:50 -0800 To: Andy Malis Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anthony Alles Subject: Re: What to say to ATM Forum? Cc: ip-atm@matmos.hpl.hp.com Andy, I did not say that *I* was unhappy with the progress of the ROLC group - after all, Dave Katz from Cisco is the editor of NHRP and I have been a member of the ROLC list since its inception. I was only reporting what other people told me - I thought I made that clear in my posting. The fact is that rightly or wrongly some people - *not* including me - believe that the ROLC group has not made as much progress as some people - including, I should add, some of the people most closely involved with the founding of ROLC - would have liked to have seen. Since I did not attend the last ROLC meeting I do not know whether this criticism is justified or not, but it might perhaps be advisable for some of the principals in this group to better advertise their progress (egad, marketing! what a concept... :-) ). As I also noted im my email, regardless of the original motivation for starting the Forum group, there are some other issues that some of us would like to pursue there, so I suspect that we will not see too much overlap. Perhaps it might be useful, however, for you to attend the next Forum meeting and report on the current status of NHRP/NARP? Just a thought. Anthony At 6:57 AM 8/6/1994 -0500, Andy Malis wrote: >Anthony, > >> As far as I know, no one in the Forum is unhappy with RFC 1483 and there >> are no suggestions to revisit encapsulation issues, per se. Rather, >> some people have expressed some concern about the seemingly slow pace >> (I'm not passing judgement here) of the ROLC group in solving the single >> LIS restriction in RFC 1577. > >> Hence the idea was to look at alternative ways of solving this problem - >> either by moving towards some kind of peer based model or by spurring a >> faster response from ROLC. This, at least, was one of the original >> motivations for organizing this BOF. > >As the ROLC (Routing Over Large Clouds) Working Group chair, I find this >VERY interesting, and somewhat disturbing, since this is the first I've >heard about this particular motivation for the ATM Forum BOF (and I've >already spoken to several of the principals involved). Let me remind you >that ROLC is an open working group, and we welcome assistance from any and >all that are willing to participate. At last week's ROLC meeting, I >counted exactly ONE interested and involved person who also attends the ATM >Forum and who took the time to read the current spec and offer detailed >comments, and to him I offer thanks. At the end of the meeting, I >solicited for other contributors to assist the document editor. > >PLEASE - if you or others are not happy with the rate of progress of the >ROLC group, please contribute to ROLC rather than do duplicate work >elsewhere. > >If you would like to join the ROLC mailing list, just send me email. If >you would like to read the current (pre-Toronto) version of the proposal, >please read draft-ietf-rolc-nhrp-01.txt, available via anonymous FTP from >ds.internic.net, in the internet-drafts/ directory. > >Andy > >__________________________________________________________________________ >Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 >Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 _____________________________________________________________________ Anthony Alles Cisco Systems Product Manager: ATM Tel: 408-526-5424 email: aalles@cisco.com Fax: 408-526-7666 Mail: 170 West Tasman Drive, San Jose CA 95134-1706, USA. Cisco Location: Building D, San Jose Single Site.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02749; 8 Aug 94 9:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02745; 8 Aug 94 9:33 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa06097; 8 Aug 94 9:33 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA112275242; Mon, 8 Aug 1994 04:27:22 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from mailgate.ericsson.se by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA111945227; Mon, 8 Aug 1994 04:27:07 -0700 Received: from ebcs03.ebc.ericsson.se by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.14) id AA01034; Mon, 8 Aug 94 13:26:45 +0200 Received: from ebc.ericsson.se.ericsson.se (sgsun70.ebc.ericsson.se) by ebcs03.ebc.ericsson.se (4.1/SMI-4.1-LME1.6) id AA02395; Mon, 8 Aug 94 13:26:36 +0200 Received: from ebcw298.ericsson.se by ebc.ericsson.se.ericsson.se (4.1/SMI-4.1) id AA16025; Mon, 8 Aug 94 13:26:37 +0200 Date: Mon, 8 Aug 94 13:26:37 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: SG/EBC/FB/FX Bengt Persson 08-764 0343 Message-Id: <9408081126.AA16025@ebc.ericsson.se.ericsson.se> To: ip-atm@matmos.hpl.hp.com Subject: Re: multicasting > ..... > >CONCLUSION: > > >To summarize, we should be thinking about at least three issues when we try > >to compile our list of IPmc-over-ATMmc requirements: sender versus receiver- > >initiated joins; groups and group address resolution; and point-to-multipoint > >versus multipoint-to-multipoint data flow mechanisms. What other issues are > >there and what should our requirements be? > > 1 major other issue is QoS: You may want: > a) differnt QoS on different branches/leaves of a multicast distribution > tree > b) you may want to cjhange the QoS (or even the membership) as things > change > c) you want to think quite hard abouut congestion control - most the > ABR congestion control schemes have RM cells comeing back from sinks > towards the source. This clearly fails completly in a multicast (point > to multipoint) scenario....unless you are smart about aggregating > congestion information .... In Frame Relay Forum work is progressing on an Implementation Agreement on Multicasting. There one has opted to signal status information in a simple way. Information from all leafs is either ANDed or ORed to get the status for the group. For more detailed information, an out-of-band management protocol (e.g. SNMP with FR service MIB with extentions) is used and not the signaling protocol. This makes it very easy for the network and simple multicast users while still usable in complex environments. Similar solutions might be considered also IP over ATM environments. /Bengt > > that'll do to be getting on with:-) > > thanks for raising this - it is something that must be sorted before > ATM is going to be much use to the IP community > > jon > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06308; 8 Aug 94 12:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06304; 8 Aug 94 12:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24876; 8 Aug 94 12:53 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA182959289; Mon, 8 Aug 1994 08:21:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gateway.mitre.org by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA182629287; Mon, 8 Aug 1994 08:21:27 -0700 Received: from backup.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA22887; Mon, 8 Aug 94 11:21:25 -0400 Received: by backup.mitre.org.mitre.org (4.1/SMI-4.1) id AA03282; Mon, 8 Aug 94 11:20:37 EDT Message-Id: <9408081520.AA03282@backup.mitre.org.mitre.org> To: jonathan@dsg.stanford.edu Cc: ip-atm@matmos.hpl.hp.com Subject: multicast Date: Mon, 08 Aug 94 11:20:36 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: susan@backup.mitre.org Jonathan, Good points. I agree that these issues need to be considered. Certainly the IPmc routers will need information from the appropriate ATMmc components so that they can make good routing decisions. I don't know enough about the ROLC WG to know whether this issue is in their domain as opposed to the IP-over-ATM WG's domain. Anybody have any thoughts on this? Do you have any thoughts on what information, specifically, the IPmc routing and resource-allocation mechanisms will need to be provided? This would provide good requirements input to the new ATM Forum multiprotocol BOF. susan ------- Forwarded Message Received: from mwunix.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA18700; Sun, 7 Aug 94 17:20:42 -0400 Organization: The MITRE Corp. Return-Path: jonathan@DSG.Stanford.EDU Received: from Kahului.Stanford.EDU (Kahului.Stanford.EDU [36.18.0.61]) by mwunix.mitre.org (8.6.4/8.6.4) with ESMTP id RAA06855 for ; Sun, 7 Aug 1994 17:20:41 -0400 Received: (from jonathan@localhost) by Kahului.Stanford.EDU (8.6.9/8.6.9) id OAA13914; Sun, 7 Aug 1994 14:20:34 -0700 Date: Sun, 7 Aug 1994 14:20:34 -0700 From: Jonathan Stone Message-Id: <199408072120.OAA13914@Kahului.Stanford.EDU> To: susan@gateway.mitre.org (Susan Symington) Cc: ip-atm@matmos.hpl.hp.com Subject: Re: multicasting >To summarize, we should be thinking about at least three issues when we try >to compile our list of IPmc-over-ATMmc requirements: sender versus receiver- >initiated joins; groups and group address resolution; and point-to-multipoint >versus multipoint-to-multipoint data flow mechanisms. What other issues are >there and what should our requirements be? Another issue you might wish to consider is to go beyond supporting IPmc-over-ATMmc, and having ATMmc support IPmc *routing*. I'm thinking of scenarios like this: multiple multicast senders, where some senders are ATM-connected and some are not; multiple multicast recievers, where some recievers are ATM-connected and some are not. And there might not even be direct ATM connectivity between all the ATM-connected participants in a single group. The issue here is providing enough information to the IPmc routing and resource-allocation mechanisms to allow them to make sensible decisions about mc group members in the ATM-connected cloud(s). Providing that information may require more information from ATMmc than ATMmc would otherwise give to recievers. (If I understand ATMmc, the signalling protocols and the ATM net are doing what's done explicitly via IPmc routing; and unlike IPmc, that information isn't being passed via mc to any host that wants to hear it.) It's not clear whether the original message was intended to address this particular issue, or whether it was limited in scope to suppporting IPmc over some IPmc group connected via a single ATM-connected graph. ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06373; 8 Aug 94 12:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06369; 8 Aug 94 12:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25022; 8 Aug 94 12:58 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA167598146; Mon, 8 Aug 1994 08:02:26 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gateway.mitre.org by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA167268139; Mon, 8 Aug 1994 08:02:19 -0700 Received: from backup.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA22773; Mon, 8 Aug 94 11:02:13 -0400 Received: by backup.mitre.org.mitre.org (4.1/SMI-4.1) id AA03243; Mon, 8 Aug 94 11:01:25 EDT Message-Id: <9408081501.AA03243@backup.mitre.org.mitre.org> To: fong@fore.com Cc: ip-atm@matmos.hpl.hp.com Subject: multicast Date: Mon, 08 Aug 94 11:01:24 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: susan@backup.mitre.org Fong, You seem to agree that both your contribution on group addressing and the leaf-initiated join contribution will prove valuable in the specification of an IPmc/ATMmc interface. Great. Specifically, you advocate: 1) The IP-over-ATM WG should make a strong statement to the ATM Forum that we require the functionality provided by the group addressing and leaf-initiated join contributions. Is the new multiprotocol BOF the place that we should make these statements, or would a statement to the signalling group via our liaison be more appropriate/effective? Any thoughts on this? 2) It is also important that the ITU (international standards community) get the message about the importance of group addressing and leaf- initiated joins. Do you think that we should relay this message directly to the ITU, or is it sufficient to send the message to the Forum and have the ITU pick it up via there? Do we have an ITU liaison? 3) The IP-over-ATM group should work, possibly in conjunction with the TUBA group, to recommend an algorithm for mapping IPmc group addresses to ATMmc group addresses. You want to avoid using ARP and inARP to provide this mapping/translation. With regard to #3, I alternate between understanding and agreeing with it and being confused by it. I would appreciate it if you could elaborate on your point a little more. I think my confusion stems from the way that your group addressing concept strictly separates the multicast group address from the actual mechanism used to distribute the data. If you want to have an algorithm that automatically translates an IPmc address into an ATM group address, fine, but there still has to be some mechanism that takes this ATM group address and "translates" it into whatever it needs to translate it into to get the data distributed multicast-style. This second "translation" is dependent on the multicast mechanism that is actually being used (multiple overlaid pt-to-mpt VCs, multicast server, etc.). This second translation and the actual mechanism(s?) used are where the gist of the problems lie, and I would like for our WG to discuss these. Such a discussion would have to include, as Jonathan Stone said in his message, a discussion of how ATMmc will support IPmc *routing*. I would be happy to work on recommending such an IPmc/ATM group address translation algorithm as you are advocating, as long as it is understood that we are pushing the problem of getting appropriate multicast VCs set up elsewhere. Am I understanding everything correctly? It is my understanding that Fore has implemented IPmc over ATMmc. Would it be possible for you to explain to this group how Fore's implementation works? I'm sure that we would all find whatever details you are free to share to be most enlightening, and therefore most welcome. Thanks. Susan Symington ------- Forwarded Message Received: from mwunix.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA15693; Sat, 6 Aug 94 18:34:31 -0400 Organization: The MITRE Corp. Return-Path: fong@fore.com Received: from relay.fore.com (relay.fore.com [192.88.243.14]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id SAA09738 for ; Sat, 6 Aug 1994 18:34:28 -0400 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA17370; Sat, 6 Aug 94 18:27:01 EDT Received: from pothole.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA10638; Sat, 6 Aug 94 18:25:02 EDT Received: by pothole.fore.com (4.1/SMI-4.1) id AA00907; Sat, 6 Aug 94 18:24:46 EDT Date: Sat, 6 Aug 94 18:24:46 EDT From: fong@fore.com (Fong-Ching Liaw) Message-Id: <9408062224.AA00907@pothole.fore.com> To: ip-atm@matmos.hpl.hp.com, susan@gateway.mitre.org Subject: Re: multicasting Susan It is not coincidental that the ATM group addresses look and smell just like IP mulitcast. It is designed using the same idea. Also, because the ATM call parameters are expressed explicitly in ATM messages (such as SETUP and ADD PARTY), security options such as specified in atm94-0325R1 are also available to ATM groups. Actually, depends on how sender specify his leaf-initiated option, sender may or may not be informed of receiver's join. It should be straigtforward to map IPmc address to ATM group address since ATM group addresses space is so big, so you are not missing anything :-) I think this group (maybe in conjuction with tuba group ?) should recommend to ATM Forum's multiprotocol BOF/WG an algorithm mapping between these two, otherwise there is no hope for IP to run any automatical operation over ATM. Please, NO ARP or INARP. The leaf initiated join comes useful when receiver know the "call identifier" it want to join. So, it is perfect tool to allow receivers to "reconnect" to connections, but it does not help to form the group. As you pointed out, the call parameter is separated from the group, it is possible to indicate many-to-many when it's available. To get around the scalibility problem in large number of senders, we may want to separate IPmc addresses into space for low-load, delay insensitive many-to-many groups and high-load few-to-many groups. Some optimization is then possible (such as using mc server for first case, and ATM group for the latter.) This is a half baked idea. A strong statement into ATM Forum to support both Leaf-Init and Group address will not only make the Forum spec. provides such functionality, it also signals to ITU-T and therefore an international standard on public networks is possible. Thanks, - -Fong ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08503; 8 Aug 94 15:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08499; 8 Aug 94 15:03 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa27636; 8 Aug 94 15:03 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA228775939; Mon, 8 Aug 1994 10:12:19 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA228445931; Mon, 8 Aug 1994 10:12:11 -0700 Date: Mon, 8 Aug 1994 10:12:11 -0700 Message-Id: <199408081712.AA228445931@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: ATM INAP DSU clarification Hi Folks, I wanted to make a clarification to a statement I made on Friday about the state of the worlds of DSU and FR from the ATM INAP meeting. ATM DSU's take a high speed serial interconnect feed from a router. The router's job is to place packets on the link, encapsulated, and they add a header. The DSU reads the header, then shreds the remainder of the packet (including the encapsulation) into ATM cells and cheerfully sends them along the VC. At the other end of the pipe, the DSU rebuilds the packet and hands it to the router, the router strips the encapsulation to produce an IP packet. Routers are using FR (NLPID) encapsulation on the serial link. To the DSU, the encapsulation is part of the data stream and is therefore ignored. DSU's were consistently using AAL3/4 to carry the PDU's. One vendor can now support AAL5. At some point in the future, the other major DSU vendor will support AAL5 also. Router vendors, with native ATM interfaces, are supporting LLC/SNAP encapsulation and AAL5 only. So you can see that a native ATM router interface cannot interoperate with a DSU shredded PDU. Same for hosts with native ATM interfaces. AAL3/4 != AAL5 and NLPID != LLC/SNAP. The ATM INAP folks have it as a goal to be able to get to an all LLC/SNAP and AAL5 world within the next year. Again, this is just an informational data point. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08859; 8 Aug 94 15:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08855; 8 Aug 94 15:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28015; 8 Aug 94 15:24 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA245858120; Mon, 8 Aug 1994 10:48:40 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from kentrox.com (kentrox.kentrox.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA245438116; Mon, 8 Aug 1994 10:48:36 -0700 Received: by kentrox.com (/\==/\ Smail3.1.28.1 #28.5) id ; Mon, 8 Aug 94 10:48 PDT Received: by kentrox.com (4.1/SMI-4.1) id AA04646; Mon, 8 Aug 94 10:48:28 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gary Hanson Message-Id: <9408081748.AA04646@kentrox.com> Subject: Re: no comments on my comments? To: Mark Laubach Date: Mon, 8 Aug 94 10:48:27 PDT Cc: ip-atm@matmos.hpl.hp.com In-Reply-To: <199408061657.AA010632242@matmos.hpl.hp.com>; from "Mark Laubach" at Aug 6, 94 9:57 am X-Mailer: ELM [version 2.3 PL0] To prevent potential misunderstandings, I want to clarify some DSU/Router division-of-labor issues raised in Mark's response: > There was a similar discussion at the ATM Internet NAP meeting at Toronto. > I was > asked to introduce IP over ATM to the crowd and to be on hand as a > consultant. I > basically took a back seat as a fly on the wall. The basic consensus was > that the > NAPs want to use LLC/SNAP and will get there as soon as possible. This means > that the two DSU vendors need to add LLC/SNAP into their products so that > directly > connected hosts and routers can talk to to routers that are connected via a > DSU. Hosts and routers may use *any* encapsulation techniques they feel necessary in supporting their various interoperability goals, and the DSUs along the path will remain blithely ignorant. DSUs process the ATM and AAL layers only, and neither add, remove, nor modify any encapsulations that reside in the user data of a CPAAL5_PDU. (Except in the case where a DSU also acts as a host over a set of VC links, the role of a DSU should not even be controversial here.) > The DSUs only support RFC1490 encapsulation. ATM native interfaces in the > routers are supporting LLC/SNAP only. Yes, the FR vs LLC is a problem, but > the crowd settled on getting to LLC as soon as possible and to not have a > mixed world. This is just a data point. Again, by the principle of irrelevance, DSUs can be said to support any and all encapsulations, within their role as ATM layer and AAL processing entities. -gary _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ ______ _/ _/ | /// | TM Gary Hanson gary@kentrox.com _/ _/ | ADC|Kentrox P.O. Box 10704 503-641-3321 (FAX) _/ _/ |______| Portland, Oregon 97210 800-733-5511 x6333 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10916; 8 Aug 94 17:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10912; 8 Aug 94 17:02 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00459; 8 Aug 94 17:02 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA207422409; Mon, 8 Aug 1994 09:13:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA207022380; Mon, 8 Aug 1994 09:13:00 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.2-14 #2740) id <01HFNZQ0U2CG8Y5S8G@sys30.timeplex.com>; Mon, 8 Aug 1994 12:10:53 EDT Received: from buddry.timeplex.com by louie.timeplex.com (4.1/SMI-4.1) id AA29149; Mon, 8 Aug 94 11:10:44 CDT Date: Mon, 08 Aug 1994 11:10:44 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Bubenik Subject: Re: multicasting To: ip-atm@matmos.hpl.hp.com Message-Id: <9408081610.AA29149@louie.timeplex.com> Content-Transfer-Encoding: 7BIT > The ATM Forum Draft 94-0325R1 by Rick Bubenik and Pete Flugstad (both of ASCOM > TIMEPLEX, INC.) attempts to reconcile the sender versus receiver differences > between IPmc and ATMmc by providing for mechanisms within ATM signaling that > allow leaf initiated Joins (LIJs) as well as sender-initiated joins. This > ATM Forum contribution seems to be one that the IETF IP-over-ATM group should > study and consider as it generates a list of requirements for mapping IPmc > to ATMmc. Not only does it provide the receiver-initiated join option that is > required to support IPmc; it also provides for a security option to allow > the sender (root) to determine whether or not a leaf requesting to join a group > should be permitted. Such a security option improves on the multicasting service > provided by IPmc and will be an important feature in support of some user > communities. > > In particular, one potential requirement that the IP-over-ATM WG can send to > the ATM Forum is that the ATM forum should either adopt the LIJ (94-0325R1) > contribution or something equivalent as part of the UNI 4.0 specification. > This may well happen absent of a recommendation from our WG, but it sure couldn't > hurt. For your information, here's the ASCII version of ATM Forum 94-0325R1 contribution, referenced by Susan above. Note that we intend to submit a revised version of this contribution at the September ATM Forum meeting, but the general mechanisms and ideas should remain largely intact. I'll also send a PostScript version in a separate message. > Because of the connectionless nature of IP networks, the service provided is > multipoint-to-multipoint in both directions among all group members. Because > of the connection-oriented nature of ATM networks, however, transmission among > group members is dependent on the type of multicast VCs being used. The ATM > Forum has so far defined the signaling specifications for unidirectional, > point-to-multipoint VCs only. ("Unidirectional" is used to mean that data > can be sent only in the direction from the root to the leaves on the VC; no > return bandwidth from the leaves to the root is provided.) No ATM Forum > signaling specifications have yet been defined for bidirectional point-to- > multipoint VCs or for multipoint-to-multipoint VCs. In fact, the Forum > signaling working group has tabled consideration of multipoint-to-multipoint > VCs until some indefinite future time. This isn't entirely correct. The current requirement pending for UNI 4.0 signaling is support of "multipoint communication configurations." It has not yet been decided whether these will be implemented via a single, native ATM mpt-to-mpt connection, or via a collection of pt-to-mpt or pt-to-pt connections. Consequently, there's still room to influence the direction of the Forum. We submitted detailed proposals for mpt-to-mpt signaling in contribution ATMF 94-0264 (which I've included below for reference). Contribution ATMF 94-0457 (by R. Buhrke of AT&T) refined our approach (and is recommended reading, if you have access to it). While the signaling aspects of mpt-to-mpt are fairly straightforward (perhaps even trivial), the traffic aspects are more involved. Two of the main issues are: 1) how is bandwidth allocated on the branches of the call tree and 2) how is policing done when the flows on multiple branches merge into a single branch. Our proposal addresses issue (1) using simple, uniform assignment. Issue (2) requires some level of switch hardware support (except, perhaps, for "best effort" connections). If the IETF ultimately decides that a native ATM mpt-to-mpt capability is desirable and useful, I suggest making that desire known to the ATM Forum. Currently, the official status of this capability is that it is "on hold" until a firm justification from the user community is demonstrated. Consequently, if no justification is made, it's unlikely that it will be in UNI 4.0. rick ++++++ ********************************************************************** ATM Forum: Technical Committee, Signalling Subworking Group ATM Forum/94-0325R1 ********************************************************************** TITLE: Leaf Initiated Join Extensions ********************************************************************** SOURCES: Rick Bubenik Pete Flugstad ASCOM TIMEPLEX, INC. ASCOM TIMEPLEX, INC. 1807 Park 270 Drive 1807 Park 270 Drive St. Louis, MO 63146 St. Louis, MO 63146 (314) 579-6512 (office) (314) 579-6520 (office) (314) 542-0495 (fax) (314) 542-0495 (fax) rick@louie.timeplex.com pete@louie.timeplex.com ********************************************************************** DISTRIBUTION: ATM Forum Technical Working Group ********************************************************************** ABSTRACT In this contribution, we propose extensions to the existing (phase 1) UNI 3.1 signalling protocol to support Leaf Initiated Join (LIJ) calls. This contribution is a follow-on to contributions ATMF 94-0264 and ATMF 94-0325, where a "bare-bones" LIJ call capability was introduced (in 94-0264) then refined considerably (in 94-0325). The current contri- bution retains the general model of 94-0325, while incorporating most of the suggestions that were made at the May, 1994 ATM Forum meeting for improving the model. ********************************************************************** DATE: July 18-21, 1994 ********************************************************************** NOTICE This document is offered to the ATM Forum membership as a basis for discussion and is not binding on ASCOM TIMEPLEX or on any other member organization. The requirements, specifications, proposals, comments or other material presented herein are subject to change in form and content after further study. ASCOM TIMEPLEX specifically reserves the right to add, amend, or withdraw the statements contained herein. 1 Introduction In contribution 94-0264 (submitted to the March, 1994 ATM Forum meeting), we proposed extensions to the phase1 UNI signalling protocol to support Leaf Initiated Join (LIJ) calls. For simplicity, we imposed several restrictions on LIJ calls to avoid race conditions and minimize the protocol modifications. The Signalling SWG membership generally accepted the direction set forth in contribution 94-0264, but was concerned about some of these restrictions, as reflected in the following excerpt from the Signalling SWG meeting minutes: For leaf-initiated joins to a multipoint call, the contribution [94-0264] proposed a simplified version in which only the leaves would be allowed to perform adds and drops and in which there would be no security. There was concern that this version did not allow a mix of root-initiated and leaf-initiated joins and did not evolve directly from the current point-to-multipoint procedures, which are root-initiated. MOTION: Accept the text in this contribution as preliminary text for leaf-initiated joins, pending it can be enhanced to be an extension of the current point-to-multipoint model. DECISION --> (17/0/7) The motion passed. In response to these concerns, we submitted the first version of contribution 94-0325 to the May, 1994 ATM Forum meeting, which lifted the objectionable restrictions. Additionally, the approach taken in 94-0325 (unlike that of 94-0264) was a direct evolution of the existing root initiated point-to-multipoint procedures and fully compatible with these procedures. Quoting from the meeting minutes, contribution 94-0325 was accepted as "progressing the leaf-initiated join work," with no objections registered. Several good suggestions were made during the May meeting for refining the approach in 94-0325, so that a more capable and more generalized LIJ capability could be achieved. The current contribution, 94-0325R1, incorporates most of these suggestions. 1.1 Background In this section, we briefly present the history of our past LIJ contributions to show how this work has progressed and to highlight the changes that have been made in the past and those that are being proposed in the current contribution. 1.1.1 Transition from 94-0264 to 94-0325 ATMF 94-0264 proposed adding two new information elements to support LIJ calls. The first, the Global Call ID (GCID) information element, uniquely labels each LIJ call within the network. The second, the Leaf Initiated Join Parameters (LIJP) information element, contains options specified by the call's creator that are associated with the call. Both of these are also present in the current approach, although both have been modified slightly (for example, the GCID has been broken into separate information elements, one each for each component field, and the LIJP no longer has the parameters that restricted root adds and drops since these restrictions have been lifted). The basic LIJ call paradigm of 94-0264 is as follows: In a leaf initiated join call, the root is defined as the user who creates the call and the leaves are defined as the endpoints (or parties) who join the call after it has been created. The root creates the call using a SETUP message, which contains the GCID information elements (to uniquely label the call) and a LIJP information element (to set options associated with the call). Leaves likewise join the call using a SETUP message, which contains a GCID information elements that are used by the network to find the appropriate call to join. The SETUP message builds towards the call tree by routing towards the root and is joined to the existing call tree when it is bumped into within the network. In 94-0264, we proposed the following restrictions to keep the protocol modifications simple: 1) Leaves were required to add themselves and could not be added by the root-in 94-0325, we lifted this restriction so that the root can also add leaves. Note: in 94-0264, this restriction prevented the root from adding even the first leaf. In 94-0325, the root is allowed to add the first leaf, although we retained the ability for the root to create a call with no initial leaves so that distribution services can be more easily supported (where the clients of this service are not necessarily known when the call is created). 2) Leaves were required to drop themselves and could not be dropped by the root-in 94-0325, we lifted this restriction so that the root can also drop leaves. 3) No security, where any party can freely join the LIJ call-in 94-0325, this restriction was retained. However, the current contribution lifts this restriction. 4) The root was not notified of leaf joins and drops-in 94-0325, we lifted this restriction, although we allow these notifications to be turned on and off in case the root does not want to track the call's participants. 5) Endpoint references were not assigned to the leaves-in 94-0325, we lifted this restriction, although if the root chooses to turn off notification of leaf joins and drops, the root does not discover the leaf endpoint references (for leaves that add themselves). In summary, the only restriction that remained in 94-0325 was that of no security. Additionally, some of the changes in 94-0325 obviated the need for certain options and these options were dropped. However, we retained other options (like the ability to turn notifications on and off) so that the user can control the level of required root partici- pation in the LIJ call. 1.1.2 Transition from 94-0325 to 94-0325R1 Contribution 94-0325R1 retains the basic approach of 93-035, but adds a few enhancements and simplifications. Namely, the following changes are made: - A leaf can request to join a non-existent call. In this case, the LEAF SETUP REQUEST sent by the leaf is delivered to the (potential) root. In response to the LEAF SETUP REQUEST, the root (optionally) creates the call with the requesting leaf as the first endpoint. - Security is added by setting a flag in the LIJP information element that forces all LEAF SETUP REQUESTs to go to the root. This allows the root to selectively add or not add individual leaves based on their identity. Additional "access list" security modes are also discussed in Section 5, although we have not fleshed out all of the details for these modes yet. - New information elements (IEs) have been added to carry addresses in the LEAF SETUP REQUEST messages (and in the other new messages). These new IEs are formatted identically to the Called and Calling Party Num- ber IEs-they have been added to disambiguate the usage of the addresses. - A new message, the NEW LEAF ANNOUNCE, has been added to announce that a leaf has joined the call. Formerly, the ADD PARTY ACK was used for this purpose, but it was suggested that this use was inappropriate at the May `94 meeting. - The "discriminator" field has been dropped from the GCID information element since its presence was deemed redundant to that of the "local call identifier" field. - The GCID information element has been broken into three separate information elements, one for each field of the GCID. This was done since all GCID fields were not needed in all circumstances. We refer to the collection of new information elements that uniquely label a call as the GCID information elements or simply as the GCID. These are the main changes in the LIJ mechanism from 94-0325. Additionally, we have also added details to the "Textual Modifications" section (Section 7) to give proposed message and information element text for the phase 2 signalling protocol Interoperability Agreement. 1.2 Contribution Organization The remainder of this contribution is organized as follows. In Section 2, we describe the LIJ paradigm by way of simple examples. In Section 3, we enumerate the information element and message additions and changes. In Section 4, we give detailed examples of several LIJ scenarios to demonstrate a possible internal (NNI) implementation and to show how internal race conditions can be avoided and gracefully handled. In Section 5, we explain how the LIJ call paradigm can be extended to add "access list" security. In Section 6, we discuss how third party call setup can be supported by building on the LIJ call mechanisms. In Section 7, we give the text modifications required to extend the phase 1 UNI signalling protocol to support LIJ calls. Finally, in Section 8, we summarize our proposal. 2 Overview of Leaf Initiated Join Call Paradigm Leaves join LIJ calls in one of three ways: 1) join to an active call with other participants (leaves) currently in the call, where the network connects the joining leaf, 2) join to an inactive call with no other participants, where the root connects the leaf or 3) join to an active call, where the root connects the joining leaf (for example, for security reasons). The second and third join types use very similar procedures. Hence, case (1) is covered in Section 2.1 and cases (2) and (3) are covered together in Section 2.2. 2.1 LIJ to Active Call, Network Connects Leaf The basic LIJ call paradigm for joining an active call, where the network connects the leaf, is illustrated in Figures 1-3. Figure 1 shows the root's initial setup of the call. [ Figure 1 deleted from text version ] The procedures followed are virtually identical to the phase 1 procedures for creation of a point-to-multipoint call. The only difference is that the SETUP messages contain Global Call Identifier (GCID) and Leaf Initiated Join Parameters (LIJP) Information Elements so that the network knows this call is to be enabled for LIJ access. After the call has been created, the root can freely add additional endpoints using the phase 1 point-to-multipoint procedures. As with the first endpoint, the SETUP messages to the new endpoints will contain the GCID and LIJP information elements. Figure 2 shows the procedures that are followed when a new leaf adds itself to the call. [ Figure 2 deleted from text version ] To initiate the join, the leaf sends a new message, the LEAF SETUP REQUEST (LSR), to the network. The LEAF SETUP REQUEST contains the GCID of the call that the leaf wishes to join, the leaf's address and optionally none, some or all of the call parameters (to be used for compatibility checking). Internally, the network uses the GCID to locate the call (see Section 4 for details), then for any call parameters specified by the leaf, the network checks to make sure that these are identical with those of the call. If all specified parameters are identical, a SETUP message is sent to the leaf containing all of the call parameters. The leaf then responds with a CALL PROCEEDING (optional) followed by a CONNECT message. Note that the SETUP/CALL PROCEEDING/CONNECT interaction abides by the existing point-to-multi- point procedures, with the only exception being that the SETUP message additionally contains the GCID and the LIJP information elements (and an optional sequence number, described later in this section). The motivation for adding the LEAF SETUP REQUEST message was to retain this backward compatibility, where all new parties are added to the call by building from the call tree towards the leaf to be added. It also allows leaves to join the call without a priori knowledge of the call parameters. After the leaf has accepted the invitation into the call by responding with a CONNECT (and assuming notifications of leaf joins and drops have been turned on), the root receives a NEW LEAF ANNOUNCE (NLA) message announcing the new leaf's participation. The NEW LEAF ANNOUNCE contains a network assigned endpoint reference for the new leaf and the address of the leaf that joined the call. As an option, the leaf can include a leaf sequence number in the LEAF SETUP REQUEST message so that the LEAF SETUP REQUEST can be paired with the SETUP message response. This sequence number is placed in a new information element, the Leaf Sequence Number (LSN), which is copied without modification to the SETUP message sent in response to the LEAF SETUP REQUEST and otherwise uninterpreted by the network. If a failure occurs when attempting to fulfill the LEAF SETUP REQUEST, a LEAF SETUP FAILURE (LSF) message is returned to the leaf, as shown in Figure 3. [ Figure 3 deleted from text version ] The LEAF SETUP FAILURE contains the GCID, the LSN (if specified by the leaf) and a cause code indicating the reason for failure. Potential causes include: call parameter mismatch (if the leaf specified any of the call parameters and these were incorrect), nonexistent call (where no call corresponding to the GCID can be found) and insufficient network resources (where the call cannot be extended from the existing call tree to the leaf's UNI). 2.2 LIJ to Inactive or Active Call, Root Connects Leaf For inactive LIJ calls, the LEAF SETUP REQUEST issued by the leaf gets forwarded by the network all the way to the intended root (even though no call exists). Upon receiving the LEAF SETUP REQUEST message, the root has the option of creating a new call to the leaf by issuing a SETUP message or of sending a failure code back to the leaf in a LEAF SETUP FAILURE message. The network will also forward all LEAF SETUP REQUEST messages to the root on any LIJ call where the root requests screening of new leaves (see Section 3.2 for details on how this specification is made). In this case, the root can add the leaf by issuing an ADD PARTY message or deny the join by issuing a LEAF SETUP FAILURE. Similarly, if a leaf attempts to join a call that has been created without the GCID and LIJP information elements (that is, a call that has not been advertized to the network as being LIJ capable), the network will likewise forward the LEAF SETUP REQUEST message to the root. As above, the root has the option of issuing an ADD PARTY message to add the requesting leaf or of issuing a LEAF SETUP FAILURE to deny the join. Figure 4 shows the interactions that occur when leaf 2 sends a LEAF SETUP REQUEST to join an inactive call. [ Figure 4 deleted from text version ] In this case, the LEAF SETUP REQUEST triggers the normal steps that occur when the root creates a call to a new party independently. The only slight modification is that the root is required to echo the leaf's LSN in the SETUP message, if one was specified by the leaf. Additionally, if the root wishes to make the newly created call generally available for network supported LIJ, it must include the GCID and LIJP information elements in the SETUP message. If the root chooses not to add the requesting leaf, it issues a LEAF SETUP FAILURE message with an appropriate cause code (such as access denied), along with the LSN, if one was specified. Figure 5 shows the interactions that occur when the root requests screening of all LEAF SETUP REQUEST messages (or, alternatively, if the root does not formally advertize the call as being LIJ capable). [ Figure 5 deleted from text version ] In this case, the LEAF SETUP REQUEST triggers the normal steps that occur when the root adds a leaf to an ongoing point-to-multipoint call. As above, the only slight modification is echo of the leaf's LSN in the ADD PARTY message, if one was specified by the leaf. Once again, the root could refuse to add the requesting leaf by responding with a LEAF SETUP FAILURE message. 3 Summary of Information Element and Message Changes In this section, we summarize the information element and message additions and changes required to the phase 1 version of the UNI signalling protocol so that LIJ calls can be supported. The new information elements and messages are summarized below: - Global Call Identifier (GCID) information elements, which are used to uniquely label LIJ calls within the network: * Root Call Identifier (RCID) information element, which holds the identifier assigned to the call by the root (and unique at the root's UNI), * Root Number (RN) information element, which holds the root's address (analogous to the Called Party Number information element), * Root Subaddress (RS) information element, which holds the root's subaddress (analogous to the Called Party Subaddress information element), - Leaf Initiated Join Parameters (LIJP) information element, which allows the root to specify options associated with the call, - Leaf Sequence Number (LSN) information element, which is used by the leaf to match LEAF SETUP REQUESTs to SETUP and LEAF SETUP FAILURE replies from the network, - LEAF SETUP REQUEST (LSR) message, which is used by a leaf to request connection into a call, - LEAF SETUP FAILURE (LSF) message, which is used by the network to indicate a failure to add the leaf to the call (analogous to a RELEASE COMPLETE message), - New Leaf Number information element, which appears in the LEAF SETUP REQUEST message to identify the party to be added (analogous to the Calling Party Number information element), - New Leaf Subaddress information element, which appears in the LEAF SETUP REQUEST message and is used when traversing public networks that do not support private ATM network addresses (analogous to the use of the Calling Party Subaddress information element), - NEW LEAF ANNOUNCE message, which is used by the network to announce that a new leaf has been added (by the network) to an ongoing call. The modified information element and messages are summarized below: - Endpoint Reference information element, which is modified to contain an endpoint reference flag that distinguishes which side of an interface originates the endpoint reference value. Note: this modification was proposed in contribution 94-0421 and was approved by the signalling SWG for inclusion in UNI 3.1. Hence, no additional modifications are required. - SETUP message, which is modified to include the GCID, LIJP and LSN information elements for LIJ calls, - ADD PARTY message, which is modified to include the LSN information element, In the remainder of this section, we give an overview of the GCID and LIJP information elements. Full details of all information element and message additions and changes appear in Section 7. 3.1 Global Call Identifier Information Elements The Global Call Identifier (GCID) information elements are used to uniquely label the call within the network. Prior to contribution 94-0325R1, this information was contained in one composite information element having the following (simplified) form: |-------------------------------| | GCID Type | - Initially: "Root address-based" |-------------------------------| | Address | - Root's Address (Calling Party Number) |-------------------------------| | Local Call Identifier | - Root assigned identifier, unique at |-------------------------------| Root's UNI | Discriminator | - Timestamp, random number, constant, etc. |-------------------------------| In contribution 94-0325R1, the GCID information element is broken into a collection of GCID information elements which are described below in this section. Additionally, the "Discriminator" field is dropped (since its functionality is redundant with the "Local Call Identifier") and a new information element is added to hold the Root's subaddress. It is assumed that leaves can construct the GCID information elements by (at least) one of two means: 1) by having a priori knowledge of a "well known" service, where the root's address and the local call identifier that the root associates with this service are known and do not normally change or 2) by accessing a data base that maps abstract service descriptions into GCIDs for calls corresponding to these services. The first option might be used for broadcast feeds and for well know groups. The second option might be used for all other services that are not generally well known in nature. 3.1.1 Root Call Identifier The Root Call Identifier information element contains the "GCID Type" and the "Local Call Identifier" fields from the former GCID information element. It has the following (simplified) form: |-------------------------------| | Call Identifier Type | - Initially: "Root address-based" |-------------------------------| | Call Identifier | - Root assigned number, unique at root's |-------------------------------| UNI(e.g., timestamp, random number or well-known constant) The Call Identifier Type field indicates how the LIJ call will be identified. Initially, there is only one allowable mechanism-via the root's number and (optionally) subaddress. (In the future, a new Call Identifier Type could be defined to indicate a group address, where the leaf initiated join call is not tied to a particular user but rather "unrooted." The details of this option are left for further study.) The Call Identifier field is used by the creator to differentiate different leaf initiated join calls that have been created by the same root at the same interface. For example, the Call Identifier could hold a well-known constant, a timestamp or a random number. 3.1.2 Root Number The Root Number information element contains the "Address" field from the former GCID information element. It has the following (simplified) form: |-------------------------------| | Root Number | - Root's address (analogous to called |-------------------------------| party number) The Root Number contains the root's address. 3.1.3 Root Subaddress The Root Subaddress information element was not in the former GCID information element. It has the following (simplified) form: |-------------------------------| | Root Subaddress | - Root's subaddress (analogous to called |-------------------------------| party subaddres) The Root Subaddress is used when traversing public networks that do not support private ATM network addresses, where the Root Number is stored in the Root Subaddress field and the exit point of the public network is placed in the Root Number field (analogous to the use of Called Party Number and Called Party Subaddress in SETUP messages). 3.2 Leaf Initiated Join Parameters Information Element The Leaf Initiated Join Parameters (LIJP) information element is used by the root to associate options with the call when the call is created. It has the following (simplified) form: |----------------------------| | Security Indication | - Initially: OPEN, ROOT SCREENING |----------------------------| | Notification Indication | - Initially: NONE, ROOT |----------------------------| | Zero Leaf Behavior | - Initially: DROP CALL, MAINTAIN CALL |----------------------------| The valid options for each field are shown to the right of the field. Note that additional options may be added in the future as the LIJ capability evolves. The Security Indication specifies the level and type of security to be associated with the LIJ call. Initially, this option must be set to either OPEN (implying no security, where the network will add any new parties that request to join the call, then optionally notify the root) or ROOT SCREENING (implying that all LEAF SETUP REQUESTs will be forwarded to the root so that the root can selectively choose to add whichever parties it wants). (Note: we describe an "access list" security option in Section 5, but have not included it here since we have not yet fleshed out all of the details.) The Notification Indication specifies who gets notified of leaf joins and drops. Initially, this option can be either NONE (implying that no party gets notification of leaf joins and drops) or ROOT (implying that the root gets these notifications). In the future, leaf notification of other leaf joins and drops could be added, if desired. The Zero Leaf Behavior indicates what action the network should perform when the last leaf in the call drops out. Initially, this option can be either DROP CALL (implying that the call is released) or MAINTAIN CALL (implying that the call remains up with zero leaves so that other leaves can join in the future). If the Zero Leaf Behavior is set to MAINTAIN CALL, the root is allowed to create the call with no initial endpoints (that is, with no Called Party Number in its initial SETUP message). 4 Internal (NNI) Processing of Leaf Initiated Join Requests In this section, we give detailed examples showing how the network internally handles operations on LIJ calls. We go through the following five steps: 1) Root setup of LIJ call using existing point-to-multipoint procedures. 2) Root add party of second endpoint to call using existing point-to-multipoint procedures. 3) Leaf join to call using new LIJ procedures. We present three alternatives: 3a) Call is assumed to have a security indication of OPEN and the LEAF SETUP REQUEST is processed by the network at first node where it intersects call tree. 3b) Call is assumed to have a security indication of ROOT SCREENING and the LEAF SETUP REQUEST is forwarded to root for processing. 3c) Call is assumed to have a security indication of OPEN, but the network chooses to forward the LEAF SETUP REQUEST to the root's access node, where it is processed by the network at this point. 4) Leaf join failure due to insufficient resources. 5) Leaf join failure due to timeout of LEAF SETUP REQUEST message. In all of these scenarios, the following network configuration is used, where parties (that is, network clients) are pictured as triangles, network nodes as dark circles, and interconnects as thin solid lines: [ Figure redrawn for text version - clients are letters, Nodes are N# ] B C | | | | N1------N2 /|\ | / | \ | / | \ | / | \ | A-------N3-------N4------N5-------D \ | / | \ | / | \ | / | \|/ | N6------N7 | | | | F E 4.1 Successful Initial SETUP by Root Client A creates the call (and is the root of the call) by issuing a SETUP message to called party B, as shown below: [ Figure deleted from text version ] The SETUP message contains the mandatory (and any optional) parameters, along with the GCID and LIJP information elements. For this example, we assume that the GCID=A.1.2, and that the LIJP specifies a call with root notifi- cations of leaf joins and drops (we make different assumptions about the Security Indication of the LIJP in Section 4.3). Client B is assigned an endpoint reference of zero by A (as mandated by the point-to-multipoint procedures, since B is the first party), which we denote as {A:0} (the "A" prefix is used to indicate that the endpoint reference was assigned by A's side of the interface, as will be reflected in the endpoint reference flag). Both network nodes processing the SETUP message (N3 and N1) cache the GCID and the LIJP so that subsequent leaf joins can attach at these nodes. Client B accepts the call offering by issuing a CONNECT message and the call setup is completed as follows: [ Figure deleted from text version ] where the active branches of the call are depicted by heavy lines. Note that the SETUP message delivered to B contains the GCID and LIJP information elements. This is done for symmetry so that if B were in fact a PBX it could add leaves into the call within its domain. 4.2 Successful ADD PARTY by Root Client A now adds client C to the call using an ADD PARTY message and sets C's endpoint reference = {A:1}, as shown below: [ Figure deleted from text version ] The ADD PARTY progresses through the network and is translated into a SETUP at node N1. The SETUP message contains all of the call parameters, including the GCID and LIJP information elements. As before, N2 caches the GCID and LIJP so that is can support subsequent leaf join attachments. Upon receiving the SETUP, client C immediately accepts the call and the CONNECT/ADD PARTY ACK is sent back to A (for simplicity, CALL PROCEED- ING and CONNECT ACK messages are not shown). 4.3 Successful LEAF SETUP REQUEST by Leaf In this section, we illustrate three different scenarios for a successful LEAF SETUP REQUEST issued by a leaf. These are based upon the Security Indication specified by the root when it created the call (one of OPEN or ROOT SCREENING) and on network provider capabilities (that is, whether the network is capable of adding leaves at any internal node or just at the root's access node). 4.3.1 Security Indication is OPEN, Network Supports Joins Anywhere On Call Tree This first scenario traces a leaf join where the root specified a Security Indication of OPEN when creating the call. This results in processing of all LEAF SETUP REQUEST messages at the node where they intersect the call tree. Client D initiates the operation using a LEAF SETUP REQUEST (LSR) message, as shown below: [ Figure deleted from text version ] Client D issues the LEAF SETUP REQUEST with GCID = A.1.2 and with a Leaf Sequence Number (LSN) of 1. Internally, the network takes A's address from the GCID and uses this to route the LEAF SETUP REQUEST message towards A. The LEAF SETUP REQUEST is forwarded as a datagram by the network, passing through nodes N5 and N1 (where the call tree is located). Intermediate node N5 does not cache any information about the call or the LEAF SETUP REQUEST datagram. When node N1 receives that LEAF SETUP REQUEST and determines that it is currently supporting the call, it simulates receipt of an ADD PARTY message from the root to add D to the call (and remembers that it is processing a LEAF SETUP REQUEST from D). Node N1 also assigns D an unused endpoint reference = {N1:1} (note the "N1" prefix, indicating that the N1 side of each interface has assigned this endpoint reference value). Node N1 has multiple routes by which it can reach client D. It is not constrained to follow the route that the LEAF SETUP REQUEST message took to reach it. However, in this example, the route through node N5 is the shortest. Hence, N1 chooses this route to reach D, as shown below: [ Figure deleted from text version ] Since the call is not yet active along the link, N1 sends a SETUP message along this path. (If, for whatever reason, the route through N2 had been chosen, an ADD PARTY message would have been sent down this path since the call is active on the link.) The SETUP message contains D's address in the Called Party Number infor- mation element (copied from the New Leaf Number information element), the GCID and LIJP information elements, all other call parameter information elements originally specified by A when the call was created, and the LSN information element that D included in the LEAF SETUP REQUEST message. When D receives the SETUP, it checks the LSN to verify that the SETUP is the result of D's previous LEAF SETUP REQUEST (as opposed to being from an independent ADD PARTY issued by A). Client D responds with a CONNECT and is added to the call. (Note: for simplicity, the optional CALL PROCEEDING messages and CONNECT ACKs are not shown above.) When node N1 receives the ADD PARTY ACK, it sends a NEW LEAF ANNOUNCE message to the root A (via N3) to announce D's join (since root notification of leaf joins and drops was turned on for this call). This NEW LEAF ANNOUNCE contains the new endpoint reference assigned to D and D's address. This example has shown the case where a leaf joins itself into a call at a node that is already active. There may be other cases where a LEAF SETUP REQUEST intercepts the call tree, but the tree is not active yet at this node (that is, an earlier SETUP is still pending). In this case, the message continues to be forwarded back toward the root, until it hits an active node in call tree or the root's access node. Then, the steps above are followed (where an ADD PARTY from the root is simulated). If the call is not active at the root's access node, the LEAF SETUP REQUEST may either be held by the network until the call goes active, or forwarded to the root for processing (as when the Security Indication is set to ROOT SCREENING). 4.3.2 Security Indication is ROOT SCREENING This scenario traces the same leaf join by D as in Section 4.3.1. However, in this case, the root is assumed to have specified a Security Indication of ROOT SCREENING, forcing all LEAF SETUP REQUEST messages to be forwarded to the root. Client D initiates the operation using a LEAF SETUP REQUEST message, as shown below: [ Figure deleted from text version ] Once again, we assume that the network chooses the same route for forwarding the LEAF SETUP REQUEST datagram towards A, through nodes N5 and N1, where the call tree is bumped into. N1 receives the LEAF SETUP REQUEST and determines that it is currently supporting the call. However, since the Security Indication is ROOT SCREENING, N1 continues forwarding the message towards A and does not cache any information about the LEAF SETUP REQUEST datagram. N3 processes the LEAF SETUP REQUEST in the same manner, forwarding it across the UNI to A. Client A receives the LEAF SETUP REQUEST, processes it, and if it chooses to accept D's request to join the call, issues an ADD PARTY message. The ADD PARTY message contains D's address as the Called Party Number, a new Endpoint Reference for D and the LSN that D specified in the LEAF SETUP REQUEST (if any). The network processes the ADD PARTY following the standard phase 1 point-to-multipoint procedures, forwarding it along the call tree from N3 to N1, where it is converted into a SETUP message, which is forwarded onto N5 and D, as shown below: [ Figure deleted from text version ] When D receives the SETUP, it checks the LSN to verify that the SETUP is the result of D's previous LEAF SETUP REQUEST (as opposed to being from an independent ADD PARTY issued by A). Client D responds with a CONNECT and is added to the call. (Note: for simplicity, the optional CALL PROCEEDING messages and CONNECT ACKs are not shown above.) If the root A had not accepted the request, it would have issued a LEAF SETUP FAILURE message, with the appropriate cause value, and echoed the LSN included by D (if present). This LEAF SETUP FAILURE would be for- warded by the network back to D as a datagram (that is, without network caching of any state information). 4.3.3 Security Indication is OPEN, Network Supports Joins At Root Access Node Only This scenario traces the same leaf join by D as in Section 4.3.1 (with a Security Indication of OPEN). However, in this case, the network is assumed to force all LEAF SETUP REQUESTs to travel to the root's access node (for example, so that other network nodes do not have to cache information about LIJ calls and do not have to perform checks on all LEAF SETUP REQUESTs to see if the call is at the current node). Client D initiates the operation using a LEAF SETUP REQUEST message, as shown below: [ Figure deleted from text version ] This time, we again assume that the network chooses to forward the LEAF SETUP REQUEST datagram towards A through nodes N5 and N1, where it bumps into the call tree. When N1 receives the LEAF SETUP REQUEST, it sees that it is rooted at N3. Hence, due to the network's policy, it knows that it does not support joins at this point and knows to forward the message towards N3. When node N3 receives the LEAF SETUP REQUEST, it determines that it is currently supporting the call and that the call is rooted locally. N3 then proceeds as in Section 4.3.1, simulating receipt of an ADD PARTY message from the root to add D to the call (and remembers that it is processing a LEAF SETUP REQUEST from D). The remaining steps in this case are omitted since they are similar to those shown in Section 4.3.1, the difference being that the join is initiated by the network at N3 rather than at N1. 4.4 Unsuccessful LEAF SETUP REQUEST by Leaf We now give a failure scenario to show the internal interactions that occur on failure. In this example, client E issues a LEAF SETUP REQUEST message with GCID = A.1.2 and LSN = 1. The LEAF SETUP REQUEST message proceeds through N7, and from there to N5, as shown below: [ Figure deleted from text version ] At node N5, the LEAF SETUP REQUEST triggers a simulated ADD PARTY, and is immediately translated into a SETUP, which is sent back to N7. At N7, there are insufficient resources to support the call, so N7 clears the call by sending a RELEASE COMPLETE message back to N5, as shown below: [ Figure deleted from text version ] At N5, the RELEASE COMPLETE message is recognized as a response to the LEAF SETUP REQUEST. So, N5 creates a LEAF SETUP FAILURE message and includes the cause code from the RELEASE COMPLETE and the LSN from the LEAF SETUP REQUEST. It then sends the LEAF SETUP FAILURE to E. 4.5 LEAF SETUP REQUEST Timeout When a leaf sends a LEAF SETUP REQUEST message, a timer is started. The LEAF SETUP REQUEST is acknowledged by the receipt of either: a SETUP message (on success) or a LEAF SETUP FAILURE message (on failure). By inserting an LSN in the LEAF SETUP REQUEST message, the leaf can match the request with the response in the event that multiple LEAF SETUP REQUESTs are pending. The following diagram shows the situation where client F issues a LEAF SETUP REQUEST with LSN = 1, times this request out, then issues a second LEAF SETUP REQUEST with LSN = 2: [ Figure deleted from text version ] At this point, it is possible that both LEAF SETUP REQUESTs could be processed and acknowledged by the network. Client F can distinguish which one is being acknowledged by the LSN in the SETUP or LEAF SETUP FAILURE mes- sage returned. The following diagram shows this case, where two SETUPs have been returned: There is no requirement that F accept one of the SETUPs over the other. It can choose to accept either one (or both, if it so chooses). In all likelihood, F will accept the first SETUP message to arrive (the one with LSN = 2 in this case) and deny the second message, as depicted below: [ Figure deleted from text version ] Note that if the two LEAF SETUP REQUESTs had intercepted to the call tree at the same node, the second join would have waited for the pending SETUP to complete, and, if accepted, would have resulted in an ADD PARTY message to F with LSN = 2. This waiting for the SETUP to complete is as per the existing phase 1 point-to-multipoint procedures. 5 Options for Adding Security In Section 3.2, we introduced two security options: OPEN and ROOT SCREENING. A third security option that we are currently investigating is that of access list security, where the root specifies a list of addresses of parties that are allowed to join the call. If any of these parties issues a LEAF SETUP REQUEST, the party's address will be found on the access list when the call tree is bumped into and a SETUP will be returned to add the party into the call. If a party not on the list issues a LEAF SETUP REQUEST, its address will not be found on the access list and a LEAF SETUP FAILURE will be returned with a cause code indicating permission to join the call was denied (alternatively, the LEAF SETUP REQUEST could be forwarded to the root for root screening). Taking this one step further, the access list could contain address prefixes in addition to complete addresses, where all parties whose address matches the prefix are allowed to join the call. This option would be useful in environments, for example, where all parties on the same subnet as the root are allowed to access the service offered by the root but no other parties (outside of the root's subnet) are given access. The access list itself could be specified either as an extension to the LIJP information element or in a separate information element. 6 Third Party Call Setup Our approach to leaf initiated joins provides a framework upon which third party call setup support can be built. For example, the third party could issue the LEAF SETUP REQUEST on behalf of another party to initiate creation of a new call (depicted in Figure 6) or joining of a party to an ongoing point-to-multipoint call (depicted in Figure 7, where the Security Indication is assumed to specify ROOT SCREENING). To facilitate this functionality, the LEAF SETUP REQUEST should be modified to include the following two information elements: - Initiator Number-to identify the third party initiating the call setup, and - Initiator Subaddress-for use when traversing public networks that do not support private ATM Forum addresses. Additionally, a new message, the LEAF SETUP ACK, should be introduced so that the third party can obtain an acknowledgment of successful call creations and leaf additions (recall that the acknowledgment is implicit in the SETUP message for leafs that add themselves). [ Figure 6 deleted from text version ] [ Figure 7 deleted from text version ] To further generalize the third party call setup capability, multiple New Leaf Number information elements could be allowed in the LEAF SETUP REQUEST so that a third party can add multiple parties with one message. This proposed solution only addresses one aspect of the third party call setup problem. Namely, initiation by the third party, where the parties to be connected are capable of running the signalling protocol. The other aspect of this problem is redirection of signalling messages from the parties to be added to a surrogate signalling entity (or entities), for use when the parties to be added are not capable of running the signalling protocol. Our solution does not address this aspect of the problem. 7 Textual Modifications This section contains draft textual modifications for adding the leaf initiated join capability to the UNI signalling protocol. We have not (yet) completed a detailed review of the contents of this section, but have decided to include it in this revision to give the ATM Forum membership more concrete specifics on how the LIJ capability will be implemented and to seek early feedback on the approach we are pursuing. 7.1 Messages for Leaf Initiated Join Call and Connection Control [Insert table summarizing new messages] 7.1.1 LEAF SETUP REQUEST This message is sent by a user to the network to initiate leaf joining procedures. Message Type: LEAF SETUP REQUEST Significance: global Direction: both [ Table deleted from text version ] 7.1.2 LEAF SETUP FAILURE This message is sent by the network to indicate a failure to join the user to the requested call. Message Type: LEAF SETUP FAILURE Significance: global Direction: both [ Table deleted from text version ] 7.1.3 NEW LEAF ANNOUNCE This message is sent to announce the addition of a new leaf to an existing connection. Message type: NEW LEAF ANNOUNCE Significance: global Direction: both [ Table deleted from text version ] 7.2 Information Element Coding for Leaf Initiated Join Call and Connection Control 7.2.1 LEAF INITIATED JOIN PARAMETERS The Leaf Initiated Join Parameters (LIJP) information element is used by the root to associate options with the call when the call is created. [ Table deleted from text version ] 7.2.2 LEAF SEQUENCE NUMBER The Leaf Sequence Number (LSN) information element is used by a joining leaf to associate a SETUP or LEAF SETUP FAILURE response with the corresponding LEAF SETUP REQUEST message that triggered the response. [ Table deleted from text version ] 7.2.3 Root Call Identifier The Root Call Identifier (RCID) information element is used to uniquely label a call at the Root. [ Table deleted from text version ] 7.2.4 ROOT NUMBER The Root Number (RN) information element is used to identify the new leaf that is joining the call. Its format is identical to that of the Called Party Number information element, except for a different information element identifier. 7.2.5 ROOT SUBADDRESS The Root Subaddress (RS) information element is used to identify the new leaf that is joining the call. Its format is identical to that of the Called Party Subaddress information element, except for a different information element identifier. 7.2.6 NEW LEAF NUMBER The New Leaf Number (NLN) information element is used to identify the new leaf that is joining the call. Its format is identical to that of the Calling Party Number information element, except for a different information element identifier. 7.2.7 NEW LEAF SUBADDRESS The New Leaf Subaddress (NLS) information element is used to identify the new leaf that is joining the call. Its format is identical to that of the Calling Party Subaddress information element, except for a different information element identifier. 8 Summary We propose that the approach to leaf initiated joins described in this contribution be adopted by the ATM Forum membership as the general direction for adding this capability to the phase 1 UNI signalling protocol. ************************************************************************** ATM Forum: Technical Committee, Signalling Subworking Group ATM Forum/94-0264 ************************************************************************** TITLE: Changes to support Phase 2 capabilities: virtual path connection establishment, multipoint-to-multipoint connections and leaf initiated join. ************************************************************************** SOURCES: Rick Bubenik Pete Flugstad ASCOM TIMEPLEX, INC. ASCOM TIMEPLEX, INC. 1807 Park 270 Drive 1807 Park 270 Drive St. Louis, MO 63146 St. Louis, MO 63146 (314) 579-6512 (office) (314) 579-6520 (office) (314) 542-0495 (fax) (314) 542-0495 (fax) rick@louie.timeplex.com pete@louie.timeplex.com ************************************************************************** DISTRIBUTION: ATM Forum Technical Committee, Signalling Subworking Group ************************************************************************** ABSTRACT This contribution proposes baseline text and modifications to the phase 1 UNI signalling protocol to support new capabilities of the phase 2 signalling protocol. New messages, information elements and procedures are described for the support of virtual path connection establishment, multipoint-to-multipoint connection establishment, and leaf initiated joins of calls. ************************************************************************** DATE: March 20 -- 23, 1994 ************************************************************************** NOTICE This document is offered to the ATM Forum membership as a basis for discussion and is not binding on ASCOM TIMEPLEX or on any other member organization. The requirements, specifications, proposals, comments or other material presented herein are subject to change in form and content after further study. ASCOM TIMEPLEX specifically reserves the right to add, amend, or withdraw the statements contained herein. 1 Introduction At the January 1994 ATM Forum meeting, virtual path connection establishment, multipoint-to-multipoint connection support and leaf initiated joins to calls were accepted as capabilities to be included in the phase 2 signalling protocol. This contribution proposes changes and additions to the phase 1 information elements, messages and procedures needed to support these capabilities. Section 2 discusses changes and additions to the protocol to support virtual path connection establishment. Section 3 discusses changes and additions to the protocol to support multipoint-to-multipoint connection establishment. Section 4 discusses changes and additions to the protocol to support leaf initiated joins. Section 5 summarizes the contribution. 2 Optional Virtual Path Connection Support 2.1 Introduction This section gives the changes needed to support Virtual Path Connection (VPC) establishment in the UNI signalling protocol. This section addresses changes to the Messages, Information Elements and Procedures sections. Other sections of the specification, such as the capabilities list of Section 5.1.2, may need to be reviewed to bring them into alignment with this contribution and other phase 2 capabilities. Virtual path connection establishment is supported by adding a Connection Level field to the Broadband Bearer Capability Information Element (IE). This field indicates the type of connection requested, Virtual Path or Virtual Channel. The details of the change are given below. 2.2 Information Elements 2.2.1 BROADBAND BEARER CAPABILITY Octet 5 of the Broadband Bearer Capability (BBC) IE (described on page 207 of the 3.0 ATM UNI specification) is modified to include a "Connection Level" field (in what was formally a spare field) and codings for the Connection Level are added, as follows: 8 7 6 5 4 3 2 1 Octets |-----------------------------------| | Broadband Bearer Capability | | 0 1 0 1 1 1 1 0 | 1 | Information element identifier | |-----------------------------------| | 1 | Coding| IE Inst. field | 2 |ext | Stndrd| | |-----------------------------------| | Length of B-BC contents | 3 |-----------------------------------| | Length of B-BC contents (cont) | 4 |-----------------------------------| | |0/1 | Conn | Bearer Class | 5 | |ext | Level | | |-----------------------------------| | 1 | 0 0 | Traffic | Timing | 5a |ext | Spare | Type | Req. | |-----------------------------------| | 1 | Sus to| 0 0 0 | User Pl | 6 |ext | Clping| Spare | Config | |-----------------------------------| [...] | Connection Level (octet 5) | Bits | | 7 6 | Meaning | -----------|-------------------------------------- | 0 0 | Virtual Channel Connection | 0 1 | Virtual Path Connection All other fields and descriptions in the BBC IE remain the same. 2.2.2 CONNECTION IDENTIFIER IE The VCI description (p. 230) of the Connection Identifier IE is augmented with a note indicating when the VCI is valid, as follows: Virtual Channel Identifier (octets 8 and 9) A two octet binary number assigned to the ATM connection representing the identifier of the Virtual Channel Connection VCI Value | ------------------------------------------------------------- 0 - 15 | Reserved by CCITT 16 - 31 | Reserved by ATM Forum 32 - 65535 | Available for assignment by these procedures. Some value in this range may not be available for use (e.g., permanent connections) | Note - When a Virtual Path Connection is signaled for (as | indicated in the Connection Level field of the Broadband | Bearer Capability IE), the VCI value contained in the | Connection Identifier IE will be ignored by the network. All other fields and descriptions remain the same. 2.3 Messages No changes to any message format, content or description are needed to support virtual path connection establishment. 2.4 Procedures The procedures for creating and clearing virtual path connections are essentially identical to those for virtual channel connections. The procedures text in Section 5.5 applies as currently stated, with four minor modifications listed here. Namely, the second paragraph of Section 5.5.1.2.1 (p. 240) should be modified to read: | The network selects any available VPCI and VCI for virtual channel | connections, and any available VPCI for virtual path connections. and the fourth paragraph should be modified to read: | If the network is not able to allocate a VCI or VPCI, a RELEASE COMPLETE message with cause #45, "No VPCI/VCI available," is sent by the network. Section 5.5.2.3 (p. 244) requires similar modifications, where the first paragraph should be restated as follows: The network shall allocate a VPCI/VCI value and include this value | in the SETUP message (for virtual path connections, the network | does not set the VCI value and the user ignores this field). and the third paragraph should be modified to read: | If the indicated VCI or VPCI is not available, a RELEASE COMPLETE message with cause #35, "Requested VPCI/VCI not available," is sent by the user. 2.5 Discussion As shown in this section, support for virtual path connection establishment in the signalling protocol is straightforward. A minor change to the BBC IE (addition of a Connection Level field) is needed to support this capability. Additionally, four minor textual modifications are required to the procedures section (Section 5.5), where these changes do not fundamentally alter the procedures themselves. 3 Optional Multipoint-to-Multipoint Connection Support 3.1 Introduction This section gives the changes needed to support multipoint-to- multipoint connection establishment in the UNI signalling protocol. This section addresses changes to the messages, information elements and procedures sections. Other sections of the specification, such as the capabilities list of Section 5.1.2, may need to be reviewed to bring them into alignment with this contribution and other phase 2 capabilities. Multipoint-to-multipoint connections are supported by adding a code point to the User Plane Connection Configuration field of the Broadband Bearer Capability IE specifying a multipoint-to-multipoint connection configuration. The details of the change are given below. In addition to the change to the BBC IE, guidelines for assigning traffic parameters and mapping these parameters to branches of the connection are required. It is proposed that the forward and backward traffic parameters be assigned identically for multipoint-to-multipoint connections, and that all branches of the connection be given the same parameter sets. This results in uniform traffic specifications on all branches of the connection in both directions. Section 3.2 contains a more in depth description of the use of traffic descriptors in multipoint-to-multipoint calls/connections. This section is appropriate for inclusion in a phase 2 protocol capabilities list (analogous to Section 5.1.2 of the current specification). Sections 3.3 through 3.5 describe the information element, message and procedures changes, respectively, for supporting multipoint-to-multipoint calls. Section 3.6 contains a summary. 3.2 Multipoint-to-Multipoint Capability The root of a multipoint-to-multipoint call is defined as the user who initially sets up the call (i.e., the calling user). The leaves are all other endpoints that are added to the call, whether they are added by the root (via ADD_PARTY) or by some other means (e.g., leaf initiated join or provisioning). The multipoint-to-multipoint call contains one multipoint-to-multipoint connection [note: other phase 2 capabilities may allow calls to contain more than one connection]. All participants in the multipoint-to-multipoint connection (that is, the root and the leaves) both transmit and receive on the connection. All participants receive the transmissions of all other parties (but do not receive their own transmissions). When creating the call, the root specifies a traffic descriptor for the multipoint-to-multipoint connection in the initial SETUP message (contained in the ATM Traffic Descriptor IE). The traffic descriptor for multipoint-to-multipoint connections is constrained to have identical forward and backward parameter values for all traffic parameters specified. The traffic descriptor is applied uniformly to all branches of the connection. So, for example, if the traffic descriptor specifies a peak cell rate (PCR) of P, a PCR of P is assigned to the root's UNI and a PCR of P is assigned to the UNI of each leaf added to the connection. Note that if multiple participants in the connection transmit at the same time at their peak rate P, the aggregate transmission rate of all participants may exceed the specified rate of individual branches within the connection. If this occurs, the cells in excess may either be marked CLP=1 or dropped, as when point-to-point connections exceed the values contained in their specified traffic descriptors. 3.3 Information Elements While only the Broadband Bearer Capability IE requires a change in coding to support multipoint-to-multipoint calls, three other IEs require additional notes or minor changes: the ATM Adaptation Layer Parameters IE, the ATM Traffic Descriptor IE and the QoS Parameters IE. These changes are indicated in this section. 3.3.1 ATM Adaptation Layer Parameters Change the second paragraph of the ATM Adaptation Layer Parameters IE section (p. 194) to read as follows: The ATM adaptation layer parameters information element may also be included in the CONNECT message to indicate that the called party to a point-to-point call (or the first leaf of a point-to- | multipoint or multipoint-to-multipoint call) wishes to indicate the Forward and Backward Maximum CPCS-SDU size (for AAL 3/4 and AAL5), reduce the value of the MID (for AAL 3/4), or indicate user-defined ALL information. 3.3.2 ATM TRAFFIC DESCRIPTOR The ATM Traffic Descriptor IE (p. 201) is augmented with a note, which is applied to all peak cell rate (PCR), sustainable cell rate (SRC) and maximum burst size (MBS) octet groups of the IE, that reads as follows: | Note 8 - For multipoint-to-multipoint connections, the forward | and backward traffic parameters (of each type) must be | identical. Additionally, if one direction of a forward | or backward traffic parameter is specified, the other | direction must also be specified (with an identical | value). 3.3.3 BROADBAND BEARER CAPABILITY The required BBC IE (p. 207) changes to support multipoint-to- multipoint calls are shown below (along with the changes proposed for VPC establishment in Section 2): 8 7 6 5 4 3 2 1 Octets |-----------------------------------| | Broadband Bearer Capability | | 0 1 0 1 1 1 1 0 | 1 | Information element identifier | |-----------------------------------| | 1 | Coding| IE Inst. field | 2 |ext | Stndrd| | |-----------------------------------| | Length of B-BC contents | 3 |-----------------------------------| | Length of B-BC contents (cont) | 4 |-----------------------------------| | |0/1 | Conn | Bearer Class | 5 | |ext | Level | | |-----------------------------------| | 1 | 0 0 | Traffic | Timing | 5a |ext | Spare | Type | Req. | |-----------------------------------| | 1 | Sus to| 0 0 0 | User Pl | 6 |ext | Clping| Spare | Config | |-----------------------------------| [...] | Connection Level (octet 5) | Bits | | 7 6 | Meaning | -----------|-------------------------------------- | 0 0 | Virtual Channel Connection | 0 1 | Virtual Path Connection [...] User plane connection configuration (octet 6) Bits | 2 1 | Meaning -----------|-------------------------------------- 0 0 | Point-to-point 0 1 | Point-to-multipoint | 1 1 | Multipoint-to-multipoint All other fields and descriptions in the BBC IE remain the same. 3.3.4 QUALITY OF SERVICE PARAMETERS The Quality of Service Parameter IE (p. 231) is augmented with a note, inserted in the specification at the end of the first full paragraph. The note reads as follows: | Note - Some networks may limit the quality of service classes | available for multipoint-to-multipoint connections, | where one or more of the classes listed for this IE | are not supported. All other fields and descriptions in the QoS Parameters IE remain the same. 3.4 Messages No changes to any message format, content or description are needed to support multipoint-to-multipoint connections. 3.5 Procedures The procedures for creating and clearing multipoint-to-multipoint calls are essentially identical to those for point-to-multipoint and calls. Additionally, the leaf initiated join procedures described in the Section 4 of this contribution can also be used to create multipoint-to- multipoint calls. Several minor modifications are required to Section 5.6 of the UNI specification to generalize the language to apply to both unidirectional point-to-multipoint calls and bidirectional multipoint- to-multipoint calls. These modifications are indicated here. Change the title of Section 5.6 (p. 259) to read: 5.6 Call/Connection Control Procedures for Point-to-Multipoint | and Multipoint-to-Multipoint Root Initiated Join Calls Change paragraph one of Section 5.6 (p. 259) to read: This section describes procedures for point-to-multipoint and | multipoint-to-multipoint calls, where the creator of the call adds | all new endpoints (i.e., "Root Initiated Join" calls). The signalling channel used is the same as the one assigned for point-to-point connections. This signalling specification supports point-to- multipoint calls where information is multicasted unidirectionally | from one calling user to a set of called users. This signalling | specification also supports multipoint-to-multipoint calls where all | users can both transmit and receive, where all users receive the | transmissions of all other users (but do not receive their own | transmissions). The calling user is also referred to as the Root; the | called users are also referred to as Leaves. In the procedures of | this section, the Root initiates the joining of all parties to the | call. Hence, these calls are referred to as "Root initiated join | calls." Point-to-multipoint and multipoint-to-multipoint Root | initiated join calls are initiated with a SETUP message which contains an Endpoint reference information element and a Broadband bearer | capability information element indicating point-to-multipoint or | multipoint-to-multipoint in the user plane connection configuration | field. Throughout the remainder of this section, "Root initiated | join calls" will be referred to simply as "calls" for brevity. Change the sixth full paragraph of section 5.6.1.1 (second to the bottom on p. 261) to read: | If the SETUP contains a Broadband Bearer Capability information | element indicating point-to-multipoint in the user plane connection | configuration field, and the ATM User Traffic Descriptor information element contains a non-zero backward user cell rate parameter the network shall reject the SETUP request with cause #73, "Unsupported combination of traffic parameters". Add a paragraph immediately after this paragraph to read: | If the SETUP contains a Broadband bearer capability information | element indicating multipoint-to-multipoint in the user plane | connection configuration field, and the ATM User cell rate | information element does not contain identical forward and backward | parameter values for all traffic parameters specified, the network | shall reject the SETUP request with cause #73, "Unsupported | combination of traffic parameters". In the remainder of Section 5.6 (except for the in the paragraphs identified above), change all occurrences of the phrase "point-to-multipoint" to the phrase "point-to-multipoint or multipoint-to-multipoint." Appendix C contains informative text on the "point-to-multipoint" procedures. This appendix should be generalized in the same manner as Section 5.6 was generalized here to apply to both point-to-multipoint and multipoint-to-multipoint procedures for root initiated join calls. 3.6 Discussion As shown in this section, support for multipoint-to-multipoint call establishment in the signalling protocol is straightforward, as shown in this section. Only a minor change to the BBC IE coding is needed to support the capability. The procedures remain essentially the same as those for point-to-multipoint, where the only changes required in the specification are generalization of the language in Section 5.6 to apply to both call types. 4 Leaf Initiated Join Support 4.1 Introduction This section gives the changes needed to support leaf initiated joins to calls in the UNI Signalling protocol. This section addresses changes to the messages, information elements and procedures sections. Other sections of the specification, such as the capabilities list of Section 5.1.2, may need to be reviewed to bring them into alignment with this contribution and other phase 2 capabilities. Leaf initiated join is supported by adding two new IEs and new procedures to be used when a leaf adds itself to a call. No new messages are required. The first new IE is the Global Call ID (GCID) IE, which uniquely labels the call within the network. The second new IE is the Leaf Initiated Join Parameters (LIJP) IE, which contains five options specified by the call's creator that are associated with the call. Both of these IEs are described in more detail below. Section 4.2 provides an overview of the leaf initiated join model and the options available. This section is appropriate for inclusion in a phase 2 protocol capabilities list (analogous to Section 5.1.2 of the current specification), or as an introduction to a leaf initiated join procedures section (analogous to the introduction in Section 5.6 on point- to-multipoint procedures). Sections 4.3 through 4.6 describe the procedures, information element, message and error code additions and changes, respectively, for supporting leaf initiated joins. Section 4.7 contains a summary and discussion of the issues identified. 4.2 Overview In a leaf initiated join call, the root is defined as the user who creates the call and the leaves are defined as the endpoints (or parties) who join the call after it has been created. The root creates the call using a SETUP message, which contains the GCID IE (to uniquely label the call) and a LIJP IE (to set options associated with the call). Leaves likewise join the call using a SETUP message, which contains a GCID IE that is used by the network to find the appropriate call to join (details of how this is accomplished are described in Section 4.7.1). For the phase 2 protocol, several restrictions are placed on leaf initiated join calls so that the basic procedures remain simple and straightforward, and so that no race conditions occur. Hooks are put in place so that all of these restrictions can be relaxed in the future, if the demand arises. The first restriction is that all leaves MUST add themselves -- the root is not able to any add leaves to the call. This implies that when the call is initially created, the root is the only endpoint in the call. The SETUP message issued by the root for leaf initiated join calls does not allow the specification of another endpoint (called party). After the SETUP completes, the call exists between the network and the root only. Leaves then add themselves to this call using the procedures described in Section 4.3. The second restriction is that the leaves MUST drop themselves -- the root cannot individually drop leaves from the call. The root can, however, clear the entire call at any time (dropping all leaves). The third restriction is that there is no security -- all leaf initiated join calls are completely open so that any leaf can freely join. The fourth restriction is that the root is not notified in any way of leaves that join or drop out of the call. Hence, the root cannot determine the number of leaves or the identity of the leaves participating in the call from the UNI signalling protocol alone. The fifth restriction is that no endpoint references are assigned to the leaves that join the call. Restrictions three and four obviate the need for endpoint references since the root does not get notifications of new leaves and since the root cannot individually drop leaves from the call. As mentioned above, hooks are put in place so that all of these restrictions can be relaxed in the future. In Section 4.7.2, after the details of leaf initiated join have been presented and after the complexities have been explained, these restrictions will be revisited and the difficulting of lifting each one will be discussed. If the demand exists, some of these restrictions could be lifted for the phase 2 protocol. 4.2.1 Global Call Identifier IE Overview The Global Call Identifier (GCID) IE is used to uniquely label the call within the network. It has the following (simplified) form: |-----------------------------------| | GCID Type | |-----------------------------------| | Address | |-----------------------------------| | Local Call Identifier | |-----------------------------------| | Discriminator | |-----------------------------------| The GCID Type field indicates how the remainder of the GCID should be interpreted. Initially, there is only one valid interpretation, which indicates that the Address field must be the address of the root. (In the future, a new GCID Type could be defined to indicate a group address, where the leaf initiated join call is not tied to a particular user but rather "unrooted." The details of this option are left for further study.) The Local Call Identifier field is used by the creator to differentiate different leaf initiated join calls that have been created by the same root at the same interface. The Discriminator field is used (if needed) to further differentiate calls over time that are created with the same Local Call Identifier. For example, the Discriminator could hold a timestamp or a random number, to differentiate calls created at different times with the same Local Call Identifier (this capability might be used if the semantics of the call change over time). It is assumed that leaves can construct the GCID by (at least) one of two means: 1) by having a priori knowledge of a "well known" service, where the root's address and the local call identifier and discriminator that the root associates with this service are known and do not normally change or 2) by accessing a data base that maps abstract service descriptions into GCIDs for calls corresponding to these services. The first option might be used for broadcast feeds and for well know groups. The second option might be used for all other services that are not generally well known in nature. 4.2.2 Leaf Initiated Join Parameters IE Overview The Leaf Initiated Join Parameters (LIJP) IE is used by the root to associate options with the call when the call is created. It has the following (simplified) form: |-----------------------------------| | Security Indication | |-----------------------------------| | Notification Indication | |-----------------------------------| | Drop Restriction | |-----------------------------------| | Add Restriction | |-----------------------------------| | Endpoint Reference Type | |-----------------------------------| All of these fields currently have only one valid setting and all have been inserted to provide the "hooks" mentioned above for lifting the restrictions that are currently placed on leaf initiated join calls. The Security Indication must be set to OPEN (implying no security). The Notification Indication must be set to NONE (implying that the root does not get notification of leaf joins and drops). The Drop Restriction and the Add Restriction must each be set to LEAF ONLY (implying that only leaves can add and drop themselves). The Endpoint Reference Type must be set to NONE (implying that endpoint references are not used to identify leaves). 4.3 Procedures This section contains strawman procedures for creating, joining, dropping out of and clearing leaf initiated join calls. It is expected that these procedures will be placed in a separate (new) section of the UNI specification, potentially with some or all of the introductory material from Section 4.2 of this contribution prepended. The strawman nature of these procedures indicates that further clarifications and modifications are highly likely. However, the main operations are covered in sufficient detail to evaluate the basic paradigm being proposed. [Note: below we use "X.Y" to designate the new section into which the leaf initiated join procedures are placed. For example, X.Y = 5.10 is possible, based on the current UNI specification.] X.Y Leaf Initiated Join Procedures This section describes procedures for setting up a call for leaf initiated join access. The procedures make no assumptions about the call's topology (unidirectional point-to-multipoint and bidirectional multipoint- to-multipoint topologies are both supported) or about the connection level (virtual path and virtual channel calls are both supported). Unlike the Root initiated join procedures described in Section 5.6 of the UNI specification, the leaf initiated join procedures do not require require separate party-states and link-states. Only link-states are used. X.Y.1 Call/Connection Establishment at the Root The Root initiates establishment of a leaf initiated join call following the basic procedures described in Section 5.5 for point-to-point calls. The link-states for the call change according to the call state changes as described in Section 5.5. The following additions apply: The SETUP message sent by the Root must contain a Global Call ID (GCID) IE and Leaf Initiated Join Parameter (LIJP) IE, and MUST NOT contain a Called Party Number IE, Called Party Subaddress IE or Endpoint Reference IE. All other required and optional IEs in the SETUP message remain the same. However, since no new party is added as a result of the root's SETUP message, no negotiation of user-to-user IE parameters is allowed (meaning that at most one occurrence of each negotiable IE is permissible). On receiving the SETUP at the network side of the interface, the network will determine if it supports leaf initiated join calls. If it does not, it will initiate clearing procedures with cause #63, "Service or option not available, unspecified." [Note: it may be desirable to define a new cause number for this case.] If the network does support leaf initiated join calls, it will optionally send a CALL PROCEEDING message to the Root, allocate resources on the link to the Root to support the call, change the link-state for the call to Active, and send a CONNECT message back to the Root. No other activity is performed by the network. The call is not progressed in any direction, and the call is maintained until such a time as the Root initiates clearing procedures. On receiving the CONNECT message, the Root shall change its link-state to Active and respond with a CONNECT ACK message, which the network effectly ignores (that is, this message does not cause a state change in the network or enable/disable any timers). At this time, the Root may send traffic over the established connection. However, until a leaf joins the connection, the root's transmissions are simply dropped by the network at the root's UNI. X.Y.2 Call/Connection Establishment from the leaf. The leaf initiates leaf initiated join procedures on its interface by sending a SETUP message across its interface, and following basic point-to-point procedures, as if it was the initiator of the call. The link-states for the call change according to the state changes described in Section 5.5. The following additions apply: The SETUP message sent by the leaf must contain the same Global Call ID IE as that specified by the Root for the call that the leaf wants to join, and MUST NOT contain a Called Party Number IE, Called Party Subaddress IE, Endpoint Reference IE, or Leaf Initiated Join Parameters IE. All other required and optional IEs in the SETUP message remain the same. Upon receiving the SETUP message on the network side of the interface, the network will optionally respond with a CALL PROCEEDING message. If the call exists in the network and the IEs specified in the leaf's SETUP message contain compatible values to those specified in the Root's SETUP message, then the network will accept the leaf's SETUP and transmit a CONNECT message back to the leaf. In order for the leaf's SETUP message to be compatible with the Root's SETUP message, all mandatory IEs must contain the exact same values as in the Root's corresponding IEs, and the leaf's SETUP message must not contain any additional optional IEs that were not specified by the Root. The optional IEs that the leaf specifies must also contain exactly the same values as the corresponding values that the Root specified, with one exception. Namely, it is permissible for the leaf to indicate multiple options for negotiable IEs (such as the Broadband Low Layer Information). When checking for IE compatibility, the network makes sure that the (single) value specified by the Root during leaf initiated join call creation matches one of the options specified by the leaf. The CONNECT message sent to the leaf after finding the call contains the AAL Parameters IE and the Broadband Low Layer Information IE specified by the Root (if the Root included these IEs in the SETUP message it used to create the leaf initiated join call). If the call exists in the network and the IEs specified in the leaf's SETUP message do not contain compatible values to those specified in the Root's SETUP message, then the network will reject the call and initiate standard clearing procedures towards the leaf with the cause #XX: "leaf call parameters do not match root call parameters in leaf initiated join call." If the call does not exist within the network, the network will respond with a RELEASE COMPLETE message to the leaf with cause #XX: "global call ID not found." X.Y.3 Call/Connection clearing Clearing of the call is initiated by the Root of the call, and follows procedures defined in Section X.Y.3.2. Dropping a leaf may only be initiated by the leaf itself, and follows procedures defined in Section X.Y.3.4. X.Y.3.1 Exception conditions Under normal conditions, call clearing is usually initiated when the Root or the network sends a RELEASE message and follows the procedures defined in Sections 5.5.4.3 and 5.5.4.4 respectively. The only exception to the above rule is in response to a SETUP message, where the network can reject a call/connection from the Root (e.g., because of the unavailability of a suitable virtual channel) by: responding with a RELEASE COMPLETE message provided no other response has previously been sent, releasing the call reference and entering the Null state. X.Y.3.2 Clearing the call initiated by the Root Call clearing by the Root of a leaf initiated join call follows the same procedures as for point-to-point calls (see Section 5.5.4). Upon receiving the RELEASE message, the network propagates the RELEASE down all branches towards all leaves and clears the call along all paths. X.Y.3.3 Dropping a party initiated by the Root Dropping of an individual party of the call by the Root is not supported by this implementation agreement. X.Y.3.4 Dropping a party initiated by the leaf A leaf may remove itself from the call at any time by following the procedures in Section 5.5.4. The following additions apply: The network shall progress the call clearing message from the leaf towards the Root until such time as the clearing message reaches a point where the call branches, and other branches (to other leaves) are in a non-Null state. At this point the network shall not progress the call clearing message any further. If the call clearing message reaches the Root's access node, and no more leaves are present in the call, the call will be cleared on all branches expect for the interface to the Root. The only way for the call to be cleared over this interface (barring network failures) is for the Root to issue a RELEASE. X.Y.4 Handling of error conditions Error conditions are handled as per Section 5.5.6. The following additions apply: Either the Global Call Identifier IE or the Called Party Number IE must be present in any SETUP message, but both must not appear. If both are present, the network responds with cause #XX: "illegal IE combination for leaf initiated join call". If the Global Call Identifier IE is present, then the Called Party Subaddress and Endpoint Reference are disallowed. If either is present, the network responds with cause #XX: "illegal IE combination for leaf initiated join call". If the Root of a leaf initiated join call specifies more than one B-LLI IE (implying a user-to-user negotiation), then the network responds with cause #XX: "illegal IE combination for leaf initiated join call". 4.4 Information Elements This section presents the new information elements needed to support leaf initiated joins to calls. These are the Global Call Identifier IE and the Leaf Initiated Join Parameters IE. 4.4.1 (NEW) GLOBAL CALL IDENTIFIER The Global Call Identifier (GCID) IE is used to uniquely label a call supporting leaf initiated joins within the network. 8 7 6 5 4 3 2 1 Octets |-----------------------------------| | Global Call Identifier | | X X X X X X X X | 1 | Information element identifier | |-----------------------------------| | 1 | Coding| IE Inst. field | 2 |ext | Stndrd| | |-----------------------------------| | Length of GCID contents | 3 |-----------------------------------| | Length of GCID contents (cont) | 4 |-----------------------------------| | Local Call Identifier | 5 |-----------------------------------| | Local Call Identifier (cont) | 6 |-----------------------------------| | Local Call Identifier (cont) | 7 |-----------------------------------| | Local Call Identifier (cont) | 8 |-----------------------------------| | GCID Discriminator | 9 |-----------------------------------| | GCID Discriminator (cont) | 10 |-----------------------------------| | GCID Discriminator (cont) | 11 |-----------------------------------| | GCID Discriminator (cont) | 12 |-----------------------------------| | 1 | 0 0 0 | GCID | 13 |ext | Spare | Type | |-----------------------------------| | 1 | Type of | Addr/Num Plan | 14 |ext | Number | Identifier | |-----------------------------------| | 0 | Address/Number Digits | 15 etc. | | (IA5 Characters) | Note 1 |-----------------------------------| | NSAP Address Octets | 15 etc. | | Note 2 |-----------------------------------| Note 1 - If the use of the E.164 numbering plan is indicated in the addressing/numbering plan identification, the number digits appear in multiple octet 15's in the same order in which they would be entered on a numeric keypad; i.e., the number digit which would be entered first is located in first octet 15. Digits are coded in IA5 characters. Bit 8 is set to 0. Note 2 - If the use of OSI NSAP addressing is indicated in the addressing/numbering plan identification, the address is coded as described in ISO 8348/AD 2, using the preferred binary encoding. Coding Standard (octet 2) Bits | 7 6 | Meaning -----------|------------------------------------------------ 0 0 | ITU-TS (CCITT) standardized IE Instruction Field (octet 2) Bits | 5 4 3 2 1 | Meaning -----------|------------------------------------------------ 0 0 0 0 0 | IE Instruction field not significant Local Call ID (octets 5-8) The Local Call ID is a 4 octet value used to differentiate calls created by the same Root. GCID Discriminator (octets 9-12) The Discriminator is a 4 octet value used to differentiate between instances of calls created by the same Root, with the same Local Call ID. There are many possibilities for assigning values to this field including: a timestamp, a randomly generated number for every instance, an increasing counter for every instance, a well-known value (e.g., 0, which may be used for calls that do not change across instantiations). GCID Type (octet 13) Bits | 4 3 2 1 | Meaning -----------|------------------------------------------------ 0 0 0 1 | Rooted Address [Note: additional codepoints are reserved in the GCID Type field space for subsequent support of non-rooted, group-based GCIDs and other types of GCIDs.] Type of Number (octet 14) Bits | 7 6 5 | Meaning -----------|------------------------------------------------ 0 0 0 | Unknown 0 0 1 | International number Address/Numbering Plan Identification (octet 14) Bits | 4 3 2 1 | Meaning -----------|------------------------------------------------ 0 0 0 1 | ISDN/telephony numbering plan (E.164) (Note 1) 0 0 1 0 | ISO NSAP (Note 2) Note 1 - If the E.164 numbering plan is used, "Type of Number" shall be coded as "International Number" Note 2 - If the OSI NSAP addressing format is used, "Type of Number" shall be coded as "Unknown" Address (octet 14, etc.) If the coding "international number/ISDN/telephony numbering plan (Recommendation E.164)" is used, the address is coded as IA5 characters according to the format specified in the numbering plan. If the coding "unknown/ISO NSAP" is used, the address is coded as described in ISO 8348, Addendum 2, using the preferred binary encoding. 4.4.2 (NEW) LEAF INITIATED JOIN PARAMETERS The Leaf Initiated Join Parameters (LIJP) IE is used by the root to associate options with the call when the call is created. 8 7 6 5 4 3 2 1 Octets |-----------------------------------| | Leaf Initiated Join Parameters | | X X X X X X X X | 1 | Information element identifier | |-----------------------------------| | 1 | Coding| IE Inst. field | 2 |ext | Stndrd| | |-----------------------------------| | Length of LIJP contents | 3 |-----------------------------------| | Length of LIJP contents (cont) | 4 |-----------------------------------| | 1 | 0 0 0 | Security | 5 |ext | Spare | Indication | |-----------------------------------| | 1 | 0 0 0 | Notification | 6 |ext | Spare | Indication | |-----------------------------------| | 1 | 0 0 0 | Drop | 7 |ext | Spare | Restriction | |-----------------------------------| | 1 | 0 0 0 | Add | 8 |ext | Spare | Restriction | |-----------------------------------| | 1 | 0 0 0 | EP Ref | 9 |ext | Spare | Type | |-----------------------------------| Coding Standard (octet 2) Bits | 7 6 | Meaning -----------|------------------------------------------------ 0 0 | ITU-TS (CCITT) standardized IE Instruction Field (octet 2) Bits | 5 4 3 2 1 | Meaning -----------|------------------------------------------------ 0 0 0 0 0 | IE Instruction field not significant Security Indication (octet 5) Bits | 4 3 2 1 | Meaning ---------|------------------------------------------------ 0 0 0 0 | Open Call [Note: additional codepoints are reserved in the Security Indication field to allow future expansion to include new security modes, such as a Root provided access list or Root verification of leaf joins.] Notification Indication (octet 6) Bits | 4 3 2 1 | Meaning ---------|------------------------------------------------ 0 0 0 0 | No Notification [Note: additional codepoints are reserved in the Notification Indication field to allow future expansion to include new notification modes, such as Root notification of leaf joins, Root notification of leaf drops, leaf notification of leaf joins and leaf notification of leaf drops.] Drop Restriction (octet 7) Bits | 4 3 2 1 | Meaning ---------|------------------------------------------------ 0 0 0 0 | Leaf Drops only [Note: additional codepoints are reserved in the Join Drop Restriction field to allow future expansion to include new drop modes, such as both Root and leaf drops of leaves and (maybe) Root only drops of leaves.] Add Restriction (octet 8) Bits | 4 3 2 1 | Meaning ---------|------------------------------------------------ 0 0 0 1 | Leaf Adds only [Note: additional codepoints are reserved in the Join Add Restriction field to allow future expansion to include new add modes, such as both Root and leaf adds of leaves.] Endpoint Reference Type (octet 9) Bits | 4 3 2 1 | Meaning ---------|------------------------------------------------ 0 0 0 0 | No EP Ref [Note: additional codepoints are reserved in the Endpoint Reference Type field to allow future expansion to include new endpoint reference types, such as phase 1 endpoint references and (perhaps) a new leaf address-based endpoint reference.] 4.5 Messages 4.5.1 SETUP The SETUP message needs to be modified as indicated in this section to support leaf initiated join calls. This message is sent by the calling user to the network to initiate | call establishment. It may also be used by a calling user (i.e., a | leaf) to join an already existing call. Message Type: SETUP Significance: global Direction: both [Note: new notes to the SETUP table below are lettered instead of numbered.] |------------------|-----------|-----------|-------|--------| | IE | Reference | Direction | Type | Length | |------------------|-----------|-----------|-------|--------| | Proto discr | 5.4.2 | both | M | 1 | |------------------|-----------|-----------|-------|--------| | Call Ref | 5.4.3 | both | M | 4 | |------------------|-----------|-----------|-------|--------| | Message type | 5.4.4.1 | both | M | 2 | |------------------|-----------|-----------|-------|--------| | Message length | 5.4.4.2 | both | M | 2 | |------------------|-----------|-----------|-------|--------| | AAL Params | 5.4.4.5 | both | O(1) | 4-20 | |------------------|-----------|-----------|-------|--------| | ATM UCR | 5.4.4.6 | both | M | 12-30 | |------------------|-----------|-----------|-------|--------| | BBC | 5.4.4.7 | both | M | 6-7 | |------------------|-----------|-----------|-------|--------| | B-HLI | 5.4.4.8 | both | O(2) | 4-13 | |------------------|-----------|-----------|-------|--------| | BRI | 5.4.4.19 | both | O(3) | 4-5 | |------------------|-----------|-----------|-------|--------| | B-LLI | 5.4.4.9 | both | O(4) | 4-17 | |------------------|-----------|-----------|-------|--------| | | Called Party No. | 5.4.4.11 | both | M(A) | (5) | |------------------|-----------|-----------|-------|--------| | Called PS | 5.4.4.12 | both | O(6) | 4-25 | |------------------|-----------|-----------|-------|--------| | Calling Party No.| 5.4.4.13 | both | O(7) | 4-26 | |------------------|-----------|-----------|-------|--------| | Calling PS | 5.4.4.14 | both | O(8) | 4-25 | |------------------|-----------|-----------|-------|--------| | Conn ID | 5.4.4.16 | N->U | M | 9 | |------------------|-----------|-----------|-------|--------| | QoS Params | 5.4.4.18 | both | M | 6 | |------------------|-----------|-----------|-------|--------| | BSC | 5.4.4.21 | both | O(9) | 4-5 | |------------------|-----------|-----------|-------|--------| | Transit Net | 5.4.4.22 | U->N | O(10) | 4-8 | |------------------|-----------|-----------|-------|--------| | EP Ref | 5.4.8.1 | both | O(11) | 4-7 | |------------------|-----------|-----------|-------|--------| | | GCID | 5.4.8.3 | U->N | O(B) | (C) | | |------------------|-----------|-----------|-------|--------| | | LIJ Params | 5.4.8.4 | U->N | O(D) | 9 | | |------------------|-----------|-----------|-------|--------| Note 1 - Included in the user-to-network direction when the calling user wants to pass ATM adaptation layer parameters information to the called user. Included in the network- to-user direction if the calling user included an ATM adaptation layer parameters information element in the SETUP message. Note 2 - Included in the user-to-network direction when the calling user wants to pass broadband high layer information to the called user. Included in the network-to-user direction if the calling user included a Broadband high layer information element in the SETUP message. Note 3 - Included when two or more Broadband low layer information elements are included for Broadband low layer information negotiation. Note 4 - Included in the user-to-network direction when the calling user wants to pass Broadband low layer information to the called user. Included in the network-to-user direction if the calling user included a Broadband low layer information in the SETUP message. Two or three information elements may be included in descending order of priority, i.e., highest priority first, if the Broadband low layer information negotiation procedures are used (see Annex C). Note 5 - Minimum length depends on the numbering plan. Maximum length is 25 octets. Note 6 - Included in the user-to-network direction when the calling user wants to indicate the called party subaddress. Included in the network-to-user direction if the calling user included a Called party subaddress information element in the SETUP message. Note 7 - May be included by the calling user or by the network to identify the calling user. Note 8 - Included in the user-to-network direction when the calling user wants to indicate the calling party subaddress. Included in the network-to-user direction if the calling user included a Calling party subaddress information element in the SETUP message. Note 9 - It is optional for the user to include the Broadband sending complete information element when enbloc sending procedures (i.e., compete address information is included) are used; its interpretation by the network is optional. It is optional for the network to include the Broadband sending complete information element when enbloc receiving procedures (i.e., compete address information is included) are used. Note 10 -Included by the calling user to select a particular transit network (see Annex D.) Note 11 -Not used to point-to-point connection establishment. Must be included in SETUP messages involved in point-to-multipoint connection establishment. | Note A - Mandatory for a non-leaf initiated join call. Must NOT be | present in leaf initiated join calls (where the presence | of the Global call identifier information element indicates | that the call is a leaf initiated join call). | | Note B - Mandatory for leaf initiated join calls. Must NOT be present | in non-leaf initiated join calls. | | Note C - Minimum length depends on the numbering plan. Maximum length | is 34 octets. | | Note D - Mandatory in a SETUP message used by the Root to create a leaf | initiated join call. Must NOT be present in any other SETUP | message (including that used by a leaf to join an already | existing leaf initiated join call). 4.6 Cause Codes Three new cause codes must be defined for leaf initiated joins (the use of which was identified in Section 4.3) and added to Annex E. These are: cause #XX: "leaf call parameters do not match root call parameters in leaf initiated join call." cause #XX: "global call ID not found." cause #XX: "illegal IE combination for leaf initiated join call". 4.7 Discussion Modifications for adding leaf initiated join support to the phase 1 UNI signalling protocol have been presented in this section. These modifications are reasonably straightforward, but by no means trivial. Two new IEs are required (GCID and LIJP), new procedures are required and some of the existing messages must be modified to include the new IEs (and to restrict the use of some existing IEs). Two issues have been heretofore ignored up until this point: 1) the internal mechanisms used to support leaf initiated join calls and 2) the complexities that arise when the restrictions mentioned in Section 4.2 are lifted. Issue (1) has not been covered earlier since it is not a UNI signalling protocol issue. However, the basics of the internal support mechanisms will be covered now to provide an "existence proof" that such mechanisms can be implemented and that these mechanisms are reasonably straightforward. Issue (2) will also be addressed now so that the implications of lifting some or all of these restrictions in the future can be understood. 4.7.1 Internal Implementation Considerations When the Root creates a leaf initiated join call, the network associates the GCID with the call and caches this relationship. Since the call is only active at the Root's access node, this is the only place where the association is maintained. When a leaf wishes to join the call, a SETUP message containing the GCID is submitted to the network. The leaf's access node checks to see if it knows about the GCID (i.e., it checks to see if the Root or any other leaves at this node are currently participating in the call). If so, the leaf is added. If not, the leaf's SETUP message is propagated towards the Root using the Root's address for routing, as extracted from the GCID. At each internal network node along the path from the leaf to the Root, the network checks to see if the GCID is known. Once a node supporting the GCID is found, the leaf is added into the call at this point and the CONNECT message is sent back towards the leaf. This implementation scheme requires that each network node supporting a leaf initiated join call maintain a mapping from GCID to call parameters for that call. However, no mapping is required for non-leaf initiated join calls. There is one condition where SETUP messages from multiple leaves can interact. Namely, when two leaves issue SETUPs at roughly the same time, the first SETUP message may begin traversing down an internal path to the Root in search of the call, while the second SETUP message bumps into a node where the first SETUP is still pending. In this case, the node where the SETUP messages intersect should buffer the second SETUP message until a CONNECT or RELEASE COMPLETE message is returned for the first SETUP message (note: this buffering of messages is analogous to the buffering of ADD PARTY messages that occurs in the point-to-multipoint procedures when a SETUP is pending down a link that the ADD PARTY needs to follow). If a CONNECT is returned, the node should then add the second leaf into the call as if the SETUP had arrived after the call had been established at this node. If a RELEASE COMPLETE is returned for the first SETUP message, the node should propagate the second SETUP message towards the Root. (The second SETUP message is not rejected locally at the intersecting node primarily to facilitate lifting of the restrictions in the future. For example, with an enhanced security mode, the first leaf might be barred from joining the call while the second leaf is allowed to join. By always forwarding the SETUPs towards the Root, an active node participating in the call can cache security information and make the right decision.) 4.7.2 Lifting the Restrictions Five restrictions were placed on leaf initiated joins, as discussed in Section 4.2. The complexity of lifting these restrictions is discussed now. Since lifting each of these restrictions leads to complexities, they should only be lifted if there is a strong demand to do so. This contribution DOES NOT propose to lift any of these restrictions for the phase 2 protocol. 4.7.2.1 Root add of leaves Allowing the Root to add leaves creates complications for the internal mechanisms that implement leaf initiated join calls. Namely, nodes must contend with intersecting SETUP requests, where one SETUP request is being routed towards the root and another is destined for a new leaf being added (by the Root) to the call. This problem is actually more complicated that meets the eye. Simply blocking one of the SETUPs until the other completes does not always solve the problem (since the two might pass one another on the wire and bump into each other at different nodes, resulting in deadlock). There are solutions to this problem, but they are involved and should only be investigated if there is a strong demand for this option. 4.7.2.2 Root drop of leaves Allowing the Root to drop leaves can be done fairly easily, but it first requires that endpoint references be associated with each leaf so that the Root has a handle to use when dropping a leaf (see Section 4.7.2.5 below for a description of how endpoint references can be added). Once the Root has an endpoint reference handle, it can easily drop endpoints. Internally, there are two implementation strategies for dropping the leaf. The first is analogous to the drop procedure in point-to-multipoint calls, where a DROP PARTY is sent by the root, which propagates through the network along the call tree until the last branching node is reached, then is converted into a RELEASE message on the final path the the leaf. This approach leads to race conditions if a new leaf has just joined in on the path to the leaf being dropped. The second implementation strategy is to send an internal datagram to the leaf to be dropped's access node, then clear the leaf back towards the call tree as when the leaf dropped out directly. This approach avoids the race conditions, but requires a new "datagram" to inform the leaf's access node that the leaf is to be dropped. 4.7.2.3 Enhanced security modes The current proposal only offers an OPEN security mode for leaf initiated join calls. The complexity of adding additional security modes depends on the modes to be added. One mode that would be fairly easy to implement is where the Root supplies a list of leaves that can freely join the call when creating the call. The network then caches this information with the GCID and propagates it to any nodes that support the call. When a new leaf wishes to join, the join is allowed if the leaf is on the list, otherwise the join fails. Another security mode that is not as easy to implement is a "Root query," where the Root is asked for each leaf attempting to join whether the leaf should be allowed to join. This requires new messages, procedures and information elements to carry the query from the point where the leaf bumps into the call tree to the Root, then to carry the Root's response back. Additionally, it adds delay to the leaf join operation and makes the Root a bottleneck in that is must approve or deny all join requests. 4.7.2.4 Root notification of adds and drops The current proposal does not notify the root when new leaves join and drop out of the call. The complexity of adding notifications is not too difficult. For notification of joins, a new message type could be defined, which holds the leaf's address (i.e., the calling party number), and is sent to the Root every time a new leaf joins the call. For notification of drops, the leaf's address is not readily available. Therefore, drop notification is more easily accomplished if endpoint references have been assigned to each endpoint (as discussed in Section 4.7.2.5), in which case the endpoint reference of the dropping leaf can be sent to the root in a notification message (perhaps in a DROP PARTY ACK message). 4.7.2.5 Use of endpoint references Assignment of endpoint references to the leaves that join the call can be done without too much difficulty, but this requires new messages, procedures and (maybe) information elements. The basic idea is for the branching node to assign an endpoint reference to the new leaf, then propagate this value back to the Root in a new ENDPOINT REFERENCE REPORT message. Each node on the path back to the Root may need to remap the endpoint reference value, if the chosen value is already in use at that node. The ENDPOINT REFERENCE REPORT message could also be augmented to contain the new leaf's address so that the root gets a notification of the identify of the new participant. The root could then use the endpoint reference to drop the endpoint from the call (Section 4.7.2.2) and the network could use the endpoint reference to notify the Root when the leaf drops itself from the call (Section 4.7.2.4). Note that support for endpoint references in leaf initiated join calls might require use of party-states. 5 Summary This contribution has proposed changes necessary to support the accepted Phase 2 capabilities of virtual path connection establishment, multipoint-to-multipoint connections and leaf initiated joins. It is further proposed that the indicated text of this contribution be incorporated into the baseline phase 2 signalling specification as strawman text for solutions to these problems. It is recognized that subsequent clarifications, modifications and fine-tuning may be required to complete the solutions for these capabilities.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11281; 8 Aug 94 17:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11277; 8 Aug 94 17:20 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00830; 8 Aug 94 17:20 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA269493709; Mon, 8 Aug 1994 12:21:49 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA269163704; Mon, 8 Aug 1994 12:21:44 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA20629; Mon, 8 Aug 94 15:23:23 EDT Received: from pothole.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA05233; Mon, 8 Aug 94 15:21:21 EDT Received: by pothole.fore.com (4.1/SMI-4.1) id AA00999; Mon, 8 Aug 94 15:21:04 EDT Date: Mon, 8 Aug 94 15:21:04 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fong-Ching Liaw Message-Id: <9408081921.AA00999@pothole.fore.com> To: fong@fore.com, susan@backup.mitre.org Subject: Re: multicast Cc: ip-atm@matmos.hpl.hp.com, ddp@fore.com > Fong, > > You seem to agree that both your contribution on group addressing > and the leaf-initiated join contribution will prove valuable in > the specification of an IPmc/ATMmc interface. Great. Yes. This is the only way ATM mc can scale the same as IPmc. > > Specifically, you advocate: > > 1) The IP-over-ATM WG should make a strong statement to the ATM Forum > that we require the functionality provided by the group addressing and > leaf-initiated join contributions. Is the new multiprotocol BOF the place > that we should make these statements, or would a statement to the > signalling group via our liaison be more appropriate/effective? Any > thoughts on this? > The statement can go to both signaling WG and multiprotocol BOF. On top of that, I think this group could provide valuable input to the requirement list for both atm group and leaf-initiate join to make sure it is usable by IPmc. We (FORE) are trying very hard to make sure this is the case, but it is always possible we left out important requirements. My contribution lists a few open issues, such as scope, group address assignment inside an ISO delegated authority. Jon's message on QOS is another aspect. Right now, all parameters must be the same for all leaves. RSVP, on the other hand, allows different bandwidth for each leaf. So, there is mismatch. Jonathan's point on IPmc routing and ATMmc routing is anther aspect which I scratched the surface later. > 2) It is also important that the ITU (international standards community) > get the message about the importance of group addressing and leaf- > initiated joins. Do you think that we should relay this message > directly to the ITU, or is it sufficient to send the message to the > Forum and have the ITU pick it up via there? Do we have an ITU liaison? I think ATMF does have ITU-T liaison. Right now, I am more concerned with getting these capability into private networks (it is "optional" for private network). Leaf-initiated join might be in better status (i.e. required I think. Rick, please correct me if you are on the net). It would be nice to have same capability from public network and private network, but I am not sure it is really important at this time. The assumption is that if public network providers think it is vital for them to provide the service, they will make effort to get it into ITU-T. But as users, we need to scream to them if we think it is vital service for us : > > I think my confusion stems from the way > that your group addressing concept strictly separates the multicast > group address from the actual mechanism used to distribute the data. > If you want to have an algorithm that automatically translates an IPmc > address into an ATM group address, fine, but there still has to be > some mechanism that takes this ATM group address and "translates" it > into whatever it needs to translate it into to get the data distributed > multicast-style. This second "translation" is dependent on the multicast > mechanism that is actually being used (multiple overlaid pt-to-mpt VCs, > multicast server, etc.). This second translation and the actual > mechanism(s?) used are where the gist of the problems lie, and I would > like for our WG to discuss these. Such a discussion would have to include, > as Jonathan Stone said in his message, a discussion of how ATMmc will > support IPmc *routing*. > > I would be happy to work on recommending such an IPmc/ATM group address > translation algorithm as you are advocating, as long as it is understood > that we are pushing the problem of getting appropriate multicast VCs set up > elsewhere. Am I understanding everything correctly? > > It is my understanding that Fore has implemented IPmc over ATMmc. Would > it be possible for you to explain to this group how Fore's implementation > works? I'm sure that we would all find whatever details you are free to > share to be most enlightening, and therefore most welcome. > I will be happy to share the basic idea of FORE's IPmc over ATMmc. When a host join an IP group IP-G, the ATM driver recieves an IP_MULTIADD ioctl, it then translates that to join ATM-G (translation between IP-G and ATM-G is algorithmic). One advantage (or limitation) FORE implementation is that the ATM-SPANs net is treated as an IP subnet so scoping is not interpreted (or used) at this point. When a router is to forward a multicast packet to its ATM interface, it sets up a connection to the group, and the connection is established to all members registered. If there are routers attached on the ATM net, it will receive the multicast packet and may forward it toward other networks behind it (but not back on to the ATM net). This approach relies on ATMmc to reach all registered IP members attached on the connected ATM network, and routers to forward IPmc packets to other type of local networks. The ATM network establishes connections to IPmembers because the addresses used. The problem gets more complicated when ATM has its own routing hierarchy and provide connectivity to multiple IP subnets. The mutlicast packet (or connection) should reach only those members within the scope of the multicast packet or connection (IPv4 uses TTL, and IPng might use something different, ATM needs to define a mechanism). As Jonathan pointed out, the solution (or problem) depends on ATM's role in IPmc's routing, and how ATM's routing hierarchy maps to IP's routing hierarchy. Assume we want to use ATMmc to reach members (on same subnet or not) directly attached to ATM net, and routers to forward IPmc packets to other nets. ATMmc would have to reach Regestered IP members (this can be done by the address mapping), within IP scoping rules (ignore QOS issue for now). This puts a requirement on ATM mc scoping : it has to be closely related to IPmc scoping. I think this is possible, assuming we usually want IPmc packets to reach a confined community, which can be : subnet (TTL=1), site (TTL=16), company (TTL=?), and global (TTL>127). (I steal these idea from SIPP MC addresses) Map these administrative hierarchy to ATM is easy since ATMnetwork is also hierarchically constructed. In this way, a router attached to ATM receives IPmc packets only if it is within the scope of the IPmc packet. The routers still exchange multicast/unicast routing to construct multicast forwarding tree (if necessary) when it does receive packets from its ATM interface. I assume only one router is responsible to forward IPmc packets from other net to ATM net. Oh, another point, the pt-mpt connection can be though of as similar to the MOSPF source tree which covers members directly attached to ATMnetwork, and are within the scope. This does not address the issue of using servers, many pt-mpt or one mpt-mpt connection. The SETUP message will carry the ATM group address as called party address, as well as one global call identifier to allow detecting multiple data streams from the same connection. Since IP packets carry full header, the need to co-relate VCCs with IPmc address are not important. However, the singaling message carry group information, members can do intelligent thing at call setup time. If we want to use mpt-mpt connections, we have to help ATM Forum define the traffic mechanism, and how are we going to solve the cell interleaving problem if we use AAL5. Rick's contribution on this hinted on using VPs, and allow apps to use VCI to multiplexing. I think the use of VPs at UNI passed one time and got reversed ? Rick ? -Fong   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11575; 8 Aug 94 17:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11571; 8 Aug 94 17:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01393; 8 Aug 94 17:45 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA295737071; Mon, 8 Aug 1994 13:17:51 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA295387069; Mon, 8 Aug 1994 13:17:49 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id QAA20230; Mon, 8 Aug 1994 16:14:33 -0400 Message-Id: <199408082014.QAA20230@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: susan@backup.mitre.org Cc: fong@fore.com, ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: multicast In-Reply-To: Your message of Mon, 08 Aug 94 11:01:24 -0400. <9408081501.AA03243@backup.mitre.org.mitre.org> Date: Mon, 08 Aug 94 16:14:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [..] >>but there still has to be >>some mechanism that takes this ATM group address and "translates" it >>into whatever it needs to translate it into to get the data distributed >>multicast-style. This second "translation" is dependent on the multicast >>mechanism that is actually being used (multiple overlaid pt-to-mpt VCs, >>multicast server, etc.). This second translation and the actual >>mechanism(s?) used are where the gist of the problems lie, and I would >>like for our WG to discuss these. Susan, I'm not sure I understand what WG you refer to, here. If it is the IETF one then I don't understand why we need to concern ourselves with the ATM subsystem's method of establishing multicast VCs. Surely it is cleaner for us to simply 'black box' much of the ATM specific mechanisms. This approach will encourage IPmc development to be specified in terms of 'generic' link layer services. We define the service required from ATM multicast (group addresses, etc), figure out ways of including ATM-connected nodes into IPmc groups, etc. Leave the internals of ATM to ATM Forum to hammer out, prodded on your 'requirements'. If you meant an ATM Forum WG, then my humble apologies and I'll crawl back into my inbox :-) regards, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11689; 8 Aug 94 17:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11685; 8 Aug 94 17:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01630; 8 Aug 94 17:53 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA288266683; Mon, 8 Aug 1994 13:11:23 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA287936679; Mon, 8 Aug 1994 13:11:19 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA20796; Mon, 8 Aug 94 16:13:11 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA09615; Mon, 8 Aug 94 16:11:10 EDT Received: by marlin (4.1/SMI-4.1) id AA12056; Mon, 8 Aug 94 16:11:08 EDT Date: Mon, 8 Aug 94 16:11:08 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408082011.AA12056@marlin> To: fong@fore.com, susan@backup.mitre.org Subject: Re: multicast Cc: ip-atm@matmos.hpl.hp.com > > 2) It is also important that the ITU (international standards community) > > get the message about the importance of group addressing and leaf- > > initiated joins. Do you think that we should relay this message > > directly to the ITU, or is it sufficient to send the message to the > > Forum and have the ITU pick it up via there? Do we have an ITU liaison? > > I think ATMF does have ITU-T liaison. Right now, I am more concerned with > getting these capability into private networks (it is "optional" > for private network). Leaf-initiated join might be in better status (i.e. > required I think. Rick, please correct me if you are on the net). > It would be nice to have same capability from public network > and private network, but I am not sure it is really important at > this time. The assumption is that if public network providers think it > is vital for them to provide the service, they will make effort to > get it into ITU-T. But as users, we need to scream to them if we > think it is vital service for us : The ATMF does have an ITU-T liason. The two specs are being kept somewhat in synch (through great pain sometimes, eg. the SSCOP debacle). > If we want to use mpt-mpt connections, we have to help ATM Forum > define the traffic mechanism, and how are we going to solve > the cell interleaving problem if we use AAL5. > Rick's contribution on this hinted on using VPs, and allow apps to use > VCI to multiplexing. I think the use of VPs at UNI passed one time > and got reversed ? Rick ? The use of VPs at the UNI will not be in ATMF UNI 4.0. There are many who believe that support of VPs at the UNI will not scale due to the limited # of VPs at the NNI (2^12 = 4096). Also, use of VCIs for multiplexing at the UNI does not scale due to the limited # (2^16 = 64K) AND limited hardware resources of adapter cards (many adapters are stressed out supporting 1024 simultaneous reassembly states: some have only 128). The best solution I've heard is Brian Lyle, et al's paper on distributed resynchronizing servers. I don't see that issue floating to the top of the priority queue for a couple of years unless someone here wanted to work on specifying it. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12018; 8 Aug 94 18:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12014; 8 Aug 94 18:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02067; 8 Aug 94 18:18 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA018278489; Mon, 8 Aug 1994 13:41:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA017948485; Mon, 8 Aug 1994 13:41:25 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id QAA23524; Mon, 8 Aug 1994 16:40:57 -0400 Message-Id: <199408082040.QAA23524@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Susan Symington Cc: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: multicasting In-Reply-To: Your message of Fri, 05 Aug 94 15:28:22 -0400. <9408051928.AA11017@gateway.mitre.org> Date: Mon, 08 Aug 94 16:40:54 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [..] >>3) Multipoint-to-multipoint versus point-to-multipoint data distribution [..] >>If we take the tack of using overlaid point-to-multipont VCs, then we will be >>accepting the limitations of this mechanism (e.g., how well does it scale for >>large groups?) for the time being, but it does not preclude us from defining >>an interface to other mechanisms as they may become available in the future. Another criteria when considering link layer services required by IPmc is to ask "what impact will the various choices have on the likelyhood of successful and timely implementation?". In the same way that RFC1483 and RFC1577 attempt to provide a conceptually 'easy' first phase migration to ATM, we might consider a bare-bones IPmc-over-ATMmc using UNI3.0 or 3.1 as they currently stand. When will vendors actually have 'real' ATMmc, and which standard will it conform to? gja (contemplating out loud, a dangerous habit to have :) --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12581; 8 Aug 94 19:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12577; 8 Aug 94 19:08 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03064; 8 Aug 94 19:08 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA027948972; Mon, 8 Aug 1994 13:49:32 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gateway.mitre.org by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA027608965; Mon, 8 Aug 1994 13:49:25 -0700 Received: from backup.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA26065; Mon, 8 Aug 94 16:49:23 -0400 Received: by backup.mitre.org.mitre.org (4.1/SMI-4.1) id AA03784; Mon, 8 Aug 94 16:48:34 EDT Message-Id: <9408082048.AA03784@backup.mitre.org.mitre.org> To: gja@thumper.bellcore.com Cc: ip-atm@matmos.hpl.hp.com Subject: Re: multicast In-Reply-To: Your message of "Mon, 08 Aug 94 16:14:31 EDT." <199408082014.QAA20230@thumper.bellcore.com> Date: Mon, 08 Aug 94 16:48:32 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: susan@backup.mitre.org gja, Yes, I agree that we want to have a "black box" and the IETF should not be concerned with ATM internals. You have a good point; no need to crawl back into your inbox. I'll admit to not having expressed myself well in the text that you quote. What I meant is that I am uncomfortable with an approach that says that we will simply use an algorithm to translate IPmc addresses into ATMmc addresses and let the ATM Forum take care of the rest. If we want to simply use an algorithm to translate IPmc addresses into ATMmc addresses, fine; as long as we don't stop there and leave the routing issues undiscussed (how the IPmc routing will make good decisions when traversing ATM clouds as per Jonathan Stone's email). When you have a black box, you must have very clearly defined inputs and outputs. What information is ATM going to provide to IPmc so that it can make good routing decisions, and what information is IPmc going to provide to ATMmc so that a given IPmc/ATMmc address translates into an efficient route, e.g. and efficient multicast dataflow? susan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13291; 8 Aug 94 19:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13287; 8 Aug 94 19:31 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03567; 8 Aug 94 19:31 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA046850039; Mon, 8 Aug 1994 14:07:19 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA046520035; Mon, 8 Aug 1994 14:07:15 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA20906; Mon, 8 Aug 1994 16:07:14 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1) id AA15836; Mon, 8 Aug 1994 16:07:11 -0500 Received: from dbg.dev.cdx.mot.com (dbg.dev.cdx.mot.com [134.33.32.39]) by merlin.dev.cdx.mot.com (8.6.9/8.6.9) with ESMTP id RAA12261; Mon, 8 Aug 1994 17:07:09 -0400 Received: from localhost (localhost [127.0.0.1]) by dbg.dev.cdx.mot.com (8.6.9/8.6.5) with SMTP id RAA25104; Mon, 8 Aug 1994 17:07:08 -0400 Message-Id: <199408082107.RAA25104@dbg.dev.cdx.mot.com> X-Authentication-Warning: dbg.dev.cdx.mot.com: Host localhost didn't use HELO protocol To: Mark Laubach Cc: dan@merlin.dev.cdx.mot.com, ip-atm@matmos.hpl.hp.com Subject: Re: no comments on my comments? In-Reply-To: Your message of "Sat, 06 Aug 94 09:57:22 PDT." <199408061657.AA010632242@matmos.hpl.hp.com> Date: Mon, 08 Aug 94 17:07:06 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp > There was a similar discussion at the ATM Internet NAP meeting at Toronto. > I was > asked to introduce IP over ATM to the crowd and to be on hand as a > consultant. I > basically took a back seat as a fly on the wall. The basic consensus was > that the > NAPs want to use LLC/SNAP and will get there as soon as possible. This means > that the two DSU vendors need to add LLC/SNAP into their products so that > directly > connected hosts and routers can talk to to routers that are connected via a > DSU. > The DSUs only support RFC1490 encapsulation. ATM native interfaces in the > routers are supporting LLC/SNAP only. Yes, the FR vs LLC is a problem, but > the crowd settled on getting to LLC as soon as possible and to not have a > mixed world. This is just a data point. The draft is about _SVCs_, hosts and routers. This has nothing to do with DSUs in a PVC-only environment. I hope all your arguments in this case are not based on this misunderstanding?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13624; 8 Aug 94 19:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13620; 8 Aug 94 19:55 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04044; 8 Aug 94 19:55 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA084124009; Mon, 8 Aug 1994 15:13:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA083754002; Mon, 8 Aug 1994 15:13:22 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.2-14 #2740) id <01HFOCC9AFB48Y5WAS@sys30.timeplex.com>; Mon, 8 Aug 1994 18:11:32 EDT Received: from buddry.timeplex.com by louie.timeplex.com (4.1/SMI-4.1) id AA00402; Mon, 8 Aug 94 17:11:29 CDT Date: Mon, 08 Aug 1994 17:11:29 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Bubenik Subject: Re: multicast To: ip-atm@matmos.hpl.hp.com, fong@fore.com Message-Id: <9408082211.AA00402@louie.timeplex.com> Content-Transfer-Encoding: 7BIT >> 2) It is also important that the ITU (international standards community) >> get the message about the importance of group addressing and leaf- >> initiated joins. Do you think that we should relay this message >> directly to the ITU, or is it sufficient to send the message to the >> Forum and have the ITU pick it up via there? Do we have an ITU liaison? > > I think ATMF does have ITU-T liaison. Right now, I am more concerned with > getting these capability into private networks (it is "optional" > for private network). Leaf-initiated join might be in better status (i.e. > required I think. Rick, please correct me if you are on the net). You are correct -- it is listed as a (non-optional) requirement for UNI 4.0. > If we want to use mpt-mpt connections, we have to help ATM Forum > define the traffic mechanism, and how are we going to solve > the cell interleaving problem if we use AAL5. > Rick's contribution on this hinted on using VPs, and allow apps to use > VCI to multiplexing. I think the use of VPs at UNI passed one time > and got reversed ? Rick ? This is correct. Switched VPs at the UNI were accepted in the January requirements vote, then dropped from the list at the May meeting. Since May, I've heard some complaints about this limitation, so there may be some impetus to reconsider this decision in the future. rick ++++++ Rick Bubenik Ascom Timeplex, Inc. 1807 Park 270 Drive St. Louis, Mo. 63146 (314) 579-6512 [office] (314) 542-0495 [fax] rick@louie.timeplex.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14161; 8 Aug 94 20:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14157; 8 Aug 94 20:52 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05026; 8 Aug 94 20:52 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA080773819; Mon, 8 Aug 1994 15:10:19 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA080443816; Mon, 8 Aug 1994 15:10:16 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id SAA01430; Mon, 8 Aug 1994 18:10:00 -0400 Message-Id: <199408082210.SAA01430@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: susan@backup.mitre.org Cc: gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: multicast In-Reply-To: Your message of Mon, 08 Aug 94 16:48:32 -0400. <9408082048.AA03784@backup.mitre.org.mitre.org> Date: Mon, 08 Aug 94 18:09:59 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com Susan, I think I share your concern over algorithmic mapping of IPmc to ATMmc addresses. (I'm not even sure I understand why it has been suggested - perhaps someone can clarify, for me if no one else, why ATMARP mechanisms cannot perform this mapping?) However, I'm not sure I understand the problem that you are seeking an answer for here: [..] >>What information is ATM going to provide >>to IPmc so that it can make good routing decisions, I see ATM cloud(s) with IP nodes (routers, and possibly end nodes) at their edges. An IPmc 'group' is established through some means external to the ATM network's concerns. Some members are ATM connected, others reachable through ATM connected routers. Presumably it is the IPmc layer's responsibility to 'know' what IP nodes are directly attached? Simplistically, the IP level routing decision then treats each ATM cloud it comes across as a single hop to many members of the multicast group (or to routers on paths to members beyond the cloud). That's doesn't appear to be something that 'ATM' can provide information about. >> and what >>information is IPmc going to provide to ATMmc so that a given >>IPmc/ATMmc address translates into an efficient route, e.g. >>and efficient multicast dataflow? The IPmc layer defines membership of the ATMmc group address, based on its knowledge of each IP endpoint it needs to reach across or through a given ATM cloud. Beyond this point (and I'm pushing the 'black box' principal hard here) surely the ATM cloud is the only one concerned about optimal internal routing architectures? How can the IPmc layer affect it? regards, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00342; 9 Aug 94 3:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00326; 9 Aug 94 3:41 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa00539; 9 Aug 94 3:40 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA064302223; Mon, 8 Aug 1994 14:43:43 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA063672140; Mon, 8 Aug 1994 14:42:20 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.2-14 #2740) id <01HFOB8BBTSW8Y5S24@sys30.timeplex.com>; Mon, 8 Aug 1994 17:40:21 EDT Received: from buddry.timeplex.com by louie.timeplex.com (4.1/SMI-4.1) id AA00346; Mon, 8 Aug 94 16:39:54 CDT Date: Mon, 08 Aug 1994 16:39:54 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Rick Bubenik Subject: Re: multicasting To: ip-atm@matmos.hpl.hp.com Message-Id: <9408082139.AA00346@louie.timeplex.com> Content-Transfer-Encoding: 7BIT Here's the PostScript version of ATM Forum 94-0325R1 contribution (on Leaf Initiated Joins), as referenced in a previous e-mail. rick ++++++ %!PS-Adobe-3.0 %%BoundingBox: (atend) %%Pages: (atend) %%PageOrder: (atend) %%DocumentFonts: (atend) %%Creator: Frame 4.0 %%DocumentData: Clean7Bit %%EndComments %%BeginProlog % % Frame ps_prolog 4.0, for use with Frame 4.0 products % This ps_prolog file is Copyright (c) 1986-1993 Frame Technology % Corporation. All rights reserved. This ps_prolog file may be % freely copied and distributed in conjunction with documents created % using FrameMaker, FrameBuilder and FrameViewer as long as this % copyright notice is preserved. % % Frame products normally print colors as their true color on a color printer % or as shades of gray, based on luminance, on a black-and white printer. The % following flag, if set to True, forces all non-white colors to print as pure % black. This has no effect on bitmap images. /FMPrintAllColorsAsBlack false def % % Frame products can either set their own line screens or use a printer's % default settings. Three flags below control this separately for no % separations, spot separations and process separations. If a flag % is true, then the default printer settings will not be changed. If it is % false, Frame products will use their own settings from a table based on % the printer's resolution. /FMUseDefaultNoSeparationScreen true def /FMUseDefaultSpotSeparationScreen true def /FMUseDefaultProcessSeparationScreen false def % % For any given PostScript printer resolution, Frame products have two sets of % screen angles and frequencies for printing process separations, which are % recomended by Adobe. The following variable chooses the higher frequencies % when set to true or the lower frequencies when set to false. This is only % effective if the appropriate FMUseDefault...SeparationScreen flag is false. /FMUseHighFrequencyScreens true def % % PostScript Level 2 printers contain an "Accurate Screens" feature which can % improve process separation rendering at the expense of compute time. This % flag is ignored by PostScript Level 1 printers. /FMUseAcccurateScreens true def % % The following PostScript procedure defines the spot function that Frame % products will use for process separations. You may un-comment-out one of % the alternative functions below, or use your own. % % Dot function /FMSpotFunction {abs exch abs 2 copy add 1 gt {1 sub dup mul exch 1 sub dup mul add 1 sub } {dup mul exch dup mul add 1 exch sub }ifelse } def % % Line function % /FMSpotFunction { pop } def % % Elipse function % /FMSpotFunction { dup 5 mul 8 div mul exch dup mul exch add % sqrt 1 exch sub } def % % /FMversion (4.0) def /FMLevel1 /languagelevel where {pop languagelevel} {1} ifelse 2 lt def /FMPColor FMLevel1 { false /colorimage where {pop pop true} if } { true } ifelse def /FrameDict 400 dict def systemdict /errordict known not {/errordict 10 dict def errordict /rangecheck {stop} put} if % The readline in PS 23.0 doesn't recognize cr's as nl's on AppleTalk FrameDict /tmprangecheck errordict /rangecheck get put errordict /rangecheck {FrameDict /bug true put} put FrameDict /bug false put mark % Some PS machines read past the CR, so keep the following 3 lines together! currentfile 5 string readline 00 0000000000 cleartomark errordict /rangecheck FrameDict /tmprangecheck get put FrameDict /bug get { /readline { /gstring exch def /gfile exch def /gindex 0 def { gfile read pop dup 10 eq {exit} if dup 13 eq {exit} if gstring exch gindex exch put /gindex gindex 1 add def } loop pop gstring 0 gindex getinterval true } bind def } if /FMshowpage /showpage load def /FMquit /quit load def /FMFAILURE { dup = flush FMshowpage /Helvetica findfont 12 scalefont setfont 72 200 moveto show FMshowpage FMquit } def /FMVERSION { FMversion ne { (Frame product version does not match ps_prolog!) FMFAILURE } if } def /FMBADEPSF { (PostScript Lang. Ref. Man., 2nd Ed., H.2.4 says EPS must not call X ) dup dup (X) search pop exch pop exch pop length 4 -1 roll putinterval FMFAILURE } def /FMLOCAL { FrameDict begin 0 def end } def /concatprocs { /proc2 exch cvlit def/proc1 exch cvlit def/newproc proc1 length proc2 length add array def newproc 0 proc1 putinterval newproc proc1 length proc2 putinterval newproc cvx }def FrameDict begin /FMnone 0 def /FMcyan 1 def /FMmagenta 2 def /FMyellow 3 def /FMblack 4 def /FMcustom 5 def /FrameNegative false def /FrameSepIs FMnone def /FrameSepBlack 0 def /FrameSepYellow 0 def /FrameSepMagenta 0 def /FrameSepCyan 0 def /FrameSepRed 1 def /FrameSepGreen 1 def /FrameSepBlue 1 def /FrameCurGray 1 def /FrameCurPat null def /FrameCurColors [ 0 0 0 1 0 0 0 ] def /FrameColorEpsilon .001 def /eqepsilon { sub dup 0 lt {neg} if FrameColorEpsilon le } bind def /FrameCmpColorsCMYK { 2 copy 0 get exch 0 get eqepsilon { 2 copy 1 get exch 1 get eqepsilon { 2 copy 2 get exch 2 get eqepsilon { 3 get exch 3 get eqepsilon } {pop pop false} ifelse }{pop pop false} ifelse } {pop pop false} ifelse } bind def /FrameCmpColorsRGB { 2 copy 4 get exch 0 get eqepsilon { 2 copy 5 get exch 1 get eqepsilon { 6 get exch 2 get eqepsilon }{pop pop false} ifelse } {pop pop false} ifelse } bind def /RGBtoCMYK { 1 exch sub 3 1 roll 1 exch sub 3 1 roll 1 exch sub 3 1 roll 3 copy 2 copy le { pop } { exch pop } ifelse 2 copy le { pop } { exch pop } ifelse dup dup dup 6 1 roll 4 1 roll 7 1 roll sub 6 1 roll sub 5 1 roll sub 4 1 roll } bind def /CMYKtoRGB { dup dup 4 -1 roll add 5 1 roll 3 -1 roll add 4 1 roll add 1 exch sub dup 0 lt {pop 0} if 3 1 roll 1 exch sub dup 0 lt {pop 0} if exch 1 exch sub dup 0 lt {pop 0} if exch } bind def /FrameSepInit { 1.0 RealSetgray } bind def /FrameSetSepColor { /FrameSepBlue exch def /FrameSepGreen exch def /FrameSepRed exch def /FrameSepBlack exch def /FrameSepYellow exch def /FrameSepMagenta exch def /FrameSepCyan exch def /FrameSepIs FMcustom def setCurrentScreen } bind def /FrameSetCyan { /FrameSepBlue 1.0 def /FrameSepGreen 1.0 def /FrameSepRed 0.0 def /FrameSepBlack 0.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 1.0 def /FrameSepIs FMcyan def setCurrentScreen } bind def /FrameSetMagenta { /FrameSepBlue 1.0 def /FrameSepGreen 0.0 def /FrameSepRed 1.0 def /FrameSepBlack 0.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 1.0 def /FrameSepCyan 0.0 def /FrameSepIs FMmagenta def setCurrentScreen } bind def /FrameSetYellow { /FrameSepBlue 0.0 def /FrameSepGreen 1.0 def /FrameSepRed 1.0 def /FrameSepBlack 0.0 def /FrameSepYellow 1.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 0.0 def /FrameSepIs FMyellow def setCurrentScreen } bind def /FrameSetBlack { /FrameSepBlue 0.0 def /FrameSepGreen 0.0 def /FrameSepRed 0.0 def /FrameSepBlack 1.0 def /FrameSepYellow 0.0 def /FrameSepMagenta 0.0 def /FrameSepCyan 0.0 def /FrameSepIs FMblack def setCurrentScreen } bind def /FrameNoSep { /FrameSepIs FMnone def setCurrentScreen } bind def /FrameSetSepColors { FrameDict begin [ exch 1 add 1 roll ] /FrameSepColors exch def end } bind def /FrameColorInSepListCMYK { FrameSepColors { exch dup 3 -1 roll FrameCmpColorsCMYK { pop true exit } if } forall dup true ne {pop false} if } bind def /FrameColorInSepListRGB { FrameSepColors { exch dup 3 -1 roll FrameCmpColorsRGB { pop true exit } if } forall dup true ne {pop false} if } bind def /RealSetgray /setgray load def /RealSetrgbcolor /setrgbcolor load def /RealSethsbcolor /sethsbcolor load def end /setgray { FrameDict begin FrameSepIs FMnone eq { RealSetgray } { FrameSepIs FMblack eq { RealSetgray } { FrameSepIs FMcustom eq FrameSepRed 0 eq and FrameSepGreen 0 eq and FrameSepBlue 0 eq and { RealSetgray } { 1 RealSetgray pop } ifelse } ifelse } ifelse end } bind def /setrgbcolor { FrameDict begin FrameSepIs FMnone eq { RealSetrgbcolor } { 3 copy [ 4 1 roll ] FrameColorInSepListRGB { FrameSepBlue eq exch FrameSepGreen eq and exch FrameSepRed eq and { 0 } { 1 } ifelse } { FMPColor { RealSetrgbcolor currentcmykcolor } { RGBtoCMYK } ifelse FrameSepIs FMblack eq {1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse RealSetgray } ifelse end } bind def /sethsbcolor { FrameDict begin FrameSepIs FMnone eq { RealSethsbcolor } { RealSethsbcolor currentrgbcolor setrgbcolor } ifelse end } bind def FrameDict begin /setcmykcolor where { pop /RealSetcmykcolor /setcmykcolor load def } { /RealSetcmykcolor { 4 1 roll 3 { 3 index add 0 max 1 min 1 exch sub 3 1 roll} repeat setrgbcolor pop } bind def } ifelse userdict /setcmykcolor { FrameDict begin FrameSepIs FMnone eq { RealSetcmykcolor } { 4 copy [ 5 1 roll ] FrameColorInSepListCMYK { FrameSepBlack eq exch FrameSepYellow eq and exch FrameSepMagenta eq and exch FrameSepCyan eq and { 0 } { 1 } ifelse } { FrameSepIs FMblack eq {1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse RealSetgray } ifelse end } bind put FMLevel1 not { /patProcDict 5 dict dup begin <0f1e3c78f0e1c387> { 3 setlinewidth -1 -1 moveto 9 9 lineto stroke 4 -4 moveto 12 4 lineto stroke -4 4 moveto 4 12 lineto stroke} bind def <0f87c3e1f0783c1e> { 3 setlinewidth -1 9 moveto 9 -1 lineto stroke -4 4 moveto 4 -4 lineto stroke 4 12 moveto 12 4 lineto stroke} bind def <8142241818244281> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke -1 -1 moveto 9 9 lineto stroke } bind def <03060c183060c081> { 1 setlinewidth -1 -1 moveto 9 9 lineto stroke 4 -4 moveto 12 4 lineto stroke -4 4 moveto 4 12 lineto stroke} bind def <8040201008040201> { 1 setlinewidth -1 9 moveto 9 -1 lineto stroke -4 4 moveto 4 -4 lineto stroke 4 12 moveto 12 4 lineto stroke} bind def end def /patDict 15 dict dup begin /PatternType 1 def /PaintType 2 def /TilingType 3 def /BBox [ 0 0 8 8 ] def /XStep 8 def /YStep 8 def /PaintProc { begin patProcDict bstring known { patProcDict bstring get exec } { 8 8 true [1 0 0 -1 0 8] bstring imagemask } ifelse end } bind def end def } if /combineColor { FrameSepIs FMnone eq { graymode FMLevel1 or not { [/Pattern [/DeviceCMYK]] setcolorspace FrameCurColors 0 4 getinterval aload pop FrameCurPat setcolor } { FrameCurColors 3 get 1.0 ge { FrameCurGray RealSetgray } { FMPColor graymode and { 0 1 3 { FrameCurColors exch get 1 FrameCurGray sub mul } for RealSetcmykcolor } { 4 1 6 { FrameCurColors exch get graymode { 1 exch sub 1 FrameCurGray sub mul 1 exch sub } { 1.0 lt {FrameCurGray} {1} ifelse } ifelse } for RealSetrgbcolor } ifelse } ifelse } ifelse } { FrameCurColors 0 4 getinterval aload FrameColorInSepListCMYK { FrameSepBlack eq exch FrameSepYellow eq and exch FrameSepMagenta eq and exch FrameSepCyan eq and FrameSepIs FMcustom eq and { FrameCurGray } { 1 } ifelse } { FrameSepIs FMblack eq {FrameCurGray 1.0 exch sub mul 1.0 exch sub 4 1 roll pop pop pop} { FrameSepIs FMyellow eq {pop FrameCurGray 1.0 exch sub mul 1.0 exch sub 3 1 roll pop pop} { FrameSepIs FMmagenta eq {pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub exch pop } { FrameSepIs FMcyan eq {pop pop pop FrameCurGray 1.0 exch sub mul 1.0 exch sub } {pop pop pop pop 1} ifelse } ifelse } ifelse } ifelse } ifelse graymode FMLevel1 or not { [/Pattern [/DeviceGray]] setcolorspace FrameCurPat setcolor } { graymode not FMLevel1 and { dup 1 lt {pop FrameCurGray} if } if RealSetgray } ifelse } ifelse } bind def /savematrix { orgmatrix currentmatrix pop } bind def /restorematrix { orgmatrix setmatrix } bind def /dmatrix matrix def /dpi 72 0 dmatrix defaultmatrix dtransform dup mul exch dup mul add sqrt def /freq dpi dup 72 div round dup 0 eq {pop 1} if 8 mul div def /sangle 1 0 dmatrix defaultmatrix dtransform exch atan def /dpiranges [ 2540 2400 1693 1270 1200 635 600 0 ] def /CMLowFreqs [ 100.402 94.8683 89.2289 100.402 94.8683 66.9349 63.2456 47.4342 ] def /YLowFreqs [ 95.25 90.0 84.65 95.25 90.0 70.5556 66.6667 50.0 ] def /KLowFreqs [ 89.8026 84.8528 79.8088 89.8026 84.8528 74.8355 70.7107 53.033 ] def /CLowAngles [ 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 71.5651 ] def /MLowAngles [ 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 18.4349 ] def /YLowTDot [ true true false true true false false false ] def /CMHighFreqs [ 133.87 126.491 133.843 108.503 102.523 100.402 94.8683 63.2456 ] def /YHighFreqs [ 127.0 120.0 126.975 115.455 109.091 95.25 90.0 60.0 ] def /KHighFreqs [ 119.737 113.137 119.713 128.289 121.218 89.8026 84.8528 63.6395 ] def /CHighAngles [ 71.5651 71.5651 71.5651 70.0169 70.0169 71.5651 71.5651 71.5651 ] def /MHighAngles [ 18.4349 18.4349 18.4349 19.9831 19.9831 18.4349 18.4349 18.4349 ] def /YHighTDot [ false false true false false true true false ] def /PatFreq [ 10.5833 10.0 9.4055 10.5833 10.0 10.5833 10.0 9.375 ] def /screenIndex { 0 1 dpiranges length 1 sub { dup dpiranges exch get 1 sub dpi le {exit} {pop} ifelse } for } bind def /getCyanScreen { FMUseHighFrequencyScreens { CHighAngles CMHighFreqs} {CLowAngles CMLowFreqs} ifelse screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load } bind def /getMagentaScreen { FMUseHighFrequencyScreens { MHighAngles CMHighFreqs } {MLowAngles CMLowFreqs} ifelse screenIndex dup 3 1 roll get 3 1 roll get /FMSpotFunction load } bind def /getYellowScreen { FMUseHighFrequencyScreens { YHighTDot YHighFreqs} { YLowTDot YLowFreqs } ifelse screenIndex dup 3 1 roll get 3 1 roll get { 3 div {2 { 1 add 2 div 3 mul dup floor sub 2 mul 1 sub exch} repeat FMSpotFunction } } {/FMSpotFunction load } ifelse 0.0 exch } bind def /getBlackScreen { FMUseHighFrequencyScreens { KHighFreqs } { KLowFreqs } ifelse screenIndex get 45.0 /FMSpotFunction load } bind def /getSpotScreen { getBlackScreen } bind def /getCompositeScreen { getBlackScreen } bind def /FMSetScreen FMLevel1 { /setscreen load }{ { 8 dict begin /HalftoneType 1 def /SpotFunction exch def /Angle exch def /Frequency exch def /AccurateScreens FMUseAcccurateScreens def currentdict end sethalftone } bind } ifelse def /setDefaultScreen { FMPColor { orgrxfer cvx orggxfer cvx orgbxfer cvx orgxfer cvx setcolortransfer } { orgxfer cvx settransfer } ifelse orgfreq organgle orgproc cvx setscreen } bind def /setCurrentScreen { FrameSepIs FMnone eq { FMUseDefaultNoSeparationScreen { setDefaultScreen } { getCompositeScreen FMSetScreen } ifelse } { FrameSepIs FMcustom eq { FMUseDefaultSpotSeparationScreen { setDefaultScreen } { getSpotScreen FMSetScreen } ifelse } { FMUseDefaultProcessSeparationScreen { setDefaultScreen } { FrameSepIs FMcyan eq { getCyanScreen FMSetScreen } { FrameSepIs FMmagenta eq { getMagentaScreen FMSetScreen } { FrameSepIs FMyellow eq { getYellowScreen FMSetScreen } { getBlackScreen FMSetScreen } ifelse } ifelse } ifelse } ifelse } ifelse } ifelse } bind def end /gstring FMLOCAL /gfile FMLOCAL /gindex FMLOCAL /orgrxfer FMLOCAL /orggxfer FMLOCAL /orgbxfer FMLOCAL /orgxfer FMLOCAL /orgproc FMLOCAL /orgrproc FMLOCAL /orggproc FMLOCAL /orgbproc FMLOCAL /organgle FMLOCAL /orgrangle FMLOCAL /orggangle FMLOCAL /orgbangle FMLOCAL /orgfreq FMLOCAL /orgrfreq FMLOCAL /orggfreq FMLOCAL /orgbfreq FMLOCAL /yscale FMLOCAL /xscale FMLOCAL /edown FMLOCAL /manualfeed FMLOCAL /paperheight FMLOCAL /paperwidth FMLOCAL /FMDOCUMENT { array /FMfonts exch def /#copies exch def FrameDict begin 0 ne /manualfeed exch def /paperheight exch def /paperwidth exch def 0 ne /FrameNegative exch def 0 ne /edown exch def /yscale exch def /xscale exch def FMLevel1 { manualfeed {setmanualfeed} if /FMdicttop countdictstack 1 add def /FMoptop count def setpapername manualfeed {true} {papersize} ifelse {manualpapersize} {false} ifelse {desperatepapersize} {false} ifelse { (Can't select requested paper size for Frame print job!) FMFAILURE } if count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for } {{1 dict dup /PageSize [paperwidth paperheight]put setpagedevice}stopped { (Can't select requested paper size for Frame print job!) FMFAILURE } if {1 dict dup /ManualFeed manualfeed put setpagedevice } stopped pop } ifelse FMPColor { currentcolorscreen cvlit /orgproc exch def /organgle exch def /orgfreq exch def cvlit /orgbproc exch def /orgbangle exch def /orgbfreq exch def cvlit /orggproc exch def /orggangle exch def /orggfreq exch def cvlit /orgrproc exch def /orgrangle exch def /orgrfreq exch def currentcolortransfer FrameNegative { 1 1 4 { pop { 1 exch sub } concatprocs 4 1 roll } for 4 copy setcolortransfer } if cvlit /orgxfer exch def cvlit /orgbxfer exch def cvlit /orggxfer exch def cvlit /orgrxfer exch def } { currentscreen cvlit /orgproc exch def /organgle exch def /orgfreq exch def currenttransfer FrameNegative { { 1 exch sub } concatprocs dup settransfer } if cvlit /orgxfer exch def } ifelse end } def /pagesave FMLOCAL /orgmatrix FMLOCAL /landscape FMLOCAL /pwid FMLOCAL /FMBEGINPAGE { FrameDict begin /pagesave save def 3.86 setmiterlimit /landscape exch 0 ne def landscape { 90 rotate 0 exch dup /pwid exch def neg translate pop }{ pop /pwid exch def } ifelse edown { [-1 0 0 1 pwid 0] concat } if 0 0 moveto paperwidth 0 lineto paperwidth paperheight lineto 0 paperheight lineto 0 0 lineto 1 setgray fill xscale yscale scale /orgmatrix matrix def gsave } def /FMENDPAGE { grestore pagesave restore end showpage } def /FMFONTDEFINE { FrameDict begin findfont ReEncode 1 index exch definefont FMfonts 3 1 roll put end } def /FMFILLS { FrameDict begin dup array /fillvals exch def dict /patCache exch def end } def /FMFILL { FrameDict begin fillvals 3 1 roll put end } def /FMNORMALIZEGRAPHICS { newpath 0.0 0.0 moveto 1 setlinewidth 0 setlinecap 0 0 0 sethsbcolor 0 setgray } bind def /fx FMLOCAL /fy FMLOCAL /fh FMLOCAL /fw FMLOCAL /llx FMLOCAL /lly FMLOCAL /urx FMLOCAL /ury FMLOCAL /FMBEGINEPSF { end /FMEPSF save def /showpage {} def % See Adobe's "PostScript Language Reference Manual, 2nd Edition", page 714. % "...the following operators MUST NOT be used in an EPS file:" (emphasis ours) /banddevice {(banddevice) FMBADEPSF} def /clear {(clear) FMBADEPSF} def /cleardictstack {(cleardictstack) FMBADEPSF} def /copypage {(copypage) FMBADEPSF} def /erasepage {(erasepage) FMBADEPSF} def /exitserver {(exitserver) FMBADEPSF} def /framedevice {(framedevice) FMBADEPSF} def /grestoreall {(grestoreall) FMBADEPSF} def /initclip {(initclip) FMBADEPSF} def /initgraphics {(initgraphics) FMBADEPSF} def /initmatrix {(initmatrix) FMBADEPSF} def /quit {(quit) FMBADEPSF} def /renderbands {(renderbands) FMBADEPSF} def /setglobal {(setglobal) FMBADEPSF} def /setpagedevice {(setpagedevice) FMBADEPSF} def /setshared {(setshared) FMBADEPSF} def /startjob {(startjob) FMBADEPSF} def /lettertray {(lettertray) FMBADEPSF} def /letter {(letter) FMBADEPSF} def /lettersmall {(lettersmall) FMBADEPSF} def /11x17tray {(11x17tray) FMBADEPSF} def /11x17 {(11x17) FMBADEPSF} def /ledgertray {(ledgertray) FMBADEPSF} def /ledger {(ledger) FMBADEPSF} def /legaltray {(legaltray) FMBADEPSF} def /legal {(legal) FMBADEPSF} def /statementtray {(statementtray) FMBADEPSF} def /statement {(statement) FMBADEPSF} def /executivetray {(executivetray) FMBADEPSF} def /executive {(executive) FMBADEPSF} def /a3tray {(a3tray) FMBADEPSF} def /a3 {(a3) FMBADEPSF} def /a4tray {(a4tray) FMBADEPSF} def /a4 {(a4) FMBADEPSF} def /a4small {(a4small) FMBADEPSF} def /b4tray {(b4tray) FMBADEPSF} def /b4 {(b4) FMBADEPSF} def /b5tray {(b5tray) FMBADEPSF} def /b5 {(b5) FMBADEPSF} def FMNORMALIZEGRAPHICS [/fy /fx /fh /fw /ury /urx /lly /llx] {exch def} forall fx fw 2 div add fy fh 2 div add translate rotate fw 2 div neg fh 2 div neg translate fw urx llx sub div fh ury lly sub div scale llx neg lly neg translate /FMdicttop countdictstack 1 add def /FMoptop count def } bind def /FMENDEPSF { count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for FMEPSF restore FrameDict begin } bind def FrameDict begin /setmanualfeed { %%BeginFeature *ManualFeed True statusdict /manualfeed true put %%EndFeature } bind def /max {2 copy lt {exch} if pop} bind def /min {2 copy gt {exch} if pop} bind def /inch {72 mul} def /pagedimen { paperheight sub abs 16 lt exch paperwidth sub abs 16 lt and {/papername exch def} {pop} ifelse } bind def /papersizedict FMLOCAL /setpapername { /papersizedict 14 dict def papersizedict begin /papername /unknown def /Letter 8.5 inch 11.0 inch pagedimen /LetterSmall 7.68 inch 10.16 inch pagedimen /Tabloid 11.0 inch 17.0 inch pagedimen /Ledger 17.0 inch 11.0 inch pagedimen /Legal 8.5 inch 14.0 inch pagedimen /Statement 5.5 inch 8.5 inch pagedimen /Executive 7.5 inch 10.0 inch pagedimen /A3 11.69 inch 16.5 inch pagedimen /A4 8.26 inch 11.69 inch pagedimen /A4Small 7.47 inch 10.85 inch pagedimen /B4 10.125 inch 14.33 inch pagedimen /B5 7.16 inch 10.125 inch pagedimen end } bind def /papersize { papersizedict begin /Letter {lettertray letter} def /LetterSmall {lettertray lettersmall} def /Tabloid {11x17tray 11x17} def /Ledger {ledgertray ledger} def /Legal {legaltray legal} def /Statement {statementtray statement} def /Executive {executivetray executive} def /A3 {a3tray a3} def /A4 {a4tray a4} def /A4Small {a4tray a4small} def /B4 {b4tray b4} def /B5 {b5tray b5} def /unknown {unknown} def papersizedict dup papername known {papername} {/unknown} ifelse get end statusdict begin stopped end } bind def /manualpapersize { papersizedict begin /Letter {letter} def /LetterSmall {lettersmall} def /Tabloid {11x17} def /Ledger {ledger} def /Legal {legal} def /Statement {statement} def /Executive {executive} def /A3 {a3} def /A4 {a4} def /A4Small {a4small} def /B4 {b4} def /B5 {b5} def /unknown {unknown} def papersizedict dup papername known {papername} {/unknown} ifelse get end stopped } bind def /desperatepapersize { statusdict /setpageparams known { paperwidth paperheight 0 1 statusdict begin {setpageparams} stopped end } {true} ifelse } bind def /DiacriticEncoding [ /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quotesingle /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash /zero /one /two /three /four /five /six /seven /eight /nine /colon /semicolon /less /equal /greater /question /at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore /grave /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar /braceright /asciitilde /.notdef /Adieresis /Aring /Ccedilla /Eacute /Ntilde /Odieresis /Udieresis /aacute /agrave /acircumflex /adieresis /atilde /aring /ccedilla /eacute /egrave /ecircumflex /edieresis /iacute /igrave /icircumflex /idieresis /ntilde /oacute /ograve /ocircumflex /odieresis /otilde /uacute /ugrave /ucircumflex /udieresis /dagger /.notdef /cent /sterling /section /bullet /paragraph /germandbls /registered /copyright /trademark /acute /dieresis /.notdef /AE /Oslash /.notdef /.notdef /.notdef /.notdef /yen /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /ordfeminine /ordmasculine /.notdef /ae /oslash /questiondown /exclamdown /logicalnot /.notdef /florin /.notdef /.notdef /guillemotleft /guillemotright /ellipsis /.notdef /Agrave /Atilde /Otilde /OE /oe /endash /emdash /quotedblleft /quotedblright /quoteleft /quoteright /.notdef /.notdef /ydieresis /Ydieresis /fraction /currency /guilsinglleft /guilsinglright /fi /fl /daggerdbl /periodcentered /quotesinglbase /quotedblbase /perthousand /Acircumflex /Ecircumflex /Aacute /Edieresis /Egrave /Iacute /Icircumflex /Idieresis /Igrave /Oacute /Ocircumflex /.notdef /Ograve /Uacute /Ucircumflex /Ugrave /dotlessi /circumflex /tilde /macron /breve /dotaccent /ring /cedilla /hungarumlaut /ogonek /caron ] def /ReEncode { dup length dict begin { 1 index /FID ne {def} {pop pop} ifelse } forall 0 eq {/Encoding DiacriticEncoding def} if currentdict end } bind def FMPColor { /BEGINBITMAPCOLOR { BITMAPCOLOR} def /BEGINBITMAPCOLORc { BITMAPCOLORc} def /BEGINBITMAPTRUECOLOR { BITMAPTRUECOLOR } def /BEGINBITMAPTRUECOLORc { BITMAPTRUECOLORc } def } { /BEGINBITMAPCOLOR { BITMAPGRAY} def /BEGINBITMAPCOLORc { BITMAPGRAYc} def /BEGINBITMAPTRUECOLOR { BITMAPTRUEGRAY } def /BEGINBITMAPTRUECOLORc { BITMAPTRUEGRAYc } def } ifelse /K { FMPrintAllColorsAsBlack { dup 1 eq 2 index 1 eq and 3 index 1 eq and not {7 {pop} repeat 0 0 0 1 0 0 0} if } if FrameCurColors astore pop combineColor } bind def /graymode true def /bwidth FMLOCAL /bpside FMLOCAL /bstring FMLOCAL /onbits FMLOCAL /offbits FMLOCAL /xindex FMLOCAL /yindex FMLOCAL /x FMLOCAL /y FMLOCAL /setPatternMode { FMLevel1 { /bwidth exch def /bpside exch def /bstring exch def /onbits 0 def /offbits 0 def freq sangle landscape {90 add} if {/y exch def /x exch def /xindex x 1 add 2 div bpside mul cvi def /yindex y 1 add 2 div bpside mul cvi def bstring yindex bwidth mul xindex 8 idiv add get 1 7 xindex 8 mod sub bitshift and 0 ne FrameNegative {not} if {/onbits onbits 1 add def 1} {/offbits offbits 1 add def 0} ifelse } setscreen offbits offbits onbits add div FrameNegative {1.0 exch sub} if /FrameCurGray exch def } { pop pop dup patCache exch known { patCache exch get } { dup patDict /bstring 3 -1 roll put patDict 9 PatFreq screenIndex get div dup matrix scale makepattern dup patCache 4 -1 roll 3 -1 roll put } ifelse /FrameCurGray 0 def /FrameCurPat exch def } ifelse /graymode false def combineColor } bind def /setGrayScaleMode { graymode not { /graymode true def FMLevel1 { setCurrentScreen } if } if /FrameCurGray exch def combineColor } bind def /normalize { transform round exch round exch itransform } bind def /dnormalize { dtransform round exch round exch idtransform } bind def /lnormalize { 0 dtransform exch cvi 2 idiv 2 mul 1 add exch idtransform pop } bind def /H { lnormalize setlinewidth } bind def /Z { setlinecap } bind def /PFill { graymode FMLevel1 or not { gsave 1 setgray eofill grestore } if } bind def /PStroke { graymode FMLevel1 or not { gsave 1 setgray stroke grestore } if stroke } bind def /fillvals FMLOCAL /X { fillvals exch get dup type /stringtype eq {8 1 setPatternMode} {setGrayScaleMode} ifelse } bind def /V { PFill gsave eofill grestore } bind def /Vclip { clip } bind def /Vstrk { currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /N { PStroke } bind def /Nclip { strokepath clip newpath } bind def /Nstrk { currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /M {newpath moveto} bind def /E {lineto} bind def /D {curveto} bind def /O {closepath} bind def /n FMLOCAL /L { /n exch def newpath normalize moveto 2 1 n {pop normalize lineto} for } bind def /Y { L closepath } bind def /x1 FMLOCAL /x2 FMLOCAL /y1 FMLOCAL /y2 FMLOCAL /R { /y2 exch def /x2 exch def /y1 exch def /x1 exch def x1 y1 x2 y1 x2 y2 x1 y2 4 Y } bind def /rad FMLOCAL /rarc {rad arcto } bind def /RR { /rad exch def normalize /y2 exch def /x2 exch def normalize /y1 exch def /x1 exch def mark newpath { x1 y1 rad add moveto x1 y2 x2 y2 rarc x2 y2 x2 y1 rarc x2 y1 x1 y1 rarc x1 y1 x1 y2 rarc closepath } stopped {x1 y1 x2 y2 R} if cleartomark } bind def /RRR { /rad exch def normalize /y4 exch def /x4 exch def normalize /y3 exch def /x3 exch def normalize /y2 exch def /x2 exch def normalize /y1 exch def /x1 exch def newpath normalize moveto mark { x2 y2 x3 y3 rarc x3 y3 x4 y4 rarc x4 y4 x1 y1 rarc x1 y1 x2 y2 rarc closepath } stopped {x1 y1 x2 y2 x3 y3 x4 y4 newpath moveto lineto lineto lineto closepath} if cleartomark } bind def /C { grestore gsave R clip setCurrentScreen } bind def /CP { grestore gsave Y clip setCurrentScreen } bind def /FMpointsize FMLOCAL /F { FMfonts exch get FMpointsize scalefont setfont } bind def /Q { /FMpointsize exch def F } bind def /T { moveto show } bind def /RF { rotate 0 ne {-1 1 scale} if } bind def /TF { gsave moveto RF show grestore } bind def /P { moveto 0 32 3 2 roll widthshow } bind def /PF { gsave moveto RF 0 32 3 2 roll widthshow grestore } bind def /S { moveto 0 exch ashow } bind def /SF { gsave moveto RF 0 exch ashow grestore } bind def /B { moveto 0 32 4 2 roll 0 exch awidthshow } bind def /BF { gsave moveto RF 0 32 4 2 roll 0 exch awidthshow grestore } bind def /G { gsave newpath normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath PFill fill grestore } bind def /Gstrk { savematrix newpath 2 index 2 div add exch 3 index 2 div sub exch normalize 2 index 2 div sub exch 3 index 2 div add exch translate scale 0.0 0.0 1.0 5 3 roll arc restorematrix currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /Gclip { newpath savematrix normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath clip newpath restorematrix } bind def /GG { gsave newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath PFill fill grestore } bind def /GGclip { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath clip newpath restorematrix } bind def /GGstrk { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath restorematrix currentlinewidth exch setlinewidth PStroke setlinewidth } bind def /A { gsave savematrix newpath 2 index 2 div add exch 3 index 2 div sub exch normalize 2 index 2 div sub exch 3 index 2 div add exch translate scale 0.0 0.0 1.0 5 3 roll arc restorematrix PStroke grestore } bind def /Aclip { newpath savematrix normalize translate 0.0 0.0 moveto dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath strokepath clip newpath restorematrix } bind def /Astrk { Gstrk } bind def /AA { gsave savematrix newpath 3 index 2 div add exch 4 index 2 div sub exch normalize 3 index 2 div sub exch 4 index 2 div add exch translate rotate scale 0.0 0.0 1.0 5 3 roll arc restorematrix PStroke grestore } bind def /AAclip { savematrix newpath normalize translate 0.0 0.0 moveto rotate dnormalize scale 0.0 0.0 1.0 5 3 roll arc closepath strokepath clip newpath restorematrix } bind def /AAstrk { GGstrk } bind def /x FMLOCAL /y FMLOCAL /w FMLOCAL /h FMLOCAL /xx FMLOCAL /yy FMLOCAL /ww FMLOCAL /hh FMLOCAL /FMsaveobject FMLOCAL /FMoptop FMLOCAL /FMdicttop FMLOCAL /BEGINPRINTCODE { /FMdicttop countdictstack 1 add def /FMoptop count 7 sub def /FMsaveobject save def userdict begin /showpage {} def FMNORMALIZEGRAPHICS 3 index neg 3 index neg translate } bind def /ENDPRINTCODE { count -1 FMoptop {pop pop} for countdictstack -1 FMdicttop {pop end} for FMsaveobject restore } bind def /gn { 0 { 46 mul cf read pop 32 sub dup 46 lt {exit} if 46 sub add } loop add } bind def /str FMLOCAL /cfs { /str sl string def 0 1 sl 1 sub {str exch val put} for str def } bind def /ic [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0223 0 {0 hx} {1 hx} {2 hx} {3 hx} {4 hx} {5 hx} {6 hx} {7 hx} {8 hx} {9 hx} {10 hx} {11 hx} {12 hx} {13 hx} {14 hx} {15 hx} {16 hx} {17 hx} {18 hx} {19 hx} {gn hx} {0} {1} {2} {3} {4} {5} {6} {7} {8} {9} {10} {11} {12} {13} {14} {15} {16} {17} {18} {19} {gn} {0 wh} {1 wh} {2 wh} {3 wh} {4 wh} {5 wh} {6 wh} {7 wh} {8 wh} {9 wh} {10 wh} {11 wh} {12 wh} {13 wh} {14 wh} {gn wh} {0 bl} {1 bl} {2 bl} {3 bl} {4 bl} {5 bl} {6 bl} {7 bl} {8 bl} {9 bl} {10 bl} {11 bl} {12 bl} {13 bl} {14 bl} {gn bl} {0 fl} {1 fl} {2 fl} {3 fl} {4 fl} {5 fl} {6 fl} {7 fl} {8 fl} {9 fl} {10 fl} {11 fl} {12 fl} {13 fl} {14 fl} {gn fl} ] def /sl FMLOCAL /val FMLOCAL /ws FMLOCAL /im FMLOCAL /bs FMLOCAL /cs FMLOCAL /len FMLOCAL /pos FMLOCAL /ms { /sl exch def /val 255 def /ws cfs /im cfs /val 0 def /bs cfs /cs cfs } bind def 400 ms /ip { is 0 cf cs readline pop { ic exch get exec add } forall pop } bind def /rip { bis ris copy pop is 0 cf cs readline pop { ic exch get exec add } forall pop pop ris gis copy pop dup is exch cf cs readline pop { ic exch get exec add } forall pop pop gis bis copy pop dup add is exch cf cs readline pop { ic exch get exec add } forall pop } bind def /wh { /len exch def /pos exch def ws 0 len getinterval im pos len getinterval copy pop pos len } bind def /bl { /len exch def /pos exch def bs 0 len getinterval im pos len getinterval copy pop pos len } bind def /s1 1 string def /fl { /len exch def /pos exch def /val cf s1 readhexstring pop 0 get def pos 1 pos len add 1 sub {im exch val put} for pos len } bind def /hx { 3 copy getinterval cf exch readhexstring pop pop } bind def /h FMLOCAL /w FMLOCAL /d FMLOCAL /lb FMLOCAL /bitmapsave FMLOCAL /is FMLOCAL /cf FMLOCAL /wbytes { dup dup 24 eq { pop pop 3 mul } { 8 eq {pop} {1 eq {7 add 8 idiv} {3 add 4 idiv} ifelse} ifelse } ifelse } bind def /BEGINBITMAPBWc { 1 {} COMMONBITMAPc } bind def /BEGINBITMAPGRAYc { 8 {} COMMONBITMAPc } bind def /BEGINBITMAP2BITc { 2 {} COMMONBITMAPc } bind def /COMMONBITMAPc { /r exch def /d exch def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def r /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h d [w 0 0 h neg 0 h] {ip} image bitmapsave restore grestore } bind def /BEGINBITMAPBW { 1 {} COMMONBITMAP } bind def /BEGINBITMAPGRAY { 8 {} COMMONBITMAP } bind def /BEGINBITMAP2BIT { 2 {} COMMONBITMAP } bind def /COMMONBITMAP { /r exch def /d exch def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def r /is w d wbytes string def /cf currentfile def w h d [w 0 0 h neg 0 h] {cf is readhexstring pop} image bitmapsave restore grestore } bind def /ngrayt 256 array def /nredt 256 array def /nbluet 256 array def /ngreent 256 array def /gryt FMLOCAL /blut FMLOCAL /grnt FMLOCAL /redt FMLOCAL /indx FMLOCAL /cynu FMLOCAL /magu FMLOCAL /yelu FMLOCAL /k FMLOCAL /u FMLOCAL FMLevel1 { /colorsetup { currentcolortransfer /gryt exch def /blut exch def /grnt exch def /redt exch def 0 1 255 { /indx exch def /cynu 1 red indx get 255 div sub def /magu 1 green indx get 255 div sub def /yelu 1 blue indx get 255 div sub def /k cynu magu min yelu min def /u k currentundercolorremoval exec def % /u 0 def nredt indx 1 0 cynu u sub max sub redt exec put ngreent indx 1 0 magu u sub max sub grnt exec put nbluet indx 1 0 yelu u sub max sub blut exec put ngrayt indx 1 k currentblackgeneration exec sub gryt exec put } for {255 mul cvi nredt exch get} {255 mul cvi ngreent exch get} {255 mul cvi nbluet exch get} {255 mul cvi ngrayt exch get} setcolortransfer {pop 0} setundercolorremoval {} setblackgeneration } bind def } { /colorSetup2 { [ /Indexed /DeviceRGB 255 {dup red exch get 255 div exch dup green exch get 255 div exch blue exch get 255 div} ] setcolorspace } bind def } ifelse /tran FMLOCAL /fakecolorsetup { /tran 256 string def 0 1 255 {/indx exch def tran indx red indx get 77 mul green indx get 151 mul blue indx get 28 mul add add 256 idiv put} for currenttransfer {255 mul cvi tran exch get 255.0 div} exch concatprocs settransfer } bind def /BITMAPCOLOR { /d 8 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def FMLevel1 { colorsetup /is w d wbytes string def /cf currentfile def w h d [w 0 0 h neg 0 h] {cf is readhexstring pop} {is} {is} true 3 colorimage } { colorSetup2 /is w d wbytes string def /cf currentfile def 7 dict dup begin /ImageType 1 def /Width w def /Height h def /ImageMatrix [w 0 0 h neg 0 h] def /DataSource {cf is readhexstring pop} bind def /BitsPerComponent d def /Decode [0 255] def end image } ifelse bitmapsave restore grestore } bind def /BITMAPCOLORc { /d 8 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def FMLevel1 { colorsetup /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h d [w 0 0 h neg 0 h] {ip} {is} {is} true 3 colorimage } { colorSetup2 /is im 0 lb getinterval def ws 0 lb getinterval is copy pop /cf currentfile def 7 dict dup begin /ImageType 1 def /Width w def /Height h def /ImageMatrix [w 0 0 h neg 0 h] def /DataSource {ip} bind def /BitsPerComponent d def /Decode [0 255] def end image } ifelse bitmapsave restore grestore } bind def /BITMAPTRUECOLORc { /d 24 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def /is im 0 lb getinterval def /ris im 0 w getinterval def /gis im w w getinterval def /bis im w 2 mul w getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h 8 [w 0 0 h neg 0 h] {w rip pop ris} {gis} {bis} true 3 colorimage bitmapsave restore grestore } bind def /BITMAPTRUECOLOR { gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def /is w string def /gis w string def /bis w string def /cf currentfile def w h 8 [w 0 0 h neg 0 h] { cf is readhexstring pop } { cf gis readhexstring pop } { cf bis readhexstring pop } true 3 colorimage bitmapsave restore grestore } bind def /BITMAPTRUEGRAYc { /d 24 def gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /lb w d wbytes def sl lb lt {lb ms} if /bitmapsave save def /is im 0 lb getinterval def /ris im 0 w getinterval def /gis im w w getinterval def /bis im w 2 mul w getinterval def ws 0 lb getinterval is copy pop /cf currentfile def w h 8 [w 0 0 h neg 0 h] {w rip pop ris gis bis w gray} image bitmapsave restore grestore } bind def /ww FMLOCAL /r FMLOCAL /g FMLOCAL /b FMLOCAL /i FMLOCAL /gray { /ww exch def /b exch def /g exch def /r exch def 0 1 ww 1 sub { /i exch def r i get .299 mul g i get .587 mul b i get .114 mul add add r i 3 -1 roll floor cvi put } for r } bind def /BITMAPTRUEGRAY { gsave 3 index 2 div add exch 4 index 2 div add exch translate rotate 1 index 2 div neg 1 index 2 div neg translate scale /h exch def /w exch def /bitmapsave save def /is w string def /gis w string def /bis w string def /cf currentfile def w h 8 [w 0 0 h neg 0 h] { cf is readhexstring pop cf gis readhexstring pop cf bis readhexstring pop w gray} image bitmapsave restore grestore } bind def /BITMAPGRAY { 8 {fakecolorsetup} COMMONBITMAP } bind def /BITMAPGRAYc { 8 {fakecolorsetup} COMMONBITMAPc } bind def /ENDBITMAP { } bind def end /ALDsave FMLOCAL /ALDmatrix matrix def ALDmatrix currentmatrix pop /StartALD { /ALDsave save def savematrix ALDmatrix setmatrix } bind def /InALD { restorematrix } bind def /DoneALD { ALDsave restore } bind def /I { setdash } bind def /J { [] 0 setdash } bind def %%EndProlog %%BeginSetup (4.0) FMVERSION 1 1 0 0 612 792 0 1 16 FMDOCUMENT 0 0 /Times-Roman FMFONTDEFINE 1 0 /Times-Bold FMFONTDEFINE 2 0 /Helvetica FMFONTDEFINE 3 0 /Helvetica-Bold FMFONTDEFINE 4 0 /Helvetica-Oblique FMFONTDEFINE 5 0 /Times-Italic FMFONTDEFINE 32 FMFILLS 0 0 FMFILL 1 0.1 FMFILL 2 0.3 FMFILL 3 0.5 FMFILL 4 0.7 FMFILL 5 0.9 FMFILL 6 0.97 FMFILL 7 1 FMFILL 8 <0f1e3c78f0e1c387> FMFILL 9 <0f87c3e1f0783c1e> FMFILL 10 FMFILL 11 FMFILL 12 <8142241818244281> FMFILL 13 <03060c183060c081> FMFILL 14 <8040201008040201> FMFILL 16 1 FMFILL 17 0.9 FMFILL 18 0.7 FMFILL 19 0.5 FMFILL 20 0.3 FMFILL 21 0.1 FMFILL 22 0.03 FMFILL 23 0 FMFILL 24 FMFILL 25 FMFILL 26 <3333333333333333> FMFILL 27 <0000ffff0000ffff> FMFILL 28 <7ebddbe7e7dbbd7e> FMFILL 29 FMFILL 30 <7fbfdfeff7fbfdfe> FMFILL %%EndSetup %%Page: "0" 1 %%BeginPaperSize: Letter %%EndPaperSize 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K J 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 0) 513.06 35.85 T 72 72 540 720 R 7 X V 0 12 Q 0 X (******************************************************************************) 72 712 T (A) 72 694.33 T (TM Forum) 79.33 694.33 T 0 10 Q (:) 132.34 694.33 T (T) 216 694.33 T (echnical Committee, Signalling Subworking Group) 221.41 694.33 T (A) 216 677.33 T (TM Forum/94-0325R1) 222.11 677.33 T 0 12 Q (******************************************************************************) 72 659 T (TITLE) 72 641.33 T 0 10 Q (:) 105.32 641.33 T (Leaf Initiated Join Extensions) 216 641.33 T 0 12 Q (******************************************************************************) 72 623 T (SOURCES:) 72 604 T 0 10 Q (Rick Bubenik) 72 573.33 T (Pete Flugstad) 306 573.33 T (ASCOM TIMEPLEX, INC.) 72 561.33 T (ASCOM TIMEPLEX, INC.) 306 561.33 T (1807 Park 270 Drive) 72 549.33 T (1807 Park 270 Drive) 306 549.33 T (St. Louis, MO 63146) 72 537.33 T (St. Louis, MO 63146) 306 537.33 T (\050314\051 579-6512 \050of) 72 525.33 T (\336ce\051) 148.47 525.33 T (\050314\051 579-6520 \050of) 306 525.33 T (\336ce\051) 382.47 525.33 T (\050314\051 542-0495 \050fax\051) 72 513.33 T (\050314\051 542-0495 \050fax\051) 306 513.33 T (rick@louie.timeplex.com) 72 501.33 T (pete@louie.timeplex.com) 306 501.33 T 0 12 Q (******************************************************************************) 72 464 T (DISTRIBUTION) 72 446.33 T 0 10 Q (:) 155.99 446.33 T (A) 216 446.33 T (TM Forum T) 222.11 446.33 T (echnical W) 274.19 446.33 T (orking Group) 318.65 446.33 T 0 12 Q (******************************************************************************) 72 428 T (ABSTRACT) 274.66 409 T 0 10 Q 0.1 (In this contribution, we propose extensions to the existing \050phase 1\051 UNI 3.1 signalling protocol to support Leaf) 90.86 388.33 P -0.26 (Initiated Join \050LIJ\051 calls. This contribution is a follow-on to contributions ATMF 94-0264 and ATMF94-0325, where) 72 376.33 P 0.42 (a \322bare-bones\323 LIJ call capability was introduced \050in 94-0264\051 then refined considerably \050in 94-0325\051. The current) 72 364.33 P 0.05 (contribution retains the general model of 94-0325, while incorporating most of the suggestions that were made at the) 72 352.33 P (May,) 72 340.33 T (1994 ATM Forum meeting for improving the model.) 95.33 340.33 T 0 12 Q (******************************************************************************) 72 315 T (DA) 72 297.33 T (TE) 88 297.33 T 0 10 Q (:) 102.66 297.33 T (July 18\32021, 1994) 216 297.33 T 0 12 Q (******************************************************************************) 72 279 T (NOTICE) 284 260 T 0 10 Q 0.7 (This document is offered to the ATM Forum membership as a basis for discussion and is not binding on ASCOM) 72 239.33 P 0.69 (TIMEPLEX or on any other member organization. The requirements, specifications, proposals, comments or other) 72 227.33 P -0.03 (material presented herein are subject to change in form and content after further study. ASCOM TIMEPLEX specifi-) 72 215.33 P (cally reserves the right to add, amend, or withdraw the statements contained herein.) 72 203.33 T 52 674 54 684 R V 52 325 54 395 R V 52 294 54 304 R V 279.29 19.14 329.29 54.85 R 7 X V 36 18 567 63 R V FMENDPAGE %%EndPage: "0" 1 %%Page: "1" 2 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 1) 513.06 35.85 T 72 68.43 540 720 R 7 X V 1 12 Q 0 X (1) 72 712 T (Introduction) 90 712 T 0 10 Q 0.81 (In contribution 94-0264 \050submitted to the March, 1994 ATM Forum meeting\051, we proposed extensions to the) 90.86 695.33 P -0.05 (phase) 72 683.33 P -0.05 (1 UNI signalling protocol to support Leaf Initiated Join \050LIJ\051 calls. For simplicity, we imposed several restric-) 97.27 683.33 P -0.44 (tions on LIJ calls to avoid race conditions and minimize the protocol modifications. The Signalling SWG membership) 72 671.33 P -0.22 (generally accepted the direction set forth in contribution 94-0264, but was concerned about some of these restrictions,) 72 659.33 P (as reflected in the following excerpt from the Signalling SWG meeting minutes:) 72 647.33 T 2 F 0.1 (For leaf-initiated joins to a multipoint call, the contribution [94-0264] proposed a simplified version in) 99 625.33 P 0.32 (which only the leaves would be allowed to perform adds and drops and in which there would be no) 99 613.33 P -0.64 (security. There was concern that this version did not allow a mix of root-initiated and leaf-initiated joins) 99 601.33 P (and did not evolve directly from the current point-to-multipoint procedures, which are root-initiated.) 99 589.33 T -0.02 (MOTION: Accept the text in this contribution as preliminary text for leaf-initiated joins, pending it can) 99 573.33 P (be enhanced to be an extension of the current point-to-multipoint model.) 99 561.33 T (DECISION --> \05017/0/7\051 The motion passed.) 99 545.33 T 0 F -0.11 (In response to these concerns, we submitted the first version of contribution 94-0325 to the May, 1994 ATM Fo-) 90.86 523.33 P 0.14 (rum meeting, which lifted the objectionable restrictions. Additionally, the approach taken in 94-0325 \050unlike that of) 72 511.33 P -0.26 (94-0264\051 was a direct evolution of the existing root initiated point-to-multipoint procedures and fully compatible with) 72 499.33 P -0.26 (these procedures. Quoting from the meeting minutes, contribution 94-0325 was accepted as \322progressing the leaf-ini-) 72 487.33 P -0.14 (tiated join work,\323 with no objections registered. Several good suggestions were made during the May meeting for re-) 72 475.33 P 0.29 (fining the approach in 94-0325, so that a more capable and more generalized LIJ capability could be achieved. The) 72 463.33 P (current contribution, 94-0325R1, incorporates most of these suggestions.) 72 451.33 T 1 12 Q (1.1) 72 432 T (Background) 99 432 T 0 10 Q -0.04 (In this section, we briefly present the history of our past LIJ contributions to show how this work has progressed) 90.86 415.33 P -0.21 (and to highlight the changes that have been made in the past and those that are being proposed in the current contribu-) 72 403.33 P (tion.) 72 391.33 T 1 12 Q (1.1.1) 72 370 T (Transition from 94-0264 to 94-0325) 108 370 T 0 10 Q 0.29 (ATMF 94-0264 proposed adding two new information elements to support LIJ calls. The first, the Global Call) 90.86 353.33 P -0.21 (ID \050GCID\051 information element, uniquely labels each LIJ call within the network. The second, the Leaf Initiated Join) 72 341.33 P -0.57 (Parameters \050LIJP\051 information element, contains options specified by the call\325s creator that are associated with the call.) 72 329.33 P 0.54 (Both of these are also present in the current approach, although both have been modified slightly \050for example, the) 72 317.33 P -0.23 (GCID has been broken into separate information elements, one each for each component field, and the LIJP no longer) 72 305.33 P (has the parameters that restricted root adds and drops since these restrictions have been lifted\051.) 72 293.33 T 0.23 (The basic LIJ call paradigm of 94-0264 is as follows: In a leaf initiated join call, the root is defined as the user) 90.86 277.33 P -0.02 (who creates the call and the leaves are defined as the endpoints \050or parties\051 who join the call after it has been created.) 72 265.33 P 0.21 (The root creates the call using a SETUP message, which contains the GCID information elements \050to uniquely label) 72 253.33 P 0.14 (the call\051 and a LIJP information element \050to set options associated with the call\051. Leaves likewise join the call using) 72 241.33 P 0 (a SETUP message, which contains a GCID information elements that are used by the network to find the appropriate) 72 229.33 P -0.08 (call to join. The SETUP message builds towards the call tree by routing towards the root and is joined to the existing) 72 217.33 P (call tree when it is bumped into within the network.) 72 205.33 T (In 94-0264, we proposed the following restrictions to keep the protocol modifications simple:) 90.86 189.33 T (1\051) 87 173.33 T -0.12 (Leaves were required to add themselves and could not be added by the root\321in 94-0325, we lifted this restric-) 99.21 173.33 P -0.14 (tion so that the root can also add leaves. Note: in 94-0264, this restriction prevented the root from adding even) 99 161.33 P 0.21 (the first leaf. In 94-0325, the root is allowed to add the first leaf, although we retained the ability for the root) 99 149.33 P -0.43 (to create a call with no initial leaves so that distribution services can be more easily supported \050where the clients) 99 137.33 P (of this service are not necessarily known when the call is created\051.) 99 125.33 T (2\051) 87 109.33 T 0.12 (Leaves were required to drop themselves and could not be dropped by the root\321in 94-0325, we lifted this re-) 99.21 109.33 P (striction so that the root can also drop leaves.) 99 97.33 T 52 448 54 530 R V 52 350 54 422 R V 52 290 54 324 R V 52 250 54 260 R V 52 226 54 236 R V 52 170 54 180 R V 52 146 54 156 R V 52 106 54 116 R V FMENDPAGE %%EndPage: "1" 2 %%Page: "2" 3 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 2) 513.06 35.85 T 72 72 540 720 R 7 X V 0 X (3\051) 87 713.33 T 0.1 (No security, where any party can freely join the LIJ call\321in 94-0325, this restriction was retained. However,) 99.21 713.33 P (the current contribution lifts this restriction.) 99 701.33 T (4\051) 87 685.33 T -0.45 (The root was not notified of leaf joins and drops\321in 94-0325, we lifted this restriction, although we allow these) 99.21 685.33 P (notifications to be turned on and off in case the root does not want to track the call\325s participants.) 99 673.33 T (5\051) 87 657.33 T -0.12 (Endpoint references were not assigned to the leaves\321in 94-0325, we lifted this restriction, although if the root) 99.21 657.33 P 0.23 (chooses to turn off notification of leaf joins and drops, the root does not discover the leaf endpoint references) 99 645.33 P (\050for leaves that add themselves\051.) 99 633.33 T 0.8 (In summary, the only restriction that remained in 94-0325 was that of no security. Additionally, some of the) 90.86 617.33 P -0.38 (changes in 94-0325 obviated the need for certain options and these options were dropped. However, we retained other) 72 605.33 P 0.16 (options \050like the ability to turn notifications on and off\051 so that the user can control the level of required root partici-) 72 593.33 P (pation in the LIJ call.) 72 581.33 T 1 12 Q (1.1.2) 72 560 T (Transition from 94-0325 to 94-0325R1) 108 560 T 0 10 Q -0.06 (Contribution 94-0325R1 retains the basic approach of 93-035, but adds a few enhancements and simplifications.) 90.86 543.33 P (Namely, the following changes are made:) 72 531.33 T (\245) 90 515.33 T -0.06 (A leaf can request to join a non-existent call. In this case, the LEAF SETUP REQUEST sent by the leaf is de-) 99.21 515.33 P -0.47 (livered to the \050potential\051 root. In response to the LEAF SETUP REQUEST, the root \050optionally\051 creates the call) 99 503.33 P (with the requesting leaf as the first endpoint.) 99 491.33 T (\245) 90 475.33 T -0.23 (Security is added by setting a flag in the LIJP information element that forces all LEAF SETUP REQUESTs to) 99.21 475.33 P -0.03 (go to the root. This allows the root to selectively add or not add individual leaves based on their identity. Ad-) 99 463.33 P -0.22 (ditional \322access list\323 security modes are also discussed in Section) 99 451.18 P -0.22 (5, although we have not fleshed out all of the) 361.44 451.18 P (details for these modes yet.) 99 439.18 T (\245) 90 423.18 T -0.33 (New information elements \050IEs\051 have been added to carry addresses in the LEAF SETUP REQUEST messages) 99.21 423.18 P -0.35 (\050and in the other new messages\051. These new IEs are formatted identically to the Called and Calling Party Num-) 99 411.18 P (ber IEs\321they have been added to disambiguate the usage of the addresses.) 99 399.18 T (\245) 90 383.18 T -0.47 (A new message, the NEW LEAF ANNOUNCE, has been added to announce that a leaf has joined the call. For-) 99.21 383.18 P 0.18 (merly, the ADD PARTY ACK was used for this purpose, but it was suggested that this use was inappropriate) 99 371.18 P (at the May \32494 meeting.) 99 359.18 T (\245) 90 343.18 T -0.29 (The \322discriminator\323 field has been dropped from the GCID information element since its presence was deemed) 99.21 343.18 P (redundant to that of the \322local call identifier\323 field.) 99 331.18 T (\245) 90 315.18 T -0.17 (The GCID information element has been broken into three separate information elements, one for each field of) 99.21 315.18 P -0.49 (the GCID. This was done since all GCID fields were not needed in all circumstances. We refer to the collection) 99 303.18 P -0.61 (of new information elements that uniquely label a call as the GCID information element) 99 291.18 P 447.47 290.09 443.58 290.09 2 L V 0.49 H 0 Z N -0.61 (s) 443.58 291.18 P -0.61 ( or simply as the GCID.) 447.47 291.18 P -0.14 (These are the main changes in the LIJ mechanism from 94-0325. Additionally, we have also added details to the) 90.86 275.18 P 0.46 (\322Textual Modifications\323 section \050Section) 72 263.18 P 0.46 (7\051 to give proposed message and information element text for the phase 2) 240.59 263.18 P (signalling protocol Interoperability Agreement.) 72 251.18 T 1 12 Q (1.2) 72 231.85 T (Contribution Organization) 99 231.85 T 0 10 Q -0.25 (The remainder of this contribution is organized as follows. In Section) 90.86 215.18 P -0.25 (2, we describe the LIJ paradigm by way of) 371.17 215.18 P 1.62 (simple examples. In Section) 72 203.18 P 1.62 (3, we enumerate the information element and message additions and changes. In) 196.23 203.18 P -0.44 (Section) 72 191.18 P -0.44 (4, we give detailed examples of several LIJ scenarios to demonstrate a possible internal \050NNI\051 implementation) 104.5 191.18 P -0.39 (and to show how internal race conditions can be avoided and gracefully handled. In Section) 72 179.18 P -0.39 (5, we explain how the LIJ) 438.06 179.18 P -0.17 (call paradigm can be extended to add \322access list\323 security. In Section) 72 167.18 P -0.17 (6, we discuss how third party call setup can be) 355.45 167.18 P -0.19 (supported by building on the LIJ call mechanisms. In Section) 72 155.18 P -0.19 (7, we give the text modifications required to extend the) 320.64 155.18 P (phase 1 UNI signalling protocol to support LIJ calls. Finally, in Section) 72 143.18 T (8, we summarize our proposal.) 363.38 143.18 T 1 12 Q (2) 72 117.85 T (Overview of Leaf Initiated Join Call Paradigm) 90 117.85 T 0 10 Q -0.23 (Leaves join LIJ calls in one of three ways: 1\051 join to an active call with other participants \050leaves\051 currently in the) 90.86 101.18 P 0.06 (call, where the network connects the joining leaf, 2\051 join to an inactive call with no other participants, where the root) 72 89.18 P -0.51 (connects the leaf or 3\051 join to an active call, where the root connects the joining leaf \050for example, for security reasons\051.) 72 77.18 P 52 682 54 720 R V 52 654 54 664 R V 52 590 54 624 R V 52 247.85 54 568 R V 52 199.85 54 221.85 R V 52 163.85 54 185.85 R V 52 73.85 54 125.85 R V FMENDPAGE %%EndPage: "2" 3 %%Page: "3" 4 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 3) 513.06 35.85 T 72 72 540 720 R 7 X V 0 X 0.21 (The second and third join types use very similar procedures. Hence, case \0501\051 is covered in Section) 72 713.33 P 0.21 (2.1 and cases \0502\051) 472.17 713.33 P (and) 72 701.33 T (\0503\051 are covered together in Section) 88.94 701.33 T (2.2.) 230.01 701.33 T 1 12 Q (2.1) 72 682 T (LIJ to Active Call, Network Connects Leaf) 99 682 T 0 10 Q 1.32 (The basic LIJ call paradigm for joining an active call, where the network connects the leaf, is illustrated in) 90.86 665.33 P -0.06 (Figures) 72 653.33 P -0.06 (1\3203. Figure) 104.5 653.33 P -0.06 (1 shows the root\325s initial setup of the call. The procedures followed are virtually identical to the) 155.49 653.33 P -0.25 (phase 1 procedures for creation of a point-to-multipoint call. The only difference is that the SETUP messages contain) 72 401.33 P 0.78 (Global Call Identifier \050GCID\051 and Leaf Initiated Join Parameters \050LIJP\051 Information Elements so that the network) 72 389.33 P -0.07 (knows this call is to be enabled for LIJ access. After the call has been created, the root can freely add additional end-) 72 377.33 P 0.11 (points using the phase 1 point-to-multipoint procedures. As with the first endpoint, the SETUP messages to the new) 72 365.33 P (endpoints will contain the GCID and LIJP information elements.) 72 353.33 T 0.23 (Figure) 90.86 337.33 P 0.23 (2 shows the procedures that are followed when a new leaf adds itself to the call. To initiate the join, the) 119.47 337.33 P 72 72 540 720 C 72 413.29 540 650 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 304.82 597.16 M 316.04 597.16 316.04 597.16 319.83 598.14 D 323.62 599.13 323.62 599.13 324.88 602.09 D 326.14 605.04 326.14 605.04 326.14 616.86 D 326.14 628.69 326.14 628.69 324.88 631.65 D 323.62 634.6 323.62 634.6 319.83 635.59 D 316.04 636.57 316.04 636.57 290.79 636.57 D 265.54 636.57 265.54 636.57 261.75 635.59 D 257.96 634.6 257.96 634.6 256.7 631.65 D 255.43 628.69 255.43 628.69 255.43 616.86 D 255.43 605.04 255.43 605.04 256.7 602.09 D 257.96 599.13 257.96 599.13 261.75 598.14 D 265.54 597.16 277.15 597.16 304.93 597.16 D 7 X 0 0 0 1 0 0 0 K V 0.2 H 2 Z 0 X N 270.39 558.91 M 261.92 559.67 248.68 562.17 246.84 550.96 D 246.43 548.47 245.32 545.13 246.79 542.62 D 251.18 535.14 246.01 526.28 249.22 519.16 D 250.52 516.28 250.51 513.28 251.4 510.41 D 252.38 507.21 254.93 504.81 256.57 503.26 D 261.36 498.73 267.49 500.34 272.35 501.04 D 275.8 501.54 278.74 504.07 282.37 502.87 D 286.2 501.6 289.51 499.02 291.41 495.7 D 292.63 493.57 294.5 491.81 296.76 490.46 D 301.43 487.68 306.28 484.24 312.01 485.79 D 315.59 486.75 318.18 489.83 319.56 492.92 D 321.34 496.91 321.48 502.2 321.22 506.84 D 321.04 509.89 323.9 511.6 326.83 512.82 D 331.25 514.65 336.52 513.9 341.21 514.99 D 346.27 516.17 352.56 514.3 356.46 517.44 D 361.55 521.53 362.03 527.99 360.89 533.07 D 359.19 540.67 353.47 547.53 349.38 553.95 D 342.68 564.44 330.85 566.61 319.64 563.49 D 312.71 561.57 306.41 564.16 300.02 565.9 D 294.1 567.51 286.84 568.95 281.72 564.89 D 278.33 562.21 274.44 559.95 269.95 558.91 D 4 X V 1 H 0 X N 154.52 572.87 154.39 572.11 154.07 571.6 154.26 570.63 153.89 570.63 153.18 569.51 152.28 569.69 151.69 569.32 153.04 566.6 155.03 564.62 158.18 563.83 158.24 563.27 159.41 563.32 161.16 562.98 161.16 563.77 162.92 563.77 162.92 564.51 160.76 564.51 160.23 564.85 160.23 570.39 160.76 570.72 165.49 569.42 165.49 567.62 167.01 567.05 167.01 564.45 165.2 564.45 165.2 563.83 166.25 563.83 166.25 561.68 159.06 561.68 158.12 562.31 158.12 561.74 153.98 562.08 151.58 563.77 150.76 562.31 151.46 560.89 154.79 559.59 156.26 557.95 158.59 551.01 157.78 550.89 158.94 550.16 160.81 549.37 160.7 548.8 160.23 548.63 158.01 548.8 157.07 548.97 156.49 548.74 155.79 548.74 155.79 550.21 153.98 555.36 150.65 555.3 150.65 550.16 153.98 549.2 145.91 549.2 149.24 550.16 149.24 555.19 145.39 555.19 144.39 556.43 144.16 557.9 144.51 558.63 144.22 560.95 143.4 561.18 142.76 562.47 142.46 567.39 142.87 568.07 144.1 568.29 144.68 567.73 145.39 564.06 145.8 565.7 146.79 568.01 148.19 569.76 149.53 570.19 150.23 571.17 149.99 571.47 149.91 572.97 150.65 574.12 151.31 574.65 152.21 574.88 152.89 574.73 154.26 573.99 154.78 573.08 81 Y V 0.2 H 0 Z N 160.38 570.3 160.73 570.47 160.73 564.76 160.38 564.93 4 Y V N 145.27 560.72 145.45 559.2 146.2 559.25 145.68 560.72 4 Y V N 90 450 0.41 0.4 146.09 548.63 G 90 450 0.41 0.4 146.09 548.63 A 90 450 0.41 0.4 153.86 548.63 G 90 450 0.41 0.4 153.86 548.63 A 158.54 561.46 167.13 561.46 167.13 559.99 165.02 559.99 165.02 548.86 161.69 548.86 162.86 549.99 164.09 549.99 164.09 560.04 159.24 560.04 10 Y V N 223.95 544.71 243.69 531.06 219.71 532.18 221.83 538.44 4 Y 2 X V 169.7 556.06 221.84 538.44 2 L 0 X V 4 H 2 Z 2 X N 3 14 Q 0 X (root) 141.19 535.32 T 3 18 Q (Network) 267.26 529.2 T 2 10 Q (setup) 205.79 548.51 T 244.12 548.19 244.79 536.21 237.87 546.01 241 547.1 4 Y V 241 547.1 M 233.51 560.85 217.38 568.79 201.29 565.38 D 195.17 564.09 189.38 561.71 183.29 562.21 D 0.5 H N 7 X 90 450 7.5 7.5 205.79 562.71 G 0 X 90 450 7.5 7.5 205.79 562.71 A 2 12 Q (1) 202.46 558.33 T J 178.78 535.28 177.79 547.21 184.95 537.61 181.87 536.44 4 Y V [1.442 4.325] 0.721 I 181.87 536.43 M 184.55 528.43 187.97 520.85 200.79 519.32 D 215.4 517.57 228.7 522.73 241.79 527.02 D N J 7 X 90 450 7.5 6.79 203.29 518.92 G 0 X 90 450 7.5 6.79 203.29 518.92 A (2) 199.96 514.67 T 2 10 Q (call proc) 183.59 502.43 T 442.22 582.42 442.09 581.66 441.77 581.15 441.96 580.18 441.59 580.18 440.88 579.06 439.98 579.24 439.39 578.86 440.74 576.15 442.73 574.17 445.89 573.38 445.94 572.81 447.11 572.87 448.87 572.53 448.87 573.32 450.62 573.32 450.62 574.06 448.46 574.06 447.93 574.4 447.93 579.93 448.46 580.27 453.19 578.97 453.19 577.17 454.71 576.6 454.71 574 452.9 574 452.9 573.38 453.95 573.38 453.95 571.23 446.76 571.23 445.83 571.85 445.83 571.29 441.68 571.63 439.28 573.32 438.46 571.85 439.17 570.44 442.5 569.14 443.96 567.5 446.3 560.55 445.48 560.44 446.64 559.71 448.52 558.91 448.4 558.35 447.93 558.18 445.71 558.35 444.77 558.52 444.19 558.29 443.49 558.29 443.49 559.76 441.68 564.9 438.35 564.85 438.35 559.71 441.68 558.74 433.61 558.74 436.94 559.71 436.94 564.73 433.09 564.73 432.09 565.98 431.86 567.45 432.21 568.18 431.92 570.5 431.1 570.72 430.46 572.02 430.17 576.94 430.58 577.62 431.8 577.84 432.39 577.28 433.09 573.6 433.5 575.24 434.49 577.56 435.89 579.31 437.23 579.74 437.93 580.71 437.7 581.02 437.62 582.52 438.35 583.67 439.01 584.2 439.91 584.43 440.59 584.28 441.96 583.54 442.48 582.62 81 Y V 0.2 H 0 Z N 448.08 579.85 448.43 580.02 448.43 574.31 448.08 574.48 4 Y V N 432.97 570.27 433.15 568.74 433.91 568.8 433.38 570.27 4 Y V N 90 450 0.41 0.4 433.79 558.18 G 90 450 0.41 0.4 433.79 558.18 A 90 450 0.41 0.4 441.56 558.18 G 90 450 0.41 0.4 441.56 558.18 A 446.24 571.01 454.83 571.01 454.83 569.54 452.72 569.54 452.72 558.41 449.39 558.41 450.56 559.54 451.79 559.54 451.79 569.59 446.94 569.59 10 Y V N 3 14 Q (leaf 1) 424.6 544.87 T 400.39 566.65 424.39 566.43 403.92 553.9 402.15 560.28 4 Y 2 X V 359.4 548.43 402.16 560.27 2 L 0 X V 4 H 2 Z 2 X N 413.52 586.76 424.4 581.71 412.5 580.23 413.01 583.49 4 Y 0 X V 343.4 566.43 M 354.55 576.14 363.47 586.09 380.11 587.26 D 391.48 588.05 402.15 585.53 413.02 583.49 D 0.5 H N 7 X 90 450 7.5 7.5 371.9 585.93 G 0 X 90 450 7.5 7.5 371.9 585.93 A 2 12 Q (3) 368.56 581.55 T 2 10 Q (setup) 363.94 569.57 T 379.82 526.43 367.96 528.14 378.92 532.97 379.37 529.7 4 Y V 415.4 548.43 M 413.57 531.37 394.88 530.97 379.39 529.7 D N 7 X 90 450 7.5 7.5 398.9 532.5 G 0 X 90 450 7.5 7.5 398.9 532.5 A 2 12 Q (4) 395.56 528.13 T 2 10 Q (connect) 386.65 516.05 T 158.28 521.62 161.54 533.14 164.88 521.65 161.58 521.63 4 Y V 244.4 521 M 242.68 496.71 217.82 487.83 197.25 487.71 D 178.19 487.59 164.22 504.01 161.59 521.63 D N 7 X 90 450 7.5 7.5 197.9 487.79 G 0 X 90 450 7.5 7.5 197.9 487.79 A 2 12 Q (6) 194.56 483.41 T 2 10 Q (connect) 179.25 472.76 T 0 F (Both SETUPs) 262.1 624.6 T (contain GCID) 262.11 614.6 T (and LIJP IEs) 264.46 604.6 T 71.44 421.14 539.44 430.14 R 7 X V 1 F 0 X (Figur) 227.06 423.48 T (e 1. Root\325) 250.77 423.48 T (s cr) 293.72 423.48 T (eation of LIJ call.) 308.81 423.48 T 314.92 597.16 348.19 574 303.42 597.16 3 L 7 X V 0.2 H 0 X N 268.68 597.16 231.19 565 280.18 597.16 3 L 7 X V 0 X N 436.53 529.34 441.43 540.29 443.07 528.41 439.8 528.88 4 Y V 359.29 515.28 M 370.33 509.99 380.42 505.73 391.43 503.38 D 413.21 498.73 433.98 508.76 439.81 528.87 D 0.5 H N 2 F (connect ACK) 383.94 486.62 T 7 X 90 450 7.5 7.5 415.18 504.07 G 0 X 90 450 7.5 7.5 415.18 504.07 A 2 12 Q (5) 411.85 499.7 T 238.05 496.23 247.86 503.14 243.21 492.08 240.63 494.15 4 Y V 152.14 528.14 M 154.51 505.77 152.19 472.93 177.86 465.07 D 199.46 458.45 224.11 464.57 233.95 484.57 D 235.77 488.27 238.18 491.3 240.63 494.15 D N 7 X 90 450 7.5 7.5 195.18 461.21 G 0 X 90 450 7.5 7.5 195.18 461.21 A (7) 191.85 456.84 T 2 10 Q (connect ACK) 168.68 444.76 T 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 72 72 540 333.31 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 221.66 304.51 M 213.2 305.27 199.95 307.77 198.11 296.56 D 197.7 294.07 196.6 290.72 198.07 288.21 D 202.45 280.74 197.29 271.88 200.5 264.76 D 201.8 261.88 201.79 258.88 202.67 256.01 D 203.66 252.8 206.21 250.4 207.84 248.85 D 212.64 244.33 218.77 245.94 223.62 246.64 D 227.08 247.13 230.01 249.67 233.65 248.46 D 237.47 247.19 240.79 244.61 242.69 241.3 D 243.91 239.17 245.77 237.41 248.03 236.06 D 252.71 233.27 257.55 229.83 263.28 231.38 D 266.86 232.35 269.46 235.42 270.84 238.52 D 272.61 242.5 272.76 247.79 272.49 252.43 D 272.32 255.49 275.17 257.2 278.1 258.41 D 282.53 260.25 287.79 259.49 292.48 260.59 D 297.55 261.76 303.84 259.9 307.74 263.03 D 312.83 267.12 313.31 273.59 312.16 278.67 D 310.46 286.26 304.75 293.13 300.65 299.54 D 293.95 310.03 282.12 312.21 270.91 309.09 D 263.99 307.16 257.68 309.76 251.3 311.49 D 245.37 313.11 238.11 314.54 232.99 310.49 D 229.6 307.8 225.71 305.55 221.23 304.51 D 4 X 0 0 0 1 0 0 0 K V 1 H 2 Z 0 X N 105.8 318.47 105.66 317.7 105.35 317.2 105.53 316.23 105.16 316.23 104.45 315.11 103.56 315.29 102.96 314.91 104.32 312.2 106.31 310.22 109.46 309.43 109.52 308.86 110.69 308.92 112.44 308.58 112.44 309.37 114.19 309.37 114.19 310.1 112.03 310.1 111.5 310.44 111.5 315.98 112.03 316.32 116.76 315.02 116.76 313.21 118.29 312.65 118.29 310.05 116.47 310.05 116.47 309.43 117.52 309.43 117.52 307.28 110.34 307.28 109.4 307.9 109.4 307.34 105.25 307.67 102.86 309.37 102.04 307.9 102.74 306.49 106.07 305.19 107.53 303.55 109.87 296.6 109.05 296.49 110.22 295.75 112.09 294.96 111.97 294.4 111.5 294.23 109.28 294.4 108.35 294.57 107.77 294.34 107.06 294.34 107.06 295.81 105.25 300.95 101.92 300.89 101.92 295.75 105.25 294.79 97.19 294.79 100.52 295.75 100.52 300.78 96.66 300.78 95.67 302.02 95.44 303.49 95.79 304.23 95.49 306.55 94.68 306.77 94.03 308.07 93.74 312.99 94.15 313.67 95.38 313.89 95.96 313.33 96.66 309.65 97.07 311.29 98.06 313.61 99.47 315.36 100.8 315.79 101.51 316.76 101.27 317.07 101.19 318.57 101.93 319.71 102.59 320.25 103.48 320.48 104.17 320.33 105.53 319.59 106.06 318.67 81 Y V 0.2 H 0 Z N 111.65 315.9 112 316.07 112 310.36 111.65 310.53 4 Y V N 96.55 306.32 96.72 304.79 97.48 304.85 96.95 306.32 4 Y V N 90 450 0.41 0.4 97.36 294.23 G 90 450 0.41 0.4 97.36 294.23 A 90 450 0.41 0.4 105.13 294.23 G 90 450 0.41 0.4 105.13 294.23 A 109.81 307.05 118.4 307.05 118.4 305.58 116.3 305.58 116.3 294.45 112.96 294.45 114.13 295.58 115.36 295.58 115.36 305.64 110.51 305.64 10 Y V N 175.23 290.31 194.96 276.66 170.99 277.77 173.11 284.04 4 Y V 120.97 301.65 173.11 284.04 2 L 4 H 2 Z N 3 14 Q (root) 92.46 280.92 T 3 18 Q (Network) 218.54 274.79 T 130.05 280.86 129.07 292.8 136.23 283.2 133.14 282.03 4 Y V 133.15 282.03 M 135.83 274.03 139.25 266.45 152.07 264.91 D 166.68 263.17 179.98 268.32 193.07 272.62 D 0.5 H N 7 X 90 450 7.5 7.5 154.57 263.8 G 0 X 90 450 7.5 7.5 154.57 263.8 A 2 12 Q (4) 151.23 259.43 T 2 10 Q (new leaf announce) 112.01 246.6 T 393.5 328.02 393.36 327.25 393.05 326.74 393.23 325.78 392.86 325.78 392.15 324.66 391.26 324.84 390.67 324.46 392.02 321.74 394.01 319.77 397.16 318.98 397.22 318.41 398.39 318.47 400.14 318.13 400.14 318.92 401.89 318.92 401.89 319.65 399.73 319.65 399.21 319.99 399.21 325.53 399.73 325.87 404.47 324.57 404.47 322.76 405.99 322.2 405.99 319.6 404.17 319.6 404.17 318.98 405.23 318.98 405.23 316.83 398.04 316.83 397.1 317.45 397.1 316.88 392.95 317.22 390.56 318.92 389.74 317.45 390.44 316.04 393.77 314.74 395.23 313.1 397.57 306.15 396.75 306.04 397.92 305.3 399.79 304.51 399.67 303.95 399.21 303.77 396.98 303.95 396.05 304.11 395.47 303.89 394.77 303.89 394.77 305.36 392.95 310.5 389.62 310.44 389.62 305.3 392.95 304.34 384.89 304.34 388.22 305.3 388.22 310.33 384.36 310.33 383.37 311.57 383.14 313.04 383.49 313.78 383.19 316.09 382.38 316.32 381.73 317.62 381.44 322.54 381.85 323.21 383.08 323.44 383.66 322.87 384.36 319.2 384.77 320.84 385.77 323.16 387.17 324.91 388.5 325.33 389.21 326.31 388.97 326.62 388.89 328.12 389.63 329.26 390.29 329.8 391.18 330.02 391.87 329.87 393.23 329.13 393.76 328.22 81 Y V 0.2 H 0 Z N 399.35 325.44 399.7 325.61 399.7 319.91 399.35 320.08 4 Y V N 384.25 315.87 384.42 314.34 385.18 314.4 384.65 315.87 4 Y V N 90 450 0.41 0.4 385.06 303.77 G 90 450 0.41 0.4 385.06 303.77 A 90 450 0.41 0.4 392.84 303.77 G 90 450 0.41 0.4 392.84 303.77 A 397.51 316.6 406.1 316.6 406.1 315.13 404 315.13 404 304 400.67 304 401.84 305.13 403.06 305.13 403.06 315.19 398.21 315.19 10 Y V N 3 14 Q (leaf 1) 375.87 290.46 T 351.66 312.24 375.66 312.02 355.19 299.49 353.43 305.87 4 Y V 310.67 294.02 353.44 305.87 2 L 4 H 2 Z N 71.31 74.6 539.31 83.6 R 7 X V 1 10 Q 0 X (Figur) 158.14 76.93 T (e 2. Leaf initiated add to LIJ call, wher) 181.85 76.93 T (e network connects leaf.) 350.28 76.93 T 391.54 211.21 391.41 210.45 391.09 209.94 391.27 208.97 390.91 208.97 390.2 207.85 389.3 208.03 388.71 207.66 390.06 204.94 392.05 202.96 395.2 202.17 395.26 201.61 396.43 201.66 398.18 201.32 398.18 202.11 399.94 202.11 399.94 202.85 397.77 202.85 397.25 203.19 397.25 208.73 397.77 209.07 402.51 207.77 402.51 205.96 404.03 205.39 404.03 202.79 402.22 202.79 402.22 202.17 403.27 202.17 403.27 200.03 396.08 200.03 395.14 200.65 395.14 200.08 390.99 200.42 388.6 202.11 387.78 200.65 388.48 199.23 391.81 197.93 393.27 196.29 395.61 189.34 394.8 189.23 395.96 188.5 397.83 187.71 397.72 187.14 397.25 186.97 395.03 187.14 394.09 187.31 393.51 187.08 392.81 187.08 392.81 188.55 390.99 193.7 387.67 193.64 387.67 188.5 390.99 187.54 382.93 187.54 386.26 188.5 386.26 193.53 382.4 193.53 381.41 194.77 381.18 196.24 381.53 196.97 381.24 199.29 380.42 199.52 379.77 200.81 379.48 205.73 379.89 206.41 381.12 206.64 381.7 206.07 382.4 202.4 382.82 204.04 383.81 206.35 385.21 208.1 386.55 208.53 387.25 209.51 387.01 209.81 386.93 211.31 387.67 212.46 388.33 212.99 389.22 213.22 389.91 213.07 391.27 212.33 391.8 211.41 81 Y V 0.2 H 0 Z N 397.39 208.64 397.74 208.81 397.74 203.1 397.39 203.27 4 Y V N 382.29 199.06 382.46 197.54 383.22 197.59 382.7 199.06 4 Y V N 90 450 0.41 0.4 383.11 186.97 G 90 450 0.41 0.4 383.11 186.97 A 90 450 0.41 0.4 390.88 186.97 G 90 450 0.41 0.4 390.88 186.97 A 395.55 199.8 404.14 199.8 404.14 198.33 402.04 198.33 402.04 187.2 398.71 187.2 399.88 188.33 401.11 188.33 401.11 198.39 396.26 198.39 10 Y V N 3 14 Q (leaf 2) 373.92 173.66 T 356.03 222.83 373.71 206.6 350.12 211 353.08 216.91 4 Y 2 X V 283.71 251.6 353.08 216.91 2 L 4 H 2 Z N 316.01 256.07 304.13 257.6 315.02 262.6 315.52 259.33 4 Y 0 X V 382.71 215.6 M 371.3 234.36 358.4 258.6 331.28 258.03 D 326.13 257.93 320.82 259.09 315.53 259.33 D 0.5 H N 7 X 90 450 7.5 7.5 348.21 253.1 G 0 X 90 450 7.5 7.5 348.21 253.1 A 2 12 Q (1) 344.88 248.72 T 2 10 Q (leaf setup request) 328.25 263.78 T 354.7 198.61 366.27 195.45 354.79 191.99 354.74 195.3 4 Y V 274.71 242.6 M 285.88 215.44 315.66 204.81 341.99 196.59 D 346.15 195.29 350.43 195.18 354.74 195.29 D N 7 X 90 450 7.5 7.5 300.21 214.1 G 0 X 90 450 7.5 7.5 300.21 214.1 A 2 12 Q (2) 296.88 209.72 T 2 10 Q (setup) 311.11 210.93 T 256.89 212.6 260.56 224.02 263.5 212.39 260.19 212.49 4 Y V 364.71 188.6 M 337.99 162.09 288.18 180.35 265.56 204.02 D 263.28 206.41 261.33 209.36 260.2 212.48 D N 7 X 90 450 7.5 7.5 291.21 187.1 G 0 X 90 450 7.5 7.5 291.21 187.1 A 2 12 Q (3) 287.88 182.72 T 2 10 Q (connect) 301.71 184.64 T 445.27 294.71 M 445.27 306.45 445.27 306.45 447.32 310.42 D 449.37 314.38 449.37 314.38 455.52 315.7 D 461.67 317.02 461.67 317.02 486.27 317.02 D 510.87 317.02 510.87 317.02 517.03 315.7 D 523.17 314.38 523.17 314.38 525.22 310.42 D 527.28 306.45 527.28 306.45 527.28 280.02 D 527.28 253.6 527.28 253.6 525.22 249.63 D 523.17 245.67 523.17 245.67 517.03 244.35 D 510.87 243.02 510.87 243.02 486.27 243.02 D 461.67 243.02 461.67 243.02 455.52 244.35 D 449.37 245.67 449.37 245.67 447.32 249.63 D 445.27 253.6 445.27 253.6 445.27 282.67 D 7 X V 0.2 H 0 X N 445.27 294.71 410.7 267.92 445.27 282.67 3 L 7 X V 0 X N (Leaf uses new) 454.23 297.45 T (message,) 455.35 287.45 T 4 F (leaf) 501.48 287.45 T (setup request) 454.79 277.45 T 2 F (,) 515.38 277.45 T (to ask to be) 460.62 267.45 T (invited into call.) 452.29 257.45 T 351.56 150.59 356.28 146.31 356.28 94.88 351.56 90.6 261.99 90.6 257.28 94.88 257.28 146.31 261.99 150.59 8 L 7 X V 0 X N 313.85 150.59 336.48 171.6 327.99 150.59 3 L 7 X V 0 X N 327.99 150.59 351.56 150.59 2 L 7 X V 0 X N 313.85 150.59 261.99 150.59 2 L 7 X V 0 X N (Standard setup,) 271.3 137.74 T (\050call proceeding\051) 269.65 127.74 T (and connect) 279.36 117.74 T (messages are used) 262.97 107.74 T (to add leaf to call.) 267.41 97.74 T 173.42 198.82 M 189.13 198.82 189.13 198.82 194.44 197.01 D 199.74 195.21 199.74 195.21 201.51 189.79 D 203.28 184.37 203.28 184.37 203.28 162.71 D 203.28 141.04 203.28 141.04 201.51 135.62 D 199.74 130.21 199.74 130.21 194.44 128.4 D 189.13 126.6 189.13 126.6 153.77 126.6 D 118.42 126.6 118.42 126.6 113.11 128.4 D 107.81 130.21 107.81 130.21 106.04 135.62 D 104.28 141.04 104.28 141.04 104.28 162.71 D 104.28 184.37 104.28 184.37 106.04 189.79 D 107.81 195.21 107.81 195.21 113.11 197.01 D 118.42 198.82 118.42 198.82 157.31 198.82 D 7 X V 0 X N 173.42 198.82 143.88 243.6 157.31 198.82 3 L 7 X V 0 X N (New message, the) 112.81 185.31 T 4 F (new leaf announce) 110.85 175.31 T 2 F (,) 194.79 175.31 T (notifies root of new) 112.25 165.31 T (leaf, its address and) 109.47 155.31 T (its network assigned) 108.92 145.31 T (endpoint reference.) 111.13 135.31 T 72 72 540 720 C 0 0 612 792 C 52 662 54 720 R 0 X 0 0 0 1 0 0 0 K V 52 334 54 344 R V FMENDPAGE %%EndPage: "3" 4 %%Page: "4" 5 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 4) 513.06 35.85 T 72 72 540 720 R 7 X V 0 X -0.06 (leaf sends a new message, the LEAF SETUP REQUEST \050LSR\051, to the network. The LEAF SETUP REQUEST con-) 72 713.33 P 0.39 (tains the GCID of the call that the leaf wishes to join, the leaf\325s address and optionally none, some or all of the call) 72 701.33 P 1.04 (parameters \050to be used for compatibility checking\051. Internally, the network uses the GCID to locate the call \050see) 72 689.33 P -0.33 (Section) 72 677.33 P -0.33 (4 for details\051, then for any call parameters specified by the leaf, the network checks to make sure that these are) 104.5 677.33 P -0.47 (identical with those of the call. If all specified parameters are identical, a SETUP message is sent to the leaf containing) 72 665.33 P 0 (all of the call parameters. The leaf then responds with a CALL PROCEEDING \050optional\051 followed by a CONNECT) 72 653.33 P 0.04 (message. Note that the SETUP/CALL PROCEEDING/CONNECT interaction abides by the existing point-to-multi-) 72 641.33 P -0.31 (point procedures, with the only exception being that the SETUP message additionally contains the GCID and the LIJP) 72 629.33 P 0.33 (information elements \050and an optional sequence number, described later in this section\051. The motivation for adding) 72 617.33 P 0.12 (the LEAF SETUP REQUEST message was to retain this backward compatibility, where all new parties are added to) 72 605.33 P -0.34 (the call by building from the call tree towards the leaf to be added. It also allows leaves to join the call without a priori) 72 593.33 P (knowledge of the call parameters.) 72 581.33 T 0.23 (After the leaf has accepted the invitation into the call by responding with a CONNECT \050and assuming notifica-) 90.86 565.33 P -0.16 (tions of leaf joins and drops have been turned on\051, the root receives a NEW LEAF ANNOUNCE \050NLA\051 message an-) 72 553.33 P -0.5 (nouncing the new leaf\325s participation. The NEW LEAF ANNOUNCE contains a network assigned endpoint reference) 72 541.33 P (for the new leaf and the address of the leaf that joined the call.) 72 529.33 T 0.28 (As an option, the leaf can include a) 90.86 513.33 P 5 F 0.28 (leaf sequence number) 236.67 513.33 P 0 F 0.28 ( in the LEAF SETUP REQUEST message so that the) 324.43 513.33 P -0.37 (LEAF SETUP REQUEST can be paired with the SETUP message response. This sequence number is placed in a new) 72 501.33 P -0.3 (information element, the Leaf Sequence Number \050LSN\051, which is copied without modification to the SETUP message) 72 489.33 P (sent in response to the LEAF SETUP REQUEST and otherwise uninterpreted by the network.) 72 477.33 T 0.59 (If a failure occurs when attempting to fulfill the LEAF SETUP REQUEST, a LEAF SETUP FAILURE \050LSF\051) 90.86 461.33 P 0.1 (message is returned to the leaf, as shown in Figure) 72 449.33 P 0.1 (3. The LEAF SETUP FAILURE contains the GCID, the LSN \050if) 277.56 449.33 P -0.04 (specified by the leaf\051 and a cause code indicating the reason for failure. Potential causes include: call parameter mis-) 72 221.33 P -0.13 (match \050if the leaf specified any of the call parameters and these were incorrect\051, nonexistent call \050where no call corre-) 72 209.33 P 0.17 (sponding to the GCID can be found\051 and insufficient network resources \050where the call cannot be extended from the) 72 197.33 P (existing call tree to the leaf\325s UNI\051.) 72 185.33 T 1 12 Q (2.2) 72 166 T (LIJ to Inactive or Active Call, Root Connects Leaf) 99 166 T 0 10 Q -0.22 (For inactive LIJ calls, the LEAF SETUP REQUEST issued by the leaf gets forwarded by the network all the way) 90.86 149.33 P -0.18 (to the intended root \050even though no call exists\051. Upon receiving the LEAF SETUP REQUEST message, the root has) 72 137.33 P 0.04 (the option of creating a new call to the leaf by issuing a SETUP message or of sending a failure code back to the leaf) 72 125.33 P -0.19 (in a LEAF SETUP FAILURE message. The network will also forward all LEAF SETUP REQUEST messages to the) 72 113.33 P -0.18 (root on any LIJ call where the root requests screening of new leaves \050see Section) 72 101.33 P -0.18 (3.2 for details on how this specifica-) 395.26 101.33 P 0.08 (tion is made\051. In this case, the root can add the leaf by issuing an ADD PARTY message or deny the join by issuing) 72 89.33 P -0.44 (a LEAF SETUP FAILURE. Similarly, if a leaf attempts to join a call that has been created without the GCID and LIJP) 72 77.33 P 72 72 540 720 C 72 232.02 540 446 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 271.87 397.64 M 263.41 398.4 250.16 400.9 248.32 389.69 D 247.91 387.2 246.81 383.86 248.28 381.35 D 252.66 373.87 247.5 365.01 250.71 357.89 D 252.01 355.01 252 352.01 252.88 349.14 D 253.87 345.94 256.42 343.54 258.05 341.99 D 262.85 337.46 268.98 339.07 273.83 339.77 D 277.29 340.27 280.22 342.8 283.86 341.6 D 287.68 340.33 291 337.75 292.9 334.43 D 294.12 332.3 295.99 330.54 298.24 329.2 D 302.92 326.41 307.76 322.97 313.49 324.52 D 317.07 325.48 319.67 328.56 321.05 331.65 D 322.82 335.64 322.97 340.93 322.7 345.57 D 322.53 348.63 325.39 350.33 328.31 351.55 D 332.74 353.38 338 352.63 342.69 353.72 D 347.76 354.9 354.05 353.03 357.95 356.17 D 363.04 360.26 363.52 366.72 362.38 371.8 D 360.68 379.4 354.96 386.26 350.86 392.68 D 344.17 403.17 332.33 405.34 321.12 402.22 D 314.2 400.3 307.89 402.89 301.51 404.63 D 295.58 406.24 288.33 407.68 283.2 403.62 D 279.81 400.94 275.92 398.68 271.44 397.64 D 4 X 0 0 0 1 0 0 0 K V 1 H 2 Z 0 X N 156.01 411.6 155.87 410.84 155.56 410.33 155.74 409.36 155.37 409.36 154.66 408.24 153.77 408.42 153.18 408.05 154.53 405.33 156.51 403.35 159.67 402.56 159.73 402 160.9 402.05 162.65 401.71 162.65 402.51 164.4 402.51 164.4 403.24 162.24 403.24 161.71 403.58 161.71 409.12 162.24 409.45 166.98 408.15 166.98 406.35 168.49 405.78 168.49 403.18 166.68 403.18 166.68 402.56 167.73 402.56 167.73 400.42 160.55 400.42 159.61 401.04 159.61 400.47 155.46 400.81 153.07 402.51 152.25 401.04 152.95 399.62 156.28 398.32 157.74 396.68 160.08 389.73 159.26 389.62 160.43 388.89 162.3 388.1 162.18 387.53 161.71 387.36 159.49 387.53 158.56 387.7 157.98 387.47 157.27 387.47 157.27 388.94 155.46 394.09 152.13 394.03 152.13 388.89 155.46 387.93 147.4 387.93 150.73 388.89 150.73 393.92 146.87 393.92 145.88 395.16 145.65 396.63 145.99 397.36 145.7 399.68 144.88 399.91 144.24 401.2 143.95 406.12 144.36 406.8 145.59 407.02 146.17 406.46 146.87 402.79 147.28 404.43 148.27 406.74 149.68 408.49 151.01 408.92 151.72 409.9 151.48 410.2 151.4 411.7 152.14 412.85 152.8 413.38 153.69 413.61 154.38 413.46 155.74 412.72 156.27 411.8 81 Y V 0.2 H 0 Z N 161.86 409.03 162.21 409.2 162.21 403.49 161.86 403.66 4 Y V N 146.76 399.45 146.93 397.93 147.69 397.98 147.16 399.45 4 Y V N 90 450 0.41 0.4 147.57 387.36 G 90 450 0.41 0.4 147.57 387.36 A 90 450 0.41 0.4 155.35 387.36 G 90 450 0.41 0.4 155.35 387.36 A 160.02 400.19 168.61 400.19 168.61 398.72 166.51 398.72 166.51 387.59 163.18 387.59 164.35 388.72 165.57 388.72 165.57 398.78 160.72 398.78 10 Y V N 225.43 383.44 245.17 369.79 221.2 370.91 223.32 377.17 4 Y V 171.18 394.79 223.32 377.17 2 L 4 H 2 Z N 3 14 Q (root) 142.67 374.05 T 3 18 Q (Network) 268.75 367.93 T 443.71 421.15 443.58 420.39 443.26 419.88 443.44 418.91 443.08 418.91 442.36 417.79 441.47 417.97 440.88 417.59 442.23 414.88 444.22 412.9 447.37 412.11 447.43 411.54 448.6 411.6 450.35 411.26 450.35 412.05 452.11 412.05 452.11 412.79 449.94 412.79 449.42 413.13 449.42 418.66 449.94 419 454.68 417.7 454.68 415.9 456.2 415.33 456.2 412.73 454.38 412.73 454.38 412.11 455.43 412.11 455.43 409.96 448.25 409.96 447.31 410.58 447.31 410.02 443.16 410.36 440.77 412.05 439.95 410.58 440.65 409.17 443.98 407.87 445.44 406.23 447.78 399.28 446.96 399.17 448.13 398.43 450 397.64 449.89 397.08 449.42 396.91 447.2 397.08 446.26 397.25 445.68 397.02 444.98 397.02 444.98 398.49 443.16 403.63 439.83 403.58 439.83 398.43 443.16 397.47 435.1 397.47 438.43 398.43 438.43 403.46 434.57 403.46 433.58 404.71 433.35 406.18 433.7 406.91 433.4 409.23 432.59 409.45 431.94 410.75 431.65 415.67 432.06 416.35 433.29 416.57 433.87 416.01 434.57 412.33 434.98 413.97 435.98 416.29 437.38 418.04 438.71 418.47 439.42 419.45 439.18 419.75 439.1 421.25 439.84 422.4 440.5 422.93 441.39 423.16 442.08 423.01 443.44 422.27 443.97 421.35 81 Y V 0.2 H 0 Z N 449.56 418.58 449.91 418.75 449.91 413.04 449.56 413.21 4 Y V N 434.46 409 434.63 407.48 435.39 407.53 434.86 409 4 Y V N 90 450 0.41 0.4 435.27 396.91 G 90 450 0.41 0.4 435.27 396.91 A 90 450 0.41 0.4 443.05 396.91 G 90 450 0.41 0.4 443.05 396.91 A 447.72 409.74 456.31 409.74 456.31 408.27 454.21 408.27 454.21 397.14 450.88 397.14 452.05 398.27 453.27 398.27 453.27 408.32 448.42 408.32 10 Y V N 3 14 Q (leaf 1) 426.08 383.6 T 401.87 405.38 425.87 405.16 405.4 392.63 403.64 399 4 Y V 360.89 387.16 403.65 399 2 L 4 H 2 Z N 441.75 304.35 441.62 303.58 441.3 303.08 441.48 302.11 441.12 302.11 440.41 300.99 439.51 301.17 438.92 300.79 440.27 298.08 442.26 296.1 445.41 295.31 445.47 294.74 446.64 294.8 448.39 294.46 448.39 295.25 450.15 295.25 450.15 295.98 447.98 295.98 447.46 296.32 447.46 301.86 447.98 302.2 452.72 300.9 452.72 299.09 454.24 298.53 454.24 295.93 452.43 295.93 452.43 295.31 453.48 295.31 453.48 293.16 446.29 293.16 445.35 293.78 445.35 293.21 441.21 293.55 438.81 295.25 437.99 293.78 438.69 292.37 442.02 291.07 443.48 289.43 445.82 282.48 445.01 282.37 446.17 281.63 448.04 280.84 447.93 280.28 447.46 280.11 445.24 280.28 444.3 280.45 443.72 280.22 443.02 280.22 443.02 281.69 441.21 286.83 437.88 286.77 437.88 281.63 441.21 280.67 433.14 280.67 436.47 281.63 436.47 286.66 432.61 286.66 431.62 287.9 431.39 289.37 431.74 290.11 431.45 292.42 430.63 292.65 429.98 293.95 429.69 298.87 430.1 299.54 431.33 299.77 431.91 299.2 432.61 295.53 433.02 297.17 434.02 299.49 435.42 301.24 436.76 301.67 437.46 302.64 437.22 302.95 437.14 304.45 437.88 305.59 438.54 306.13 439.43 306.36 440.12 306.2 441.48 305.46 442.01 304.55 81 Y V 0.2 H 0 Z N 447.61 301.77 447.95 301.95 447.95 296.24 447.61 296.41 4 Y V N 432.5 292.2 432.67 290.67 433.43 290.73 432.91 292.2 4 Y V N 90 450 0.41 0.4 433.32 280.1 G 90 450 0.41 0.4 433.32 280.1 A 90 450 0.41 0.4 441.09 280.1 G 90 450 0.41 0.4 441.09 280.1 A 445.76 292.93 454.36 292.93 454.36 291.46 452.25 291.46 452.25 280.33 448.92 280.33 450.09 281.46 451.32 281.46 451.32 291.52 446.47 291.52 10 Y V N (leaf 2) 424.13 266.8 T J 406.24 315.97 423.92 299.73 400.33 304.13 403.28 310.05 4 Y 2 X V J 333.92 344.73 403.29 310.05 2 L J 333.92 344.73 335.71 343.84 2 L 4 H 2 Z N [3.678 9.194] 3.678 I 335.71 343.84 401.5 310.94 2 L N J 401.5 310.94 403.29 310.05 2 L N J 366.22 349.21 354.34 350.73 365.22 355.73 365.72 352.47 4 Y 0 X V 432.92 308.73 M 421.51 327.49 408.61 351.73 381.49 351.17 D 376.35 351.06 371.03 352.22 365.74 352.46 D 0.5 H N 7 X 90 450 7.5 7.5 398.42 346.23 G 0 X 90 450 7.5 7.5 398.42 346.23 A 2 12 Q (1) 395.09 341.86 T 2 10 Q (leaf setup request) 378.46 356.92 T 404.91 291.74 416.48 288.59 404.99 285.13 404.95 288.44 4 Y V 324.92 335.73 M 336.09 308.57 365.87 297.95 392.2 289.73 D 396.36 288.43 400.64 288.31 404.95 288.42 D N 7 X 90 450 7.5 7.5 354.71 302.94 G 0 X 90 450 7.5 7.5 354.71 302.94 A 2 12 Q (2) 351.37 298.57 T 2 10 Q (leaf setup failure) 304.17 284.35 T 70.6 244.45 538.6 253.45 R 7 X V 1 F 0 X (Figur) 193.71 246.78 T (e 3. Unsuccessful leaf initiated add to LIJ call.) 217.42 246.78 T 72 72 540 720 C 0 0 612 792 C 52 698 54 708 R 0 X 0 0 0 1 0 0 0 K V 52 526 54 560 R V 52 74 54 174 R V J FMENDPAGE %%EndPage: "4" 5 %%Page: "5" 6 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 5) 513.06 35.85 T 72 72 540 720 R 7 X V 0 X -0.32 (information elements \050that is, a call that has not been advertized to the network as being LIJ capable\051, the network will) 72 713.33 P 0.24 (likewise forward the LEAF SETUP REQUEST message to the root. As above, the root has the option of issuing an) 72 701.33 P (ADD PARTY message to add the requesting leaf or of issuing a LEAF SETUP FAILURE to deny the join.) 72 689.33 T -0.05 (Figure) 90.86 673.33 P -0.05 (4 shows the interactions that occur when leaf 2 sends a LEAF SETUP REQUEST to join an inactive call.) 119.47 673.33 P 0.31 (In this case, the LEAF SETUP REQUEST triggers the normal steps that occur when the root creates a call to a new) 72 445.33 P 0.56 (party independently. The only slight modification is that the root is required to echo the leaf\325s LSN in the SETUP) 72 433.33 P 0.42 (message, if one was specified by the leaf. Additionally, if the root wishes to make the newly created call generally) 72 421.33 P -0.26 (available for network supported LIJ, it must include the GCID and LIJP information elements in the SETUP message.) 72 409.33 P 0.48 (If the root chooses not to add the requesting leaf, it issues a LEAF SETUP FAILURE message with an appropriate) 72 397.33 P (cause code \050such as access denied\051, along with the LSN) 72 385.33 T 5 F (,) 294.72 385.33 T 0 F ( if one was specified.) 297.22 385.33 T -0.31 (Figure) 90.86 369.33 P -0.31 (5 shows the interactions that occur when the root requests screening of all LEAF SETUP REQUEST mes-) 119.47 369.33 P 0.19 (sages \050or, alternatively, if the root does not formally advertize the call as being LIJ capable\051. In this case, the LEAF) 72 357.33 P 0.42 (SETUP REQUEST triggers the normal steps that occur when the root adds a leaf to an ongoing point-to-multipoint) 72 117.33 P (call. As above, the only slight modification is echo of the leaf\325s LSN in the ADD PARTY message, if one was spec-) 72 105.33 T 0.66 (ified by the leaf. Once again, the root could refuse to add the requesting leaf by responding with a LEAF SETUP) 72 93.33 P (FAILURE message.) 72 81.33 T 72 72 540 720 C 72 459.59 540 670 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 406.16 514.26 417.74 511.11 406.25 507.65 406.2 510.96 4 Y 0 X 0 0 0 1 0 0 0 K V 326.17 558.25 M 337.34 531.09 367.12 520.47 393.45 512.25 D 397.61 510.95 401.89 510.83 406.2 510.95 D 0.5 H 2 Z N 7 X 90 450 7.5 7.5 351.67 529.75 G 0 X 90 450 7.5 7.5 351.67 529.75 A 2 12 Q (5) 348.34 525.38 T 2 10 Q (setup) 362.57 526.58 T 308.34 528.26 312.02 539.68 314.95 528.04 311.65 528.15 4 Y V 416.17 504.25 M 389.45 477.75 339.64 496 317.03 519.68 D 314.74 522.07 312.79 525.01 311.66 528.13 D N 7 X 90 450 7.5 7.5 342.67 502.75 G 0 X 90 450 7.5 7.5 342.67 502.75 A 2 12 Q (6) 339.34 498.38 T 2 10 Q (connect) 353.17 500.3 T 271.87 621.65 M 263.41 622.4 250.16 624.91 248.32 613.69 D 247.91 611.2 246.81 607.86 248.28 605.35 D 252.66 597.87 247.5 589.01 250.71 581.89 D 252.01 579.01 252 576.01 252.88 573.14 D 253.87 569.94 256.42 567.54 258.05 565.99 D 262.85 561.46 268.98 563.07 273.83 563.77 D 277.29 564.27 280.22 566.8 283.86 565.59 D 287.68 564.33 291 561.75 292.9 558.43 D 294.12 556.3 295.99 554.54 298.24 553.2 D 302.92 550.41 307.76 546.97 313.49 548.52 D 317.07 549.48 319.67 552.56 321.05 555.65 D 322.82 559.64 322.97 564.93 322.7 569.57 D 322.53 572.62 325.39 574.33 328.31 575.55 D 332.74 577.38 338 576.63 342.69 577.72 D 347.76 578.9 354.05 577.03 357.95 580.17 D 363.04 584.26 363.52 590.72 362.38 595.8 D 360.68 603.4 354.96 610.26 350.86 616.68 D 344.17 627.17 332.33 629.34 321.12 626.22 D 314.2 624.3 307.89 626.89 301.51 628.63 D 295.58 630.24 288.33 631.68 283.2 627.62 D 279.81 624.94 275.92 622.68 271.44 621.65 D 4 X V 1 H 0 X N 156.01 635.6 155.87 634.84 155.56 634.33 155.74 633.36 155.37 633.36 154.66 632.24 153.77 632.42 153.18 632.05 154.53 629.33 156.51 627.35 159.67 626.56 159.73 625.99 160.9 626.05 162.65 625.71 162.65 626.5 164.4 626.5 164.4 627.24 162.24 627.24 161.71 627.58 161.71 633.12 162.24 633.46 166.98 632.16 166.98 630.35 168.49 629.78 168.49 627.18 166.68 627.18 166.68 626.56 167.73 626.56 167.73 624.41 160.55 624.41 159.61 625.04 159.61 624.47 155.46 624.81 153.07 626.5 152.25 625.04 152.95 623.62 156.28 622.32 157.74 620.68 160.08 613.73 159.26 613.62 160.43 612.89 162.3 612.1 162.18 611.53 161.71 611.36 159.49 611.53 158.56 611.7 157.98 611.47 157.27 611.47 157.27 612.94 155.46 618.09 152.13 618.03 152.13 612.89 155.46 611.93 147.4 611.93 150.73 612.89 150.73 617.92 146.87 617.92 145.88 619.16 145.65 620.63 145.99 621.36 145.7 623.68 144.88 623.91 144.24 625.2 143.95 630.12 144.36 630.8 145.59 631.02 146.17 630.46 146.87 626.79 147.28 628.43 148.27 630.74 149.68 632.49 151.01 632.92 151.72 633.9 151.48 634.2 151.4 635.7 152.14 636.85 152.8 637.38 153.69 637.61 154.38 637.46 155.74 636.72 156.27 635.8 81 Y V 0.2 H 0 Z N 161.86 633.03 162.21 633.2 162.21 627.49 161.86 627.66 4 Y V N 146.76 623.45 146.93 621.93 147.69 621.98 147.16 623.45 4 Y V N 90 450 0.41 0.4 147.57 611.36 G 90 450 0.41 0.4 147.57 611.36 A 90 450 0.41 0.4 155.35 611.36 G 90 450 0.41 0.4 155.35 611.36 A 160.02 624.19 168.61 624.19 168.61 622.72 166.51 622.72 166.51 611.59 163.18 611.59 164.35 612.72 165.57 612.72 165.57 622.78 160.72 622.78 10 Y V N 225.43 607.44 245.17 593.79 221.2 594.91 223.32 601.17 4 Y V 171.18 618.79 223.32 601.17 2 L 4 H 2 Z N 3 14 Q (root) 142.67 598.05 T 3 18 Q (Network) 268.75 591.93 T 443.71 645.15 443.58 644.39 443.26 643.88 443.44 642.91 443.08 642.91 442.36 641.79 441.47 641.97 440.88 641.59 442.23 638.88 444.22 636.9 447.37 636.11 447.43 635.54 448.6 635.6 450.35 635.26 450.35 636.05 452.11 636.05 452.11 636.79 449.94 636.79 449.42 637.13 449.42 642.66 449.94 643 454.68 641.7 454.68 639.9 456.2 639.33 456.2 636.73 454.38 636.73 454.38 636.11 455.43 636.11 455.43 633.96 448.25 633.96 447.31 634.59 447.31 634.02 443.16 634.36 440.77 636.05 439.95 634.59 440.65 633.17 443.98 631.87 445.44 630.23 447.78 623.28 446.96 623.17 448.13 622.43 450 621.64 449.89 621.08 449.42 620.91 447.2 621.08 446.26 621.25 445.68 621.02 444.98 621.02 444.98 622.49 443.16 627.63 439.83 627.58 439.83 622.43 443.16 621.47 435.1 621.47 438.43 622.43 438.43 627.46 434.57 627.46 433.58 628.71 433.35 630.18 433.7 630.91 433.4 633.23 432.59 633.45 431.94 634.75 431.65 639.67 432.06 640.35 433.29 640.57 433.87 640.01 434.57 636.34 434.98 637.97 435.98 640.29 437.38 642.04 438.71 642.47 439.42 643.45 439.18 643.75 439.1 645.25 439.84 646.4 440.5 646.93 441.39 647.16 442.08 647.01 443.44 646.27 443.97 645.35 81 Y V 0.2 H 0 Z N 449.56 642.58 449.91 642.75 449.91 637.04 449.56 637.21 4 Y V N 434.46 633 434.63 631.47 435.39 631.53 434.86 633 4 Y V N 90 450 0.41 0.4 435.27 620.91 G 90 450 0.41 0.4 435.27 620.91 A 90 450 0.41 0.4 443.05 620.91 G 90 450 0.41 0.4 443.05 620.91 A 447.72 633.74 456.31 633.74 456.31 632.27 454.21 632.27 454.21 621.14 450.88 621.14 452.05 622.27 453.27 622.27 453.27 632.32 448.42 632.32 10 Y V N 3 14 Q (leaf 1) 426.08 607.6 T 441.75 528.35 441.62 527.58 441.3 527.08 441.48 526.11 441.12 526.11 440.41 524.99 439.51 525.17 438.92 524.79 440.27 522.07 442.26 520.1 445.41 519.31 445.47 518.74 446.64 518.8 448.39 518.46 448.39 519.25 450.15 519.25 450.15 519.98 447.98 519.98 447.46 520.32 447.46 525.86 447.98 526.2 452.72 524.9 452.72 523.09 454.24 522.53 454.24 519.93 452.43 519.93 452.43 519.31 453.48 519.31 453.48 517.16 446.29 517.16 445.35 517.78 445.35 517.21 441.21 517.55 438.81 519.25 437.99 517.78 438.69 516.37 442.02 515.07 443.48 513.43 445.82 506.48 445.01 506.36 446.17 505.63 448.04 504.84 447.93 504.28 447.46 504.11 445.24 504.28 444.3 504.45 443.72 504.22 443.02 504.22 443.02 505.69 441.21 510.83 437.88 510.77 437.88 505.63 441.21 504.67 433.14 504.67 436.47 505.63 436.47 510.66 432.61 510.66 431.62 511.9 431.39 513.37 431.74 514.11 431.45 516.42 430.63 516.65 429.98 517.95 429.69 522.86 430.1 523.54 431.33 523.77 431.91 523.2 432.61 519.53 433.02 521.17 434.02 523.49 435.42 525.24 436.76 525.67 437.46 526.64 437.22 526.95 437.14 528.45 437.88 529.59 438.54 530.13 439.43 530.35 440.12 530.2 441.48 529.46 442.01 528.55 81 Y V N 447.61 525.78 447.95 525.94 447.95 520.24 447.61 520.41 4 Y V N 432.5 516.2 432.67 514.67 433.43 514.73 432.91 516.2 4 Y V N 90 450 0.41 0.4 433.32 504.1 G 90 450 0.41 0.4 433.32 504.1 A 90 450 0.41 0.4 441.09 504.1 G 90 450 0.41 0.4 441.09 504.1 A 445.76 516.93 454.36 516.93 454.36 515.46 452.25 515.46 452.25 504.33 448.92 504.33 450.09 505.46 451.32 505.46 451.32 515.52 446.47 515.52 10 Y V N (leaf 2) 424.13 490.8 T 406.24 539.97 423.92 523.73 400.33 528.13 403.28 534.05 4 Y 2 X V 333.92 568.73 403.29 534.05 2 L 4 H 2 Z N 366.22 573.21 354.34 574.73 365.22 579.73 365.72 576.47 4 Y 0 X V 432.92 532.73 M 421.51 551.49 408.61 575.73 381.49 575.17 D 376.35 575.06 371.03 576.22 365.74 576.46 D 0.5 H N 7 X 90 450 7.5 7.5 398.42 570.23 G 0 X 90 450 7.5 7.5 398.42 570.23 A 2 12 Q (1) 395.09 565.86 T 2 10 Q (leaf setup request) 378.46 580.92 T 70.6 468.45 538.6 477.45 R 7 X V 1 F 0 X (Figur) 147.24 470.78 T (e 4. Leaf initiated add to inactive LIJ call, wher) 170.95 470.78 T (e r) 377.71 470.78 T (oot connects leaf.) 388.91 470.78 T 184.84 629.82 172.86 630.43 183.34 636.26 184.09 633.04 4 Y V 245.32 604.16 M 246.49 627.57 230.71 648.29 201.41 639.71 D 197.68 638.62 190.59 635.39 184.1 633.04 D N 7 X 90 450 7.5 7.5 221.42 642.23 G 0 X 90 450 7.5 7.5 221.42 642.23 A 2 12 Q (2) 218.09 637.86 T 2 10 Q (leaf setup request) 182.18 653.63 T (setup) 203.22 611.55 T 241.54 611.23 242.22 599.25 235.3 609.05 238.42 610.14 4 Y V 238.43 610.14 M 230.94 623.89 214.81 631.83 198.72 628.42 D 192.6 627.13 186.8 624.75 180.72 625.25 D N 7 X 90 450 7.5 7.5 203.22 625.75 G 0 X 90 450 7.5 7.5 203.22 625.75 A 2 12 Q (3) 199.88 621.37 T J 176.21 598.31 175.22 610.25 182.38 600.65 179.29 599.48 4 Y V [1.442 4.325] 0.721 I 179.3 599.47 M 181.98 591.47 185.4 583.89 198.22 582.36 D 212.83 580.61 226.13 585.77 239.22 590.06 D N J 7 X 90 450 7.5 6.79 200.72 581.96 G 0 X 90 450 7.5 6.79 200.72 581.96 A (4) 197.38 577.71 T 2 10 Q (call proc) 181.02 565.47 T 155.71 584.66 158.96 596.18 162.31 584.68 159.01 584.67 4 Y V 241.82 584.04 M 240.11 559.75 215.24 550.87 194.68 550.75 D 175.62 550.63 161.65 567.05 159.01 584.67 D N 7 X 90 450 7.5 7.5 195.32 550.83 G 0 X 90 450 7.5 7.5 195.32 550.83 A 2 12 Q (7) 191.99 546.45 T 2 10 Q (connect) 176.68 535.8 T (\050not in call\051) 464.14 622.87 T 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 72 132.87 540 354 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 410.44 184.96 422.02 181.81 410.53 178.35 410.49 181.66 4 Y 0 X 0 0 0 1 0 0 0 K V 330.46 228.95 M 341.63 201.79 371.41 191.17 397.74 182.95 D 401.9 181.65 406.18 181.53 410.49 181.64 D 0.5 H 2 Z N 7 X 90 450 7.5 7.5 355.96 200.45 G 0 X 90 450 7.5 7.5 355.96 200.45 A 2 12 Q (4) 352.62 196.08 T 2 10 Q (setup) 366.86 197.28 T 312.63 198.96 316.31 210.38 319.24 198.74 315.93 198.85 4 Y V 420.46 174.95 M 393.74 148.45 343.93 166.7 321.31 190.38 D 319.03 192.77 317.08 195.71 315.95 198.83 D N 7 X 90 450 7.5 7.5 346.96 173.45 G 0 X 90 450 7.5 7.5 346.96 173.45 A 2 12 Q (5) 343.62 169.08 T 2 10 Q (connect) 357.46 171 T 276.16 292.34 M 267.7 293.1 254.45 295.6 252.61 284.39 D 252.2 281.9 251.1 278.56 252.57 276.04 D 256.95 268.57 251.79 259.71 254.99 252.59 D 256.29 249.71 256.28 246.71 257.17 243.84 D 258.16 240.64 260.7 238.23 262.34 236.69 D 267.13 232.16 273.27 233.77 278.12 234.47 D 281.58 234.97 284.51 237.5 288.14 236.29 D 291.97 235.03 295.29 232.45 297.18 229.13 D 298.4 227 300.27 225.24 302.53 223.9 D 307.2 221.11 312.05 217.67 317.78 219.22 D 321.36 220.18 323.96 223.26 325.33 226.35 D 327.11 230.34 327.25 235.63 326.99 240.27 D 326.81 243.33 329.67 245.03 332.6 246.24 D 337.02 248.08 342.29 247.33 346.98 248.42 D 352.04 249.59 358.33 247.73 362.23 250.86 D 367.33 254.96 367.8 261.42 366.66 266.5 D 364.96 274.1 359.24 280.96 355.15 287.38 D 348.45 297.87 336.62 300.04 325.41 296.92 D 318.49 295 312.18 297.59 305.8 299.33 D 299.87 300.94 292.61 302.38 287.49 298.32 D 284.1 295.64 280.21 293.38 275.72 292.34 D 4 X V 1 H 0 X N 160.29 306.3 160.16 305.54 159.84 305.03 160.03 304.06 159.66 304.06 158.95 302.94 158.05 303.12 157.46 302.74 158.81 300.03 160.8 298.05 163.96 297.26 164.01 296.7 165.18 296.75 166.94 296.41 166.94 297.2 168.69 297.2 168.69 297.94 166.53 297.94 166 298.28 166 303.82 166.53 304.15 171.26 302.85 171.26 301.05 172.78 300.48 172.78 297.88 170.97 297.88 170.97 297.26 172.02 297.26 172.02 295.11 164.83 295.11 163.9 295.74 163.9 295.17 159.75 295.51 157.35 297.2 156.54 295.74 157.24 294.32 160.57 293.02 162.03 291.38 164.37 284.43 163.55 284.32 164.71 283.59 166.59 282.8 166.47 282.23 166 282.06 163.78 282.23 162.85 282.4 162.26 282.17 161.56 282.17 161.56 283.64 159.75 288.79 156.42 288.73 156.42 283.59 159.75 282.62 151.68 282.62 155.01 283.59 155.01 288.61 151.16 288.61 150.16 289.86 149.93 291.33 150.28 292.06 149.99 294.38 149.17 294.61 148.53 295.9 148.24 300.82 148.65 301.5 149.87 301.72 150.46 301.16 151.16 297.49 151.57 299.12 152.56 301.44 153.96 303.19 155.3 303.62 156 304.6 155.77 304.9 155.69 306.4 156.42 307.55 157.08 308.08 157.98 308.31 158.66 308.16 160.03 307.42 160.55 306.5 81 Y V 0.2 H 0 Z N 166.15 303.73 166.5 303.9 166.5 298.19 166.15 298.36 4 Y V N 151.04 294.15 151.22 292.63 151.98 292.68 151.45 294.15 4 Y V N 90 450 0.41 0.4 151.86 282.06 G 90 450 0.41 0.4 151.86 282.06 A 90 450 0.41 0.4 159.63 282.06 G 90 450 0.41 0.4 159.63 282.06 A 164.31 294.89 172.9 294.89 172.9 293.42 170.79 293.42 170.79 282.29 167.46 282.29 168.63 283.42 169.86 283.42 169.86 293.48 165.01 293.48 10 Y V N 229.72 278.14 249.46 264.49 225.49 265.61 227.6 271.87 4 Y V 175.47 289.49 227.61 271.87 2 L 4 H 2 Z N 3 14 Q (root) 146.96 268.75 T 3 18 Q (Network) 273.04 262.62 T 447.99 315.85 447.86 315.09 447.55 314.58 447.73 313.61 447.36 313.61 446.65 312.49 445.76 312.67 445.16 312.29 446.52 309.58 448.5 307.6 451.66 306.81 451.72 306.24 452.88 306.3 454.64 305.96 454.64 306.75 456.39 306.75 456.39 307.49 454.23 307.49 453.7 307.83 453.7 313.36 454.23 313.7 458.96 312.4 458.96 310.6 460.48 310.03 460.48 307.43 458.67 307.43 458.67 306.81 459.72 306.81 459.72 304.66 452.53 304.66 451.6 305.28 451.6 304.72 447.45 305.06 445.05 306.75 444.24 305.28 444.94 303.87 448.27 302.57 449.73 300.93 452.07 293.98 451.25 293.87 452.42 293.13 454.29 292.34 454.17 291.78 453.7 291.61 451.48 291.78 450.55 291.95 449.96 291.72 449.26 291.72 449.26 293.19 447.45 298.33 444.12 298.28 444.12 293.13 447.45 292.17 439.39 292.17 442.72 293.13 442.72 298.16 438.86 298.16 437.87 299.41 437.63 300.88 437.98 301.61 437.69 303.93 436.87 304.15 436.23 305.45 435.94 310.37 436.35 311.05 437.57 311.27 438.16 310.71 438.86 307.03 439.27 308.67 440.26 310.99 441.67 312.74 443 313.17 443.7 314.14 443.47 314.45 443.39 315.95 444.12 317.1 444.78 317.63 445.68 317.86 446.36 317.71 447.73 316.97 448.26 316.05 81 Y V 0.2 H 0 Z N 453.85 313.28 454.2 313.45 454.2 307.74 453.85 307.91 4 Y V N 438.74 303.7 438.92 302.17 439.68 302.23 439.15 303.7 4 Y V N 90 450 0.41 0.4 439.56 291.61 G 90 450 0.41 0.4 439.56 291.61 A 90 450 0.41 0.4 447.33 291.61 G 90 450 0.41 0.4 447.33 291.61 A 452.01 304.44 460.6 304.44 460.6 302.97 458.49 302.97 458.49 291.83 455.16 291.83 456.33 292.96 457.56 292.96 457.56 303.02 452.71 303.02 10 Y V N 3 14 Q (leaf 1) 430.37 278.3 T 446.04 199.05 445.9 198.28 445.59 197.77 445.77 196.81 445.4 196.81 444.69 195.69 443.8 195.87 443.2 195.49 444.56 192.77 446.54 190.8 449.7 190.01 449.76 189.44 450.92 189.5 452.68 189.16 452.68 189.95 454.43 189.95 454.43 190.68 452.27 190.68 451.74 191.02 451.74 196.56 452.27 196.9 457 195.6 457 193.79 458.52 193.22 458.52 190.63 456.71 190.63 456.71 190.01 457.76 190.01 457.76 187.86 450.58 187.86 449.64 188.48 449.64 187.91 445.49 188.25 443.1 189.95 442.28 188.48 442.98 187.07 446.31 185.77 447.77 184.13 450.11 177.18 449.29 177.07 450.46 176.33 452.33 175.54 452.21 174.97 451.74 174.81 449.52 174.97 448.59 175.15 448.01 174.92 447.3 174.92 447.3 176.39 445.49 181.53 442.16 181.47 442.16 176.33 445.49 175.37 437.43 175.37 440.76 176.33 440.76 181.36 436.9 181.36 435.91 182.6 435.67 184.07 436.02 184.81 435.73 187.12 434.91 187.35 434.27 188.65 433.98 193.57 434.39 194.24 435.62 194.47 436.2 193.9 436.9 190.23 437.31 191.87 438.3 194.19 439.71 195.94 441.04 196.36 441.75 197.34 441.51 197.65 441.43 199.15 442.17 200.29 442.83 200.83 443.72 201.05 444.4 200.9 445.77 200.16 446.3 199.25 81 Y V N 451.89 196.47 452.24 196.64 452.24 190.94 451.89 191.11 4 Y V N 436.79 186.9 436.96 185.37 437.72 185.43 437.19 186.9 4 Y V N 90 450 0.41 0.4 437.6 174.8 G 90 450 0.41 0.4 437.6 174.8 A 90 450 0.41 0.4 445.37 174.8 G 90 450 0.41 0.4 445.37 174.8 A 450.05 187.63 458.64 187.63 458.64 186.16 456.54 186.16 456.54 175.03 453.2 175.03 454.37 176.16 455.6 176.16 455.6 186.22 450.75 186.22 10 Y V N (leaf 2) 428.41 161.49 T 410.53 210.66 428.2 194.43 404.61 198.83 407.57 204.75 4 Y 2 X V 338.21 239.43 407.58 204.75 2 L 4 H 2 Z N 370.5 243.91 358.62 245.43 369.51 250.43 370 247.17 4 Y 0 X V 437.21 203.43 M 425.8 222.19 412.9 246.43 385.77 245.87 D 380.63 245.76 375.32 246.92 370.03 247.16 D 0.5 H N 7 X 90 450 7.5 7.5 402.71 240.93 G 0 X 90 450 7.5 7.5 402.71 240.93 A 2 12 Q (1) 399.37 236.56 T 2 10 Q (leaf setup request) 382.75 251.62 T 189.12 300.52 177.14 301.13 187.63 306.96 188.38 303.74 4 Y V 270.71 296.98 M 280.4 331.97 234.99 318.98 205.69 310.41 D 201.97 309.32 194.87 306.09 188.38 303.74 D N 7 X 90 450 7.5 7.5 234.28 319.36 G 0 X 90 450 7.5 7.5 234.28 319.36 A 2 12 Q (2) 230.94 314.98 T 2 10 Q (leaf setup request) 195.03 330.76 T (add party) 220.36 299.4 T 245.83 281.93 246.5 269.95 239.58 279.75 242.71 280.84 4 Y V 242.71 280.84 M 235.22 294.59 219.09 302.52 203.01 299.12 D 196.89 297.83 191.09 295.45 185.01 295.95 D N 7 X 90 450 7.5 7.5 211.79 296.45 G 0 X 90 450 7.5 7.5 211.79 296.45 A 2 12 Q (3) 208.46 292.07 T 180.49 269.01 179.51 280.95 186.67 271.35 183.58 270.18 4 Y V 183.59 270.17 M 186.26 262.17 189.68 254.59 202.51 253.06 D 217.12 251.31 230.42 256.47 243.51 260.76 D N 7 X 90 450 7.5 6.79 205.01 252.66 G 0 X 90 450 7.5 6.79 205.01 252.66 A (6) 201.67 248.41 T 2 10 Q (add party ACK) 172.45 236.17 T 406.63 300.21 430.63 299.99 410.16 287.46 408.4 293.83 4 Y V 365.64 281.99 408.41 293.83 2 L 4 H N 72.17 139.14 540.17 148.14 R 7 X V 1 F 0 X (Figur) 152.98 141.48 T (e 5. Leaf initiated add to active LIJ call, wher) 176.69 141.48 T (e r) 375.11 141.48 T (oot connects leaf.) 386.31 141.48 T 72 72 540 720 C 0 0 612 792 C 52 78 54 720 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "5" 6 %%Page: "6" 7 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 6) 513.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (3) 72 712 T (Summary of Information Element and Message Changes) 90 712 T 0 10 Q -0.4 (In this section, we summarize the information element and message additions and changes required to the phase) 90.86 695.33 P -0.4 (1) 535 695.33 P -0.39 (version of the UNI signalling protocol so that LIJ calls can be supported. The) 72 683.33 P 5 F -0.39 (new) 380.49 683.33 P 0 F -0.39 ( information elements and messages) 396.6 683.33 P (are summarized below:) 72 671.33 T (\245) 90 655.33 T 0.07 (Global Call Identifier \050GCID\051 information elements, which are used to uniquely label LIJ calls within the net-) 99.21 655.33 P (work:) 99 643.33 T (\320) 99 627.33 T 0.28 (Root Call Identifier \050RCID\051 information element, which holds the identifier assigned to the call by the root) 108 627.33 P (\050and unique at the root\325s UNI\051,) 108 615.33 T (\320) 99 599.33 T -0.38 (Root Number \050RN\051 information element, which holds the root\325s address \050analogous to the Called Party Num-) 108 599.33 P (ber information element\051,) 108 587.33 T (\320) 99 571.33 T -0.35 (Root Subaddress \050RS\051 information element, which holds the root\325s subaddress \050analogous to the Called Party) 108 571.33 P (Subaddress information element\051,) 108 559.33 T (\245) 90 543.33 T 0 (Leaf Initiated Join Parameters \050LIJP\051 information element, which allows the root to specify options associated) 99.21 543.33 P (with the call,) 99 531.33 T (\245) 90 515.33 T 0.87 (Leaf Sequence Number \050LSN\051 information element, which is used by the leaf to match LEAF SETUP RE-) 99.21 515.33 P (QUESTs to SETUP and LEAF SETUP FAILURE replies from the network,) 99 503.33 T (\245) 90 487.33 T (LEAF SETUP REQUEST \050LSR\051 message, which is used by a leaf to request connection into a call,) 99.21 487.33 T (\245) 90 471.33 T 0.19 (LEAF SETUP FAILURE \050LSF\051 message, which is used by the network to indicate a failure to add the leaf to) 99.21 471.33 P (the call \050analogous to a RELEASE COMPLETE message\051,) 99 459.33 T (\245) 90 443.33 T 0.44 (New Leaf Number information element, which appears in the LEAF SETUP REQUEST message to identify) 99.21 443.33 P (the party to be added \050analogous to the Calling Party Number information element\051,) 99 431.33 T (\245) 90 415.33 T 0.8 (New Leaf Subaddress information element, which appears in the LEAF SETUP REQUEST message and is) 99.21 415.33 P -0.42 (used when traversing public networks that do not support private ATM network addresses \050analogous to the use) 99 403.33 P (of the Calling Party Subaddress information element\051,) 99 391.33 T (\245) 90 375.33 T -0.12 (NEW LEAF ANNOUNCE message, which is used by the network to announce that a new leaf has been added) 99.21 375.33 P (\050by the network\051 to an ongoing call.) 99 363.33 T (The) 72 347.33 T 5 F (modified) 90.05 347.33 T 0 F ( information element and messages are summarized below:) 125.05 347.33 T (\245) 90 331.33 T 0.36 (Endpoint Reference information element, which is modified to contain an endpoint reference flag that distin-) 99.21 331.33 P 0.61 (guishes which side of an interface originates the endpoint reference value. Note: this modification was pro-) 99 319.33 P 0.26 (posed in contribution 94-0421 and was approved by the signalling SWG for inclusion in UNI 3.1. Hence, no) 99 307.33 P (additional modifications are required.) 99 295.33 T (\245) 90 279.33 T (SETUP message, which is modified to include the GCID, LIJP and LSN information elements for LIJ calls,) 99.21 279.33 T (\245) 90 263.33 T (ADD PARTY message, which is modified to include the LSN information element,) 99.21 263.33 T -0.26 (In the remainder of this section, we give an overview of the GCID and LIJP information elements. Full details of) 90.86 247.33 P (all information element and message additions and changes appear in Section) 72 235.33 T (7.) 384.45 235.33 T 52 556 54 662 R V 52 360 54 466 R V 52 292 54 338 R V 52 244 54 270 R V FMENDPAGE %%EndPage: "6" 7 %%Page: "7" 8 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 7) 513.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (3.1) 72 712 T (Global Call Identifier Information Elements) 99 712 T 0 10 Q 0.38 (The Global Call Identifier \050GCID\051 information elements are used to uniquely label the call within the network.) 90.86 695.33 P -0.39 (Prior to contribution 94-0325R1, this information was contained in one composite information element having the fol-) 72 683.33 P (lowing \050simplified\051 form:) 72 671.33 T 0.17 (In contribution 94-0325R1, the GCID information element is broken into a collection of GCID information ele-) 90.86 548.05 P 0.43 (ment) 72 536.05 P 95.89 534.96 92 534.96 2 L V 0.49 H 0 Z N 0.43 (s) 92 536.05 P 0.43 ( which are described below in this section. Additionally, the \322Discriminator\323 field is dropped \050since its func-) 95.89 536.05 P 0.82 (tionality is redundant with the \322Local Call Identifier\323\051 and a new information element is added to hold the Root\325s) 72 524.05 P (subaddress.) 72 512.05 T -0.6 (It is assumed that leaves can construct the GCID information elements by \050at least\051 one of two means: 1\051 by having) 90.86 496.05 P 0.05 (a priori knowledge of a \322well known\323 service, where the root's address and the local call identifier that the root asso-) 72 484.05 P -0.39 (ciates with this service are known and do not normally change or 2\051 by accessing a data base that maps abstract service) 72 472.05 P 0.06 (descriptions into GCIDs for calls corresponding to these services. The first option might be used for broadcast feeds) 72 460.05 P 0.2 (and for well know groups. The second option might be used for all other services that are not generally well known) 72 448.05 P (in nature.) 72 436.05 T 1 12 Q (3.1.1) 72 414.72 T (Root Call Identifier) 108 414.72 T 0 10 Q 0.67 (The Root Call Identifier information element contains the \322GCID Type\323 and the \322Local Call Identifier\323 fields) 90.86 398.05 P (from the former GCID information element. It has the following \050simplified\051 form:) 72 386.05 T 0.15 (The Call Identifier Type field indicates how the LIJ call will be identified. Initially, there is only one allowable) 90.86 298.49 P 0.36 (mechanism\321via the root\325s number and \050optionally\051 subaddress. \050In the future, a new Call Identifier Type could be) 72 286.49 P -0.01 (defined to indicate a group address, where the leaf initiated join call is not tied to a particular user but rather \322unroot-) 72 274.49 P -0.31 (ed.\323 The details of this option are left for further study.\051 The Call Identifier field is used by the creator to differentiate) 72 262.49 P 0.11 (different leaf initiated join calls that have been created by the same root at the same interface. For example, the Call) 72 250.49 P (Identifier could hold a well-known constant, a timestamp or a random number.) 72 238.49 T 1 12 Q (3.1.2) 72 217.16 T (Root Number) 108 217.16 T 0 10 Q -0.19 (The Root Number information element contains the \322Address\323 field from the former GCID information element.) 90.86 200.49 P (It has the following \050simplified\051 form:) 72 188.49 T (The Root Number contains the root\325s address.) 72 124.49 T 72 72 540 720 C 72 560.72 540 668 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 130.74 632.29 253.66 650.36 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 0 Z 0 X N 3 10 Q (GCID Type) 166.64 636.99 T 130.74 614.38 253.66 632.44 R 7 X V 0 X N (Address) 172.2 619.07 T 130.82 596.38 253.75 614.44 R 7 X V 0 X N (Local Call Identifier) 146.16 601.07 T 130.65 578.92 253.58 596.99 R 7 X V 0 X N (Discriminator) 159.89 583.62 T 259.1 633.4 259.1 639.74 2 L 0.01 H 2 Z N 90 180 7.76 1.73 266.85 639.77 A 270 360 3.21 0.74 255.88 633.4 A 259.1 649.58 259.1 643.25 2 L N 180 270 7.76 1.73 266.85 643.22 A 0 90 3.21 0.74 255.88 649.58 A 2 F (Initially: \322Root address-based\323) 273.79 637.7 T (Root\325s address \050called party number\051) 273.79 619.62 T J 258.93 615.65 258.93 621.99 2 L N 90 180 7.76 1.73 266.69 622.02 A 270 360 3.21 0.74 255.71 615.65 A 258.93 631.83 258.93 625.5 2 L N 180 270 7.76 1.73 266.69 625.47 A 0 90 3.21 0.74 255.71 631.83 A 259.18 597.49 259.18 603.83 2 L N 90 180 7.76 1.73 266.94 603.85 A 270 360 3.21 0.74 255.96 597.49 A 259.18 613.67 259.18 607.33 2 L N 180 270 7.76 1.73 266.94 607.31 A 0 90 3.21 0.74 255.96 613.67 A 259.01 579.32 259.01 585.66 2 L N 90 180 7.76 1.73 266.77 585.68 A 270 360 3.21 0.74 255.8 579.32 A 259.01 595.5 259.01 589.16 2 L N 180 270 7.76 1.73 266.77 589.14 A 0 90 3.21 0.74 255.8 595.5 A (Root assigned identifier, unique at root\325s UNI) 273.79 601.62 T (Timestamp, random number, constant, etc.) 273.79 583.62 T J 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 84.88 311.15 527.12 382.72 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 95.74 347.01 218.66 365.08 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 0 Z 0 X N 3 10 Q (Call Identifier Type) 112.46 351.71 T 95.82 328.96 218.75 347.02 R 7 X V 0 X N (Call Identifier) 125.61 333.65 T 224.1 348.12 224.1 354.46 2 L 0.01 H 2 Z N 90 180 7.76 1.73 231.85 354.49 A 270 360 3.21 0.74 220.88 348.12 A 224.1 364.3 224.1 357.97 2 L N 180 270 7.76 1.73 231.85 357.94 A 0 90 3.21 0.74 220.88 364.3 A 2 F (Initially: \322Root address-based\323) 238.78 352.42 T J 224.18 330.07 224.18 336.4 2 L N 90 180 7.76 1.73 231.94 336.43 A 270 360 3.21 0.74 220.96 330.07 A 224.18 346.24 224.18 339.91 2 L N 180 270 7.76 1.73 231.94 339.89 A 0 90 3.21 0.74 220.96 346.24 A (Root assigned identifier, unique at root\325s UNI \050e.g., timestamp,) 238.78 334.2 T (random number or well-known constant\051) 238.78 324.2 T J 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 84.88 137.16 527.12 185.16 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 95.74 150.1 218.66 168.17 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 0 Z 0 X N 3 10 Q (Root Number) 125.53 154.8 T 2 F (Root\325s address \050analogous to called party number\051) 238.78 155.35 T J 223.93 151.38 223.93 157.72 2 L 0.01 H 2 Z N 90 180 7.76 1.73 231.69 157.74 A 270 360 3.21 0.74 220.71 151.38 A 223.93 167.56 223.93 161.22 2 L N 180 270 7.76 1.73 231.69 161.2 A 0 90 3.21 0.74 220.71 167.56 A 72 72 540 720 C 0 0 612 792 C 52 121.16 54 720 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "7" 8 %%Page: "8" 9 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 8) 513.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (3.1.3) 72 712 T (Root Subaddress) 108 712 T 0 10 Q -0.28 (The Root Subaddress information element was not in the former GCID information element. It has the following) 90.86 695.33 P (\050simplified\051 form:) 72 683.33 T 0.49 (The Root Subaddress is used when traversing public networks that do not support private ATM network addresses,) 72 617.91 P -0.17 (where the Root Number is stored in the Root Subaddress field and the exit point of the public network is placed in the) 72 605.91 P (Root Number field \050analogous to the use of Called Party Number and Called Party Subaddress in SETUP messages\051.) 72 593.91 T 1 12 Q (3.2) 72 574.58 T (Leaf Initiated Join Parameters Information Element) 99 574.58 T 0 10 Q 0.43 (The Leaf Initiated Join Parameters \050LIJP\051 information element is used by the root to associate options with the) 90.86 557.91 P (call when the call is created. It has the following \050simplified\051 form:) 72 545.91 T 0 (The valid options for each field are shown to the right of the field. Note that additional options may be added in) 90.86 435.48 P -0.53 (the future as the LIJ capability evolves. The Security Indication specifies the level and type of security to be associated) 72 423.48 P 0.06 (with the LIJ call. Initially, this option must be set to either OPEN \050implying no security, where the network will add) 72 411.48 P -0.16 (any new parties that request to join the call, then optionally notify the root\051 or ROOT SCREENING \050implying that all) 72 399.48 P -0.14 (LEAF SETUP REQUESTs will be forwarded to the root so that the root can selectively choose to add whichever par-) 72 387.48 P 0.07 (ties it wants\051. \050Note: we describe an \322access list\323 security option in Section) 72 375.48 P 0.07 (5, but have not included it here since we) 378.1 375.48 P 0.44 (have not yet fleshed out all of the details.\051 The Notification Indication specifies who gets notified of leaf joins and) 72 363.48 P 0.35 (drops. Initially, this option can be either NONE \050implying that no party gets notification of leaf joins and drops\051 or) 72 351.48 P 0.53 (ROOT \050implying that the root gets these notifications\051. In the future, leaf notification of other leaf joins and drops) 72 339.48 P 0.24 (could be added, if desired. The Zero Leaf Behavior indicates what action the network should perform when the last) 72 327.48 P -0.42 (leaf in the call drops out. Initially, this option can be either DROP CALL \050implying that the call is released\051 or MAIN-) 72 315.48 P -0.37 (TAIN CALL \050implying that the call remains up with zero leaves so that other leaves can join in the future\051. If the Zero) 72 303.48 P -0.21 (Leaf Behavior is set to MAINTAIN CALL, the root is allowed to create the call with no initial endpoints \050that is, with) 72 291.48 P (no Called Party Number in its initial SETUP message\051.) 72 279.48 T 72 72 540 720 C 84.88 630.58 527.12 680 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 95.74 644.95 218.66 663.02 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 0 Z 0 X N 3 10 Q (Root Subaddress) 115.8 649.64 T 2 F (Root\325s subaddress \050analogous to called party subaddress\051) 238.78 650.19 T J 223.93 646.23 223.93 652.56 2 L 0.01 H 2 Z N 90 180 7.76 1.73 231.69 652.59 A 270 360 3.21 0.74 220.71 646.23 A 223.93 662.41 223.93 656.07 2 L N 180 270 7.76 1.73 231.69 656.04 A 0 90 3.21 0.74 220.71 662.4 A 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 103.45 448.15 508.55 542.58 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 128.85 506.51 251.77 524.58 R 7 X 0 0 0 1 0 0 0 K V 0.5 H 0 Z 0 X N 3 10 Q (Security Indication) 145.57 511.21 T 128.85 488.6 251.77 506.66 R 7 X V 0 X N (Notification Indication) 137.8 493.29 T 128.21 470.6 251.14 488.66 R 7 X V 0 X N (Zero Leaf Behavior) 144.39 475.29 T 257.2 507.62 257.2 513.96 2 L 0.01 H 2 Z N 90 180 7.76 1.73 264.96 513.98 A 270 360 3.21 0.74 253.99 507.62 A 257.2 523.8 257.2 517.46 2 L N 180 270 7.76 1.73 264.96 517.44 A 0 90 3.21 0.74 253.99 523.8 A 2 F (Initially: OPEN, ROOT SCREENING) 271.89 511.5 T (Initially: NONE, ROOT) 271.89 493.84 T J 257.03 489.87 257.03 496.21 2 L N 90 180 7.76 1.73 264.79 496.23 A 270 360 3.21 0.74 253.82 489.87 A 257.03 506.05 257.03 499.71 2 L N 180 270 7.76 1.73 264.79 499.69 A 0 90 3.21 0.74 253.82 506.05 A 257.28 471.7 257.28 478.04 2 L N 90 180 7.76 1.73 265.04 478.07 A 270 360 3.21 0.74 254.07 471.7 A 257.28 487.88 257.28 481.55 2 L N 180 270 7.76 1.73 265.04 481.52 A 0 90 3.21 0.74 254.07 487.88 A (Initially: DROP CALL, MAINTAIN CALL) 271.89 475.84 T J 72 72 540 720 C 0 0 612 792 C 52 570.58 54 720 R 0 X 0 0 0 1 0 0 0 K V 52 360.15 54 418.15 R V FMENDPAGE %%EndPage: "8" 9 %%Page: "9" 10 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 9) 513.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (4) 72 712 T (Internal \050NNI\051 Processing of Leaf Initiated Join Requests) 90 712 T 0 10 Q 0.4 (In this section, we give detailed examples showing how the network internally handles operations on LIJ calls.) 90.86 695.33 P (We go through the following five steps:) 72 683.33 T (1\051) 87 667.33 T (Root setup of LIJ call using existing point-to-multipoint procedures.) 99.21 667.33 T (2\051) 87 651.33 T (Root add party of second endpoint to call using existing point-to-multipoint procedures.) 99.21 651.33 T (3\051) 87 635.33 T (Leaf join to call using new LIJ procedures. We present three alternatives:) 99.21 635.33 T (3a\051) 99 619.33 T 0.11 (Call is assumed to have a security indication of OPEN and the LEAF SETUP REQUEST is processed by) 117.36 619.33 P (the network at first node where it intersects call tree.) 117.36 607.33 T (3b\051) 99 591.33 T -0.22 (Call is assumed to have a security indication of ROOT SCREENING and the LEAF SETUP REQUEST is) 117.36 591.33 P (forwarded to root for processing.) 117.36 579.33 T (3c\051) 99 563.33 T -0.39 (Call is assumed to have a security indication of OPEN, but the network chooses to forward the LEAF SET-) 117.36 563.33 P (UP REQUEST to the root\325s access node, where it is processed by the network at this point.) 117.36 551.33 T (4\051) 87 535.33 T (Leaf join failure due to insufficient resources.) 99.21 535.33 T (5\051) 87 519.33 T (Leaf join failure due to timeout of LEAF SETUP REQUEST message.) 99.21 519.33 T 0.13 (In all of these scenarios, the following network configuration is used, where parties \050that is, network clients\051 are pic-) 72 503.33 P (tured as triangles, network nodes as dark circles, and interconnects as thin solid lines:) 72 491.33 T 72 72 540 720 C 179.72 275 432.28 488 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 278.16 299 305.16 326 2 L 1 H 2 Z 0 X 0 0 0 1 0 0 0 K N 359.16 434 386.16 461 2 L N 278.16 461 305.16 434 2 L N 206.16 380 251.16 380 2 L N 359.16 380 404.16 380 2 L N 359.16 326 386.16 299 2 L N 276.92 307.15 287.16 290 266.69 290 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 293.86 T 387.39 307.15 397.63 290 377.16 290 3 Y 7 X V 0 X N (E) 384.34 293.86 T 384.92 479 395.16 461.86 374.69 461.86 3 Y 7 X V 0 X N (C) 381.59 465.71 T 204.92 389 215.16 371.86 194.69 371.86 3 Y 7 X V 0 X N (A) 201.31 375.71 T 251.16 380.86 305.16 380.86 2 L 1 H N 305.16 380.86 359.16 380.86 2 L N 305.16 434.86 359.16 434.86 2 L N 305.16 326.86 359.16 326.86 2 L N 359.16 380.86 359.16 326.86 2 L N 305.16 380.86 305.16 326.86 2 L N 305.16 434.86 305.16 380.86 2 L N 359.16 434.86 359.16 380.86 2 L N 307.34 437.04 251.16 380.86 2 L N 305.16 326.86 248.97 383.04 2 L N 359.16 378.67 302.97 434.86 2 L N 359.16 383.04 302.97 326.86 2 L N 7 X 90 450 8.31 8.57 359.85 434.43 G 2 H 0 X 90 450 8.31 8.57 359.85 434.43 A (N2) 354.4 431.75 T 7 X 90 450 8.31 8.57 359.85 380.43 G 0 X 90 450 8.31 8.57 359.85 380.43 A (N5) 354.4 377.75 T 7 X 90 450 8.31 8.57 359.85 326.43 G 0 X 90 450 8.31 8.57 359.85 326.43 A (N7) 354.4 323.75 T 7 X 90 450 8.31 8.57 305.85 326.43 G 0 X 90 450 8.31 8.57 305.85 326.43 A (N6) 300.4 323.75 T 7 X 90 450 8.31 8.57 304.46 380.43 G 0 X 90 450 8.31 8.57 304.46 380.43 A (N4) 299.01 377.75 T 7 X 90 450 8.31 8.57 250.46 380.43 G 0 X 90 450 8.31 8.57 250.46 380.43 A (N3) 245.01 377.75 T 7 X 90 450 8.31 8.57 305.85 434.43 G 0 X 90 450 8.31 8.57 305.85 434.43 A (N1) 300.4 431.75 T 405.39 388.15 415.63 371 395.16 371 3 Y 7 X V 0.5 H 0 X N (D) 401.78 374.86 T 276.92 478.14 287.16 461 266.69 461 3 Y 7 X V 0 X N (B) 273.59 464.85 T 72 72 540 720 C 0 0 612 792 C 52 548 54 642 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "9" 10 %%Page: "10" 11 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 10) 508.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (4.1) 72 712 T (Successful Initial SETUP by Root) 99 712 T 0 10 Q -0.06 (Client A creates the call \050and is the root of the call\051 by issuing a SETUP message to called party B, as shown be-) 90.86 695.33 P (low:) 72 683.33 T 0 (The SETUP message contains the mandatory \050and any optional\051 parameters, along with the GCID and LIJP informa-) 72 455.33 P -0.04 (tion elements. For this example, we assume that the GCID=A.1.2,) 72 443.33 P 0 8 Q -0.03 (*) 338.07 447.33 P 0 10 Q -0.04 ( and that the LIJP specifies a call with root notifi-) 342.07 443.33 P 2.45 (cations of leaf joins and drops \050we make different assumptions about the Security Indication of the LIJP in) 72 431.33 P 0.03 (Section) 72 419.33 P 0.03 (4.3\051. Client B is assigned an endpoint reference of zero by A \050as mandated by the point-to-multipoint proce-) 104.5 419.33 P 0.01 (dures, since B is the first party\051, which we denote as {A:0} \050the \322A\323 prefix is used to indicate that the endpoint refer-) 72 407.33 P -0.42 (ence was assigned by A\325s side of the interface, as will be reflected in the endpoint reference flag\051. Both network nodes) 72 395.33 P 0.02 (processing the SETUP message \050N3 and N1\051 cache the GCID and the LIJP so that subsequent leaf joins can attach at) 72 383.33 P 0.47 (these nodes. Client B accepts the call offering by issuing a CONNECT message and the call setup is completed as) 72 371.33 P (follows:) 72 359.33 T 0 7.2 Q (*) 72 102.6 T 0 9 Q -0.48 (We use the notation \322A.1.2\323 to refer to a GCID whose Root Call Identifier information element is of type \3221\323 \050root address based\051) 81.43 99 P -0.01 (with a Call Identifier of \3222,\323 and whose Root Number information element is \322A.\323 For these examples, we do not illustrate use) 81.43 88 P (of the Root Subaddress.) 81.43 77 T 72 72 540 720 C 179.72 467 432.28 680 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 221 563.58 211.38 566.33 221 569.09 219.99 566.33 4 Y 0 X 0 0 0 1 0 0 0 K V 247.38 566.33 219.99 566.33 2 L 0.5 H 2 Z N 297.99 642.41 302.84 633.67 294.1 638.52 296.75 639.75 4 Y V 277.39 659.12 296.75 639.75 2 L N 276.25 491 303.25 518 2 L 1 H N 357.25 626 384.25 653 2 L N 276.25 653 303.25 626 2 L N 204.25 572 249.25 572 2 L N 357.25 572 402.25 572 2 L N 357.25 518 384.25 491 2 L N 275.01 499.15 285.25 482 264.78 482 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 272.23 485.86 T 385.48 499.15 395.72 482 375.25 482 3 Y 7 X V 0 X N (E) 382.43 485.86 T 383.01 671 393.25 653.86 372.78 653.86 3 Y 7 X V 0 X N (C) 379.68 657.71 T 203.01 581 213.25 563.86 192.78 563.86 3 Y 7 X V 0 X N (A) 199.4 567.71 T 249.25 572.86 303.25 572.86 2 L 1 H N 303.25 572.86 357.25 572.86 2 L N 303.25 626.86 357.25 626.86 2 L N 303.25 518.86 357.25 518.86 2 L N 357.25 572.86 357.25 518.86 2 L N 303.25 572.86 303.25 518.86 2 L N 303.25 626.86 303.25 572.86 2 L N 357.25 626.86 357.25 572.86 2 L N 305.43 629.04 249.25 572.86 2 L N 303.25 518.86 247.07 575.04 2 L N 357.25 570.67 301.07 626.86 2 L N 357.25 575.04 301.07 518.86 2 L N 7 X 90 450 8.31 8.57 357.94 626.43 G 2 H 0 X 90 450 8.31 8.57 357.94 626.43 A (N2) 352.49 623.75 T 7 X 90 450 8.31 8.57 357.94 572.43 G 0 X 90 450 8.31 8.57 357.94 572.43 A (N5) 352.49 569.75 T 7 X 90 450 8.31 8.57 357.94 518.43 G 0 X 90 450 8.31 8.57 357.94 518.43 A (N7) 352.49 515.75 T 7 X 90 450 8.31 8.57 303.94 518.43 G 0 X 90 450 8.31 8.57 303.94 518.43 A (N6) 298.49 515.75 T 7 X 90 450 8.31 8.57 302.56 572.43 G 0 X 90 450 8.31 8.57 302.56 572.43 A (N4) 297.11 569.75 T 7 X 90 450 8.31 8.57 248.56 572.43 G 0 X 90 450 8.31 8.57 248.56 572.43 A (N3) 243.11 569.75 T 7 X 90 450 8.31 8.57 303.94 626.43 G 0 X 90 450 8.31 8.57 303.94 626.43 A (N1) 298.49 623.75 T 403.48 580.15 413.72 563 393.25 563 3 Y 7 X V 0.5 H 0 X N (D) 399.87 566.86 T 275.01 670.14 285.25 653 264.78 653 3 Y 7 X V 0 X N (B) 271.68 656.85 T 0 7 Q (SETUP) 0 -45 272.55 639.29 TF (CALL) 0 -45 289.74 660.29 TF (PROC) 0 -45 284.79 655.34 TF 273.45 644.25 268.6 653 277.34 648.15 274.68 646.91 4 Y V 294.05 627.54 274.68 646.91 2 L N 264.13 577.52 255.39 572.67 260.23 581.41 261.47 578.75 4 Y V 300.39 617.67 261.47 578.75 2 L N 287.31 621.82 296.05 626.67 291.2 617.92 289.96 620.58 4 Y V 251.05 581.67 289.96 620.58 2 L N (SETUP) 0 -315 264.09 598.5 TF (CALL) 0 -315 280.43 590.02 TF (PROC) 0 -315 285.38 585.07 TF 231.77 579.76 241.38 577 231.77 574.24 232.78 577 4 Y V 205.38 577 232.78 577 2 L N (SETUP) 210.09 579.07 T (CALL) 222.74 561.37 T (PROC) 222.74 554.37 T 7 X 90 450 5.25 5.25 214.22 591.5 G 0 X 90 450 5.25 5.25 214.22 591.5 A 2 9 Q (1) 211.72 587.75 T 7 X 90 450 5.25 5.25 231.47 547.72 G 0 X 90 450 5.25 5.25 231.47 547.72 A (2) 228.97 543.97 T 7 X 90 450 5.25 5.25 256.97 608.75 G 0 X 90 450 5.25 5.25 256.97 608.75 A (3) 254.47 605 T 7 X 90 450 5.25 5.25 276.47 584.72 G 0 X 90 450 5.25 5.25 276.47 584.72 A (4) 273.97 580.97 T 7 X 90 450 5.25 5.25 266.97 636.75 G 0 X 90 450 5.25 5.25 266.97 636.75 A (5) 264.47 633 T 7 X 90 450 5.25 5.25 300.47 665.75 G 0 X 90 450 5.25 5.25 300.47 665.75 A (6) 297.97 662 T 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 179.72 143 432.28 356 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 221 239.58 211.38 242.33 221 245.09 219.99 242.33 4 Y 0 X 0 0 0 1 0 0 0 K V 247.38 242.33 219.99 242.33 2 L 0.5 H 2 Z N 297.99 318.41 302.84 309.67 294.1 314.52 296.75 315.76 4 Y V 277.39 335.12 296.75 315.76 2 L N 276.25 167 303.25 194 2 L 1 H N 357.25 302 384.25 329 2 L N 276.25 329 303.25 302 2 L 3 H N 204.25 248 249.25 248 2 L N 357.25 248 402.25 248 2 L 1 H N 357.25 194 384.25 167 2 L N 275.01 175.15 285.25 158 264.78 158 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 272.23 161.86 T 385.48 175.15 395.72 158 375.25 158 3 Y 7 X V 0 X N (E) 382.43 161.86 T 383.01 347 393.25 329.86 372.78 329.86 3 Y 7 X V 0 X N (C) 379.68 333.71 T 203.01 257 213.25 239.86 192.78 239.86 3 Y 7 X V 0 X N (A) 199.4 243.71 T 249.25 248.86 303.25 248.86 2 L 1 H N 303.25 248.86 357.25 248.86 2 L N 303.25 302.86 357.25 302.86 2 L N 303.25 194.86 357.25 194.86 2 L N 357.25 248.86 357.25 194.86 2 L N 303.25 248.86 303.25 194.86 2 L N 303.25 302.86 303.25 248.86 2 L N 357.25 302.86 357.25 248.86 2 L N 305.43 305.04 249.25 248.86 2 L 3 H N 303.25 194.86 247.07 251.04 2 L 1 H N 357.25 246.67 301.07 302.86 2 L N 357.25 251.04 301.07 194.86 2 L N 7 X 90 450 8.31 8.57 357.94 302.43 G 2 H 0 X 90 450 8.31 8.57 357.94 302.43 A (N2) 352.49 299.75 T 7 X 90 450 8.31 8.57 357.94 248.43 G 0 X 90 450 8.31 8.57 357.94 248.43 A (N5) 352.49 245.75 T 7 X 90 450 8.31 8.57 357.94 194.43 G 0 X 90 450 8.31 8.57 357.94 194.43 A (N7) 352.49 191.75 T 7 X 90 450 8.31 8.57 303.94 194.43 G 0 X 90 450 8.31 8.57 303.94 194.43 A (N6) 298.49 191.75 T 7 X 90 450 8.31 8.57 302.56 248.43 G 0 X 90 450 8.31 8.57 302.56 248.43 A (N4) 297.11 245.75 T 7 X 90 450 8.31 8.57 248.56 248.43 G 0 X 90 450 8.31 8.57 248.56 248.43 A (N3) 243.11 245.75 T 7 X 90 450 8.31 8.57 303.94 302.43 G 0 X 90 450 8.31 8.57 303.94 302.43 A (N1) 298.49 299.75 T 403.48 256.15 413.72 239 393.25 239 3 Y 7 X V 0.5 H 0 X N (D) 399.87 242.86 T 275.01 346.14 285.25 329 264.78 329 3 Y 7 X V 0 X N (B) 271.68 332.85 T 0 7 Q (CONN) 0 -45 271.88 317.29 TF (CONNECT) 0 -45 282.79 336.67 TF 273.45 320.25 268.6 329 277.34 324.15 274.68 322.91 4 Y V 294.05 303.54 274.68 322.91 2 L N 264.13 253.52 255.39 248.67 260.23 257.41 261.47 254.75 4 Y V 300.39 293.67 261.47 254.76 2 L N 286.64 298.48 295.39 303.33 290.54 294.59 289.3 297.25 4 Y V 250.38 258.33 289.3 297.25 2 L N (CONN) 0 -315 257.25 277.02 TF 231.77 255.76 241.38 253 231.77 250.24 232.78 253 4 Y V 205.38 253 232.78 253 2 L N (ACK) 0 -45 266.93 312.34 TF (ACK) 0 -315 262.2 272.07 TF (CONN) 211.1 261.91 T (ACK) 211.1 254.91 T (CONNECT) 216.05 234.19 T (CONNECT) 0 -315 272.27 257.25 TF 7 X 90 450 5.25 5.25 297.97 338.22 G 0 X 90 450 5.25 5.25 297.97 338.22 A 2 9 Q (1) 295.47 334.47 T 7 X 90 450 5.25 5.25 261.97 316.15 G 0 X 90 450 5.25 5.25 261.97 316.15 A (2) 259.47 312.4 T 7 X 90 450 5.25 5.25 287.18 262.51 G 0 X 90 450 5.25 5.25 287.18 262.51 A (3) 284.68 258.76 T 7 X 90 450 5.25 5.25 251.97 289.22 G 0 X 90 450 5.25 5.25 251.97 289.22 A (4) 249.47 285.47 T 7 X 90 450 5.25 5.25 209.97 271.36 G 0 X 90 450 5.25 5.25 209.97 271.36 A (6) 207.47 267.61 T 7 X 90 450 5.25 5.25 231.97 227.01 G 0 X 90 450 5.25 5.25 231.97 227.01 A (5) 229.47 223.26 T 72 72 540 720 C 0 0 612 792 C 52 392 54 450 R 0 X 0 0 0 1 0 0 0 K V 52 74 54 105 R V FMENDPAGE %%EndPage: "10" 11 %%Page: "11" 12 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 11) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X -0.62 (where the active branches of the call are depicted by heavy lines. Note that the SETUP message delivered to B contains) 72 713.33 P -0.53 (the GCID and LIJP information elements. This is done for symmetry so that if B were in fact a PBX it could add leaves) 72 701.33 P (into the call within its domain.) 72 689.33 T 1 12 Q (4.2) 72 670 T (Successful ADD PARTY by Root) 99 670 T 0 10 Q 0.05 (Client A now adds client C to the call using an ADD PARTY message and sets C\325s endpoint reference = {A:1},) 90.86 653.33 P (as shown below:) 72 641.33 T 0.01 (The ADD PARTY progresses through the network and is translated into a SETUP at node N1. The SETUP message) 72 413.33 P 0.83 (contains all of the call parameters, including the GCID and LIJP information elements. As before, N2 caches the) 72 401.33 P 0.17 (GCID and LIJP so that is can support subsequent leaf join attachments. Upon receiving the SETUP, client C imme-) 72 389.33 P 0.05 (diately accepts the call and the CONNECT/ADD PARTY ACK is sent back to A \050for simplicity, CALL PROCEED-) 72 377.33 P (ING and CONNECT ACK messages are not shown\051.) 72 365.33 T 72 72 540 720 C 179.72 425 432.28 638 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 373.77 590.62 364.97 585.88 369.92 594.56 371.12 591.89 4 Y 0 X 0 0 0 1 0 0 0 K V 391.97 612.25 371.13 591.89 2 L 0.5 H 2 Z N 368.91 606.26 377.72 611 372.77 602.31 371.56 604.98 4 Y V 350.72 584.62 371.56 604.98 2 L N 321.71 577.87 312.09 580.62 321.71 583.38 320.7 580.62 4 Y V 357.09 580.62 320.7 580.62 2 L N 343.86 592.63 353.47 589.88 343.86 587.12 344.86 589.88 4 Y V 308.47 589.88 344.86 589.88 2 L N 221 521.58 211.38 524.33 221 527.09 219.99 524.33 4 Y V 247.38 524.33 219.99 524.33 2 L N 276.25 449 303.25 476 2 L 1 H N 357.25 584 384.25 611 2 L 3 H N 276.25 611 303.25 584 2 L N 204.25 530 249.25 530 2 L N 357.25 530 402.25 530 2 L 1 H N 357.25 476 384.25 449 2 L N 275.01 457.15 285.25 440 264.78 440 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 272.23 443.86 T 385.48 457.15 395.72 440 375.25 440 3 Y 7 X V 0 X N (E) 382.43 443.86 T 383.01 629 393.25 611.86 372.78 611.86 3 Y 7 X V 0 X N (C) 379.68 615.71 T 203.01 539 213.25 521.86 192.78 521.86 3 Y 7 X V 0 X N (A) 199.4 525.71 T 249.25 530.86 303.25 530.86 2 L 1 H N 303.25 530.86 357.25 530.86 2 L N 303.25 584.86 357.25 584.86 2 L 3 H N 303.25 476.86 357.25 476.86 2 L 1 H N 357.25 530.86 357.25 476.86 2 L N 303.25 530.86 303.25 476.86 2 L N 303.25 584.86 303.25 530.86 2 L N 357.25 584.86 357.25 530.86 2 L N 305.43 587.04 249.25 530.86 2 L 3 H N 303.25 476.86 247.07 533.04 2 L 1 H N 357.25 528.67 301.07 584.86 2 L N 357.25 533.04 301.07 476.86 2 L N 7 X 90 450 8.31 8.57 357.94 584.43 G 2 H 0 X 90 450 8.31 8.57 357.94 584.43 A (N2) 352.49 581.75 T 7 X 90 450 8.31 8.57 357.94 530.43 G 0 X 90 450 8.31 8.57 357.94 530.43 A (N5) 352.49 527.75 T 7 X 90 450 8.31 8.57 357.94 476.43 G 0 X 90 450 8.31 8.57 357.94 476.43 A (N7) 352.49 473.75 T 7 X 90 450 8.31 8.57 303.94 476.43 G 0 X 90 450 8.31 8.57 303.94 476.43 A (N6) 298.49 473.75 T 7 X 90 450 8.31 8.57 302.56 530.43 G 0 X 90 450 8.31 8.57 302.56 530.43 A (N4) 297.11 527.75 T 7 X 90 450 8.31 8.57 248.56 530.43 G 0 X 90 450 8.31 8.57 248.56 530.43 A (N3) 243.11 527.75 T 7 X 90 450 8.31 8.57 303.94 584.43 G 0 X 90 450 8.31 8.57 303.94 584.43 A (N1) 298.49 581.75 T 403.48 538.15 413.72 521 393.25 521 3 Y 7 X V 0.5 H 0 X N (D) 399.87 524.86 T 275.01 628.14 285.25 611 264.78 611 3 Y 7 X V 0 X N (B) 271.68 614.85 T 264.13 536.14 255.39 531.29 260.23 540.04 261.47 537.38 4 Y V 300.39 576.29 261.47 537.38 2 L N 287.31 579.82 296.05 584.67 291.2 575.92 289.96 578.58 4 Y V 251.05 539.67 289.96 578.58 2 L N 0 7 Q (ADD) 0 -315 257.07 559 TF (PARTY) 0 -315 262.02 554.05 TF 231.77 537.76 241.38 535 231.77 532.24 232.78 535 4 Y V 205.38 535 232.78 535 2 L N (ADD) 209.5 544.37 T (PARTY) 209.5 537.37 T (SETUP) 316.43 592.06 T (SETUP) 0 -315 355.64 593.75 TF (CONNECT) 0 -315 377.02 588.5 TF (CONNECT) 318.72 573.14 T (ADD) 0 -315 277.6 544.35 TF (PARTY) 0 -315 282.54 539.4 TF (ACK) 0 -315 287.49 534.45 TF (ADD) 222.43 517.81 T (PARTY) 222.43 510.81 T (ACK) 222.43 503.81 T 7 X 90 450 5.25 5.25 211 555.59 G 0 X 90 450 5.25 5.25 211 555.59 A 2 9 Q (1) 208.5 551.84 T 7 X 90 450 5.25 5.25 249 567.52 G 0 X 90 450 5.25 5.25 249 567.52 A (2) 246.5 563.77 T 7 X 90 450 5.25 5.25 321 603.45 G 0 X 90 450 5.25 5.25 321 603.45 A (3) 318.5 599.7 T 7 X 90 450 5.25 5.25 349.71 603.95 G 0 X 90 450 5.25 5.25 349.71 603.95 A (4) 347.21 600.2 T 7 X 90 450 5.25 5.25 385.57 586.66 G 0 X 90 450 5.25 5.25 385.57 586.66 A (5) 383.07 582.91 T 7 X 90 450 5.25 5.25 341.43 566.52 G 0 X 90 450 5.25 5.25 341.43 566.52 A (6) 338.93 562.77 T 7 X 90 450 5.25 5.25 273 539.95 G 0 X 90 450 5.25 5.25 273 539.95 A (7) 270.5 536.2 T 7 X 90 450 5.25 5.25 228.86 497.17 G 0 X 90 450 5.25 5.25 228.86 497.17 A (8) 226.35 493.42 T 72 72 540 720 C 0 0 612 792 C 52 650 54 660 R 0 X 0 0 0 1 0 0 0 K V 52 386 54 396 R V 52 362 54 372 R V FMENDPAGE %%EndPage: "11" 12 %%Page: "12" 13 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 12) 508.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (4.3) 72 712 T (Successful LEAF SETUP REQUEST by Leaf) 99 712 T 0 10 Q 0 (In this section, we illustrate three different scenarios for a successful LEAF SETUP REQUEST issued by a leaf.) 90.86 695.33 P 0.41 (These are based upon the Security Indication specified by the root when it created the call \050one of OPEN or ROOT) 72 683.33 P 0.31 (SCREENING\051 and on network provider capabilities \050that is, whether the network is capable of adding leaves at any) 72 671.33 P (internal node or just at the root\325s access node\051.) 72 659.33 T 1 12 Q (4.3.1) 72 638 T (Security Indication is OPEN, Network Supports Joins Anywhere On Call Tree) 108 638 T 0 10 Q -0.45 (This first scenario traces a leaf join where the root specified a Security Indication of OPEN when creating the call.) 90.86 621.33 P -0.36 (This results in processing of all LEAF SETUP REQUEST messages at the node where they intersect the call tree. Cli-) 72 609.33 P (ent D initiates the operation using a LEAF SETUP REQUEST \050LSR\051 message, as shown below:) 72 597.33 T -0.1 (Client D issues the LEAF SETUP REQUEST with GCID = A.1.2 and with a Leaf Sequence Number \050LSN\051 of 1. In-) 72 379.33 P 0.15 (ternally, the network takes A\325s address from the GCID and uses this to route the LEAF SETUP REQUEST message) 72 367.33 P -0.17 (towards A. The LEAF SETUP REQUEST is forwarded as a datagram by the network, passing through nodes N5 and) 72 355.33 P 0.02 (N1 \050where the call tree is located\051. Intermediate node N5) 72 343.33 P 5 F 0.02 (does not) 304.88 343.33 P 0 F 0.02 ( cache any information about the call or the LEAF) 338.51 343.33 P 0.28 (SETUP REQUEST datagram. When node N1 receives that LEAF SETUP REQUEST and determines that it is cur-) 72 331.33 P 0.03 (rently supporting the call, it simulates receipt of an ADD PARTY message from the root to add D to the call \050and re-) 72 319.33 P 0.92 (members that it is processing a LEAF SETUP REQUEST from D\051. Node N1 also assigns D an unused endpoint) 72 307.33 P -0.05 (reference = {N1:1} \050note the \322N1\323 prefix, indicating that the N1 side of each interface has assigned this endpoint ref-) 72 295.33 P (erence value\051.) 72 283.33 T -0.49 (Node N1 has multiple routes by which it can reach client D. It is not constrained to follow the route that the LEAF) 90.86 267.33 P 0.53 (SETUP REQUEST message took to reach it. However, in this example, the route through node N5 is the shortest.) 72 255.33 P 72 72 540 720 C 179.72 392 432.28 594 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 320.56 531.11 315.72 539.86 324.46 535.01 321.8 533.77 4 Y 0 X 0 0 0 1 0 0 0 K V 357.14 498.43 321.8 533.77 2 L 0.5 H 2 Z N 278.16 409 305.16 436 2 L 1 H N 359.16 544 386.16 571 2 L 3 H N 278.16 571 305.16 544 2 L N 206.16 490 251.16 490 2 L N 359.16 490 404.16 490 2 L 1 H N 359.16 436 386.16 409 2 L N 276.92 417.15 287.16 400 266.69 400 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 403.86 T 387.39 417.15 397.63 400 377.16 400 3 Y 7 X V 0 X N (E) 384.34 403.86 T 384.92 589 395.16 571.86 374.69 571.86 3 Y 7 X V 0 X N (C) 381.59 575.71 T 204.92 499 215.16 481.86 194.69 481.86 3 Y 7 X V 0 X N (A) 201.31 485.71 T 251.16 490.86 305.16 490.86 2 L 1 H N 305.16 490.86 359.16 490.86 2 L N 305.16 544.86 359.16 544.86 2 L 3 H N 305.16 436.86 359.16 436.86 2 L 1 H N 359.16 490.86 359.16 436.86 2 L N 305.16 490.86 305.16 436.86 2 L N 305.16 544.86 305.16 490.86 2 L N 359.16 544.86 359.16 490.86 2 L N 307.34 547.04 251.16 490.86 2 L 3 H N 305.16 436.86 248.97 493.04 2 L 1 H N 359.16 488.67 302.97 544.86 2 L N 359.16 493.04 302.97 436.86 2 L N 7 X 90 450 8.31 8.57 359.85 544.43 G 2 H 0 X 90 450 8.31 8.57 359.85 544.43 A (N2) 354.4 541.75 T 7 X 90 450 8.31 8.57 359.85 436.43 G 0 X 90 450 8.31 8.57 359.85 436.43 A (N7) 354.4 433.75 T 7 X 90 450 8.31 8.57 305.85 436.43 G 0 X 90 450 8.31 8.57 305.85 436.43 A (N6) 300.4 433.75 T 7 X 90 450 8.31 8.57 304.46 490.43 G 0 X 90 450 8.31 8.57 304.46 490.43 A (N4) 299.01 487.75 T 7 X 90 450 8.31 8.57 250.46 490.43 G 0 X 90 450 8.31 8.57 250.46 490.43 A (N3) 245.01 487.75 T 7 X 90 450 8.31 8.57 305.85 544.43 G 0 X 90 450 8.31 8.57 305.85 544.43 A (N1) 300.4 541.75 T 405.39 498.15 415.63 481 395.16 481 3 Y 7 X V 0.5 H 0 X N (D) 401.78 484.86 T 276.92 588.14 287.16 571 266.69 571 3 Y 7 X V 0 X N (B) 273.59 574.85 T 375.83 492.49 366.22 495.25 375.83 498.01 374.83 495.25 4 Y V 402.22 495.25 374.83 495.25 2 L N 0 7 Q (LSR) 378.52 497.39 T (LSR) 0 -45 338.72 521.64 TF (ADD) 324.24 573.68 T (PARTY) 324.24 566.68 T 7 X 90 450 5.25 5.25 380.43 508.66 G 0 X 90 450 5.25 5.25 380.43 508.66 A 2 9 Q (1) 377.93 504.91 T 7 X 90 450 5.61 5.25 334.5 531.81 G 0 X 90 450 5.61 5.25 334.5 531.81 A (2) 332 528.06 T 319.8 564.87 311.43 556.29 313.98 568 316.89 566.43 4 Y V 302.14 554.14 M 293.3 560.16 293.25 581.64 307.14 578.97 D 316.11 577.24 318.29 572.16 316.9 566.43 D 0.01 H N 7 X 90 450 5.25 5.25 318.57 581.66 G 0.5 H 0 X 90 450 5.25 5.25 318.57 581.66 A (3) 316.07 577.91 T 7 X 90 450 8.31 8.57 359.85 490.43 G 2 H 0 X 90 450 8.31 8.57 359.85 490.43 A 0 10 Q (N5) 354.4 487.75 T 72 72 540 720 C 0 0 612 792 C 52 252 54 720 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "12" 13 %%Page: "13" 14 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 13) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X (Hence, N1 chooses this route to reach D, as shown below:) 72 713.33 T -0.22 (Since the call is not yet active along the link, N1 sends a SETUP message along this path. \050If, for whatever) 72 485.33 P 0.06 (reason, the route through N2 had been chosen, an ADD PARTY message would have been sent down this path since) 72 473.33 P -0.19 (the call is) 72 461.33 P 5 F -0.19 (active) 112.25 461.33 P 0 F -0.19 ( on the link.\051 The SETUP message contains D\325s address in the Called Party Number infor-) 136.13 461.33 P -0.04 (mation element \050copied from the New Leaf Number information element\051, the GCID and LIJP information elements,) 72 449.33 P -0.16 (all other call parameter information elements originally specified by A when the call was created, and the LSN infor-) 72 437.33 P (mation element that D included in the LEAF SETUP REQUEST message.) 72 425.33 T -0.49 (When D receives the SETUP, it checks the LSN to verify that the SETUP is the result of D\325s previous LEAF SET-) 90.86 409.33 P -0.44 (UP REQUEST \050as opposed to being from an independent ADD PARTY issued by A\051. Client D responds with a CON-) 72 397.33 P 0.23 (NECT and is added to the call. \050Note: for simplicity, the optional CALL PROCEEDING messages and CONNECT) 72 385.33 P 0 (ACKs are not shown above.\051 When node N1 receives the ADD PARTY ACK, it sends a NEW LEAF ANNOUNCE) 72 373.33 P 0.01 (message to the root) 72 361.33 P 0.01 (A \050via N3\051 to announce D\325s join \050since root notification of leaf joins and drops was turned on for) 152.03 361.33 P (this call\051. This NEW LEAF ANNOUNCE contains the new endpoint reference assigned to D and D\325s address.) 72 349.33 T -0.23 (This example has shown the case where a leaf joins itself into a call at a node that is already) 90.86 333.33 P 5 F -0.23 (active) 456.82 333.33 P 0 F -0.23 (. There may be) 480.7 333.33 P 0.18 (other cases where a LEAF SETUP REQUEST intercepts the call tree, but the tree is not) 72 321.33 P 5 F 0.18 (active) 431.07 321.33 P 0 F 0.18 ( yet at this node \050that) 454.95 321.33 P 0.13 (is, an earlier SETUP is still pending\051. In this case, the message continues to be forwarded back toward the root, until) 72 309.33 P -0.31 (it hits an) 72 297.33 P 5 F -0.31 (active) 108.01 297.33 P 0 F -0.31 ( node in call tree or the root\325s access node. Then, the steps above are followed \050where an ADD PARTY) 131.89 297.33 P -0.26 (from the root is simulated\051. If the call is not active at the root\325s access node, the LEAF SETUP REQUEST may either) 72 285.33 P -0.14 (be held by the network until the call goes active, or forwarded to the root for processing \050as when the Security Indica-) 72 273.33 P (tion is set to ROOT SCREENING\051.) 72 261.33 T 72 72 540 720 C 179.72 502 432.28 710 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 216.33 608.24 206.72 611 216.33 613.76 215.33 611 4 Y 0 X 0 0 0 1 0 0 0 K V 251.72 611 215.33 611 2 L 0.5 H 2 Z N 375.83 598.99 366.22 601.75 375.83 604.51 374.83 601.75 4 Y V 411.22 601.75 374.83 601.75 2 L N 395.11 613.76 404.72 611 395.11 608.24 396.11 611 4 Y V 359.72 611 396.11 611 2 L N 352.37 621.62 357.22 612.88 348.47 617.72 351.13 618.96 4 Y V 312.22 657.88 351.13 618.96 2 L N 278.16 525 305.16 552 2 L 1 H N 359.16 660 386.16 687 2 L 3 H N 278.16 687 305.16 660 2 L N 206.16 610.29 251.16 610.29 2 L N 359.16 606 404.16 606 2 L N 359.16 552 386.16 525 2 L 1 H N 276.92 533.15 287.16 516 266.69 516 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 519.86 T 387.39 533.15 397.63 516 377.16 516 3 Y 7 X V 0 X N (E) 384.34 519.86 T 384.92 705 395.16 687.86 374.69 687.86 3 Y 7 X V 0 X N (C) 381.59 691.71 T 204.92 615 215.16 597.86 194.69 597.86 3 Y 7 X V 0 X N (A) 201.31 601.71 T 251.16 606.86 305.16 606.86 2 L 1 H N 305.16 606.86 359.16 606.86 2 L N 305.16 660.86 359.16 660.86 2 L 3 H N 305.16 552.86 359.16 552.86 2 L 1 H N 359.16 606.86 359.16 552.86 2 L N 305.16 606.86 305.16 552.86 2 L N 305.16 660.86 305.16 606.86 2 L N 359.16 660.86 359.16 606.86 2 L N 307.34 663.04 251.16 606.86 2 L 3 H N 305.16 552.86 248.97 609.04 2 L 1 H N 359.16 604.67 302.97 660.86 2 L 3 H N 359.16 609.04 302.97 552.86 2 L 1 H N 7 X 90 450 8.31 8.57 359.85 660.43 G 2 H 0 X 90 450 8.31 8.57 359.85 660.43 A (N2) 354.4 657.75 T 7 X 90 450 8.31 8.57 359.85 606.43 G 0 X 90 450 8.31 8.57 359.85 606.43 A (N5) 354.4 603.75 T 7 X 90 450 8.31 8.57 359.85 552.43 G 0 X 90 450 8.31 8.57 359.85 552.43 A (N7) 354.4 549.75 T 7 X 90 450 8.31 8.57 305.85 552.43 G 0 X 90 450 8.31 8.57 305.85 552.43 A (N6) 300.4 549.75 T 7 X 90 450 8.31 8.57 304.46 606.43 G 0 X 90 450 8.31 8.57 304.46 606.43 A (N4) 299.01 603.75 T 7 X 90 450 8.31 8.57 250.46 606.43 G 0 X 90 450 8.31 8.57 250.46 606.43 A (N3) 245.01 603.75 T 7 X 90 450 8.31 8.57 305.85 660.43 G 0 X 90 450 8.31 8.57 305.85 660.43 A (N1) 300.4 657.75 T 405.39 614.15 415.63 597 395.16 597 3 Y 7 X V 0.5 H 0 X N (D) 401.78 600.86 T 276.92 704.14 287.16 687 266.69 687 3 Y 7 X V 0 X N (B) 273.59 690.85 T 0 7 Q (SETUP) 0 -45 326.04 647.08 TF 310.57 643.25 305.72 652 314.46 647.15 311.81 645.91 4 Y V 350.72 607 311.81 645.91 2 L N (SETUP) 371.22 612.52 T (CONNECT) 362.47 593.23 T (CONNECT) 0 -45 312.04 637.12 TF 260.46 619.85 251.72 615 256.57 623.75 257.81 621.09 4 Y V 296.72 660 257.81 621.09 2 L N (NEW) 0 -315 252.42 640.9 TF (LEAF) 0 -315 257.37 635.95 TF (ANNOUNCE) 0 -315 262.32 631 TF (NEW) 209.3 631.03 T (LEAF) 209.3 624.03 T (ANNOUNCE) 209.3 617.03 T 7 X 90 450 5.25 5.25 340.07 649.59 G 0 X 90 450 5.25 5.25 340.07 649.59 A 2 9 Q (1) 337.57 645.84 T 7 X 90 450 5.25 5.25 377.57 624.41 G 0 X 90 450 5.25 5.25 377.57 624.41 A (2) 375.07 620.66 T 7 X 90 450 5.25 5.25 377.71 586.16 G 0 X 90 450 5.25 5.25 377.71 586.16 A (3) 375.21 582.41 T 7 X 90 450 5.25 5.25 316.43 623.38 G 0 X 90 450 5.25 5.25 316.43 623.38 A (4) 313.93 619.63 T 7 X 90 450 5.25 5.25 248 651.81 G 0 X 90 450 5.25 5.25 248 651.81 A (5) 245.5 648.06 T 7 X 90 450 5.25 5.25 217.43 641.66 G 0 X 90 450 5.25 5.25 217.43 641.66 A (6) 214.93 637.91 T 72 72 540 720 C 0 0 612 792 C 52 258 54 720 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "13" 14 %%Page: "14" 15 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 14) 508.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (4.3.2) 72 712 T (Security Indication is ROOT SCREENING) 108 712 T 0 10 Q -0.31 (This scenario traces the same leaf join by D as in Section) 90.86 695.33 P -0.31 (4.3.1. However, in this case, the root is assumed to have) 318.46 695.33 P -0.5 (specified a Security Indication of ROOT SCREENING, forcing all LEAF SETUP REQUEST messages to be forward-) 72 683.33 P (ed to the root. Client D initiates the operation using a LEAF SETUP REQUEST message, as shown below:) 72 671.33 T 0.31 (Once again, we assume that the network chooses the same route for forwarding the LEAF SETUP REQUEST data-) 72 455.33 P 0.28 (gram towards A, through nodes N5 and N1, where the call tree is bumped into. N1 receives the LEAF SETUP RE-) 72 443.33 P 1.18 (QUEST and determines that it is currently supporting the call. However, since the Security Indication is ROOT) 72 431.33 P 0 (SCREENING, N1 continues forwarding the message towards A and) 72 419.33 P 5 F 0 (does not) 347.52 419.33 P 0 F 0 ( cache any information about the LEAF) 381.13 419.33 P 0.09 (SETUP REQUEST datagram. N3 processes the LEAF SETUP REQUEST in the same manner, forwarding it across) 72 407.33 P (the UNI to A.) 72 395.33 T 0.29 (Client A receives the LEAF SETUP REQUEST, processes it, and if it chooses to accept D\325s request to join the) 90.86 379.33 P -0.15 (call, issues an ADD PARTY message. The ADD PARTY message contains D\325s address as the Called Party Number,) 72 367.33 P (a new Endpoint Reference for D and the LSN that D specified in the LEAF SETUP REQUEST \050if any\051.) 72 355.33 T -0.57 (The network processes the ADD PARTY following the standard phase 1 point-to-multipoint procedures, forward-) 90.86 339.33 P -0.24 (ing it along the call tree from N3 to N1, where it is converted into a SETUP message, which is forwarded onto N5 and) 72 327.33 P (D, as shown below:) 72 315.33 T -0.04 (When D receives the SETUP, it checks the LSN to verify that the SETUP is the result of D\325s previous LEAF SETUP) 72 87.33 P 0.34 (REQUEST \050as opposed to being from an independent ADD PARTY issued by A\051. Client D responds with a CON-) 72 75.33 P 72 72 540 720 C 179.72 466 432.28 668 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 257.46 577.18 248.72 572.33 253.57 581.08 254.81 578.42 4 Y 0 X 0 0 0 1 0 0 0 K V 302.72 626.33 254.81 578.42 2 L 0.5 H 2 Z N 319.57 605.25 314.72 614 323.46 609.15 320.81 607.91 4 Y V 359.72 569 320.81 607.91 2 L N 278.16 483 305.16 510 2 L 1 H N 359.16 618 386.16 645 2 L 3 H N 278.16 645 305.16 618 2 L N 206.16 564 251.16 564 2 L N 359.16 564 404.16 564 2 L 1 H N 359.16 510 386.16 483 2 L N 276.92 491.15 287.16 474 266.69 474 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 477.86 T 387.39 491.15 397.63 474 377.16 474 3 Y 7 X V 0 X N (E) 384.34 477.86 T 384.92 663 395.16 645.86 374.69 645.86 3 Y 7 X V 0 X N (C) 381.59 649.71 T 204.92 573 215.16 555.86 194.69 555.86 3 Y 7 X V 0 X N (A) 201.31 559.71 T 251.16 564.86 305.16 564.86 2 L 1 H N 305.16 564.86 359.16 564.86 2 L N 305.16 618.86 359.16 618.86 2 L 3 H N 305.16 510.86 359.16 510.86 2 L 1 H N 359.16 564.86 359.16 510.86 2 L N 305.16 564.86 305.16 510.86 2 L N 305.16 618.86 305.16 564.86 2 L N 359.16 618.86 359.16 564.86 2 L N 307.34 621.04 251.16 564.86 2 L 3 H N 305.16 510.86 248.97 567.04 2 L 1 H N 359.16 562.67 302.97 618.86 2 L N 359.16 567.04 302.97 510.86 2 L N 7 X 90 450 8.31 8.57 359.85 618.43 G 2 H 0 X 90 450 8.31 8.57 359.85 618.43 A (N2) 354.4 615.75 T 7 X 90 450 8.31 8.57 359.85 564.43 G 0 X 90 450 8.31 8.57 359.85 564.43 A (N5) 354.4 561.75 T 7 X 90 450 8.31 8.57 359.85 510.43 G 0 X 90 450 8.31 8.57 359.85 510.43 A (N7) 354.4 507.75 T 7 X 90 450 8.31 8.57 305.85 510.43 G 0 X 90 450 8.31 8.57 305.85 510.43 A (N6) 300.4 507.75 T 7 X 90 450 8.31 8.57 304.46 564.43 G 0 X 90 450 8.31 8.57 304.46 564.43 A (N4) 299.01 561.75 T 7 X 90 450 8.31 8.57 250.46 564.43 G 0 X 90 450 8.31 8.57 250.46 564.43 A (N3) 245.01 561.75 T 7 X 90 450 8.31 8.57 305.85 618.43 G 0 X 90 450 8.31 8.57 305.85 618.43 A (N1) 300.4 615.75 T 405.39 572.15 415.63 555 395.16 555 3 Y 7 X V 0.5 H 0 X N (D) 401.78 558.86 T 276.92 662.14 287.16 645 266.69 645 3 Y 7 X V 0 X N (B) 273.59 648.85 T 375.83 566.49 366.22 569.25 375.83 572.01 374.83 569.25 4 Y V 402.22 569.25 374.83 569.25 2 L N 0 7 Q (LSR) 378.52 571.39 T (LSR) 0 -42 336.05 595.56 TF (LSR) 0 -316 275.71 603.35 TF 7 X 90 450 5.25 5.25 380.43 582.66 G 0 X 90 450 5.25 5.25 380.43 582.66 A 2 9 Q (1) 377.93 578.91 T 7 X 90 450 5.25 5.25 333.8 605.05 G 0 X 90 450 5.25 5.25 333.8 605.05 A (2) 331.3 601.3 T 7 X 90 450 5.25 5.25 265.8 603.05 G 0 X 90 450 5.25 5.25 265.8 603.05 A (3) 263.3 599.3 T 216.33 566.24 206.72 569 216.33 571.76 215.33 569 4 Y V 242.72 569 215.33 569 2 L N 0 7 Q (LSR) 224.72 570.52 T 7 X 90 450 5.25 5.25 218.3 578.05 G 0 X 90 450 5.25 5.25 218.3 578.05 A 2 9 Q (4) 215.8 574.3 T 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 179.72 104 432.28 312 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 235.52 216.31 247.05 213 235.52 209.69 235.52 213 4 Y 0 X 0 0 0 1 0 0 0 K V 235.52 213 202.05 213 2 L 0.5 H 2 Z N 375.83 200.99 366.22 203.75 375.83 206.51 374.83 203.75 4 Y V 411.22 203.75 374.83 203.75 2 L N 395.11 215.76 404.72 213 395.11 210.24 396.11 213 4 Y V 359.72 213 396.11 213 2 L N 352.37 223.62 357.22 214.88 348.47 219.72 351.13 220.96 4 Y V 312.22 259.88 351.13 220.96 2 L N 278.16 127 305.16 154 2 L 1 H N 359.16 262 386.16 289 2 L 3 H N 278.16 289 305.16 262 2 L N 206.16 208 251.16 208 2 L N 359.16 208 404.16 208 2 L N 359.16 154 386.16 127 2 L 1 H N 276.92 135.15 287.16 118 266.69 118 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 121.86 T 387.39 135.15 397.63 118 377.16 118 3 Y 7 X V 0 X N (E) 384.34 121.86 T 384.92 307 395.16 289.86 374.69 289.86 3 Y 7 X V 0 X N (C) 381.59 293.71 T 204.92 217 215.16 199.86 194.69 199.86 3 Y 7 X V 0 X N (A) 201.31 203.71 T 251.16 208.86 305.16 208.86 2 L 1 H N 305.16 208.86 359.16 208.86 2 L N 305.16 262.86 359.16 262.86 2 L 3 H N 305.16 154.86 359.16 154.86 2 L 1 H N 359.16 208.86 359.16 154.86 2 L N 305.16 208.86 305.16 154.86 2 L N 305.16 262.86 305.16 208.86 2 L N 359.16 262.86 359.16 208.86 2 L N 307.34 265.04 251.16 208.86 2 L 3 H N 305.16 154.86 248.97 211.04 2 L 1 H N 359.16 206.67 302.97 262.86 2 L 3 H N 359.16 211.04 302.97 154.86 2 L 1 H N 7 X 90 450 8.31 8.57 359.85 262.43 G 2 H 0 X 90 450 8.31 8.57 359.85 262.43 A (N2) 354.4 259.75 T 7 X 90 450 8.31 8.57 359.85 208.43 G 0 X 90 450 8.31 8.57 359.85 208.43 A (N5) 354.4 205.75 T 7 X 90 450 8.31 8.57 359.85 154.43 G 0 X 90 450 8.31 8.57 359.85 154.43 A (N7) 354.4 151.75 T 7 X 90 450 8.31 8.57 305.85 154.43 G 0 X 90 450 8.31 8.57 305.85 154.43 A (N6) 300.4 151.75 T 7 X 90 450 8.31 8.57 304.46 208.43 G 0 X 90 450 8.31 8.57 304.46 208.43 A (N4) 299.01 205.75 T 7 X 90 450 8.31 8.57 250.46 208.43 G 0 X 90 450 8.31 8.57 250.46 208.43 A (N3) 245.01 205.75 T 7 X 90 450 8.31 8.57 305.85 262.43 G 0 X 90 450 8.31 8.57 305.85 262.43 A (N1) 300.4 259.75 T 405.39 216.15 415.63 199 395.16 199 3 Y 7 X V 0.5 H 0 X N (D) 401.78 202.86 T 276.92 306.14 287.16 289 266.69 289 3 Y 7 X V 0 X N (B) 273.59 292.85 T 0 7 Q (SETUP) 0 -45 326.04 249.08 TF 310.57 245.25 305.72 254 314.46 249.15 311.81 247.91 4 Y V 350.72 209 311.81 247.91 2 L N (SETUP) 371.22 214.52 T (CONNECT) 362.47 195.23 T (CONNECT) 0 -45 312.04 239.12 TF 286.22 256.18 296.72 262 290.9 251.51 288.56 253.84 4 Y V 288.56 253.84 251.72 217 2 L N (ADD) 0 -315 268.14 247.35 TF (PARTY) 0 -315 273.09 242.4 TF (ADD) 210.77 221.52 T (PARTY) 210.77 214.52 T 7 X 90 450 5.25 5.25 340.07 251.59 G 0 X 90 450 5.25 5.25 340.07 251.59 A 2 9 Q (3) 337.57 247.84 T 7 X 90 450 5.25 5.25 377.57 226.41 G 0 X 90 450 5.25 5.25 377.57 226.41 A (4) 375.07 222.66 T 7 X 90 450 5.25 5.25 377.71 188.16 G 0 X 90 450 5.25 5.25 377.71 188.16 A (5) 375.21 184.41 T 7 X 90 450 5.25 5.25 316.43 225.38 G 0 X 90 450 5.25 5.25 316.43 225.38 A (6) 313.93 221.63 T 7 X 90 450 5.25 5.25 261.8 257.39 G 0 X 90 450 5.25 5.25 261.8 257.39 A (2) 259.3 253.64 T 7 X 90 450 5.25 5.25 214.8 232.39 G 0 X 90 450 5.25 5.25 214.8 232.39 A (1) 212.3 228.64 T 72 72 540 720 C 0 0 612 792 C 52 72 54 720 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "14" 15 %%Page: "15" 16 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 15) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X 0.23 (NECT and is added to the call. \050Note: for simplicity, the optional CALL PROCEEDING messages and CONNECT) 72 713.33 P (ACKs are not shown above.\051) 72 701.33 T 0.56 (If the root A had not accepted the request, it would have issued a LEAF SETUP FAILURE message, with the) 90.86 685.33 P -0.32 (appropriate cause value, and echoed the LSN included by D \050if present\051. This LEAF SETUP FAILURE would be for-) 72 673.33 P (warded by the network back to D as a datagram \050that is, without network caching of any state information\051.) 72 661.33 T 1 12 Q (4.3.3) 72 640 T (Security Indication is OPEN, Network Supports Joins At Root Access Node Only) 108 640 T 0 10 Q 0.1 (This scenario traces the same leaf join by D as in Section) 90.86 623.33 P 0.1 (4.3.1 \050with a Security Indication of OPEN\051. However,) 322.98 623.33 P -0.09 (in this case, the network is assumed to force all LEAF SETUP REQUESTs to travel to the root\325s access node \050for ex-) 72 611.33 P -0.41 (ample, so that other network nodes do not have to cache information about LIJ calls and do not have to perform checks) 72 599.33 P -0.5 (on all LEAF SETUP REQUESTs to see if the call is at the current node\051. Client D initiates the operation using a LEAF) 72 587.33 P (SETUP REQUEST message, as shown below:) 72 575.33 T 0.28 (This time, we again assume that the network chooses to forward the LEAF SETUP REQUEST datagram towards A) 72 359.33 P -0.14 (through nodes N5 and N1, where it bumps into the call tree. When N1 receives the LEAF SETUP REQUEST, it sees) 72 347.33 P 0.58 (that it is rooted at N3. Hence, due to the network\325s policy, it knows that it does not support joins at this point and) 72 335.33 P -0.17 (knows to forward the message towards N3. When node N3 receives the LEAF SETUP REQUEST, it determines that) 72 323.33 P 0.19 (it is currently supporting the call and that the call is rooted locally. N3 then proceeds as in Section) 72 311.33 P 0.19 (4.3.1, simulating) 472.58 311.33 P 0.29 (receipt of an ADD PARTY message from the root to add D to the call \050and remembers that it is processing a LEAF) 72 299.33 P 0.56 (SETUP REQUEST from D\051. The remaining steps in this case are omitted since they are similar to those shown in) 72 287.33 P (Section) 72 275.33 T (4.3.1, the difference being that the join is initiated by the network at N3 rather than at N1.) 104.5 275.33 T 72 72 540 720 C 179.72 370 432.28 572 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 257.46 481.18 248.72 476.33 253.57 485.08 254.81 482.42 4 Y 0 X 0 0 0 1 0 0 0 K V 302.72 530.33 254.81 482.42 2 L 0.5 H 2 Z N 319.57 509.25 314.72 518 323.46 513.15 320.81 511.91 4 Y V 359.72 473 320.81 511.91 2 L N 278.16 387 305.16 414 2 L 1 H N 359.16 522 386.16 549 2 L 3 H N 278.16 549 305.16 522 2 L N 206.16 468 251.16 468 2 L N 359.16 468 404.16 468 2 L 1 H N 359.16 414 386.16 387 2 L N 276.92 395.15 287.16 378 266.69 378 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 381.86 T 387.39 395.15 397.63 378 377.16 378 3 Y 7 X V 0 X N (E) 384.34 381.86 T 384.92 567 395.16 549.86 374.69 549.86 3 Y 7 X V 0 X N (C) 381.59 553.71 T 204.92 477 215.16 459.86 194.69 459.86 3 Y 7 X V 0 X N (A) 201.31 463.71 T 251.16 468.86 305.16 468.86 2 L 1 H N 305.16 468.86 359.16 468.86 2 L N 305.16 522.86 359.16 522.86 2 L 3 H N 305.16 414.86 359.16 414.86 2 L 1 H N 359.16 468.86 359.16 414.86 2 L N 305.16 468.86 305.16 414.86 2 L N 305.16 522.86 305.16 468.86 2 L N 359.16 522.86 359.16 468.86 2 L N 307.34 525.04 251.16 468.86 2 L 3 H N 305.16 414.86 248.97 471.04 2 L 1 H N 359.16 466.67 302.97 522.86 2 L N 359.16 471.04 302.97 414.86 2 L N 7 X 90 450 8.31 8.57 359.85 522.43 G 2 H 0 X 90 450 8.31 8.57 359.85 522.43 A (N2) 354.4 519.75 T 7 X 90 450 8.31 8.57 359.85 468.43 G 0 X 90 450 8.31 8.57 359.85 468.43 A (N5) 354.4 465.75 T 7 X 90 450 8.31 8.57 359.85 414.43 G 0 X 90 450 8.31 8.57 359.85 414.43 A (N7) 354.4 411.75 T 7 X 90 450 8.31 8.57 305.85 414.43 G 0 X 90 450 8.31 8.57 305.85 414.43 A (N6) 300.4 411.75 T 7 X 90 450 8.31 8.57 304.46 468.43 G 0 X 90 450 8.31 8.57 304.46 468.43 A (N4) 299.01 465.75 T 7 X 90 450 8.31 8.57 250.46 468.43 G 0 X 90 450 8.31 8.57 250.46 468.43 A (N3) 245.01 465.75 T 7 X 90 450 8.31 8.57 305.85 522.43 G 0 X 90 450 8.31 8.57 305.85 522.43 A (N1) 300.4 519.75 T 405.39 476.15 415.63 459 395.16 459 3 Y 7 X V 0.5 H 0 X N (D) 401.78 462.86 T 276.92 566.14 287.16 549 266.69 549 3 Y 7 X V 0 X N (B) 273.59 552.85 T 375.83 470.49 366.22 473.25 375.83 476.01 374.83 473.25 4 Y V 402.22 473.25 374.83 473.25 2 L N 0 7 Q (LSR) 378.52 475.39 T (LSR) 0 -42 336.05 499.56 TF (LSR) 0 -316 275.71 507.35 TF 7 X 90 450 5.25 5.25 380.43 486.66 G 0 X 90 450 5.25 5.25 380.43 486.66 A 2 9 Q (1) 377.93 482.91 T 7 X 90 450 5.25 5.25 333.8 509.05 G 0 X 90 450 5.25 5.25 333.8 509.05 A (2) 331.3 505.3 T 7 X 90 450 5.25 5.25 265.8 507.05 G 0 X 90 450 5.25 5.25 265.8 507.05 A (3) 263.3 503.3 T 72 72 540 720 C 0 0 612 792 C 52 272 54 720 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "15" 16 %%Page: "16" 17 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 16) 508.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (4.4) 72 712 T (Unsuccessful LEAF SETUP REQUEST by Leaf) 99 712 T 0 10 Q 0.27 (We now give a failure scenario to show the internal interactions that occur on failure. In this example, client E) 90.86 695.33 P -0.56 (issues a LEAF SETUP REQUEST message with GCID = A.1.2 and LSN = 1. The LEAF SETUP REQUEST message) 72 683.33 P (proceeds through N7, and from there to N5, as shown below:) 72 671.33 T 0.46 (At node N5, the LEAF SETUP REQUEST triggers a simulated ADD PARTY, and is immediately translated into a) 72 443.33 P 0.03 (SETUP, which is sent back to N7. At N7, there are insufficient resources to support the call, so N7 clears the call by) 72 431.33 P (sending a RELEASE COMPLETE message back to N5, as shown below:) 72 419.33 T 0.49 (At N5, the RELEASE COMPLETE message is recognized as a response to the LEAF SETUP REQUEST. So, N5) 72 191.33 P 0.5 (creates a LEAF SETUP FAILURE message and includes the cause code from the RELEASE COMPLETE and the) 72 179.33 P (LSN from the LEAF SETUP REQUEST. It then sends the LEAF SETUP FAILURE to E.) 72 167.33 T 72 72 540 720 C 179.72 460 432.28 668 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 362.44 494.13 357.59 502.88 366.34 498.03 363.68 496.79 4 Y 0 X 0 0 0 1 0 0 0 K V 384.59 475.88 363.68 496.79 2 L 0.5 H 2 Z N 351.71 551.01 354.47 560.62 357.23 551.01 354.47 552.02 4 Y V 354.47 515.62 354.47 552.02 2 L N 366.48 525.24 363.72 515.62 360.96 525.24 363.72 524.23 4 Y V 363.72 560.62 363.72 524.23 2 L N 359.72 563.12 404.72 563.12 2 L 3 H N 278.16 483 305.16 510 2 L 1 H N 359.16 618 386.16 645 2 L 3 H N 278.16 645 305.16 618 2 L N 206.16 564 251.16 564 2 L N 359.16 510 386.16 483 2 L 1 H N 276.92 491.15 287.16 474 266.69 474 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 477.86 T 387.39 491.15 397.63 474 377.16 474 3 Y 7 X V 0 X N (E) 384.34 477.86 T 384.92 663 395.16 645.86 374.69 645.86 3 Y 7 X V 0 X N (C) 381.59 649.71 T 204.92 573 215.16 555.86 194.69 555.86 3 Y 7 X V 0 X N (A) 201.31 559.71 T 251.16 564.86 305.16 564.86 2 L 1 H N 305.16 564.86 359.16 564.86 2 L N 305.16 618.86 359.16 618.86 2 L 3 H N 305.16 510.86 359.16 510.86 2 L 1 H N 359.16 564.86 359.16 510.86 2 L N 305.16 564.86 305.16 510.86 2 L N 305.16 618.86 305.16 564.86 2 L N 359.16 618.86 359.16 564.86 2 L N 307.34 621.04 251.16 564.86 2 L 3 H N 305.16 510.86 248.97 567.04 2 L 1 H N 359.16 562.67 302.97 618.86 2 L 3 H N 359.16 567.04 302.97 510.86 2 L 1 H N 7 X 90 450 8.31 8.57 359.85 618.43 G 2 H 0 X 90 450 8.31 8.57 359.85 618.43 A (N2) 354.4 615.75 T 7 X 90 450 8.31 8.57 359.85 564.43 G 0 X 90 450 8.31 8.57 359.85 564.43 A (N5) 354.4 561.75 T 7 X 90 450 8.31 8.57 359.85 510.43 G 0 X 90 450 8.31 8.57 359.85 510.43 A (N7) 354.4 507.75 T 7 X 90 450 8.31 8.57 305.85 510.43 G 0 X 90 450 8.31 8.57 305.85 510.43 A (N6) 300.4 507.75 T 7 X 90 450 8.31 8.57 304.46 564.43 G 0 X 90 450 8.31 8.57 304.46 564.43 A (N4) 299.01 561.75 T 7 X 90 450 8.31 8.57 250.46 564.43 G 0 X 90 450 8.31 8.57 250.46 564.43 A (N3) 245.01 561.75 T 7 X 90 450 8.31 8.57 305.85 618.43 G 0 X 90 450 8.31 8.57 305.85 618.43 A (N1) 300.4 615.75 T 405.39 572.15 415.63 555 395.16 555 3 Y 7 X V 0.5 H 0 X N (D) 401.78 558.86 T 276.92 662.14 287.16 645 266.69 645 3 Y 7 X V 0 X N (B) 273.59 648.85 T 0 7 Q (LSR) 0 -45 363.71 486.33 TF (LSR) 0 -270 351.28 529.21 TF 370.52 562.29 363.74 554.82 365.53 564.75 367.58 562.61 4 Y V 340.27 589 9.02 15 359.1 567.67 A (SETUP) 0 -90 367.11 547.07 TF 7 X 90 450 5.25 5.25 358.64 481.02 G 0 X 90 450 5.25 5.25 358.64 481.02 A 2 9 Q (1) 356.14 477.27 T 7 X 90 450 5.25 5.25 340.86 526.81 G 0 X 90 450 5.25 5.25 340.86 526.81 A (2) 338.36 523.06 T 7 X 90 450 5.25 5.25 379.14 536.66 G 0 X 90 450 5.25 5.25 379.14 536.66 A (3) 376.64 532.92 T 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 179.72 208 432.28 416 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 376.62 236.37 381.47 227.62 372.72 232.47 375.38 233.71 4 Y 0 X 0 0 0 1 0 0 0 K V 375.38 233.71 354.47 254.62 2 L 0.5 H 2 Z N 357.23 273.24 354.47 263.62 351.71 273.24 354.47 272.23 4 Y V 354.47 272.23 354.47 308.62 2 L N 360.96 295.26 363.72 304.88 366.48 295.26 363.72 296.27 4 Y V 363.72 259.88 363.72 296.27 2 L N 359.72 311.12 404.72 311.12 2 L 3 H N 278.16 231 305.16 258 2 L 1 H N 359.16 366 386.16 393 2 L 3 H N 278.16 393 305.16 366 2 L N 206.16 312 251.16 312 2 L N 359.16 258 386.16 231 2 L 1 H N 276.92 239.15 287.16 222 266.69 222 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 225.86 T 387.39 239.15 397.63 222 377.16 222 3 Y 7 X V 0 X N (E) 384.34 225.86 T 384.92 411 395.16 393.86 374.69 393.86 3 Y 7 X V 0 X N (C) 381.59 397.71 T 204.92 321 215.16 303.86 194.69 303.86 3 Y 7 X V 0 X N (A) 201.31 307.71 T 251.16 312.86 305.16 312.86 2 L 1 H N 305.16 312.86 359.16 312.86 2 L N 305.16 366.86 359.16 366.86 2 L 3 H N 305.16 258.86 359.16 258.86 2 L 1 H N 359.16 312.86 359.16 258.86 2 L N 305.16 312.86 305.16 258.86 2 L N 305.16 366.86 305.16 312.86 2 L N 359.16 366.86 359.16 312.86 2 L N 307.34 369.04 251.16 312.86 2 L 3 H N 305.16 258.86 248.97 315.04 2 L 1 H N 359.16 310.67 302.97 366.86 2 L 3 H N 359.16 315.04 302.97 258.86 2 L 1 H N 7 X 90 450 8.31 8.57 359.85 366.43 G 2 H 0 X 90 450 8.31 8.57 359.85 366.43 A (N2) 354.4 363.75 T 7 X 90 450 8.31 8.57 359.85 312.43 G 0 X 90 450 8.31 8.57 359.85 312.43 A (N5) 354.4 309.75 T 7 X 90 450 8.31 8.57 359.85 258.43 G 0 X 90 450 8.31 8.57 359.85 258.43 A (N7) 354.4 255.75 T 7 X 90 450 8.31 8.57 305.85 258.43 G 0 X 90 450 8.31 8.57 305.85 258.43 A (N6) 300.4 255.75 T 7 X 90 450 8.31 8.57 304.46 312.43 G 0 X 90 450 8.31 8.57 304.46 312.43 A (N4) 299.01 309.75 T 7 X 90 450 8.31 8.57 250.46 312.43 G 0 X 90 450 8.31 8.57 250.46 312.43 A (N3) 245.01 309.75 T 7 X 90 450 8.31 8.57 305.85 366.43 G 0 X 90 450 8.31 8.57 305.85 366.43 A (N1) 300.4 363.75 T 405.39 320.15 415.63 303 395.16 303 3 Y 7 X V 0.5 H 0 X N (D) 401.78 306.86 T 276.92 410.14 287.16 393 266.69 393 3 Y 7 X V 0 X N (B) 273.59 396.85 T 0 7 Q (LSF) 0 -45 356.42 243.08 TF (LSF) 0 -90 348.99 294.5 TF 352.57 314.52 353.18 304.35 347.28 312.65 350.26 312.62 4 Y V 301 551.73 9.02 15 359.1 315.67 A (RELASE) 0 -90 375.36 301.25 TF (COMPLETE) 0 -90 368.36 301.25 TF 7 X 90 450 5.25 5.25 387.57 289.09 G 0 X 90 450 5.25 5.25 387.57 289.09 A 2 9 Q (1) 385.07 285.34 T 7 X 90 450 5.25 5.25 342 280.38 G 0 X 90 450 5.25 5.25 342 280.38 A (2) 339.5 276.63 T 7 X 90 450 5.25 5.25 355 232.38 G 0 X 90 450 5.25 5.25 355 232.38 A (3) 352.5 228.63 T 72 72 540 720 C 0 0 612 792 C 52 708 54 720 R 0 X 0 0 0 1 0 0 0 K V 52 680 54 690 R V FMENDPAGE %%EndPage: "16" 17 %%Page: "17" 18 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 17) 508.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (4.5) 72 712 T (LEAF SETUP REQUEST Timeout) 99 712 T 0 10 Q -0.09 (When a leaf sends a LEAF SETUP REQUEST message, a timer is started. The LEAF SETUP REQUEST is ac-) 90.86 695.33 P 0.05 (knowledged by the receipt of either: a SETUP message \050on success\051 or a LEAF SETUP FAILURE message \050on fail-) 72 683.33 P -0.21 (ure\051. By inserting an LSN in the LEAF SETUP REQUEST message, the leaf can match the request with the response) 72 671.33 P 0.05 (in the event that multiple LEAF SETUP REQUESTs are pending. The following diagram shows the situation where) 72 659.33 P 0.12 (client F issues a LEAF SETUP REQUEST with LSN = 1, times this request out, then issues a second LEAF SETUP) 72 647.33 P (REQUEST with LSN = 2:) 72 635.33 T -0.42 (At this point, it is possible that both LEAF SETUP REQUESTs could be processed and acknowledged by the network.) 72 407.33 P -0.53 (Client F can distinguish which one is being acknowledged by the LSN in the SETUP or LEAF SETUP FAILURE mes-) 72 395.33 P (sage returned. The following diagram shows this case, where two SETUPs have been returned:) 72 383.33 T 0.15 (There is no requirement that F accept one of the SETUPs over the other. It can choose to accept either one \050or both,) 72 155.33 P -0.18 (if it so chooses\051. In all likelihood, F will accept the first SETUP message to arrive \050the one with LSN = 2 in this case\051) 72 143.33 P 72 72 540 720 C 179.72 424 432.28 632 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 296.35 462.65 305.09 467.5 300.25 458.75 299.01 461.41 4 Y 0 X 0 0 0 1 0 0 0 K V 299.01 461.41 278.09 440.5 2 L 0.5 H 2 Z N 305.16 582.86 305.16 528.86 2 L 1 H N 306.34 565.89 309.09 575.5 311.85 565.89 309.09 566.89 4 Y V 309.09 566.89 309.09 530.5 2 L 0.5 H N 290.47 469.53 299.22 474.38 294.37 465.63 293.13 468.29 4 Y V 293.13 468.29 272.22 447.38 2 L N 306.71 513.14 309.47 522.75 312.23 513.14 309.47 514.14 4 Y V 309.47 514.14 309.47 477.75 2 L N 262.44 517.75 257.59 526.5 266.34 521.65 263.68 520.41 4 Y V 302.59 481.5 263.68 520.41 2 L N 359.72 527.12 404.72 527.12 2 L 3 H N 278.16 447 305.16 474 2 L 1 H N 359.16 582 386.16 609 2 L 3 H N 278.16 609 305.16 582 2 L N 206.16 528 251.16 528 2 L N 359.16 474 386.16 447 2 L 1 H N 276.92 455.15 287.16 438 266.69 438 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 441.86 T 387.39 455.15 397.63 438 377.16 438 3 Y 7 X V 0 X N (E) 384.34 441.86 T 384.92 627 395.16 609.86 374.69 609.86 3 Y 7 X V 0 X N (C) 381.59 613.71 T 204.92 537 215.16 519.86 194.69 519.86 3 Y 7 X V 0 X N (A) 201.31 523.71 T 305.16 528.86 251.16 528.86 2 L 1 H N 305.16 528.86 359.16 528.86 2 L N 305.16 582.86 359.16 582.86 2 L 3 H N 305.16 474.86 359.16 474.86 2 L 1 H N 359.16 528.86 359.16 474.86 2 L N 305.16 528.86 305.16 474.86 2 L N 359.16 582.86 359.16 528.86 2 L N 307.34 585.04 251.16 528.86 2 L 3 H N 305.16 474.86 248.97 531.04 2 L 1 H N 359.16 526.67 302.97 582.86 2 L 3 H N 359.16 531.04 302.97 474.86 2 L 1 H N 7 X 90 450 8.31 8.57 359.85 582.43 G 2 H 0 X 90 450 8.31 8.57 359.85 582.43 A (N2) 354.4 579.75 T 7 X 90 450 8.31 8.57 359.85 528.43 G 0 X 90 450 8.31 8.57 359.85 528.43 A (N5) 354.4 525.75 T 7 X 90 450 8.31 8.57 359.85 474.43 G 0 X 90 450 8.31 8.57 359.85 474.43 A (N7) 354.4 471.75 T 7 X 90 450 8.31 8.57 305.85 474.43 G 0 X 90 450 8.31 8.57 305.85 474.43 A (N6) 300.4 471.75 T 7 X 90 450 8.31 8.57 304.46 528.43 G 0 X 90 450 8.31 8.57 304.46 528.43 A (N4) 299.01 525.75 T 7 X 90 450 8.31 8.57 250.46 528.43 G 0 X 90 450 8.31 8.57 250.46 528.43 A (N3) 245.01 525.75 T 7 X 90 450 8.31 8.57 305.85 582.43 G 0 X 90 450 8.31 8.57 305.85 582.43 A (N1) 300.4 579.75 T 405.39 536.15 415.63 519 395.16 519 3 Y 7 X V 0.5 H 0 X N (D) 401.78 522.86 T 276.92 626.14 287.16 609 266.69 609 3 Y 7 X V 0 X N (B) 273.59 612.85 T 0 7 Q ( LSR\0502\051) 0 -315 274.17 451.76 TF ( LSR\0501\051) 0 -315 286.03 440.22 TF ( LSR\0501\051) 0 -90 312 509.97 TF ( LSR\0502\051) 0 -45 274.49 513.92 TF ( LSR\0501\051) 0 -90 311.26 559.51 TF 7 X 90 450 5.25 5.25 303.14 445.52 G 0 X 90 450 5.25 5.25 303.14 445.52 A 2 9 Q (1) 300.64 441.77 T 7 X 90 450 5.25 5.25 323.29 508.95 G 0 X 90 450 5.25 5.25 323.29 508.95 A (2) 320.78 505.2 T 7 X 90 450 5.25 5.25 322 545.24 G 0 X 90 450 5.25 5.25 322 545.24 A (3) 319.5 541.49 T 7 X 90 450 5.25 5.25 275 470.09 G 0 X 90 450 5.25 5.25 275 470.09 A (4) 272.5 466.34 T 7 X 90 450 5.25 5.25 285.86 517.81 G 0 X 90 450 5.25 5.25 285.86 517.81 A (5) 283.36 514.06 T 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 179.72 172 432.28 380 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 290.84 197.72 282.09 192.88 286.94 201.62 288.18 198.96 4 Y 0 X 0 0 0 1 0 0 0 K V 309.09 219.88 288.18 198.96 2 L 0.5 H 2 Z N 285.34 206.1 276.59 201.25 281.44 210 282.68 207.34 4 Y V 303.59 228.25 282.68 207.34 2 L N 303.48 238.49 300.72 228.88 297.96 238.49 300.72 237.48 4 Y V 300.72 273.88 300.72 237.48 2 L N 305.16 330.86 305.16 276.86 2 L 1 H N 359.72 275.12 404.72 275.12 2 L 3 H N 278.16 195 305.16 222 2 L 1 H N 359.16 330 386.16 357 2 L 3 H N 278.16 357 305.16 330 2 L N 206.16 276 251.16 276 2 L N 359.16 222 386.16 195 2 L 1 H N 276.92 203.15 287.16 186 266.69 186 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 189.86 T 387.39 203.15 397.63 186 377.16 186 3 Y 7 X V 0 X N (E) 384.34 189.86 T 384.92 375 395.16 357.86 374.69 357.86 3 Y 7 X V 0 X N (C) 381.59 361.71 T 204.92 285 215.16 267.86 194.69 267.86 3 Y 7 X V 0 X N (A) 201.31 271.71 T 305.16 276.86 251.16 276.86 2 L 1 H N 305.16 276.86 359.16 276.86 2 L N 305.16 330.86 359.16 330.86 2 L 3 H N 305.16 222.86 359.16 222.86 2 L 1 H N 359.16 276.86 359.16 222.86 2 L N 305.16 276.86 305.16 222.86 2 L N 359.16 330.86 359.16 276.86 2 L N 307.34 333.04 251.16 276.86 2 L 3 H N 305.16 222.86 248.97 279.04 2 L 1 H N 359.16 274.67 302.97 330.86 2 L 3 H N 359.16 279.04 302.97 222.86 2 L 1 H N 7 X 90 450 8.31 8.57 359.85 330.43 G 2 H 0 X 90 450 8.31 8.57 359.85 330.43 A (N2) 354.4 327.75 T 7 X 90 450 8.31 8.57 359.85 276.43 G 0 X 90 450 8.31 8.57 359.85 276.43 A (N5) 354.4 273.75 T 7 X 90 450 8.31 8.57 359.85 222.43 G 0 X 90 450 8.31 8.57 359.85 222.43 A (N7) 354.4 219.75 T 7 X 90 450 8.31 8.57 305.85 222.43 G 0 X 90 450 8.31 8.57 305.85 222.43 A (N6) 300.4 219.75 T 7 X 90 450 8.31 8.57 304.46 276.43 G 0 X 90 450 8.31 8.57 304.46 276.43 A (N4) 299.01 273.75 T 7 X 90 450 8.31 8.57 250.46 276.43 G 0 X 90 450 8.31 8.57 250.46 276.43 A (N3) 245.01 273.75 T 7 X 90 450 8.31 8.57 305.85 330.43 G 0 X 90 450 8.31 8.57 305.85 330.43 A (N1) 300.4 327.75 T 405.39 284.15 415.63 267 395.16 267 3 Y 7 X V 0.5 H 0 X N (D) 401.78 270.86 T 276.92 374.14 287.16 357 266.69 357 3 Y 7 X V 0 X N (B) 273.59 360.85 T 0 7 Q (SETUP\0502\051) 0 -315 273.25 202.95 TF (SETUP\0501\051) 0 -315 290.62 190.07 TF (SETUP\0501\051) 0 -270 298.08 289 TF 302.6 291.24 299.84 281.62 297.09 291.24 299.84 290.23 4 Y V 299.84 326.62 299.84 290.23 2 L N (SETUP\0501\051) 0 -270 298.99 239.75 TF 293.75 232.37 298.59 223.62 289.85 228.47 292.51 229.71 4 Y V 253.59 268.62 292.51 229.71 2 L N (SETUP\0502\051) 0 -45 256.54 255.71 TF (SETUP\0501\051) 0 -270 298.99 239.75 TF 7 X 90 450 5.25 5.25 286.61 298.98 G 0 X 90 450 5.25 5.25 286.61 298.98 A 2 9 Q (1) 284.11 295.23 T 7 X 90 450 5.25 5.25 287.93 255.38 G 0 X 90 450 5.25 5.25 287.93 255.38 A (3) 285.43 251.63 T 7 X 90 450 5.25 5.25 256.43 245.52 G 0 X 90 450 5.25 5.25 256.43 245.52 A (2) 253.93 241.77 T 7 X 90 450 5.25 5.25 270.14 216.52 G 0 X 90 450 5.25 5.25 270.14 216.52 A (4) 267.64 212.77 T 7 X 90 450 5.25 5.25 304.32 192.95 G 0 X 90 450 5.25 5.25 304.32 192.95 A (5) 301.82 189.2 T 72 72 540 720 C 0 0 612 792 C FMENDPAGE %%EndPage: "17" 18 %%Page: "18" 19 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 18) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X (and deny the second message, as depicted below:) 72 713.33 T -0.36 (Note that if the two LEAF SETUP REQUESTs had intercepted to the call tree at the same node, the second join would) 72 485.33 P 0.12 (have waited for the pending SETUP to complete, and, if accepted, would have resulted in an ADD PARTY message) 72 473.33 P 0.07 (to F with LSN = 2. This waiting for the SETUP to complete is as per the existing phase 1 point-to-multipoint proce-) 72 461.33 P (dures.) 72 449.33 T 1 12 Q (5) 72 424 T (Options for Adding Security) 90 424 T 0 10 Q -0.29 (In Section) 90.86 407.33 P -0.29 (3.2, we introduced two security options: OPEN and ROOT SCREENING. A third security option that) 133.89 407.33 P 0.14 (we are currently investigating is that of) 72 395.33 P 5 F 0.14 (access list) 232.12 395.33 P 0 F 0.14 ( security, where the root specifies a list of addresses of parties that) 273.09 395.33 P -0.44 (are allowed to join the call. If any of these parties issues a LEAF SETUP REQUEST, the party\325s address will be found) 72 383.33 P 0.26 (on the access list when the call tree is bumped into and a SETUP will be returned to add the party into the call. If a) 72 371.33 P 0.43 (party not on the list issues a LEAF SETUP REQUEST, its address will not be found on the access list and a LEAF) 72 359.33 P -0.05 (SETUP FAILURE will be returned with a cause code indicating permission to join the call was denied \050alternatively,) 72 347.33 P (the LEAF SETUP REQUEST could be forwarded to the root for root screening\051.) 72 335.33 T -0.62 (Taking this one step further, the access list could contain address prefixes in addition to complete addresses, where) 90.86 319.33 P -0.32 (all parties whose address matches the prefix are allowed to join the call. This option would be useful in environments,) 72 307.33 P 0.03 (for example, where all parties on the same subnet as the root are allowed to access the service offered by the root but) 72 295.33 P 0.41 (no other parties \050outside of the root\325s subnet\051 are given access. The access list itself could be specified either as an) 72 283.33 P (extension to the LIJP information element or in a separate information element.) 72 271.33 T 1 12 Q (6) 72 246 T (Third Party Call Setup) 90 246 T 0 10 Q 0.03 (Our approach to leaf initiated joins provides a framework upon which third party call setup support can be built.) 90.86 229.33 P 0.25 (For example, the third party could issue the LEAF SETUP REQUEST on behalf of another party to initiate creation) 72 217.33 P 0.13 (of a new call \050depicted in Figure) 72 205.33 P 0.13 (6\051 or joining of a party to an ongoing point-to-multipoint call \050depicted in Figure) 205.26 205.33 P 0.13 (7,) 532.5 205.33 P -0.05 (where the Security Indication is assumed to specify ROOT SCREENING\051. To facilitate this functionality, the LEAF) 72 193.33 P (SETUP REQUEST should be modified to include the following two information elements:) 72 181.33 T (\245) 90 165.33 T (Initiator Number\321to identify the third party initiating the call setup, and) 99.21 165.33 T (\245) 90 149.33 T -0.57 (Initiator Subaddress\321for use when traversing public networks that do not support private ATM Forum address-) 99.21 149.33 P (es.) 99 137.33 T 0.19 (Additionally, a new message, the LEAF SETUP ACK, should be introduced so that the third party can obtain an ac-) 72 121.33 P -0.43 (knowledgment of successful call creations and leaf additions \050recall that the acknowledgment is implicit in the SETUP) 72 109.33 P (message for leafs that add themselves\051.) 72 97.33 T 72 72 540 720 C 179.72 502 432.28 710 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 296.6 540.65 305.34 545.5 300.5 536.75 299.26 539.41 4 Y 0 X 0 0 0 1 0 0 0 K V 299.26 539.41 278.34 518.5 2 L 0.5 H 2 Z N 289.22 547.15 297.97 552 293.12 543.25 291.88 545.91 4 Y V 291.88 545.91 270.97 525 2 L N 297.71 647.89 300.47 657.5 303.23 647.89 300.47 648.89 4 Y V 300.47 648.89 300.47 560.38 2 L N 305.16 660.86 305.16 606.86 2 L 1 H N 359.72 605.12 404.72 605.12 2 L 3 H N 278.16 525 305.16 552 2 L N 359.16 660 386.16 687 2 L N 278.16 687 305.16 660 2 L N 206.16 606 251.16 606 2 L N 359.16 552 386.16 525 2 L 1 H N 276.92 533.15 287.16 516 266.69 516 3 Y 7 X V 0.5 H 0 X N 0 10 Q (F) 274.14 519.86 T 387.39 533.15 397.63 516 377.16 516 3 Y 7 X V 0 X N (E) 384.34 519.86 T 384.92 705 395.16 687.86 374.69 687.86 3 Y 7 X V 0 X N (C) 381.59 691.71 T 204.92 615 215.16 597.86 194.69 597.86 3 Y 7 X V 0 X N (A) 201.31 601.71 T 305.16 606.86 251.16 606.86 2 L 1 H N 305.16 606.86 359.16 606.86 2 L N 305.16 660.86 359.16 660.86 2 L 3 H N 305.16 552.86 359.16 552.86 2 L 1 H N 359.16 606.86 359.16 552.86 2 L N 305.16 606.86 305.16 552.86 2 L N 359.16 660.86 359.16 606.86 2 L N 307.34 663.04 251.16 606.86 2 L 3 H N 305.16 552.86 248.97 609.04 2 L N 359.16 604.67 302.97 660.86 2 L N 359.16 609.04 302.97 552.86 2 L 1 H N 7 X 90 450 8.31 8.57 359.85 660.43 G 2 H 0 X 90 450 8.31 8.57 359.85 660.43 A (N2) 354.4 657.75 T 7 X 90 450 8.31 8.57 359.85 606.43 G 0 X 90 450 8.31 8.57 359.85 606.43 A (N5) 354.4 603.75 T 7 X 90 450 8.31 8.57 359.85 552.43 G 0 X 90 450 8.31 8.57 359.85 552.43 A (N7) 354.4 549.75 T 7 X 90 450 8.31 8.57 305.85 552.43 G 0 X 90 450 8.31 8.57 305.85 552.43 A (N6) 300.4 549.75 T 7 X 90 450 8.31 8.57 304.46 606.43 G 0 X 90 450 8.31 8.57 304.46 606.43 A (N4) 299.01 603.75 T 7 X 90 450 8.31 8.57 250.46 606.43 G 0 X 90 450 8.31 8.57 250.46 606.43 A (N3) 245.01 603.75 T 7 X 90 450 8.31 8.57 305.85 660.43 G 0 X 90 450 8.31 8.57 305.85 660.43 A (N1) 300.4 657.75 T 405.39 614.15 415.63 597 395.16 597 3 Y 7 X V 0.5 H 0 X N (D) 401.78 600.86 T 276.92 704.14 287.16 687 266.69 687 3 Y 7 X V 0 X N (B) 273.59 690.85 T 0 7 Q (CONN\0502\051) 0 -315 274.98 533.83 TF (REL\0501\051) 0 -270 291.33 616.62 TF 258.44 589.88 253.59 598.62 262.34 593.78 259.68 592.54 4 Y V 259.68 592.54 298.59 553.62 2 L N (CONN\0502\051) 0 -45 258.53 583.54 TF (COMP) 0 -270 298.33 616.62 TF (REL\0501\051) 0 -270 292.54 576.83 TF (COMP) 0 -270 299.54 576.83 TF (REL\0501\051) 0 -315 291.03 522.04 TF (COMP) 0 -315 295.98 517.08 TF 7 X 90 450 5.25 5.25 272.43 547.66 G 0 X 90 450 5.25 5.25 272.43 547.66 A 2 9 Q (1) 269.93 543.91 T 7 X 90 450 5.25 5.25 258.29 573.95 G 0 X 90 450 5.25 5.25 258.29 573.95 A (2) 255.78 570.2 T 7 X 90 450 5.25 5.25 311.29 523.09 G 0 X 90 450 5.25 5.25 311.29 523.09 A (3) 308.78 519.34 T 7 X 90 450 5.25 5.25 280.71 597.24 G 0 X 90 450 5.25 5.25 280.71 597.24 A (4) 278.21 593.49 T 7 X 90 450 5.25 5.25 279.71 617.52 G 0 X 90 450 5.25 5.25 279.71 617.52 A (5) 277.21 613.77 T 72 72 540 720 C 0 0 612 792 C 52 392 54 414 R 0 X 0 0 0 1 0 0 0 K V 52 316 54 354 R V 52 94 54 278 R V FMENDPAGE %%EndPage: "18" 19 %%Page: "19" 20 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 19) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X -0.35 (To further generalize the third party call setup capability, multiple New Leaf Number information elements could) 90.86 234.29 P (be allowed in the LEAF SETUP REQUEST so that a third party can add multiple parties with one message.) 72 222.29 T -0.11 (This proposed solution only addresses one aspect of the third party call setup problem. Namely, initiation by the) 90.86 206.29 P 0.07 (third party, where the parties to be connected are capable of running the signalling protocol. The other aspect of this) 72 194.29 P -0.28 (problem is redirection of signalling messages from the parties to be added to a) 72 182.29 P 5 F -0.28 (surrogate) 383.61 182.29 P 0 F -0.28 ( signalling entity \050or entities\051,) 422.5 182.29 P -0.12 (for use when the parties to be added are not capable of running the signalling protocol. Our solution does not address) 72 170.29 P (this aspect of the problem.) 72 158.29 T 1 12 Q (7) 72 132.96 T (Textual Modifications) 90 132.96 T 0 10 Q -0.16 (This section contains) 90.86 116.29 P 196.21 115.2 177.33 115.2 2 L V 0.49 H 0 Z N -0.16 (draft) 177.33 116.29 P -0.16 ( textual modifications for adding the leaf initiated join capability to the UNI signalling) 196.21 116.29 P -0.13 (protocol. We have not \050yet\051 completed a detailed review of the contents of this section, but have decided to include it) 72 104.29 P -0.12 (in this revision to give the ATM Forum membership more concrete specifics on how the LIJ capability will be imple-) 72 92.29 P (mented and to seek early feedback on the approach we are pursuing.) 72 80.29 T 72 72 540 720 C 72 503.93 540 720 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 349.01 558.55 360.59 555.39 349.1 551.93 349.05 555.24 4 Y 0 X 0 0 0 1 0 0 0 K V 269.03 602.54 M 280.19 575.38 309.98 564.76 336.3 556.53 D 340.46 555.23 344.75 555.12 349.06 555.23 D 0.5 H 2 Z N 7 X 90 450 7.5 7.5 294.53 574.04 G 0 X 90 450 7.5 7.5 294.53 574.04 A 2 12 Q (5) 291.19 569.66 T 2 10 Q (setup) 305.42 570.87 T 251.2 572.54 254.88 583.96 257.81 572.33 254.5 572.43 4 Y V 359.03 548.54 M 332.3 522.04 282.49 540.29 259.88 563.96 D 257.59 566.35 255.65 569.3 254.51 572.42 D N 7 X 90 450 7.5 7.5 285.53 547.04 G 0 X 90 450 7.5 7.5 285.53 547.04 A 2 12 Q (6) 282.19 542.66 T 2 10 Q (connect) 296.03 544.58 T 214.73 665.93 M 206.26 666.69 193.02 669.19 191.17 657.98 D 190.76 655.49 189.66 652.14 191.13 649.63 D 195.51 642.16 190.35 633.3 193.56 626.18 D 194.86 623.3 194.85 620.29 195.73 617.43 D 196.72 614.22 199.27 611.82 200.9 610.27 D 205.7 605.75 211.83 607.36 216.69 608.06 D 220.14 608.55 223.07 611.09 226.71 609.88 D 230.53 608.61 233.85 606.04 235.75 602.72 D 236.97 600.59 238.84 598.83 241.09 597.48 D 245.77 594.69 250.61 591.25 256.35 592.8 D 259.92 593.77 262.52 596.84 263.9 599.94 D 265.67 603.92 265.82 609.21 265.55 613.85 D 265.38 616.91 268.24 618.62 271.16 619.83 D 275.59 621.67 280.86 620.91 285.55 622.01 D 290.61 623.18 296.9 621.32 300.8 624.45 D 305.89 628.54 306.37 635.01 305.23 640.09 D 303.53 647.68 297.81 654.55 293.71 660.96 D 287.02 671.45 275.18 673.63 263.97 670.51 D 257.05 668.58 250.74 671.18 244.36 672.91 D 238.43 674.53 231.18 675.96 226.06 671.91 D 222.67 669.22 218.77 666.97 214.29 665.93 D 4 X V 1 H 0 X N 98.86 679.89 98.73 679.12 98.41 678.62 98.59 677.65 98.22 677.65 97.51 676.53 96.62 676.71 96.03 676.33 97.38 673.61 99.37 671.64 102.52 670.85 102.58 670.28 103.75 670.34 105.5 670 105.5 670.79 107.25 670.79 107.25 671.52 105.09 671.52 104.57 671.86 104.57 677.4 105.09 677.74 109.83 676.44 109.83 674.63 111.35 674.07 111.35 671.47 109.53 671.47 109.53 670.85 110.58 670.85 110.58 668.7 103.4 668.7 102.46 669.32 102.46 668.76 98.31 669.09 95.92 670.79 95.1 669.32 95.8 667.91 99.13 666.61 100.59 664.97 102.93 658.02 102.11 657.91 103.28 657.17 105.15 656.38 105.04 655.82 104.57 655.65 102.35 655.82 101.41 655.99 100.83 655.76 100.13 655.76 100.13 657.23 98.31 662.37 94.98 662.31 94.98 657.17 98.31 656.21 90.25 656.21 93.58 657.17 93.58 662.2 89.72 662.2 88.73 663.44 88.5 664.91 88.85 665.65 88.55 667.96 87.74 668.19 87.09 669.49 86.8 674.41 87.21 675.09 88.44 675.31 89.02 674.75 89.72 671.07 90.13 672.71 91.12 675.03 92.53 676.78 93.86 677.21 94.57 678.18 94.33 678.49 94.25 679.99 94.99 681.13 95.65 681.67 96.54 681.9 97.23 681.74 98.59 681.01 99.12 680.09 81 Y V 0.2 H 0 Z N 104.71 677.32 105.06 677.48 105.06 671.78 104.71 671.95 4 Y V N 89.61 667.74 89.78 666.21 90.54 666.27 90.01 667.74 4 Y V N 90 450 0.41 0.4 90.42 655.65 G 90 450 0.41 0.4 90.42 655.65 A 90 450 0.41 0.4 98.2 655.65 G 90 450 0.41 0.4 98.2 655.65 A 102.87 668.47 111.46 668.47 111.46 667 109.36 667 109.36 655.87 106.03 655.87 107.2 657 108.42 657 108.42 667.06 103.57 667.06 10 Y V N 168.29 651.73 188.03 638.08 164.05 639.19 166.17 645.46 4 Y V 114.03 663.07 166.17 645.46 2 L 4 H 2 Z N 3 14 Q (root) 85.53 642.34 T 3 18 Q (Network) 211.6 636.21 T 386.56 689.44 386.43 688.67 386.11 688.16 386.3 687.2 385.93 687.2 385.22 686.08 384.32 686.26 383.73 685.88 385.08 683.16 387.07 681.19 390.22 680.4 390.28 679.83 391.45 679.89 393.2 679.55 393.2 680.34 394.96 680.34 394.96 681.07 392.79 681.07 392.27 681.41 392.27 686.95 392.79 687.29 397.53 685.99 397.53 684.18 399.05 683.61 399.05 681.02 397.23 681.02 397.23 680.4 398.29 680.4 398.29 678.25 391.1 678.25 390.16 678.87 390.16 678.3 386.02 678.64 383.62 680.34 382.8 678.87 383.5 677.46 386.83 676.16 388.29 674.52 390.63 667.57 389.81 667.46 390.98 666.72 392.85 665.93 392.74 665.36 392.27 665.2 390.05 665.36 389.11 665.54 388.53 665.31 387.83 665.31 387.83 666.78 386.02 671.92 382.68 671.86 382.68 666.72 386.02 665.76 377.95 665.76 381.28 666.72 381.28 671.75 377.42 671.75 376.43 672.99 376.2 674.46 376.55 675.2 376.26 677.51 375.44 677.74 374.8 679.04 374.5 683.96 374.91 684.63 376.14 684.86 376.72 684.29 377.42 680.62 377.83 682.26 378.83 684.58 380.23 686.33 381.56 686.76 382.27 687.73 382.03 688.04 381.95 689.54 382.69 690.68 383.35 691.22 384.24 691.45 384.93 691.29 386.3 690.55 386.82 689.64 81 Y V 0.2 H 0 Z N 392.42 686.86 392.76 687.03 392.76 681.33 392.42 681.5 4 Y V N 377.31 677.29 377.48 675.76 378.24 675.82 377.72 677.29 4 Y V N 90 450 0.41 0.4 378.13 665.19 G 90 450 0.41 0.4 378.13 665.19 A 90 450 0.41 0.4 385.9 665.19 G 90 450 0.41 0.4 385.9 665.19 A 390.57 678.02 399.17 678.02 399.17 676.55 397.06 676.55 397.06 665.42 393.73 665.42 394.9 666.55 396.12 666.55 396.12 676.61 391.27 676.61 10 Y V N 3 14 Q (third party) 352.22 651.89 T 384.6 572.63 384.47 571.87 384.15 571.36 384.34 570.39 383.97 570.39 383.26 569.27 382.36 569.45 381.77 569.08 383.12 566.36 385.11 564.38 388.26 563.59 388.32 563.03 389.49 563.08 391.24 562.74 391.24 563.54 393 563.54 393 564.27 390.83 564.27 390.31 564.61 390.31 570.15 390.83 570.48 395.57 569.18 395.57 567.38 397.09 566.81 397.09 564.21 395.28 564.21 395.28 563.59 396.33 563.59 396.33 561.45 389.14 561.45 388.2 562.07 388.2 561.5 384.06 561.84 381.66 563.54 380.84 562.07 381.55 560.65 384.88 559.35 386.34 557.71 388.67 550.77 387.86 550.65 389.02 549.92 390.89 549.13 390.78 548.56 390.31 548.39 388.09 548.56 387.15 548.73 386.57 548.5 385.87 548.5 385.87 549.97 384.06 555.12 380.73 555.06 380.73 549.92 384.06 548.96 375.99 548.96 379.32 549.92 379.32 554.95 375.47 554.95 374.47 556.19 374.24 557.66 374.59 558.39 374.3 560.71 373.48 560.94 372.84 562.23 372.55 567.15 372.95 567.83 374.18 568.05 374.77 567.49 375.47 563.82 375.88 565.46 376.87 567.77 378.27 569.52 379.61 569.95 380.31 570.93 380.08 571.23 379.99 572.73 380.73 573.88 381.39 574.41 382.29 574.64 382.97 574.49 384.34 573.75 384.86 572.84 81 Y V N 390.46 570.06 390.81 570.23 390.81 564.52 390.46 564.69 4 Y V N 375.35 560.48 375.53 558.96 376.29 559.01 375.76 560.48 4 Y V N 90 450 0.41 0.4 376.17 548.39 G 90 450 0.41 0.4 376.17 548.39 A 90 450 0.41 0.4 383.94 548.39 G 90 450 0.41 0.4 383.94 548.39 A 388.61 561.22 397.21 561.22 397.21 559.75 395.1 559.75 395.1 548.62 391.77 548.62 392.94 549.75 394.17 549.75 394.17 559.81 389.32 559.81 10 Y V N (client A) 359.59 535.08 T 349.1 584.25 366.77 568.02 343.18 572.42 346.14 578.34 4 Y 2 X V 276.77 613.02 346.14 578.33 2 L 4 H 2 Z N 302.62 674.43 290.76 672.59 299.84 680.44 301.23 677.43 4 Y 0 X V 374.28 689.86 M 362.87 708.62 339.28 695.57 316.42 684.86 D 311.58 682.59 306.48 679.98 301.24 677.43 D 0.5 H N 7 X 90 450 7.5 7.5 331.27 689.52 G 0 X 90 450 7.5 7.5 331.27 689.52 A 2 12 Q (1) 327.94 685.14 T 2 10 Q (leaf setup request) 291.32 703.78 T 72.02 511.3 540.02 520.3 R 7 X V 1 F 0 X (Figur) 167.83 513.64 T (e 6. Third party cr) 191.54 513.64 T (eation of call between r) 275.52 513.64 T (oot and client A.) 374.21 513.64 T 127.69 674.1 115.71 674.71 126.2 680.55 126.94 677.33 4 Y V 188.17 648.45 M 189.34 671.86 173.56 692.57 144.26 684 D 140.53 682.91 133.44 679.67 126.95 677.32 D N 7 X 90 450 7.5 7.5 164.27 686.52 G 0 X 90 450 7.5 7.5 164.27 686.52 A 2 12 Q (2) 160.94 682.14 T 2 10 Q (leaf setup request) 125.03 697.92 T (setup) 146.07 655.84 T 184.4 655.52 185.07 643.54 178.15 653.34 181.27 654.43 4 Y V 181.28 654.42 M 173.79 668.18 157.66 676.11 141.57 672.71 D 135.45 671.41 129.65 669.03 123.57 669.53 D N 7 X 90 450 7.5 7.5 146.07 670.03 G 0 X 90 450 7.5 7.5 146.07 670.03 A 2 12 Q (3) 142.74 665.66 T J 119.06 642.6 118.07 654.54 125.24 644.93 122.15 643.77 4 Y V [1.442 4.325] 0.721 I 122.15 643.76 M 124.83 635.76 128.25 628.18 141.07 626.65 D 155.68 624.9 168.98 630.05 182.07 634.35 D N J 7 X 90 450 7.5 6.79 143.57 626.25 G 0 X 90 450 7.5 6.79 143.57 626.25 A (4) 140.24 622 T 2 10 Q (call proc) 123.87 609.76 T 98.56 628.94 101.82 640.47 105.16 628.97 101.86 628.96 4 Y V 184.67 628.33 M 182.96 604.04 158.1 595.16 137.53 595.03 D 118.47 594.92 104.5 611.33 101.86 628.95 D N 7 X 90 450 7.5 7.5 138.17 595.11 G 0 X 90 450 7.5 7.5 138.17 595.11 A 2 12 Q (7) 134.84 590.74 T 2 10 Q (connect) 119.53 580.09 T (\050not in call\051) 362.38 640.01 T 441.42 688.93 446.46 709.06 459.33 712.29 510.78 712.29 523.65 709.06 527.94 699.37 527.94 634.78 523.65 625.09 510.78 621.86 459.33 621.86 446.46 625.09 442.17 634.78 442.17 670.3 13 L 7 X V 0.2 H 0 X N 442.85 691.17 378.57 704.55 441.42 671.09 3 L 7 X V 0 X N (Contains third) 453.73 699.14 T (party\325s address) 450.68 689.14 T (\050in) 442.07 679.14 T 4 F (Initiator Number) 455.96 679.14 T 2 F (IE\051, root\325s address) 444.01 669.14 T (\050in) 445.12 659.14 T 4 F (GCID) 459.01 659.14 T 2 F ( IEs\051 and) 484.01 659.14 T (client A\325s address) 445.4 649.14 T (\050in) 456.51 639.14 T 4 F (New Leaf) 470.4 639.14 T (Number) 459.02 629.14 T 2 F ( IE\051) 494.58 629.14 T 346.65 643.43 357.85 647.71 350.62 638.14 348.64 640.78 4 Y V 311.42 637 M 320.59 632.69 337.14 634.81 348.65 640.78 D 0.01 H N 7 X 90 450 7.5 7.5 332.13 635.09 G 0.5 H 0 X 90 450 7.5 7.5 332.13 635.09 A 2 12 Q (8) 328.8 630.71 T 2 10 Q (leaf setup ACK) 307.17 618.63 T (\050new message\051) 306.35 608.63 T 72 72 540 720 C 0 0 612 792 C 72 72 540 720 C 72 244.96 540 503.93 C 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 410.44 320.61 422.02 317.45 410.53 313.99 410.49 317.3 4 Y 0 X 0 0 0 1 0 0 0 K V 330.46 364.59 M 341.63 337.43 371.41 326.81 397.74 318.59 D 401.9 317.29 406.18 317.17 410.49 317.29 D 0.5 H 2 Z N 7 X 90 450 7.5 7.5 355.96 336.09 G 0 X 90 450 7.5 7.5 355.96 336.09 A 2 12 Q (4) 352.62 331.72 T 2 10 Q (setup) 366.86 332.92 T 312.63 334.6 316.31 346.02 319.24 334.39 315.93 334.49 4 Y V 420.46 310.59 M 393.74 284.09 343.93 302.34 321.31 326.02 D 319.03 328.41 317.08 331.35 315.95 334.48 D N 7 X 90 450 7.5 7.5 346.96 309.09 G 0 X 90 450 7.5 7.5 346.96 309.09 A 2 12 Q (5) 343.62 304.72 T 2 10 Q (connect) 357.46 306.64 T 276.16 427.99 M 267.7 428.74 254.45 431.25 252.61 420.04 D 252.2 417.54 251.1 414.2 252.57 411.69 D 256.95 404.21 251.79 395.35 254.99 388.23 D 256.29 385.35 256.28 382.35 257.17 379.49 D 258.16 376.28 260.7 373.88 262.34 372.33 D 267.13 367.8 273.27 369.42 278.12 370.11 D 281.58 370.61 284.51 373.14 288.14 371.94 D 291.97 370.67 295.29 368.09 297.18 364.78 D 298.4 362.64 300.27 360.88 302.53 359.54 D 307.2 356.75 312.05 353.31 317.78 354.86 D 321.36 355.83 323.96 358.9 325.33 361.99 D 327.11 365.98 327.25 371.27 326.99 375.91 D 326.81 378.97 329.67 380.67 332.6 381.89 D 337.02 383.73 342.29 382.97 346.98 384.06 D 352.04 385.24 358.33 383.38 362.23 386.51 D 367.33 390.6 367.8 397.06 366.66 402.15 D 364.96 409.74 359.24 416.6 355.15 423.02 D 348.45 433.51 336.62 435.68 325.41 432.57 D 318.49 430.64 312.18 433.23 305.8 434.97 D 299.87 436.58 292.61 438.02 287.49 433.96 D 284.1 431.28 280.21 429.02 275.72 427.99 D 4 X V 1 H 0 X N 160.29 441.94 160.16 441.18 159.84 440.67 160.03 439.7 159.66 439.7 158.95 438.58 158.05 438.76 157.46 438.39 158.81 435.67 160.8 433.69 163.96 432.9 164.01 432.34 165.18 432.39 166.94 432.05 166.94 432.85 168.69 432.85 168.69 433.58 166.53 433.58 166 433.92 166 439.46 166.53 439.8 171.26 438.5 171.26 436.69 172.78 436.12 172.78 433.52 170.97 433.52 170.97 432.9 172.02 432.9 172.02 430.76 164.83 430.76 163.9 431.38 163.9 430.81 159.75 431.15 157.35 432.85 156.54 431.38 157.24 429.96 160.57 428.67 162.03 427.02 164.37 420.08 163.55 419.96 164.71 419.23 166.59 418.44 166.47 417.87 166 417.7 163.78 417.87 162.85 418.04 162.26 417.82 161.56 417.82 161.56 419.29 159.75 424.43 156.42 424.37 156.42 419.23 159.75 418.27 151.68 418.27 155.01 419.23 155.01 424.26 151.16 424.26 150.16 425.5 149.93 426.97 150.28 427.7 149.99 430.02 149.17 430.25 148.53 431.55 148.24 436.46 148.65 437.14 149.87 437.37 150.46 436.8 151.16 433.13 151.57 434.77 152.56 437.08 153.96 438.84 155.3 439.26 156 440.24 155.77 440.54 155.69 442.05 156.42 443.19 157.08 443.72 157.98 443.95 158.66 443.8 160.03 443.06 160.55 442.15 81 Y V 0.2 H 0 Z N 166.15 439.37 166.5 439.54 166.5 433.83 166.15 434.01 4 Y V N 151.04 429.8 151.22 428.27 151.98 428.33 151.45 429.8 4 Y V N 90 450 0.41 0.4 151.86 417.7 G 90 450 0.41 0.4 151.86 417.7 A 90 450 0.41 0.4 159.63 417.7 G 90 450 0.41 0.4 159.63 417.7 A 164.31 430.53 172.9 430.53 172.9 429.06 170.79 429.06 170.79 417.93 167.46 417.93 168.63 419.06 169.86 419.06 169.86 429.12 165.01 429.12 10 Y V N 229.72 413.78 249.46 400.13 225.49 401.25 227.6 407.52 4 Y V 175.47 425.13 227.61 407.51 2 L 4 H 2 Z N 3 14 Q (root) 146.96 404.39 T 3 18 Q (Network) 273.04 398.27 T 446.04 334.69 445.9 333.92 445.59 333.42 445.77 332.45 445.4 332.45 444.69 331.33 443.8 331.51 443.2 331.13 444.56 328.42 446.54 326.44 449.7 325.65 449.76 325.08 450.92 325.14 452.68 324.8 452.68 325.59 454.43 325.59 454.43 326.32 452.27 326.32 451.74 326.66 451.74 332.2 452.27 332.54 457 331.24 457 329.43 458.52 328.87 458.52 326.27 456.71 326.27 456.71 325.65 457.76 325.65 457.76 323.5 450.58 323.5 449.64 324.12 449.64 323.56 445.49 323.89 443.1 325.59 442.28 324.12 442.98 322.71 446.31 321.41 447.77 319.77 450.11 312.82 449.29 312.71 450.46 311.97 452.33 311.18 452.21 310.62 451.74 310.45 449.52 310.62 448.59 310.79 448.01 310.56 447.3 310.56 447.3 312.03 445.49 317.17 442.16 317.11 442.16 311.97 445.49 311.01 437.43 311.01 440.76 311.97 440.76 317 436.9 317 435.91 318.24 435.67 319.71 436.02 320.45 435.73 322.77 434.91 322.99 434.27 324.29 433.98 329.21 434.39 329.89 435.62 330.11 436.2 329.55 436.9 325.87 437.31 327.51 438.3 329.83 439.71 331.58 441.04 332.01 441.75 332.98 441.51 333.29 441.43 334.79 442.17 335.93 442.83 336.47 443.72 336.7 444.4 336.55 445.77 335.81 446.3 334.89 81 Y V 0.2 H 0 Z N 451.89 332.12 452.24 332.29 452.24 326.58 451.89 326.75 4 Y V N 436.79 322.54 436.96 321.01 437.72 321.07 437.19 322.54 4 Y V N 90 450 0.41 0.4 437.6 310.45 G 90 450 0.41 0.4 437.6 310.45 A 90 450 0.41 0.4 445.37 310.45 G 90 450 0.41 0.4 445.37 310.45 A 450.05 323.27 458.64 323.27 458.64 321.8 456.54 321.8 456.54 310.67 453.2 310.67 454.37 311.8 455.6 311.8 455.6 321.86 450.75 321.86 10 Y V N 3 14 Q (client B) 421.03 297.14 T 410.53 346.31 428.2 330.07 404.61 334.47 407.57 340.39 4 Y 2 X V 338.21 375.07 407.58 340.39 2 L 4 H 2 Z N 189.12 436.16 177.14 436.77 187.63 442.6 188.38 439.38 4 Y 0 X V 270.71 432.63 M 280.4 467.61 234.99 454.63 205.69 446.05 D 201.97 444.96 194.87 441.73 188.38 439.38 D 0.5 H N 7 X 90 450 7.5 7.5 234.28 455 G 0 X 90 450 7.5 7.5 234.28 455 A 2 12 Q (2) 230.94 450.63 T 2 10 Q (leaf setup request) 195.03 466.4 T (add party) 220.36 435.04 T 245.83 417.57 246.5 405.59 239.58 415.39 242.71 416.48 4 Y V 242.71 416.48 M 235.22 430.23 219.09 438.17 203.01 434.76 D 196.89 433.47 191.09 431.09 185.01 431.59 D N 7 X 90 450 7.5 7.5 211.79 432.09 G 0 X 90 450 7.5 7.5 211.79 432.09 A 2 12 Q (3) 208.46 427.71 T 180.49 404.65 179.51 416.59 186.66 406.99 183.58 405.82 4 Y V 183.59 405.82 M 186.26 397.81 189.68 390.23 202.51 388.7 D 217.12 386.95 230.42 392.11 243.51 396.4 D N 7 X 90 450 7.5 6.79 205.01 388.3 G 0 X 90 450 7.5 6.79 205.01 388.3 A (6) 201.67 384.06 T 2 10 Q (add party ACK) 172.45 371.81 T 72.17 259.78 540.17 268.78 R 7 X V 1 F 0 X (Figur) 72.91 262.12 T (e 7. Third party add of client B to ongoing call \050assuming Security Indication of ROOT SCREENING\051.) 96.62 262.12 T 448.13 450.01 448 449.24 447.68 448.73 447.87 447.77 447.5 447.77 446.79 446.65 445.89 446.83 445.3 446.45 446.65 443.73 448.64 441.76 451.79 440.97 451.85 440.4 453.02 440.46 454.77 440.12 454.77 440.91 456.53 440.91 456.53 441.64 454.36 441.64 453.84 441.98 453.84 447.52 454.36 447.86 459.1 446.56 459.1 444.75 460.62 444.19 460.62 441.59 458.81 441.59 458.81 440.97 459.86 440.97 459.86 438.82 452.67 438.82 451.73 439.44 451.73 438.88 447.59 439.21 445.19 440.91 444.37 439.44 445.08 438.03 448.4 436.73 449.87 435.09 452.2 428.14 451.39 428.02 452.55 427.29 454.42 426.5 454.31 425.94 453.84 425.77 451.62 425.94 450.68 426.11 450.1 425.88 449.4 425.88 449.4 427.35 447.59 432.49 444.26 432.43 444.26 427.29 447.59 426.33 439.52 426.33 442.85 427.29 442.85 432.32 439 432.32 438 433.56 437.77 435.03 438.12 435.77 437.83 438.08 437.01 438.31 436.37 439.61 436.07 444.52 436.48 445.2 437.71 445.43 438.3 444.86 439 441.19 439.41 442.83 440.4 445.15 441.8 446.9 443.14 447.33 443.84 448.3 443.61 448.61 443.52 450.11 444.26 451.25 444.92 451.79 445.82 452.02 446.5 451.86 447.87 451.12 448.39 450.21 81 Y V 0.2 H 0 Z N 453.99 447.43 454.34 447.6 454.34 441.9 453.99 442.07 4 Y V N 438.88 437.86 439.05 436.33 439.82 436.39 439.29 437.86 4 Y V N 90 450 0.41 0.4 439.7 425.76 G 90 450 0.41 0.4 439.7 425.76 A 90 450 0.41 0.4 447.47 425.76 G 90 450 0.41 0.4 447.47 425.76 A 452.14 438.59 460.74 438.59 460.74 437.12 458.63 437.12 458.63 425.99 455.3 425.99 456.47 427.12 457.7 427.12 457.7 437.18 452.85 437.18 10 Y V N 3 14 Q (third party) 413.79 412.46 T 364.18 435.01 352.33 433.16 361.4 441.01 362.8 438.01 4 Y V 435.85 450.43 M 424.44 469.19 400.85 456.14 378 445.43 D 373.15 443.16 368.05 440.55 362.82 438 D 0.5 H 2 Z N 7 X 90 450 7.5 7.5 392.85 450.09 G 0 X 90 450 7.5 7.5 392.85 450.09 A 2 12 Q (1) 389.51 445.71 T 2 10 Q (leaf setup request) 352.89 464.35 T (\050not in call\051) 423.96 400.58 T 408.21 404 419.41 408.29 412.18 398.71 410.2 401.36 4 Y V 373 397.57 M 382.16 393.26 398.71 395.38 410.23 401.35 D 0.01 H N 7 X 90 450 7.5 7.5 393.7 395.66 G 0.5 H 0 X 90 450 7.5 7.5 393.7 395.66 A 2 12 Q (7) 390.37 391.28 T 2 10 Q (leaf setup ACK) 368.74 379.2 T (\050new message\051) 367.92 369.2 T 273.75 346.01 252.14 335.57 264.93 355.88 269.34 350.95 4 Y V 285.72 365.57 269.35 350.94 2 L 4 H N 244.75 332.4 244.62 331.64 244.3 331.13 244.48 330.16 244.12 330.16 243.41 329.04 242.51 329.22 241.92 328.85 243.27 326.13 245.26 324.15 248.41 323.36 248.47 322.8 249.64 322.85 251.39 322.51 251.39 323.3 253.15 323.3 253.15 324.04 250.98 324.04 250.46 324.38 250.46 329.92 250.98 330.26 255.72 328.95 255.72 327.15 257.24 326.58 257.24 323.98 255.43 323.98 255.43 323.36 256.48 323.36 256.48 321.21 249.29 321.21 248.35 321.84 248.35 321.27 244.21 321.61 241.81 323.3 240.99 321.84 241.69 320.42 245.02 319.12 246.48 317.48 248.82 310.54 248 310.42 249.17 309.69 251.04 308.9 250.93 308.33 250.46 308.16 248.24 308.33 247.3 308.5 246.72 308.27 246.02 308.27 246.02 309.74 244.21 314.89 240.88 314.83 240.88 309.69 244.21 308.73 236.14 308.73 239.47 309.69 239.47 314.72 235.61 314.72 234.62 315.96 234.39 317.43 234.74 318.16 234.45 320.48 233.63 320.71 232.98 322.01 232.69 326.92 233.1 327.6 234.33 327.83 234.91 327.26 235.61 323.59 236.02 325.23 237.02 327.54 238.42 329.3 239.75 329.72 240.46 330.7 240.22 331 240.14 332.51 240.88 333.65 241.54 334.18 242.43 334.41 243.12 334.26 244.48 333.52 245.01 332.61 81 Y V 0.2 H 0 Z N 250.6 329.83 250.95 330 250.95 324.29 250.6 324.46 4 Y V N 235.5 320.25 235.67 318.73 236.43 318.78 235.91 320.25 4 Y V N 90 450 0.41 0.4 236.32 308.16 G 90 450 0.41 0.4 236.32 308.16 A 90 450 0.41 0.4 244.09 308.16 G 90 450 0.41 0.4 244.09 308.16 A 248.76 320.99 257.36 320.99 257.36 319.52 255.25 319.52 255.25 308.39 251.92 308.39 253.09 309.52 254.32 309.52 254.32 319.58 249.46 319.58 10 Y V N 3 14 Q (client A) 219.74 294.85 T 2 10 Q (\050already in call\051) 211.13 283.3 T 72 72 540 720 C 0 0 612 792 C 52 76.96 54 240.96 R 0 X 0 0 0 1 0 0 0 K V FMENDPAGE %%EndPage: "19" 20 %%Page: "20" 21 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 20) 508.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (7.1) 72 712 T (Messages for Leaf Initiated Join Call and Connection Control) 99 712 T 0 10 Q ([Insert table summarizing new messages]) 90.86 695.33 T 1 12 Q (7.1.1) 72 674 T (LEAF SETUP REQUEST) 108 674 T 0 10 Q (This message is sent by a user to the network to initiate leaf joining procedures.) 72 657.33 T (Message Type:) 72 633.33 T (LEAF SETUP REQUEST) 144 633.33 T (Significance:) 72 618.33 T (global) 144 618.33 T (Direction:) 72 603.33 T (both) 144 603.33 T (Note # - Refer to the UNI 3.1 Specification for the numbered notes.) 72 166.33 T (Note A - Unused by network, must be set to special value) 72 142.33 T 5 F (to be determined) 305.02 142.33 T 0 F (.) 372.23 142.33 T (Note B - Minimum length depends on the numbering plan. Maximum length is 25 octets.) 72 118.33 T (Note C -) 72 94.33 T -0.38 (These fields may be included by the new leaf if it would like the network or root to verify the call parameters) 108.94 94.33 P (before attempting the leaf join.) 108 82.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Information Element) 120.2 575.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Reference) 254.24 575.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Direction) 327.61 575.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (T) 408.58 575.33 T (ype) 413.98 575.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length) 476.33 575.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Protocol discriminator) 91.5 555.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.2) 264.5 555.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 555.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 414.05 555.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 488 555.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Call reference) 91.5 535.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.3) 264.5 535.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 535.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M\050A\051) 407.11 535.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 488 535.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Message type) 91.5 515.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.4.1) 260.75 515.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 515.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 414.05 515.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 488 515.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Message length) 91.5 495.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.4.2) 260.75 495.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 495.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 414.05 495.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 488 495.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (AAL parameters) 91.5 475.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.5) 260.75 475.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 475.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 404.48 472.33 T (\0501,C\051) 411.7 475.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-20) 481.33 475.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (A) 91.5 452.33 T (TM user cell rate) 97.61 452.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.6) 260.75 452.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 452.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O\050C\051) 408.23 452.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (12-30) 478.83 452.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Broadband bearer capability) 91.5 432.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.7) 260.75 432.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 432.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O\050C\051) 408.23 432.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6-7) 483.83 432.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Broadband high layer information) 91.5 412.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.8) 260.75 412.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 412.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 404.48 409.33 T (\0502,C\051) 411.7 412.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-13) 481.33 412.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Broadband repeat indicator) 91.5 389.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.19) 258.25 389.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 389.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 404.48 386.33 T (\0503,C\051) 411.7 389.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-5) 483.83 389.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Broadband low layer information) 91.5 366.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.9) 260.75 366.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 366.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 404.48 363.33 T (\0504,C\051) 411.7 366.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-17) 481.33 366.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (QoS parameter) 91.5 343.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.18) 258.25 343.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 343.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O\050C\051) 408.23 343.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6) 488 343.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (T) 91.5 323.33 T (ransit network selection) 97.26 323.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.22) 258.25 323.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 323.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 401.98 320.33 T (\05010,C\051) 409.2 323.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-8) 483.83 323.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (New Leaf number) 91.5 300.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.A) 259.64 300.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 300.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 414.05 300.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (\050B\051) 483.83 300.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (New Leaf subaddress) 91.5 280.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.B) 259.92 280.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 280.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 414.89 277.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-25) 481.33 280.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Root number) 91.5 257.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.C) 259.92 257.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 257.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 414.05 257.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (\050B\051) 483.83 257.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Root subaddress) 91.5 237.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.D) 259.64 237.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 237.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 414.89 234.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-25) 481.33 237.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Root call identi\336er) 91.5 214.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.E) 260.2 214.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 214.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 414.05 214.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (9) 488 214.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Sequence Number) 91.5 194.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.G) 259.64 194.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 337.61 194.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 414.89 194.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (8) 488 194.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 85.5 587.75 85.5 187.25 2 L V 0.5 H 0 Z N 238.5 588.25 238.5 186.75 2 L V N 310.5 588.25 310.5 186.75 2 L V N 382.5 588.25 382.5 186.75 2 L V N 454.5 588.25 454.5 186.75 2 L V N 526.5 587.75 526.5 187.25 2 L V N 85.25 588 526.75 588 2 L V N 85.25 568 526.75 568 2 L V N 85.25 548 526.75 548 2 L V N 85.25 528 526.75 528 2 L V N 85.25 508 526.75 508 2 L V N 85.25 488 526.75 488 2 L V N 85.25 465 526.75 465 2 L V N 85.25 445 526.75 445 2 L V N 85.25 425 526.75 425 2 L V N 85.25 402 526.75 402 2 L V N 85.25 379 526.75 379 2 L V N 85.25 356 526.75 356 2 L V N 85.25 336 526.75 336 2 L V N 85.25 313 526.75 313 2 L V N 85.25 293 526.75 293 2 L V N 85.25 270 526.75 270 2 L V N 85.25 250 526.75 250 2 L V N 85.25 227 526.75 227 2 L V N 85.25 207 526.75 207 2 L V N 85.25 187 526.75 187 2 L V N 52 79 54 720 R V 52 532 54 542 R V 52 469 54 482 R V 52 449 54 459 R V 52 429 54 439 R V 52 406 54 419 R V 52 383 54 396 R V 52 360 54 373 R V 52 340 54 350 R V 52 320 54 330 R V 52 317 54 330 R V 52 297 54 307 R V 52 297 54 307 R V 52 297 54 307 R V 52 277 54 287 R V 52 277 54 287 R V 52 274 54 287 R V 52 254 54 264 R V 52 254 54 264 R V 52 254 54 264 R V 52 234 54 244 R V 52 234 54 244 R V 52 231 54 244 R V 52 211 54 221 R V 52 211 54 221 R V 52 211 54 221 R V 52 211 54 221 R V 52 211 54 221 R V 52 191 54 201 R V 52 191 54 201 R V 52 191 54 201 R V 52 191 54 201 R V 52 191 54 201 R V FMENDPAGE %%EndPage: "20" 21 %%Page: "21" 22 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 21) 508.06 35.85 T 72 72 540 720 R 7 X V 1 12 Q 0 X (7.1.2) 72 712 T (LEAF SETUP FAILURE) 108 712 T 0 10 Q (This message is sent by the network to indicate a failure to join the user to the requested call.) 72 695.33 T (Message Type:) 72 671.33 T (LEAF SETUP FAILURE) 144 671.33 T (Significance:) 72 656.33 T (global) 144 656.33 T (Direction:) 72 641.33 T (both) 144 641.33 T (Note A - Unused by network, must be set to special value) 72 359.33 T 5 F (to be determined) 305.02 359.33 T 0 F (.) 372.23 359.33 T (Note B - Minimum length depends on the numbering plan. Maximum length is 25 octets.) 72 335.33 T 1 12 Q (7.1.3) 72 310 T (NEW LEAF ANNOUNCE) 108 310 T 0 10 Q (This message is sent to announce the addition of a new leaf to an existing connection.) 72 293.33 T (Message type:) 72 269.33 T (NEW LEAF ANNOUNCE) 144 269.33 T (Significance:) 72 254.33 T (global) 144 254.33 T (Direction:) 72 239.33 T (both) 144 239.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Information Element) 120.2 613.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Reference) 249.74 613.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Direction) 323.11 613.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (T) 404.08 613.33 T (ype) 409.48 613.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length) 471.83 613.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Protocol discriminator) 96 593.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.2) 260 593.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 593.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 593.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 483.5 593.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Call reference) 96 573.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.3) 260 573.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 573.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M\050A\051) 402.61 573.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 483.5 573.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Message type) 96 553.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.4.1) 256.25 553.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 553.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 553.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 483.5 553.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Message length) 96 533.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.4.2) 256.25 533.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 533.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 533.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 483.5 533.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Cause) 96 513.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.5.15) 253.75 513.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 513.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 513.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6-34) 476.83 513.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (New Leaf number) 96 493.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.A) 255.14 493.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 493.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 493.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (\050B\051) 479.33 493.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (New Leaf subaddress) 96 473.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.B) 255.41 473.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 473.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 410.39 470.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-25) 476.83 473.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Root number) 96 450.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.C) 255.41 450.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 450.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 450.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (\050B\051) 479.33 450.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Root subaddress) 96 430.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.D) 255.14 430.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 430.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 410.39 427.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-25) 476.83 430.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Root call identi\336er) 96 407.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.E) 255.7 407.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 407.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 407.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (9) 483.5 407.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Sequence Number) 96 387.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.F) 255.97 387.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 387.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 410.39 387.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (8) 483.5 387.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Information Element) 120.2 211.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Reference) 249.74 211.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Direction) 323.11 211.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (T) 404.08 211.33 T (ype) 409.48 211.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length) 471.83 211.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Protocol discriminator) 96 191.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.2) 260 191.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 191.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 191.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 483.5 191.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Call reference) 96 171.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.3) 260 171.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 171.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 171.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 483.5 171.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Message type) 96 151.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.4.1) 256.25 151.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 151.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 151.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 483.5 151.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Message length) 96 131.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.4.2) 256.25 131.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 131.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 131.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 483.5 131.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (New Leaf number) 96 111.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.A) 255.14 111.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 111.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 409.55 111.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (\050A\051) 479.06 111.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (New Leaf subaddress) 96 91.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.B) 255.41 91.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 91.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (O) 410.39 88.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4-25) 476.83 91.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 90 625.75 90 380.25 2 L V 0.5 H 0 Z N 234 626.25 234 379.75 2 L V N 306 626.25 306 379.75 2 L V N 378 626.25 378 379.75 2 L V N 450 626.25 450 379.75 2 L V N 522 625.75 522 380.25 2 L V N 89.75 626 522.25 626 2 L V N 89.75 606 522.25 606 2 L V N 89.75 586 522.25 586 2 L V N 89.75 566 522.25 566 2 L V N 89.75 546 522.25 546 2 L V N 89.75 526 522.25 526 2 L V N 89.75 506 522.25 506 2 L V N 89.75 486 522.25 486 2 L V N 89.75 463 522.25 463 2 L V N 89.75 443 522.25 443 2 L V N 89.75 420 522.25 420 2 L V N 89.75 400 522.25 400 2 L V N 89.75 380 522.25 380 2 L V N 90 223.75 90 81.25 2 L V N 234 224.25 234 80.75 2 L V N 306 224.25 306 80.75 2 L V N 378 224.25 378 80.75 2 L V N 450 224.25 450 80.75 2 L V N 522 223.75 522 81.25 2 L V N 89.75 224 522.25 224 2 L V N 89.75 204 522.25 204 2 L V N 89.75 184 522.25 184 2 L V N 89.75 164 522.25 164 2 L V N 89.75 144 522.25 144 2 L V N 89.75 124 522.25 124 2 L V N 89.75 104 522.25 104 2 L V N 89.75 81 522.25 81 2 L V N 52 236 54 720 R V 52 570 54 580 R V 52 490 54 500 R V 52 490 54 500 R V 52 490 54 500 R V 52 470 54 480 R V 52 470 54 480 R V 52 467 54 480 R V 52 447 54 457 R V 52 447 54 457 R V 52 447 54 457 R V 52 427 54 437 R V 52 427 54 437 R V 52 424 54 437 R V 52 404 54 414 R V 52 404 54 414 R V 52 404 54 414 R V 52 404 54 414 R V 52 404 54 414 R V 52 384 54 394 R V 52 384 54 394 R V 52 384 54 394 R V 52 384 54 394 R V 52 384 54 394 R V 52 208 54 218 R V 52 188 54 198 R V 52 168 54 178 R V 52 148 54 158 R V 52 128 54 138 R V 52 108 54 118 R V 52 108 54 118 R V 52 108 54 118 R V 52 88 54 98 R V 52 88 54 98 R V 52 85 54 98 R V FMENDPAGE %%EndPage: "21" 22 %%Page: "22" 23 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 22) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X (Note A - Minimum length depends on the numbering plan. Maximum length is 25 octets.) 72 678.33 T (Note B - The endpoint reference is generated by the network.) 72 654.33 T 1 12 Q (7.2) 72 629 T (Information Element Coding for Leaf Initiated Join Call and Connection Control) 99 629 T (7.2.1) 72 607 T (LEAF INITIATED JOIN PARAMETERS) 108 607 T 0 10 Q 0.43 (The Leaf Initiated Join Parameters \050LIJP\051 information element is used by the root to associate options with the) 90.86 590.33 P (call when the call is created.) 72 578.33 T (Coding Standard \050octet 2\051) 117 294.33 T (IE Instruction Field \050octet 2\051) 117 219.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Endpoint reference) 96 707.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5.4.8.1) 256.25 707.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (both) 333.11 707.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (M) 402.89 704.33 T (\050B\051) 411.78 707.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (7) 483.5 707.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0 12 Q (Bits) 267.45 564 T (8) 132.87 547 T (7) 173.23 547 T (6) 213.59 547 T (5) 253.95 547 T (4) 294.3 547 T (3) 334.66 547 T (2) 375.02 547 T (1) 415.38 547 T (Octets) 452.11 547 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Initiated Join Parameters) 204.98 530 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 131.54 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 171.9 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 212.25 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 252.61 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 292.97 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 333.33 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 373.69 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 414.05 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 464.44 513 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Information element Identi\336er) 204.47 496 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 132.87 479 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ext) 128.54 465 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Coding) 178.74 479 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Standard) 175.08 465 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (IE Instruction Field) 290.67 479 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 464.44 479 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length of LIJP contents) 219.3 448 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 464.44 448 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length of LIJP contents \050continued\051) 190.14 431 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 464.44 431 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 132.87 414 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 173.23 414 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.59 414 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 253.95 414 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Security) 337.85 414 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5) 464.44 405.5 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ext) 128.54 397 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Spare) 202.92 397 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Indication) 333.51 397 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 132.87 380 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 173.23 380 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.59 380 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 253.95 380 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Noti\336cation) 329.18 380 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6) 464.44 371.5 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ext) 128.54 363 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Spare) 202.92 363 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Indication) 333.51 363 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 132.87 346 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 173.23 346 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.59 346 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 253.95 346 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Zero Leaf) 334.02 346 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (7) 464.44 337.5 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ext) 128.54 329 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Spare) 202.92 329 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Behavior) 335.85 329 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 186.08 274 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 342.86 274 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (7) 185.48 257 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6) 200.02 257 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.48 240 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 200.02 240 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ITU-TS \050CCITT\051 standardized) 256.94 240 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 186.08 199 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 340.3 199 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5) 157.98 182 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 171.89 182 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 185.8 182 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 199.7 182 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 182 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 157.98 165 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 165 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 165 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 165 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.61 165 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (IE instruction \336eld not signi\336cant) 254.38 165 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 90 719.75 90 697.25 2 L V 0.5 H 0 Z N 234 720.25 234 696.75 2 L V N 306 720.25 306 696.75 2 L V N 378 720.25 378 696.75 2 L V N 450 720.25 450 696.75 2 L V N 522 719.75 522 697.25 2 L V N 89.75 720 522.25 720 2 L V N 89.75 697 522.25 697 2 L V N 115.69 540.75 115.69 323.25 2 L V N 156.05 490.25 156.05 458.75 2 L V N 156.05 425.25 156.05 322.75 2 L V N 236.77 490.25 236.77 458.75 2 L V N 277.12 425.25 277.12 322.75 2 L V N 438.56 540.75 438.56 323.25 2 L V N 115.44 541 438.81 541 2 L V N 115.44 490 438.81 490 2 L V N 115.44 459 438.81 459 2 L V N 115.44 442 438.81 442 2 L V N 115.44 425 438.81 425 2 L V N 115.44 391 438.81 391 2 L V N 115.44 357 438.81 357 2 L V N 115.44 323 438.81 323 2 L V N 253.94 285 253.94 234 2 L V N 137.56 251 474.44 251 2 L V N 251.38 210 251.38 159 2 L V N 140.12 176 471.88 176 2 L V N 52 109 54 685 R V 52 701 54 714 R V 52 526 54 538 R V 52 526 54 538 R V 52 509 54 521 R V 52 509 54 521 R V 52 509 54 521 R V 52 509 54 521 R V 52 509 54 521 R V 52 509 54 521 R V 52 509 54 521 R V 52 509 54 521 R V 52 509 54 521 R V 52 492 54 504 R V 52 461 54 487 R V 52 461 54 487 R V 52 475 54 487 R V 52 444 54 456 R V 52 427 54 439 R V 52 410 54 422 R V 52 410 54 422 R V 52 410 54 422 R V 52 410 54 422 R V 52 410 54 422 R V 52 401.5 54 413.5 R V 52 393 54 405 R V 52 393 54 405 R V 52 393 54 405 R V 52 376 54 388 R V 52 376 54 388 R V 52 376 54 388 R V 52 376 54 388 R V 52 376 54 388 R V 52 367.5 54 379.5 R V 52 359 54 371 R V 52 359 54 371 R V 52 359 54 371 R V 52 342 54 354 R V 52 342 54 354 R V 52 342 54 354 R V 52 342 54 354 R V 52 342 54 354 R V 52 333.5 54 345.5 R V 52 325 54 337 R V 52 325 54 337 R V 52 325 54 337 R V 52 270 54 282 R V 52 253 54 265 R V 52 253 54 265 R V 52 253 54 265 R V 52 253 54 265 R V 52 253 54 265 R V 52 253 54 265 R V 52 253 54 265 R V 52 253 54 265 R V 52 236 54 248 R V 52 236 54 248 R V 52 236 54 248 R V 52 236 54 248 R V 52 236 54 248 R V 52 236 54 248 R V 52 236 54 248 R V 52 236 54 248 R V 52 236 54 248 R V 52 195 54 207 R V 52 178 54 190 R V 52 178 54 190 R V 52 178 54 190 R V 52 178 54 190 R V 52 178 54 190 R V 52 178 54 190 R V 52 178 54 190 R V 52 178 54 190 R V 52 161 54 173 R V 52 161 54 173 R V 52 161 54 173 R V 52 161 54 173 R V 52 161 54 173 R V 52 161 54 173 R V 52 161 54 173 R V 52 161 54 173 R V 52 161 54 173 R V FMENDPAGE %%EndPage: "22" 23 %%Page: "23" 24 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 23) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X (Security Indication \050octet 5\051) 117 713.33 T (Notification Indication \050octet 6\051) 117 605.33 T (Zero Leaf Behavior \050octet 7\051) 117 497.33 T 1 12 Q (7.2.2) 72 402 T (LEAF SEQUENCE NUMBER) 108 402 T 0 10 Q -0.01 (The Leaf Sequence Number \050LSN\051 information element is used by a joining leaf to associate a SETUP or LEAF) 90.86 385.33 P (SETUP FAILURE response with the corresponding LEAF SETUP REQUEST message that triggered the response.) 72 373.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0 12 Q (Bits) 186.08 693 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 340.3 693 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 171.89 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 185.8 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 199.7 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.61 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (OPEN) 254.38 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 642 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 642 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 642 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 642 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ROOT SCREENING) 254.38 642 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 186.08 585 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 340.3 585 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 171.89 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 185.8 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 199.7 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 551 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 551 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 551 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.61 551 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (NONE) 254.38 551 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 534 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 534 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 534 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 534 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ROOT) 254.38 534 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 186.08 477 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 340.3 477 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 171.89 460 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 185.8 460 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 199.7 460 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 460 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 443 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 443 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 443 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.61 443 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (DROP CALL) 254.38 443 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 426 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 426 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 426 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 426 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (MAINT) 254.38 426 T (AIN CALL) 292.74 426 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 267.45 359 T (8) 132.87 342 T (7) 173.23 342 T (6) 213.59 342 T (5) 253.95 342 T (4) 294.3 342 T (3) 334.66 342 T (2) 375.02 342 T (1) 415.38 342 T (Octets) 452.11 342 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Sequence Number) 220.48 325 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 131.54 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 171.9 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 212.25 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 252.61 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 292.97 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 333.33 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 373.69 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 414.05 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 464.44 308 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Information element Identi\336er) 204.47 291 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 132.87 274 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ext) 128.54 260 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Coding) 178.74 274 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Standard) 175.08 260 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (IE Instruction Field) 290.67 274 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 464.44 274 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length of LSN contents) 219.3 243 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 464.44 243 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length of LSN contents \050continued\051) 190.14 226 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 464.44 226 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Sequence Number) 220.48 209 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5) 464.44 209 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Sequence Number \050continued\051) 191.32 192 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6) 464.44 192 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Sequence Number \050continued\051) 191.32 175 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (7) 464.44 175 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Leaf Sequence Number \050continued\051) 191.32 158 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (8) 464.44 158 T 251.38 704 251.38 636 2 L V 0.5 H 0 Z N 140.12 670 471.88 670 2 L V N 251.38 596 251.38 528 2 L V N 140.12 562 471.88 562 2 L V N 251.38 488 251.38 420 2 L V N 140.12 454 471.88 454 2 L V N 115.69 335.75 115.69 152.25 2 L V N 156.05 285.25 156.05 253.75 2 L V N 236.77 285.25 236.77 253.75 2 L V N 438.56 335.75 438.56 152.25 2 L V N 115.44 336 438.81 336 2 L V N 115.44 285 438.81 285 2 L V N 115.44 254 438.81 254 2 L V N 115.44 237 438.81 237 2 L V N 115.44 220 438.81 220 2 L V N 115.44 203 438.81 203 2 L V N 115.44 186 438.81 186 2 L V N 115.44 169 438.81 169 2 L V N 115.44 152 438.81 152 2 L V N 52 104 54 720 R V 52 689 54 701 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 638 54 650 R V 52 638 54 650 R V 52 638 54 650 R V 52 638 54 650 R V 52 638 54 650 R V 52 581 54 593 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 547 54 559 R V 52 547 54 559 R V 52 547 54 559 R V 52 547 54 559 R V 52 547 54 559 R V 52 547 54 559 R V 52 547 54 559 R V 52 547 54 559 R V 52 547 54 559 R V 52 530 54 542 R V 52 530 54 542 R V 52 530 54 542 R V 52 530 54 542 R V 52 530 54 542 R V 52 473 54 485 R V 52 456 54 468 R V 52 456 54 468 R V 52 456 54 468 R V 52 456 54 468 R V 52 456 54 468 R V 52 456 54 468 R V 52 456 54 468 R V 52 456 54 468 R V 52 439 54 451 R V 52 439 54 451 R V 52 439 54 451 R V 52 439 54 451 R V 52 439 54 451 R V 52 439 54 451 R V 52 439 54 451 R V 52 439 54 451 R V 52 439 54 451 R V 52 422 54 434 R V 52 422 54 434 R V 52 422 54 434 R V 52 422 54 434 R V 52 422 54 434 R V 52 321 54 333 R V 52 321 54 333 R V 52 304 54 316 R V 52 304 54 316 R V 52 304 54 316 R V 52 304 54 316 R V 52 304 54 316 R V 52 304 54 316 R V 52 304 54 316 R V 52 304 54 316 R V 52 304 54 316 R V 52 287 54 299 R V 52 256 54 282 R V 52 256 54 282 R V 52 270 54 282 R V 52 239 54 251 R V 52 222 54 234 R V 52 205 54 217 R V 52 205 54 217 R V 52 188 54 200 R V 52 188 54 200 R V 52 171 54 183 R V 52 171 54 183 R V 52 154 54 166 R V 52 154 54 166 R V FMENDPAGE %%EndPage: "23" 24 %%Page: "24" 25 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 24) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X (Coding Standard \050octet 2\051) 117 713.33 T (IE Instruction Field \050octet 2\051) 117 638.33 T (Leaf Sequence Number \050octets 5-8\051) 117 563.33 T -0.07 (The Leaf Sequence Number is used by a joining leaf to associate a SETUP or LEAF SETUP FAILURE) 126 547.33 P (response with the corresponding LEAF SETUP REQUEST message that triggered the response.) 126 535.33 T 1 12 Q (7.2.3) 72 514 T (Root Call Identifier) 108 514 T 0 10 Q (The Root Call Identifier \050RCID\051 information element is used to uniquely label a call at the Root.) 90.86 497.33 T (Coding Standard \050octet 2\051) 117 213.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0 12 Q (Bits) 186.08 693 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 342.86 693 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (7) 185.48 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6) 200.02 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.48 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 200.02 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ITU-TS \050CCITT\051 standardized) 256.94 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 186.08 618 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 340.3 618 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5) 157.98 601 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 171.89 601 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 185.8 601 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 199.7 601 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 601 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 157.98 584 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 584 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 584 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 584 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.61 584 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (IE instruction \336eld not signi\336cant) 254.38 584 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 268.11 483 T (8) 133.52 466 T (7) 173.88 466 T (6) 214.24 466 T (5) 254.6 466 T (4) 294.96 466 T (3) 335.32 466 T (2) 375.68 466 T (1) 416.04 466 T (Octets) 452.11 466 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Global Call Identi\336er) 226.45 449 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 132.19 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 172.55 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 212.91 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 253.27 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 293.63 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 333.99 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 374.35 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (X) 414.71 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 464.44 432 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Information element Identi\336er) 205.13 415 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 133.52 398 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ext) 129.19 384 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Coding) 179.39 398 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Standard) 175.73 384 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (IE Instruction Field) 291.32 398 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 464.44 398 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length of GCID contents) 216.62 367 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 464.44 367 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Length of GCID contents \050continued\051) 187.46 350 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 464.44 350 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 133.52 333 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 173.88 333 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 214.24 333 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 254.6 333 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (GCID) 343.84 333 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5) 464.44 324.5 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ext) 129.19 316 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Spare) 203.58 316 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (T) 346.59 316 T (ype) 353.08 316 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Local Call Identi\336er) 229.12 299 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6) 464.44 299 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Local Call Identi\336er \050continued\051) 199.96 282 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (7) 464.44 282 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Local Call Identi\336er \050continued\051) 199.96 265 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (8) 464.44 265 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Local Call Identi\336er \050continued\051) 199.96 248 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (9) 464.44 248 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 186.08 193 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 342.86 193 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (7) 185.48 176 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (6) 200.02 176 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.48 159 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 200.02 159 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (ITU-TS \050CCITT\051 standardized) 256.94 159 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 253.94 704 253.94 653 2 L V 0.5 H 0 Z N 137.56 670 474.44 670 2 L V N 251.38 629 251.38 578 2 L V N 140.12 595 471.88 595 2 L V N 116.34 459.75 116.34 242.25 2 L V N 156.7 409.25 156.7 377.75 2 L V N 156.7 344.25 156.7 309.75 2 L V N 237.42 409.25 237.42 377.75 2 L V N 277.78 344.25 277.78 309.75 2 L V N 439.22 459.75 439.22 242.25 2 L V N 116.09 460 439.47 460 2 L V N 116.09 409 439.47 409 2 L V N 116.09 378 439.47 378 2 L V N 116.09 361 439.47 361 2 L V N 116.09 344 439.47 344 2 L V N 116.09 310 439.47 310 2 L V N 116.09 293 439.47 293 2 L V N 116.09 276 439.47 276 2 L V N 116.09 259 439.47 259 2 L V N 116.09 242 439.47 242 2 L V N 253.94 204 253.94 153 2 L V N 137.56 170 474.44 170 2 L V N 52 103 54 720 R V 52 689 54 701 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 614 54 626 R V 52 597 54 609 R V 52 597 54 609 R V 52 597 54 609 R V 52 597 54 609 R V 52 597 54 609 R V 52 597 54 609 R V 52 597 54 609 R V 52 597 54 609 R V 52 580 54 592 R V 52 580 54 592 R V 52 580 54 592 R V 52 580 54 592 R V 52 580 54 592 R V 52 580 54 592 R V 52 580 54 592 R V 52 580 54 592 R V 52 580 54 592 R V 52 445 54 457 R V 52 445 54 457 R V 52 428 54 440 R V 52 428 54 440 R V 52 428 54 440 R V 52 428 54 440 R V 52 428 54 440 R V 52 428 54 440 R V 52 428 54 440 R V 52 428 54 440 R V 52 428 54 440 R V 52 411 54 423 R V 52 380 54 406 R V 52 380 54 406 R V 52 394 54 406 R V 52 363 54 375 R V 52 346 54 358 R V 52 329 54 341 R V 52 329 54 341 R V 52 329 54 341 R V 52 329 54 341 R V 52 329 54 341 R V 52 320.5 54 332.5 R V 52 312 54 324 R V 52 312 54 324 R V 52 312 54 324 R V 52 295 54 307 R V 52 295 54 307 R V 52 278 54 290 R V 52 278 54 290 R V 52 261 54 273 R V 52 261 54 273 R V 52 244 54 256 R V 52 244 54 256 R V 52 189 54 201 R V 52 172 54 184 R V 52 172 54 184 R V 52 172 54 184 R V 52 172 54 184 R V 52 172 54 184 R V 52 172 54 184 R V 52 172 54 184 R V 52 172 54 184 R V 52 155 54 167 R V 52 155 54 167 R V 52 155 54 167 R V 52 155 54 167 R V 52 155 54 167 R V 52 155 54 167 R V 52 155 54 167 R V 52 155 54 167 R V 52 155 54 167 R V FMENDPAGE %%EndPage: "24" 25 %%Page: "25" 26 612 792 0 FMBEGINPAGE [0 0 0 1 0 0 0] [ 0 1 1 0 1 0 0] [ 1 0 1 0 0 1 0] [ 1 1 0 0 0 0 1] [ 1 0 0 0 0 1 1] [ 0 1 0 0 1 0 1] [ 0 0 1 0 1 1 0] [ 0.5 0.5 0 0.5 0 0 0.5] 8 FrameSetSepColors FrameNoSep 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 0 0 0 1 0 0 0 K 72 746 540 756 R 7 X 0 0 0 1 0 0 0 K V 72 32.67 540 42.67 R V 0 10 Q 0 X (ATMF 94-0325R1) 72 35.85 T (Page 25) 508.06 35.85 T 72 72 540 720 R 7 X V 0 X (IE Instruction Field \050octet 2\051) 117 713.33 T (GCID Type \050octet 5\051) 117 622.33 T (Local Call ID \050octets 6-9\051) 117 531.33 T (The Local Call ID is a 4 octet value used to differentiate calls created by the same Root) 126 515.33 T 1 12 Q (7.2.4) 72 494 T (ROOT NUMBER) 108 494 T 0 10 Q -0.19 (The Root Number \050RN\051 information element is used to identify the new leaf that is joining the call. Its for-) 117 477.33 P 0.54 (mat is identical to that of the Called Party Number information element, except for a different information element) 72 465.33 P (identifier.) 72 453.33 T 1 12 Q (7.2.5) 72 432 T (ROOT SUBADDRESS) 108 432 T 0 10 Q 0.15 (The Root Subaddress \050RS\051 information element is used to identify the new leaf that is joining the call. Its) 117 415.33 P 0.08 (format is identical to that of the Called Party Subaddress information element, except for a different information ele-) 72 403.33 P (ment identifier.) 72 391.33 T 1 12 Q (7.2.6) 72 370 T (NEW LEAF NUMBER) 108 370 T 0 10 Q -0.03 (The New Leaf Number \050NLN\051 information element is used to identify the new leaf that is joining the call.) 117 353.33 P -0.09 (Its format is identical to that of the Calling Party Number information element, except for a different information ele-) 72 341.33 P (ment identifier.) 72 329.33 T 1 12 Q (7.2.7) 72 308 T (NEW LEAF SUBADDRESS) 108 308 T 0 10 Q 0.46 (The New Leaf Subaddress \050NLS\051 information element is used to identify the new leaf that is joining the) 117 291.33 P -0.23 (call. Its format is identical to that of the Calling Party Subaddress information element, except for a different informa-) 72 279.33 P (tion element identifier.) 72 267.33 T 1 12 Q (8) 72 242 T (Summary) 90 242 T 0 10 Q -0.11 (We propose that the approach to leaf initiated joins described in this contribution be adopted by the ATM Forum) 90.86 225.33 P (membership as the general direction for adding this capability to the phase 1 UNI signalling protocol.) 72 213.33 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0 12 Q (Bits) 186.08 693 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 340.3 693 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (5) 157.98 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 171.89 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 185.8 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 199.7 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 676 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 157.98 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 213.61 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (IE instruction \336eld not signi\336cant) 254.38 659 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Bits) 186.08 602 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Meaning) 340.3 602 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (4) 171.89 585 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (3) 185.8 585 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (2) 199.7 585 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 585 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 171.89 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 185.8 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (0) 199.7 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (1) 213.61 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K (Rooted Address) 254.38 568 T 0.5 0.5 0 0.5 0 0 0.5 K 0 0 0 1 0 0 0 K 251.38 704 251.38 653 2 L V 0.5 H 0 Z N 140.12 670 471.88 670 2 L V N 251.38 613 251.38 562 2 L V N 140.12 579 471.88 579 2 L V N 52 238 54 720 R V 52 689 54 701 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 672 54 684 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 655 54 667 R V 52 598 54 610 R V 52 581 54 593 R V 52 581 54 593 R V 52 581 54 593 R V 52 581 54 593 R V 52 581 54 593 R V 52 581 54 593 R V 52 581 54 593 R V 52 581 54 593 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V 52 564 54 576 R V FMENDPAGE %%EndPage: "25" 26 %%Trailer %%BoundingBox: 0 0 612 792 %%PageOrder: Ascend %%Pages: 26 %%DocumentFonts: Times-Roman %%+ Times-Bold %%+ Helvetica %%+ Helvetica-Bold %%+ Helvetica-Oblique %%+ Times-Italic %%EOF   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01348; 9 Aug 94 5:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01344; 9 Aug 94 5:47 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02589; 9 Aug 94 5:47 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA190650166; Tue, 9 Aug 1994 01:16:06 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hubbub.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA190320164; Tue, 9 Aug 1994 01:16:04 -0700 Received: from [198.92.30.65] (macip-dialup-19.cisco.com [198.92.30.65]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id BAA10633; Tue, 9 Aug 1994 01:15:56 -0700 Message-Id: <199408090815.BAA10633@hubbub.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Aug 1994 01:15:58 -0800 To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anthony Alles Subject: Real world multicasting Cc: gja@thumper.bellcore.com, Susan Symington , dino@cisco.com, percyk@glare.cisco.com >Another criteria when considering link layer services required by IPmc >is to ask "what impact will the various choices have on the likelyhood >of successful and timely implementation?". In the same way that RFC1483 >and RFC1577 attempt to provide a conceptually 'easy' first phase migration >to ATM, we might consider a bare-bones IPmc-over-ATMmc using UNI3.0 or 3.1 >as they currently stand. When will vendors actually have 'real' >ATMmc, and which standard will it conform to? > >gja (contemplating out loud, a dangerous habit to have :) I'm glad to see little bit of pragmatism creeping into this discussion. While all the discussion about Fong and Rick's contributions was very interesting and valuable, we should not forget that the first goal should be to get a workable solution for multicast over ATM that people can deploy with UNI 3.0/3.1 signaling. Both these contributions relate only to UNI 4.0 which will not be finalized until mid 1994 and which will probably not be implemented widely till mid 1995 (if the lag for UNI 3.0 is any guide). Long before all that happens, the issue will become irrelevant because LAN Emulation will have become the de facto choice for ATM multiprotocol connectivity. If 1577 and network layer solutions are to have any future over ATM (and I think that they should), then we need a solution *today* for multicast support that builds upon the signaling that exists *today* - i.e UNI 3.0/3.1, not something that may exist sometime in the future. I would strongly endorse the call therefore that we look at defining a workable - even if not fully optimal - solution that can be implemented quickly, while at the same time, if the group desires, pursuing a longer term solution built upon the expected features of UNI 4.0 (and driving this, if required). Let's not forget the immediate problem. Just a comment also on some recent statements that the IP group should only worry about mapping IP Mcast addressing into ATM group addresses and not worry about the ATM Mcast mechanism, since this is in the cloud. While this may be the ideal case, as I mentioned in my earlier email, unfortunately today there is no such defined ATM Mcast mechanism. Hence, if an immediate solution is needed then we will need to pick a mechanism (overlaid pt-to-mpt trees, multicast server, whatever) and use that as the basis of the scheme, just like the LAN Emulation group did. We can go back to the ideal layering approach next year when UNI 4.0 is better defined, but we are not there yet, while we do have pressing needs to solve *today*. Anthony _____________________________________________________________________ Anthony Alles Cisco Systems Product Manager: ATM Tel: 408-526-5424 email: aalles@cisco.com Fax: 408-526-7666 Mail: 170 West Tasman Drive, San Jose CA 95134-1706, USA. Cisco Location: Building D, San Jose Single Site.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08197; 9 Aug 94 13:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08193; 9 Aug 94 13:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13727; 9 Aug 94 13:45 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA271197779; Tue, 9 Aug 1994 08:56:19 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA270867772; Tue, 9 Aug 1994 08:56:12 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA23611; Tue, 9 Aug 94 11:57:53 EDT Received: from pothole.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA09761; Tue, 9 Aug 94 11:55:44 EDT Received: by pothole.fore.com (4.1/SMI-4.1) id AA01059; Tue, 9 Aug 94 11:55:29 EDT Date: Tue, 9 Aug 94 11:55:29 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fong-Ching Liaw Message-Id: <9408091555.AA01059@pothole.fore.com> To: gja@thumper.bellcore.com Subject: Re: multicast Cc: ip-atm@matmos.hpl.hp.com, fong@fore.com > I think I share your concern over algorithmic mapping of > IPmc to ATMmc addresses. (I'm not even sure I understand > why it has been suggested - perhaps someone can clarify, for > me if no one else, why ATMARP mechanisms cannot perform > this mapping?) Assume we are going to map IPmc to ATMmc addresses and use ATMARP to do that. Can you share what you think the ATMARP server/client need to do ? And how does that mapping get "installed" in ATMARP ? I do agree with Anthony that we need an interim solution which uses 3.0 and capability supported by Phase 1 P-NNI (such as anycast). However, I hope we don't spend all our resources try to perfect the interim solution, and forget there are better ways of doing things. Another point about server approach: if we were to use a server approach to implement IPmc, the server has to know every receivers, and every host needs to register with server. This does not scale to high bandwidth and large number of receivers. Extra hop from sender to server introduces extra delay as well, it is harder to guarantee Qos (not impossible). LANE does not have any delay requirement, so they don't care if the packets are delayed by other traffic at server. Assuming we let sender adds all receivers, and use ATMARP to find all the receivers, it does not scale as IPmc. If majority of IPmc applications are video and audio which requires QOS guarantee, we need to be more careful about the server approach. Thanks, -Fong   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10171; 9 Aug 94 15:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10167; 9 Aug 94 15:48 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16781; 9 Aug 94 15:48 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA017204909; Tue, 9 Aug 1994 10:55:09 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from tigger.jvnc.net by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA016794906; Tue, 9 Aug 1994 10:55:06 -0700 Received: from franklin-tty14.jvnc.net. (franklin-tty14.jvnc.net) by tigger.jvnc.net with SMTP id AA24914 (5.65c/IDA-1.4.4 for ip-atm@matmos.hpl.hp.com); Tue, 9 Aug 1994 13:53:37 -0400 Message-Id: Date: Tue, 9 Aug 94 13:52:16 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" Subject: Re: What to say to ATM Forum? Reply-To: dave@corecom.com To: Andy Malis , Anthony Alles Cc: ip-atm@matmos.hpl.hp.com X-Mailer: VersaTerm Link v1.1.1 Dave Katz and I are revising the current draft, and hope to have an i-d available shortly. Andy can correct me if I'm wrong, but I believe the ROLC group expects Next Hop Resolution Protocol to be proposed as a standard at or by the next IETF meeting. Please read the draft and post comments to the ROLC mailing list (or directly to Dave Katz or me). >If you would like to join the ROLC mailing list, just send me email. If >you would like to read the current (pre-Toronto) version of the proposal, >please read draft-ietf-rolc-nhrp-01.txt, available via anonymous FTP from >ds.internic.net, in the internet-drafts/ directory. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10414; 9 Aug 94 16:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10409; 9 Aug 94 16:01 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17080; 9 Aug 94 16:01 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA299594136; Tue, 9 Aug 1994 10:42:16 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA297623028; Tue, 9 Aug 1994 10:23:48 -0700 Date: Tue, 9 Aug 1994 10:23:48 -0700 Message-Id: <199408091723.AA297623028@matmos.hpl.hp.com> To: Anthony Alles Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: Real world multicasting Cc: ip-atm@matmos.hpl.hp.com >Just a comment also on some recent statements that the IP group should only >worry about mapping IP Mcast addressing into ATM group addresses and not >worry about the ATM Mcast mechanism, since this is in the cloud. While >this may be the ideal case, as I mentioned in my earlier email, >unfortunately today there is no such defined ATM Mcast mechanism. Hence, >if an immediate solution is needed then we will need to pick a mechanism >(overlaid pt-to-mpt trees, multicast server, whatever) and use that as the >basis of the scheme, just like the LAN Emulation group did. We can go back >to the ideal layering approach next year when UNI 4.0 is better defined, >but we are not there yet, while we do have pressing needs to solve *today*. I agree with Anthony. It would be real helpful to have something that could be put into the mcast section of RFC1577 when we try to roll the status from proposed to draft. Is there any possibility of just using the LANE mechanism as a basis? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12119; 9 Aug 94 17:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12115; 9 Aug 94 17:42 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19404; 9 Aug 94 17:42 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA042479321; Tue, 9 Aug 1994 12:08:41 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA042149318; Tue, 9 Aug 1994 12:08:38 -0700 Received: from emsr0.emsr.att.com by ig1.att.att.com id AA01430; Tue, 9 Aug 94 15:07:45 EDT Received: from snipe.ho.att.com by emsr0.emsr.att.com (4.1/EMS-1.1 SunOS) id AA01104; Tue, 9 Aug 94 15:07:29 EDT Message-Id: Date: Tue, 9 Aug 94 15:08:37 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Greg Wetzel, +1 908 949 6630" Subject: Re: multicast Reply-To: G_F_Wetzel@att.com To: ip-atm@matmos.hpl.hp.com X-Mailer: VersaTerm Link v1.1.3 >Another point about server approach: I'm not advocating the server approach, mind you, but some of the concerns are solvable by appropriate scoping. >if we were to use a server approach to implement IPmc, the server >has to know every receivers, and every host needs to register >with server. This does not scale to high bandwidth and large number >of receivers.... If the server serves only the LIS (assume this is before ROLC cut-through gets implemented), then you have the same scaling properties as with today's IPmc with tunnels. For version 3.0/3.1 UNI, the ATMmc consists only of the systems comprising the Logical IP Subnet and can use pt-to-mpt from server to clients with pt-to-pt return from client to server (or if no pt-to-mpt is available, bi-directional pt-to-pt connections). These servers *could* be multicast-capable routers, in which case the ATMmc is a straightforward mapping of the IPmc topology onto ATM using the best mechanism available to the ATM network implementing the LIS (e.g., mpt-to-mpt if that's supported, pt-to-mpt if not, and pt-to-pt in the worst case). Within the next higher level of scope, the multicast servers on the various LISs can be similarly interconnected. Since the interfaces at this level probably align with organizational boundaries, there's a good chance that this will neatly align with the physical topology for another, higher level, scope. If other levels of scope are needed, these can be introduced. So we may end up with 3-4 levels of hierarchy in a server-structured ATMmc: LIS/workgroup, building/site/campus, enterprise, worldwide ATM internet. This is where addressing and routing has to be carefully considered. What is the scope of a particular IPmc address? how is that scope related to any associated ATMmc address? Should there be explicit protocol mechanisms to define the desired scope? For example, we run various IPmc groups inside AT&T, but the scope is limited sometimes to specific sites, sometimes to AT&T's internal AS, and infrequently to the entire Internet. Similarly, we import some, but not all IPmc groups off the Internet into the internal AT&T internet. Right now, this scoping is enforced by administration on the IPmc routers/tunnels and our firewall. But this requires that users communicate their needs to adminstrators, which is inconvenient for the user and bad for the administrator (ever had someone unintentionally saturate *your* IP backbone with multicast traffic :-). Wouldn't it be better if we could classify each IPmc group we created into a few predefined (by AS) scopes and let the IPmc routers handle the scoping automatically (e.g., all groups with scope 1 are limited to the site, scope 2 to AT&T, scope 3 to the Internet)? IPmc can't accommodate this easily because it requires that there be a scope tag associated with each IPmc address. It *could* be handled by ATMmc, however, if the address, or better the setup message itself, had scope built in. TTL hop count won't work since it doesn't discriminate on the metric needed (e.g., crossing a particular boundary router or switch). >Assuming we let sender adds all receivers, and use ATMARP to >find all the receivers, it does not scale as IPmc. > >If majority of IPmc applications are video and audio which >requires QOS guarantee, we need to be more careful about the >server approach. Greg Wetzel G_F_Wetzel@att.com +1 908 949 6630 (voice) +1 908 949 1726 (fax) AT&T Bell Laboratories Room 1L-426 P.O. Box 3030 101 Crawfords Corner Road Holmdel, NJ 07733-3030   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12816; 9 Aug 94 18:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12812; 9 Aug 94 18:13 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20127; 9 Aug 94 18:13 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA077724585; Tue, 9 Aug 1994 13:36:25 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA077324580; Tue, 9 Aug 1994 13:36:20 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.2-14 #2740) id <01HFPMMBPTV48Y67NI@sys30.timeplex.com>; Tue, 9 Aug 1994 16:16:46 EDT Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA06439; Tue, 9 Aug 94 16:19:01 EDT Date: Tue, 09 Aug 1994 16:18:59 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: What to say to ATM Forum? In-Reply-To: Your message of "Tue, 09 Aug 1994 13:52:16 EDT." To: dave@corecom.com Cc: Andy Malis , Anthony Alles , ip-atm@matmos.hpl.hp.com Message-Id: <9408092019.AA06439@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Dave, > Dave Katz and I are revising the current draft, and hope to > have an i-d available shortly. Andy can correct me if I'm > wrong, but I believe the ROLC group expects Next Hop Resolution > Protocol to be proposed as a standard at or by the next IETF > meeting. Please read the draft and post comments to the ROLC > mailing list (or directly to Dave Katz or me). Thanks much for the update. For the benefit of those of you not on the rolc list, the WG does hope to be able to complete work by the San Jose meeting, and at that time recommend that NHRP be submitted for the standards track. If you would like to read (and comment on) the pre-Toronto NHRP draft, you can find it in draft-ietf-rolc-nhrp-01.txt. Let's move further rolc discussion to its own list: rolc@maelstrom.timeplex.com. Cheers, Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13096; 9 Aug 94 18:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13092; 9 Aug 94 18:34 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20498; 9 Aug 94 18:34 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA064034104; Tue, 9 Aug 1994 13:28:24 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from glare.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA063694102; Tue, 9 Aug 1994 13:28:22 -0700 Received: (percyk@localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA09758; Tue, 9 Aug 1994 13:28:19 -0700 Date: Tue, 9 Aug 1994 13:28:19 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Percy Khabardar Message-Id: <199408092028.NAA09758@glare.cisco.com> To: ip-atm@matmos.hpl.hp.com Cc: dino@cisco.com Subject: Multicasting over ATM draft We'd like to propose a solution for doing multicasting over ATM networks using existing standards. The goal was to keep the protocol simple, robust, and easy to implement. We want traditional multicast-based protocols to work unmodified over ATM. This is only a preliminary draft. Also note that although this draft references routers the same concepts are equally applicable to other ATM hosts. - Percy & Dino ATM Multicasting On Routers --------------------------- Percy Khabardar & Dino Farinacci cisco Systems August 9, 1994 Introduction ------------ Today's ATM capable routers are increasingly using the high bandwidth and low latency beneifts of ATM to interconnect existing (legacy) LAN internetworks. Multicast and broadcast capabilities which are so fundamental to a shared LAN is not available on ATM however. Moreover most of the existing network layer protocols rely on this multicasting property offered by today's LAN for correct operations. In the absence of multicasting on ATM, today's routers use a technique called pseudo-broadcasting to propogate multicast/broadcast packets across the ATM network to build their routing tables. Pseudo broadcasting requires the router's ATM interfaces to be statically configured with the network layer address and the ATM address of the neighbouring (next hop) ATM router. The ATM driver in the router would then replicate a outgoing multicast/broadcast packet onto every ATM interface which has pseudo-broadcast configured. There are two serious limitiations with this approach. First as the size of the network grows the amount of (error prone) configuration to be done by the user increases dramatically. Second with the increasing use of multimedia applicatons even a fairly small sized network would seriously overload the CPU of a router as it tries to replicate every received multicast packet on it's ATM interfaces. Design Goals ------------ The goal of this document is to provide a multicast solution for ATM networks which would efficiently solve the two above mentioned problems. The design goals are as follows - - Minimize router configuration. The routers should build their routing tables dynamically by multicasting techniques outlined in this document. - Minimize router overhead. The router should be able to send a multicast packet on the ATM network just as efficiently as it does on today's shared LAN networks i.e. the router sends a single packet/ cell to the network and the network delivers the packet/cell to all multicast members of the group. There should be no packet replication done by the router. The switch does cell replication. This is not a problem as today's switches have efficient mechanisms for cell replication. - The network layer directly interfaces to the ATM driver. - Redundancy (No single points of failure). There is no single point of failure in the design proposed. The network will continue to function if one or more routers fails as long as there is a route from the source host to a destination host. - Distributed Load. Every router is responsible for transmitting it's own multicast packets to the rest of the ATM network. There are no centralized multicast server(s) towards which all multicast traffic is directed and from which all multicast traffic flows to the network. - Transparent to Multicast Protocols - the scheme is transparent to network layer (routing) protocols and IP multicast protocols. It could also be used by bridging protocols. The design provides a basic multicasting facility on ATM networks which could be used by any higher layer protocol. Note - this document only outlines a concept. Packet formats and state machines will follow in later documents. All references to router in this document refers to an ATM capable router wishing to participate in ATM multicasting with other ATM capable routers. Point-to-Multipoint Connections ------------------------------- The basic ATM capability used by this design is the Point-to-Multipoint connection provided by ATM Forum's UNI 3.0 and higher Signalling protocols. A Point-to-Multipoint connection is a collection of associated ATM VC links, with associated endpoints nodes with the following properties: - One ATM link, called the Root Link, serves as the root in a simple tree topology. When the Root node sends information, all of the remaining nodes on the connection called Leaf nodes, receive copies of the information. - Currently only zero return bandwidth from leaves to the root is supported, i.e. data can be sent in only one direction - from root to leaf. - The Leaf Nodes cannot communicate directly to each other with this connection type. A point-to-multipoint connection is setup by first establishing a point to point connection between the root node and one leaf node. After this setup is complete, additional leaf nodes can be added to the connection by "add party" requests from the root node. A leaf node may be added or dropped from a point-to-multipoint connection at any time after the establishment of the connection. A new leaf node can be added to an existing connection via the root node issuing an add party request. A leaf node can be dropped from a connection as a result of a request sent by either the root node or by the leaf node to be dropped (but not by another leaf). Note - Leaf Initiated Joins which are being currently discussed in the ATM Forum for inclusion in UNI4.0 are not covered in this document. Protocol Details ---------------- As mentioned above, point-to-multipoint connections is the basic mechanism used in the design. However establishment of point-to- multipoint connections requires knowledge of ATM addresses of the members of the multicast group. A router wishing to participate in ATM multicasting with other routers finds out the ATM addresses of it's group members and becomes part of the multicast group as follows - - Every router has knowledge of and should be able to reach a well-known end node on the ATM network. The function of this well known ATM end node is to provide routers coming online with ATM addresses of existing group members. The functionality of the well known ATM end node could also be embedded in a router. - Every router at startup time opens up a point-to-point connection with this well known ATM end node and informs it of its ATM address and the multicast group it wants to be a part of. The well-known ATM end node in turn informs the incoming router of the ATM addresses of all the existing group members. - Once the incoming router gets ATM addresses of all it's group members it opens up point-to-multipoint connections with each of the multicast group members. - The other routers on detecting that they have become Leaves to the incoming router add the incoming router to their point-to-multipoint connections (the incoming router becomes a Leaf to each of the existing group members point-to-multipoint connections). - Thus every router is a Root to every other router in the same multicast group. It is also a Leaf to every other router in the same multicast group. An example would help clarify the mechanism - To simplify the example it is assumed that there is only one multicast group in the ATM network. It even assumes that the well-known ATM end node is also a router. 1. Router B coming online establishes a point-to-point connection with with a well-known ATM router A. On establishing the connection it informs Router A of it's ATM address and the multicast group it wants to be a member of. 2. Router A stores router B's ATM address and the group it wants to be a part of. 3. Router A informs router B of all the existing group members. Since router A is the only router currently in the same multicast group it informs router B of it's ATM address. 4. Router A opens up a point-to-multipoint connection with router B. Similarly Router B opens up a point-to-multipoint connection with router A. 4. At this point there are 2 routers in the ATM network, each acting as a Root to each other. Each router can send multicast packets to the other on it's point-to-multipoint vc. 5. Router C coming online would similarly establish a point-to-point connection with router A. On establishing the connection it informs router A of it's ATM address and the multicast group it wants to be a member of. 6. Router A stores router C's ATM address and the multicast group it wants to be a part of. 7. Router A informs router C of the existing group members (in this case routers A and B). 8. Router C on getting this information opens a point-to-muiltipoint connection with routers A and B. 9. Routers A and B on detecting that they have become leaves to C in turn add router C to their respective point-to-multipoint connections. 10. At this point there are three roots in the network each with 2 leaves. Each router can send multicast packets to the other two over it's point-to-multipoint connections. The basic mechanism could be summarized as follows - A incoming router establishes point-to-point connection with a well known node. The well-known node stores the incoming router's ATM address and the multicast group it wants to be a part of. The well known node informs the incoming router of the ATM addresses of all the existing group members. The incoming router opens a point-to- multipoint connection and adds all the existing group members to it. The existing group memmbers on detecting that they have become leaves to a new member adds the new member to their point-to-multipoint connections. To leave a multicast group, a member closes it's point-to-multipoint connection to the group. The existing group members on detecting that a member has gone away also drop that member (leaf) from their point- to-multipoint connections. The going away member should also inform the well known node that it no longer wishes to be a part of the multicast group. What happens if the well known node fails? ------------------------------------------ As mentioned in the desgin goals there should not be a single point of failure in the network. It might appear however that the well known node is a single point of failure. If it dies then a new router coming online would be able to obtain the ATM addresses of the group members. However such is not the case. If the well known node dies for any reason the point-to-point connection between itself and all the routers would also be torn down. The routers on detecting this would open up a new svc connection to a backup node. The ATM address of the backup node is also known to every router. Since routers at this stage have knowledge of their group members it again registers their ATM addresses with the backup server. To minimize network traffic the routers indicate to the backup node that it already has knowledge of existing group members. In this case the backup node will only inform the routers of new incoming routers. Every router should however continously keep on trying to establish connection with the primary well known node. On establishing such a connection the connection to the backup node should be torn down. What happens if one of the multicast router fails? -------------------------------------------------- If one of the multicast router in the network fails all the routers which have a point-to-multipoint vc open with it detect this and remove this router as their leaf and from their internal table. The network will continue to function. (It is no different from a router failing on a shared LAN). Configuration Requirements on the Router ---------------------------------------- Only two ATM addresses need to be configured on the router. The ATM addresses of the primary and the backup well known nodes. VC Support ---------- The total number of "multicast vc's" active on a router is equal to N. where N is the number of members in a multicast group. Switch Requirements ------------------- To participate in multicasting the switches need to support UNI3.0 and higher Signalling protocols - in particular the point-to- multipoint component of UNI3.0 is a requirement. Conclusion ---------- We believe that we have been able to show a scheme which makes the ATM network look like a shared LAN on which multicasting is as easily done as on a shared LAN. The design is distributed, there are no single points of failure and the protocol complexity is minimal.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13251; 9 Aug 94 18:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13247; 9 Aug 94 18:44 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20673; 9 Aug 94 18:44 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA096246245; Tue, 9 Aug 1994 14:04:05 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA095916242; Tue, 9 Aug 1994 14:04:02 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id RAA13695; Tue, 9 Aug 1994 17:02:00 -0400 Message-Id: <199408092102.RAA13695@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Anthony Alles Cc: ip-atm@matmos.hpl.hp.com Subject: Re: Real world multicasting In-Reply-To: Your message of Tue, 09 Aug 94 01:15:58 -0800. <199408090815.BAA10633@hubbub.cisco.com> Date: Tue, 09 Aug 94 17:01:59 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [I wrote...] >>>Another criteria when considering link layer services required by IPmc >>>is to ask "what impact will the various choices have on the likelyhood >>>of successful and timely implementation?". >>I'm glad to see little bit of pragmatism creeping into this discussion. I promise I'll try not to do it too often :-) [..] >>Just a comment also on some recent statements that the IP group should only >>worry about mapping IP Mcast addressing into ATM group addresses and not >>worry about the ATM Mcast mechanism, since this is in the cloud. While >>this may be the ideal case, as I mentioned in my earlier email, >>unfortunately today there is no such defined ATM Mcast mechanism. Unless I missed a post, I think I was responsible for trying to 'black box' the ATM cloud. Just to put it into perspective, I certainly think we need to take note of how ATMmc connections are established, but only to the extent that UNI 3.0 or 3.1 allow - i.e. Sender initiated ADD PARTY, etc. My concern was to avoid people wasting time thinking IP needed to worry about how the ATM cloud actually chooses its inter-switch mc topology (and other internal issues). regards, gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01174; 10 Aug 94 6:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01170; 10 Aug 94 6:17 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa02709; 10 Aug 94 6:17 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA228368940; Wed, 10 Aug 1994 01:55:40 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from mailgate.ericsson.se by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA228038932; Wed, 10 Aug 1994 01:55:32 -0700 Received: from ebcs03.ebc.ericsson.se by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.14) id AA29879; Wed, 10 Aug 94 10:54:55 +0200 Received: from ebc.ericsson.se.ericsson.se (sgsun70.ebc.ericsson.se) by ebcs03.ebc.ericsson.se (4.1/SMI-4.1-LME1.6) id AA18190; Wed, 10 Aug 94 10:54:53 +0200 Received: from ebcw298.ericsson.se by ebc.ericsson.se.ericsson.se (4.1/SMI-4.1) id AA07094; Wed, 10 Aug 94 10:54:52 +0200 Date: Wed, 10 Aug 94 10:54:52 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: SG/EBC/FB/FX Bengt Persson 08-764 0343 Message-Id: <9408100854.AA07094@ebc.ericsson.se.ericsson.se> To: percyk@cisco.com Subject: Re: Multicasting over ATM draft Cc: ip-atm@matmos.hpl.hp.com Percy and Dino proposes: > We'd like to propose a solution for doing multicasting over ATM networks > using existing standards. The goal was to keep the protocol simple, robust, > and easy to implement. We want traditional multicast-based protocols to > work unmodified over ATM. > > This is only a preliminary draft. Also note that although this draft > references routers the same concepts are equally applicable to other ATM > hosts. > > - Percy & Dino > > > > > > ATM Multicasting On Routers > --------------------------- > Percy Khabardar & Dino Farinacci > cisco Systems > August 9, 1994 > > > Introduction > ------------ > > Today's ATM capable routers are increasingly using the high bandwidth > ...... > > Conclusion > ---------- > > We believe that we have been able to show a scheme which makes the > ATM network look like a shared LAN on which multicasting is as easily > done as on a shared LAN. The design is distributed, there are no > single points of failure and the protocol complexity is minimal. > The proposed scheme is an obvious primary choice for initial implementations of IPmc of ATM. It simple to understand and implement and robust and effiecient enough for even fairly largescale usage. No problems with mc-groups spanning multiple networks (as long as the NNI suppost UNI 3.0 functionality on ATMmc). No problems with many groups in a network and even very large groups (>>1000 members) are easy to handle as long all members support that many VCs. The only problem I have identified so far is some potential racing in the call setups (two new members attach to the network "simultainusly") but that should be solvable with a timer or procedureal rules. The requirement for configuring two ATM addresses seem to be an overkill. Many networks support logical numbers, such that only one party will recive calls to a given number as long as that pary is operational (similar to 800 numbers but only one server at a time). If the network do not support exclusivity a separate procedure between the servers could sovlve any such problems. /Bengt (note: personal opinion and not company sanctioned)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09020; 10 Aug 94 14:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09016; 10 Aug 94 14:11 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13333; 10 Aug 94 14:11 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA004605188; Wed, 10 Aug 1994 09:13:08 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ccc.casc.com (casc.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA004275184; Wed, 10 Aug 1994 09:13:04 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jmoy@alpo.casc.com Received: from alpo.casc.com ([192.9.200.2]) by ccc.casc.com (4.1/3.1.012693-Cascade) Message-Id: <9408101611.AA16144@ccc.casc.com> Date: Wed, 10 Aug 94 12:11:04 EDT Received: by chi.cascade (4.1/SMI-4.1) id AA00205; Wed, 10 Aug 94 12:00:33 EDT To: ip-atm@matmos.hpl.hp.com Cc: percyk@cisco.com, dino@cisco.com Subject: Multicasting over ATM draft Percy and Dino- A couple of quick comments about your draft. First, in the IP multicast model a sender to a group does not have to be a member of the group itself. Your proposal does not seem to support this, although it could definitely be changed to do so. Second, if you are going to use an ATM cloud as part of the MBONE, you really want the IP multicast routers at the edge to listen promiscuously to all groups. Again, your proposal does not address this, although it could. I also think that it would be clearer if you just replace "router" with "group member" (or something) in the whole draft. There really isn't anything specific to routers in the draft, and that's just confusing the issue (in my opinion). John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09200; 10 Aug 94 14:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09196; 10 Aug 94 14:20 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13474; 10 Aug 94 14:20 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA023358322; Wed, 10 Aug 1994 10:05:22 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from feta.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA023028321; Wed, 10 Aug 1994 10:05:21 -0700 Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA28155; Wed, 10 Aug 1994 10:04:18 -0700 Date: Wed, 10 Aug 1994 10:04:18 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dino Farinacci Message-Id: <199408101704.KAA28155@feta.cisco.com> To: jmoy@alpo.casc.com Cc: ip-atm@matmos.hpl.hp.com, percyk@cisco.com In-Reply-To: jmoy@alpo.casc.com's message of Wed, 10 Aug 94 12:11:04 EDT <9408101611.AA16144@ccc.casc.com> Subject: Multicasting over ATM draft >> A couple of quick comments about your draft. First, in the IP >> multicast model a sender to a group does not have to be a member >> of the group itself. Your proposal does not seem to support this, >> although it could definitely be changed to do so. Second, if you >> are going to use an ATM cloud as part of the MBONE, you really >> want the IP multicast routers at the edge to listen promiscuously >> to all groups. Again, your proposal does not address this, >> although it could. John, as you state sender-only systems is easy to implement. Just need to find out group membership and not required to join. Our intent here is to make a logical multicast mesh so routing protocols and IP multicast can treat ATM as they would an Ethernet. Initially, we envision all IP multicast packets are sent to a previously setup ATM group (much the same way IP multicast is sent on Token Ring but it will not involve every system on the ATM network). So, all routers do get all multicasts. One item I should point out. This proposal is for general multicast on ATM. It is not designed specifically for IP multicast but other forms of single-hop multicast. In a second phase, we look at other methods that make for scalable IP multicast over ATM. >> I also think that it would be clearer if you just replace "router" >> with "group member" (or something) in the whole draft. There >> really isn't anything specific to routers in the draft, and that's >> just confusing the issue (in my opinion). We will make this change. Thanks for comments. Dino   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09282; 10 Aug 94 14:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09277; 10 Aug 94 14:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13565; 10 Aug 94 14:23 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA029668557; Wed, 10 Aug 1994 10:09:17 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from feta.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA029328551; Wed, 10 Aug 1994 10:09:11 -0700 Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA28405; Wed, 10 Aug 1994 10:09:24 -0700 Date: Wed, 10 Aug 1994 10:09:24 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dino Farinacci Message-Id: <199408101709.KAA28405@feta.cisco.com> To: percyk@cisco.com, ip-atm@matmos.hpl.hp.com In-Reply-To: Percy Khabardar's message of Wed, 10 Aug 1994 09:29:20 -0700 <199408101629.JAA09826@glare.cisco.com> Subject: [ebcbghp@ebc.ericsson.se: Re: Multicasting over ATM draft] >> The requirement for configuring two ATM addresses seem to be an >> overkill. Many networks support logical numbers, such that only one >> party will recive calls to a given number as long as that pary is >> operational (similar to 800 numbers but only one server at a time). >> If the network do not support exclusivity a separate procedure >> between the servers could sovlve any such problems. Bengt, we are aware of ATM logical addresses. However, we were not sure (at least I was not) how widely how available it is so we decided to provide a little configuration. Maybe switch vendors on this list can comment about this. Dino P.S. Please copy me on any responses, I'm not on this list.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09712; 10 Aug 94 14:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09708; 10 Aug 94 14:40 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14046; 10 Aug 94 14:40 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA048438924; Wed, 10 Aug 1994 10:15:24 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from glare.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA048048922; Wed, 10 Aug 1994 10:15:22 -0700 Received: (percyk@localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA12173; Wed, 10 Aug 1994 10:15:18 -0700 Date: Wed, 10 Aug 1994 10:15:18 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Percy Khabardar Message-Id: <199408101715.KAA12173@glare.cisco.com> To: dino@cisco.com Cc: ip-atm@matmos.hpl.hp.com In-Reply-To: Dino Farinacci's message of Wed, 10 Aug 1994 10:09:24 -0700 <199408101709.KAA28405@feta.cisco.com> Subject: [ebcbghp@ebc.ericsson.se: Re: Multicasting over ATM draft] >> The requirement for configuring two ATM addresses seem to be an >> overkill. Many networks support logical numbers, such that only one >> party will recive calls to a given number as long as that pary is >> operational (similar to 800 numbers but only one server at a time). >> If the network do not support exclusivity a separate procedure >> between the servers could sovlve any such problems. Bengt, we are aware of ATM logical addresses. However, we were not sure (at least I was not) how widely how available it is so we decided to provide a little configuration. Maybe switch vendors on this list can comment about this. I think you are referring to anycasting here. Anycasting is not a part of UNI3.0 or 3.1 (it's in UNI4.0) and hence we did not want to use that feature in the design. - Percy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10105; 10 Aug 94 14:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10101; 10 Aug 94 14:57 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14488; 10 Aug 94 14:57 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA065930172; Wed, 10 Aug 1994 10:36:12 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gimli.trillium.com.trillium.com (gimli.trillium.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA065460138; Wed, 10 Aug 1994 10:35:39 -0700 Received: by trillium.com (5.0/SMI-SVR4) id AA05454; Wed, 10 Aug 1994 10:37:31 +0800 Date: Wed, 10 Aug 1994 10:37:31 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rajeev@trillium.com Message-Id: <9408101737.AA05454@trillium.com> To: ip-atm@matmos.hpl.hp.com Subject: IP over ISDN X-Sun-Charset: US-ASCII Content-Length: 983 I apologize if this question is deemed irrelevant to this group, but I could think of no other place to ask this: is there an RFC or some other specification about how to use IP over ISDN? What I specifically want to know is if there is any recommendation about how IP should use ISDN signalling (Q.931) to establish B-channels (similar to the ATM signalling for IP draft), whether there is a notion of ARP over ISDN (similar to ATMARP), etc. Of course, once a clear B-channel has been established, IP can run over PPP or similar link protocols. Thanks for any comments you may offer. ------------------------------------------------------------------- Rajeev Gupta Email : rajeev@trillium.com Trillium Digital Systems, Inc. Voice (w) : (310) 479-0500 Los Angeles, CA 90025. Fax (w) : (310) 575-0172 * I speak only for myself, but make no claim to original thought * -------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10284; 10 Aug 94 15:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10280; 10 Aug 94 15:06 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14671; 10 Aug 94 15:06 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA080711357; Wed, 10 Aug 1994 10:55:57 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from glare.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA080381355; Wed, 10 Aug 1994 10:55:55 -0700 Received: (percyk@localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA14571; Wed, 10 Aug 1994 10:55:42 -0700 Date: Wed, 10 Aug 1994 10:55:42 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Percy Khabardar Message-Id: <199408101755.KAA14571@glare.cisco.com> To: ebcbghp@ebc.ericsson.se Cc: dino@cisco.com, ip-atm@matmos.hpl.hp.com In-Reply-To: SG/EBC/FB/FX Bengt Persson 08-764 0343's message of Wed, 10 Aug 94 10:54:52 +0200 <9408100854.AA07094@ebc.ericsson.se.ericsson.se> Subject: Multicasting over ATM draft Bengt, > The only problem I have identified so far is some potential racing in the > call setups (two new members attach to the network "simultainusly") but > that should be solvable with a timer or procedureal rules. I think this could be solved by requiring the well known server to process each "Join" request serially and completely before processing the next one. - Percy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15907; 10 Aug 94 21:31 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15903; 10 Aug 94 21:31 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23348; 10 Aug 94 21:31 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA143530638; Wed, 10 Aug 1994 16:17:18 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA143200635; Wed, 10 Aug 1994 16:17:15 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.3-7 #2740) id <01HFR7540ZC08Y5CBD@sys30.timeplex.com>; Wed, 10 Aug 1994 19:15:22 EDT Received: from michdry. (michdry.timeplex.com) by louie.timeplex.com (4.1/SMI-4.1) id AA04455; Wed, 10 Aug 94 18:14:56 CDT Date: Wed, 10 Aug 1994 18:14:56 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Gaddis Subject: Re: Real world multicasting To: ip-atm@matmos.hpl.hp.com Message-Id: <9408102314.AA04455@louie.timeplex.com> Content-Transfer-Encoding: 7BIT > > I'm glad to see little bit of pragmatism creeping into this discussion. > While all the discussion about Fong and Rick's contributions was very > interesting and valuable, we should not forget that the first goal should > be to get a workable solution for multicast over ATM that people can deploy > with UNI 3.0/3.1 signaling. Both these contributions relate only to UNI > 4.0 which will not be finalized until mid 1994 and which will probably not > be implemented widely till mid 1995 (if the lag for UNI 3.0 is any guide). > > Long before all that happens, the issue will become irrelevant because LAN > Emulation will have become the de facto choice for ATM multiprotocol > connectivity. If 1577 and network layer solutions are to have any future > over ATM (and I think that they should), then we need a solution *today* > for multicast support that builds upon the signaling that exists *today* - > i.e UNI 3.0/3.1, not something that may exist sometime in the future. > > Anthony > Anthony makes many good points but we must also be careful not to take the need for short term pragmatism too far. It can lead to the development of systems that are not scalable but must still be accomodated for backward compatibility. When (and if) we fix the scaling issues for 4.0 the resultant combined 3.1/4.0 system might be far more complex then we intended. I also believe that we should be very careful not to hang our hopes on LAN emulation exclusively. 1577 will likely gain "legs" and if we punt now we will probably have to pay for this in the not too distant future. I suggest that the IETF consider *both* 3.1 and 4.0 compatibility in their multicast design. A transition and interoperability plan should be understood a priori to acceptance of the 3.1 approach. Also, it would be very helpful if the IETF continue with proactive support of the addressing and signaling components needed for "believable" scalability in UNI 4.0. Mike Gaddis Director, Software Development Ascom Timeplex email: gaddis@timeplex.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16991; 10 Aug 94 22:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16986; 10 Aug 94 22:26 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24133; 10 Aug 94 22:26 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA165524225; Wed, 10 Aug 1994 17:17:05 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA165174208; Wed, 10 Aug 1994 17:16:48 -0700 Date: Wed, 10 Aug 1994 17:16:48 -0700 Message-Id: <199408110016.AA165174208@matmos.hpl.hp.com> To: Mike Gaddis Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: Real world multicasting Cc: ip-atm@matmos.hpl.hp.com >I suggest that the IETF consider *both* 3.1 and 4.0 compatibility >in their multicast design. A transition and interoperability plan should >be understood a priori to acceptance of the 3.1 approach. Also, it >would be very helpful if the IETF continue with proactive support of the >addressing and signaling components needed for "believable" scalability >in UNI 4.0. An RFC can only reference published (public) works. UNI 4.0 is not going to be out for quite some time (on the IPmc scale). UNI 3.1 may be a little too far out, but withing range of writing a spec cover UNI 3.0 now and ramping to 3.1 as part of the proposed to draft transition. This is what will be done with the signaling draft, for example. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24746; 11 Aug 94 3:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24742; 11 Aug 94 3:09 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa28019; 11 Aug 94 3:09 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA218894798; Wed, 10 Aug 1994 22:59:58 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from chenas.inria.fr by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA218564795; Wed, 10 Aug 1994 22:59:55 -0700 Received: from ost.fr (orion.ost.fr.38.104.193.in-addr.arpa) by chenas.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet id AA14834; Thu, 11 Aug 1994 07:59:55 +0200 (MET) Received: by ost.fr (5.0/SMI-SVR4) id AA22023; Thu, 11 Aug 1994 07:57:54 --100 Received: From OST3-RDC/WORKQUEUE by charon.ost.fr via Charon-4.0A-VROOM with IPX id 100.940811082832.384; 11 Aug 94 08:29:04 +0500 Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CHRISTOPHE MARIE To: rajeev@trillium.com, ip-atm@matmos.hpl.hp.com Date: Thu, 11 Aug 1994 08:28:26 GMT Subject: Re: IP over ISDN Priority: normal X-Mailer: Pegasus Mail/Windows (v1.11a) Content-Length: 2174 > Date: Wed, 10 Aug 1994 10:37:31 +0800 > From: rajeev@trillium.com > To: ip-atm@matmos.hpl.hp.com > Subject: IP over ISDN > > I apologize if this question is deemed irrelevant to this group, but > I could think of no other place to ask this: is there an RFC or some > other specification about how to use IP over ISDN? What I specifically > want to know is if there is any recommendation about how IP should > use ISDN signalling (Q.931) to establish B-channels (similar to the > ATM signalling for IP draft), whether there is a notion of ARP over ISDN > (similar to ATMARP), etc. Of course, once a clear B-channel > has been established, IP can run over PPP or similar link protocols. > > Thanks for any comments you may offer. > > ------------------------------------------------------------------- > Rajeev Gupta Email : rajeev@trillium.com > Trillium Digital Systems, Inc. Voice (w) : (310) 479-0500 > Los Angeles, CA 90025. Fax (w) : (310) 575-0172 > * I speak only for myself, but make no claim to original thought * > ------------------------------------------------------------------- > Hi Rajeev, There is a mailing list called comp.dcom.isdn. Perhaps it would more relevant. But, I'll try to answer your questions. For IP over ISDN, you have basivally two ways to implement it: First : use X.25 on B or D ISDN channels and be compliant with the RFC1356. Second : use PPP on B channel and be compliant with all the RFCs refering to PPP. There is no recommandation on how IP should manage ISDN Signalling. In fact, there is at this time (except for ATM and perhaps for Frame-Relay) no recommandation at all for managing connection and disconnection over switched WANs. Here in Europe, it is one of our major interoperability problem. I expect this will help. chris ---------------------------------------------------------- OST Christophe MARIE ZI du Sud-Est, BP 158 tel : (33) 99-325-050 35515 Cesson-Sevigne Cedex fax : (33) 99-417-175 France chris.marie@ost.fr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10453; 11 Aug 94 15:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10449; 11 Aug 94 15:06 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10605; 11 Aug 94 15:06 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA027876317; Thu, 11 Aug 1994 10:31:57 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA027546315; Thu, 11 Aug 1994 10:31:55 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA16589; Thu, 11 Aug 1994 12:31:53 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1) id AA16433; Thu, 11 Aug 1994 12:31:51 -0500 Received: from dbg.dev.cdx.mot.com (dbg.dev.cdx.mot.com [134.33.32.39]) by merlin.dev.cdx.mot.com (8.6.9/8.6.9) with ESMTP id NAA12674; Thu, 11 Aug 1994 13:31:50 -0400 Received: from localhost (localhost [127.0.0.1]) by dbg.dev.cdx.mot.com (8.6.9/8.6.5) with SMTP id NAA27312; Thu, 11 Aug 1994 13:31:48 -0400 Message-Id: <199408111731.NAA27312@dbg.dev.cdx.mot.com> X-Authentication-Warning: dbg.dev.cdx.mot.com: Host localhost didn't use HELO protocol To: Mark Laubach Cc: ip-atm@matmos.hpl.hp.com Subject: Re: ATM INAP DSU clarification In-Reply-To: Your message of "Mon, 08 Aug 94 10:12:11 PDT." <199408081712.AA228445931@matmos.hpl.hp.com> Date: Thu, 11 Aug 94 13:31:45 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp > Routers are using FR (NLPID) encapsulation on the serial link. > To the DSU, the encapsulation is part of the data stream and > is therefore ignored. DSU's were consistently using AAL3/4 > to carry the PDU's. One vendor can now support AAL5. At > some point in the future, the other major DSU vendor will > support AAL5 also. > > Router vendors, with native ATM interfaces, are supporting > LLC/SNAP encapsulation and AAL5 only. So you can see that > a native ATM router interface cannot interoperate with a > DSU shredded PDU. Same for hosts with native ATM > interfaces. AAL3/4 != AAL5 and NLPID != LLC/SNAP. > > The ATM INAP folks have it as a goal to be able to get to > an all LLC/SNAP and AAL5 world within the next year. As another data point, my boss attended an NII meeting in Washington this week. One of the handouts from a Pacific*Bell presentation on their California First project (labelled, for those of you who have a copy, "Figure PBO-2. Phase 1 Option B California NAP Topology") clearly shows a Mid-level connected to a frame relay network. On the other side of the frame relay network is a box marked 'IWU', connected by a DS-3 to an ATM network. That has lots of ATM over DS3s to routers on the edges of CIX/FIXs, other mid-levels, NSPs, Federal Agency backbones and very high speed backbones. The legend identifies IWU as a "Layer 2 InterWorking Unit". Clearly, the IWU is not a router. Therefore, either a) the routers talking IP over ATM to all the other networks really run RFC 1490 over FRSSCS over AAL5; or b) IWU somehow-or-other converts RFC 1490 into RFC 1483 and vice-versa. I'd hate to be the poor sucker who had to implement (b), so I've got to believe (a). I hope that this doesn't incite the "architecture police" to go to San Ramon tomorrow morning at 2 AM, bash down the door and 'disappear' the nice Pac*Bell folks :-).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15530; 11 Aug 94 19:57 EDT Received: from corp.timeplex.com by IETF.CNRI.Reston.VA.US id aa15520; 11 Aug 94 19:57 EDT Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.3-7 #2740) id <01HFSEHB3O348Y6URN@sys30.timeplex.com>; Thu, 11 Aug 1994 15:56:02 EDT Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA16893; Thu, 11 Aug 94 15:48:14 EDT Date: Thu, 11 Aug 1994 15:48:13 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: rolc and ip/atm multicasting To: rolc@maelstrom.timeplex.com, ip-atm@matmos.hpl.hp.com Cc: malis@maelstrom.timeplex.com, jhalpern@newbridge.com Reply-to: rolc@maelstrom.timeplex.com Message-id: <9408111948.AA16893@maelstrom.timeplex.com> Content-transfer-encoding: 7BIT [My apologies to those of you receiving this twice - I realize there is quite a bit of overlap between the two lists.] For those of you not on the ip-atm list, there has been some discussion there about doing rolc-like optimization of IP multicast routing when layered over ATM multicasting. At present, the rolc WG is working on optimizing unicast datagram flow over large link-layer networks (ATM or otherwise) that have an IP routing topology overlaid on them in other than a simple one-one manner. We have not discussed multicast flows at all in the WG, and there is reasonable doubt whether it is within the current charter to do so. The biggest problem is that rolc is trying to find a network-layer solution that works over arbitrary link-layer networks, and there is so little multicasting commonality between different link layer technologies (when it is even supported) that finding a general solution may not be possible (other than datagram replication at the network layer, of course :-) ). Even if the WG decides that it would like to tackle multicasting, realizing that different solutions may be required for the various link layer technologies, no WG member has to date either suggested this work be tackled or contributed any ideas on how to do it. So, this message is both a poll and a solicitation: 1. Do people think the rolc WG should include multicasting in its charter? 2. If yes, do people feel it is OK to have link-layer-specific multicasting solutions? Or carried to an extreme, one solution for ATM Forum UNI 3.0, a second for 3.1, a third for 4.0, and so on, given that they each provide different ATM multicasting capabilities? 3. Are there any volunteers out there to work on a draft (or drafts) on how to optimize IPv4 [and, for the future, IPng] multicast flows over link layers that support their own multicasting facilities? Again, this would concentrate on the case where the link layer net has an arbitrary IP topology overlay; groups like ip-atm will work on the one-one case (one such draft has already appeared on the ip-atm list). One important point: this work will, of necessity, be separate from the current NHRP draft, so we can get a unicast solution out as soon as possible. Please, send replies ONLY to rolc@maelstrom.timeplex.com. The ip-atm list has enough mail as it is! Thanks, Andy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16607; 11 Aug 94 22:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16602; 11 Aug 94 22:00 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19937; 11 Aug 94 22:00 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA107992532; Thu, 11 Aug 1994 17:48:52 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA107662524; Thu, 11 Aug 1994 17:48:44 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.3-7 #2740) id <01HFSNKBDKWW8Y6H97@sys30.timeplex.com>; Thu, 11 Aug 1994 20:16:33 EDT Received: from michdry. (michdry.timeplex.com) by louie.timeplex.com (4.1/SMI-4.1) id AA06916; Thu, 11 Aug 94 19:15:47 CDT Date: Thu, 11 Aug 1994 19:15:47 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Gaddis Subject: Re: Real world multicasting To: laubach@netcom.com Cc: ip-atm@matmos.hpl.hp.com Message-Id: <9408120015.AA06916@louie.timeplex.com> Content-Transfer-Encoding: 7BIT > > >I suggest that the IETF consider *both* 3.1 and 4.0 compatibility > >in their multicast design. A transition and interoperability plan should > >be understood a priori to acceptance of the 3.1 approach. Also, it > >would be very helpful if the IETF continue with proactive support of the > >addressing and signaling components needed for "believable" scalability > >in UNI 4.0. > > (> > Mike Gaddis) > > An RFC can only reference published (public) works. UNI 4.0 is not > going to be out for quite some time (on the IPmc scale). UNI 3.1 may > be a little too far out, but withing range of writing a spec cover UNI 3.0 > now and ramping to 3.1 as part of the proposed to draft transition. This > is what will be done with the signaling draft, for example. > > Mark (Laubach) > > While I will admit my ignorance of the internal machinations and rules of the IETF, I do not believe my recommendations are incompatible with your comment. It makes perfect sense to support IPmc on the early ATMF UNIs using the building blocks that exist in those protocols. My point is that the designers of the early mechanisms should be cognizant of the future extensions to the ATMF UNI protocol suite and their impact to how the IPmc-to-ATM "firewall" should be structured so as to avoid a difficult migration to UNI 4.0 and beyond. A migration beyond 3.1 *will* be necessary because the underlying 3.0/3.1 broadcast/multicasting mechanisms are fundamentally broken for use on any high performance network of sufficient size. Consider the cost of reserving a full mesh of point-to-multipoint connections with Peak Cell Rates (PCRs) and Sustained Cell Rates (SCRs) etc. reserved for each IP transmitter on the network. No correlation of these different flows is possible within the network (no language to specify correlation exists in the protocol) even though--as they approach the eventually receiver(s)--these flows are part of the same broadcast flow. If you do a detailed analysis of the Call Admission Control (CAC) algorithms being proposed in the ATMF for PNNI and that are be built on the mechanisms of the Traffic Management group, then it will become obvious (unless something dramatic changes) that CAC blocking will occur very quickly. Furthermore, the root initiated restriction, given the inevitable CAC blocking, will make any attempt at dynamic joins to the broadcast trees ineffective (latency and root signaling congestion). This is the point I believe that Susan was making when she recognized the lack of scalability that can be achieved with a meshed set of root initiated point-to-multipoint connections for multicast ATM. You can't "black-box" these limitations away, they are fundamental. Therefore, if one accepts the need for future migration to a more robust infrastructure it makes perfect sense for the IETF to champion new capabilities that are deemed desireable for future protocol releases. If the IETF, because of its internal rules, cannot do this type of pro-active lobbying, then participating companies that are also primary members of the ATMF should do so. The fundamental requirements are leaf-initiated joins and ATM group addresses. Ultimately, a mechanism for multipoint-to-multipoint VP SVCs at the UNI that support bandwidth correlation and leaf initiated joins with group address-global call identifiers would be useful (whew :}). All of the above mechanisms have, from one time or another, been voted in (and sometimes voted back out) in the ATMF. The actual details for setting up and maintaining these signaling mechanisms are well known and specified (see Rick Bubenik's ATMF contributions and our protocol specification for the Connection Management Access Protocol (CMAP)). Adding security mechanisms to the leaf join has not yet been fully flushed out in the ATMF contributions but a very complete model for leaf/root security exists in CMAP. The only real difficulty is in traffic management (TM) for ABR connections for multipoint-to-multipoint. I can say--authoritatively--that the TM difficulties can be solved. Summary: Yes, by all means, design IPmc for 3.0/3.1, we await your specification with anticipation. But let's also debate what we want the final mechanism to be and push the Forum in the agreed upon direction together. I have suggested a possible set of mechanisms and there are probably many others. Let's make sure the eventual migration is not a fork-lift operation. Mike Gaddis Director, Software Development Ascom Timeplex email: gaddis@timeplex.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04538; 12 Aug 94 11:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04534; 12 Aug 94 11:03 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08673; 12 Aug 94 11:03 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA213898227; Fri, 12 Aug 1994 06:30:27 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA213568225; Fri, 12 Aug 1994 06:30:25 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA05781; Fri, 12 Aug 1994 06:12:59 -0700 Received: from tigger.jvnc.net by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA20289; Fri, 12 Aug 1994 06:13:03 -0700 Received: from franklin-tty17.jvnc.net. (franklin-tty17.jvnc.net) by tigger.jvnc.net with SMTP id AA19536 (5.65c/IDA-1.4.4 for ip-atm@matmos.hpl.hp.com); Fri, 12 Aug 1994 09:08:55 -0400 Message-Id: Date: Fri, 12 Aug 94 09:07:32 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David M. Piscitello" Subject: Re: Real world multicasting Reply-To: dave@corecom.com To: Anthony Alles , ip-atm@matmos.hpl.hp.com Cc: gja@thumper.bellcore.com, Susan Symington , dino@cisco.com, percyk@glare.cisco.com X-Mailer: VersaTerm Link v1.1.1 Multiprotocol routing over NBMA nets is somewhat orthogonal to the issue of multicast support. NHRP does not need multicast (although the draft Dave and I are working on suggests uses of multicast). We'll route IP over ATM nicely without multicast support. Please don't interpret this to suggest I'm opposed to multicasting, but I have been listening to folks express fears about building dependencies on multicasting (group addressing) routing protocols for NBMA networks, esp. WAN NBMA nets, where usage sensitive billing may be applied. I'm not sure I agree with all the arguments, but I will concede that if we can do routing efficiently without multicasting we should explore the possibility. >connectivity. If 1577 and network layer solutions are to have any future >over ATM (and I think that they should), then we need a solution *today* >for multicast support that builds upon the signaling that exists *today* - >i.e UNI 3.0/3.1, not something that may exist sometime in the future. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11650; 12 Aug 94 18:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11646; 12 Aug 94 18:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19047; 12 Aug 94 18:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA283235346; Fri, 12 Aug 1994 14:02:26 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from noc.msc.edu by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA282905344; Fri, 12 Aug 1994 14:02:24 -0700 Received: from uh.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA14042; Fri, 12 Aug 94 16:02:18 -0500 Received: by uh.msc.edu (5.65/MSC/v3.1r(920220)) id AA08103; Fri, 12 Aug 94 16:02:17 -0500 Date: Fri, 12 Aug 94 16:02:17 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tim Salo Message-Id: <9408122102.AA08103@uh.msc.edu> To: dan@merlin.dev.cdx.mot.com Subject: Re: ATM INAP DSU clarification Cc: atm-nap@msc.edu, ip-atm@matmos.hpl.hp.com > To: laubach@netcom.com (Mark Laubach) > Cc: ip-atm@matmos.hpl.hp.com > Subject: Re: ATM INAP DSU clarification > Date: Thu, 11 Aug 94 13:31:45 -0400 > From: dan@merlin.dev.cdx.mot.com > [...] > > The ATM INAP folks have it as a goal to be able to get to > > an all LLC/SNAP and AAL5 world within the next year. > [...] > On the other side of the frame relay network is a box > marked 'IWU', connected by a DS-3 to an ATM network. ... > The legend identifies IWU as a "Layer > 2 InterWorking Unit". Clearly, the IWU is not a router. Therefore, > either a) the routers talking IP over ATM to all the other networks > really run RFC 1490 over FRSSCS over AAL5; or b) IWU somehow-or-other > converts RFC 1490 into RFC 1483 and vice-versa. I'd hate to be the > poor sucker who had to implement (b), so I've got to believe (a). To further complicate interoperability, during the ATM NAP Workshop a suggestion was made that a Layer 2 InterWorking Unit also be used to connect the PacBell SMDS [LLC/SNAP] network with the ATM-based NAP. I suppose this is more evidence, as if we needed any, of what a mess we have made of encapsulation[s], (or maybe why we like routers...). -tjs   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12061; 12 Aug 94 19:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12057; 12 Aug 94 19:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19993; 12 Aug 94 19:15 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA004959532; Fri, 12 Aug 1994 15:12:12 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA004569527; Fri, 12 Aug 1994 15:12:07 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA07382; Fri, 12 Aug 94 18:13:54 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA16372; Fri, 12 Aug 94 18:11:25 EDT Received: by marlin (4.1/SMI-4.1) id AA24067; Fri, 12 Aug 94 18:11:23 EDT Date: Fri, 12 Aug 94 18:11:23 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408122211.AA24067@marlin> To: dan@merlin.dev.cdx.mot.com, tjs@msc.edu Subject: Re: ATM INAP DSU clarification Cc: atm-nap@msc.edu, ip-atm@matmos.hpl.hp.com > To further complicate interoperability, during the ATM NAP Workshop a > suggestion was made that a Layer 2 InterWorking Unit also be used to > connect the PacBell SMDS [LLC/SNAP] network with the ATM-based NAP. > > I suppose this is more evidence, as if we needed any, of what a mess > we have made of encapsulation[s], (or maybe why we like routers...). > > -tjs I see it a different way (the glass is half full, not half empty). This is evidence of how flexible ATM is. It can "tunnel" just about any protocol at any layer: physical layer, data link layer, network layer, etc. There are necessarily different encapsulations for each of these. To specify a single encapsulation limits the usefulness and scope of ATM unnecessarily. Comlaining about multiple encapsulations is like complaining that if someone gives you money you might have to figure out where to invest it! I hate when that happens :-). Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com > From atmpost@matmos.hpl.hp.com Fri Aug 12 17:43:23 1994 > Sender: atmpost@matmos.hpl.hp.com > X-Info: Submissions to ip-atm@matmos.hpl.hp.com > X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com > X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm > X-Loop: ATM CLP.bit ON > Date: Fri, 12 Aug 94 16:02:17 -0500 > From: tjs@msc.edu (Tim Salo) > To: dan@merlin.dev.cdx.mot.com > Subject: Re: ATM INAP DSU clarification > Cc: atm-nap@msc.edu, ip-atm@matmos.hpl.hp.com > > > To: laubach@netcom.com (Mark Laubach) > > Cc: ip-atm@matmos.hpl.hp.com > > Subject: Re: ATM INAP DSU clarification > > Date: Thu, 11 Aug 94 13:31:45 -0400 > > From: dan@merlin.dev.cdx.mot.com > > [...] > > > The ATM INAP folks have it as a goal to be able to get to > > > an all LLC/SNAP and AAL5 world within the next year. > > [...] > > On the other side of the frame relay network is a box > > marked 'IWU', connected by a DS-3 to an ATM network. ... > > The legend identifies IWU as a "Layer > > 2 InterWorking Unit". Clearly, the IWU is not a router. Therefore, > > either a) the routers talking IP over ATM to all the other networks > > really run RFC 1490 over FRSSCS over AAL5; or b) IWU somehow-or-other > > converts RFC 1490 into RFC 1483 and vice-versa. I'd hate to be the > > poor sucker who had to implement (b), so I've got to believe (a). >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12588; 12 Aug 94 20:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12584; 12 Aug 94 20:02 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20651; 12 Aug 94 20:02 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA024422852; Fri, 12 Aug 1994 16:07:32 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA024012831; Fri, 12 Aug 1994 16:07:11 -0700 Date: Fri, 12 Aug 1994 16:07:11 -0700 Message-Id: <199408122307.AA024012831@matmos.hpl.hp.com> To: Drew Perkins Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: ATM INAP DSU clarification Cc: atm-nap@msc.edu, ip-atm@matmos.hpl.hp.com, dan@merlin.dev.cdx.mot.com, tjs@msc.edu > .... Comlaining >about multiple encapsulations is like complaining that if someone gives you >money you might have to figure out where to invest it! Drew, I think I'll only agree with this when ATM has been around long enough to develop enough maturity equal to that of our banking and investment institutions....:-) Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05403; 13 Aug 94 18:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05399; 13 Aug 94 18:21 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12177; 13 Aug 94 18:21 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA180041707; Sat, 13 Aug 1994 14:01:47 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA179711700; Sat, 13 Aug 1994 14:01:40 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA08511; Sat, 13 Aug 94 17:03:48 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA10869; Sat, 13 Aug 94 17:01:21 EDT Received: by marlin (4.1/SMI-4.1) id AA26837; Sat, 13 Aug 94 17:01:20 EDT Date: Sat, 13 Aug 94 17:01:20 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408132101.AA26837@marlin> To: dino@cisco.com, percyk@cisco.com Subject: Re: [ebcbghp@ebc.ericsson.se: Re: Multicasting over ATM draft] Cc: ip-atm@matmos.hpl.hp.com I suggest that the spec should say that up to two ATM addresses can be configured. The first number configured is the primary server. The second is the backup server. Once Anycast addresses become available, the spec will be enhanced to specify a well-known address, and any existing implementations may be configured with the well-known anycast address as its primary address. Further, the spec will be configured to use this well-known anycast address as the primary or secondary address if overrides are not configured. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com > From atmpost@matmos.hpl.hp.com Wed Aug 10 13:53:51 1994 > Sender: atmpost@matmos.hpl.hp.com > X-Info: Submissions to ip-atm@matmos.hpl.hp.com > X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com > X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm > X-Loop: ATM CLP.bit ON > Date: Wed, 10 Aug 1994 10:15:18 -0700 > From: Percy Khabardar > To: dino@cisco.com > Cc: ip-atm@matmos.hpl.hp.com > Subject: [ebcbghp@ebc.ericsson.se: Re: Multicasting over ATM draft] > > > >> The requirement for configuring two ATM addresses seem to be an > >> overkill. Many networks support logical numbers, such that only one > >> party will recive calls to a given number as long as that pary is > >> operational (similar to 800 numbers but only one server at a time). > >> If the network do not support exclusivity a separate procedure > >> between the servers could sovlve any such problems. > > Bengt, we are aware of ATM logical addresses. However, we were > not sure (at least I was not) how widely how available it is so we decided > to provide a little configuration. > > Maybe switch vendors on this list can comment about this. > > > I think you are referring to anycasting here. Anycasting is not a part of > UNI3.0 or 3.1 (it's in UNI4.0) and hence we did not want to use that feature > in the design. > > - Percy > > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05474; 13 Aug 94 18:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05470; 13 Aug 94 18:32 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12310; 13 Aug 94 18:32 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA194232418; Sat, 13 Aug 1994 14:13:38 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA193902406; Sat, 13 Aug 1994 14:13:26 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA08519; Sat, 13 Aug 94 17:14:47 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA11255; Sat, 13 Aug 94 17:12:19 EDT Received: by marlin (4.1/SMI-4.1) id AA26874; Sat, 13 Aug 94 17:12:18 EDT Date: Sat, 13 Aug 94 17:12:18 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408132112.AA26874@marlin> To: ebcbghp@ebc.ericsson.se, percyk@cisco.com Subject: Re: Multicasting over ATM draft Cc: dino@cisco.com, ip-atm@matmos.hpl.hp.com A race condition exists which must be solved in the protocol somehow. Let's say two hosts, A and B, connect simultaneously. These requests will somehow be serialized by the time the server receives them (eg. in an ATM switch, in the OS, etc.). Let's say A is received first and processed to completion. I.e. the server will inform A of all preceding group members. But the group is large and A is far away so that it takes a while for the response to propagate to A. Now, the server receives and processes B's request. B is much closer with faster connectivity. B receives the address of A (A was processed first) and immediately establishes a connection to A, before A has received the response. The only indication that A will ever receive of B's membership is this connection request, so A had better be prepared to receive incoming connection requests for a group, after it has launched the request, but before it receives the response about group members. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com > From atmpost@matmos.hpl.hp.com Wed Aug 10 14:31:08 1994 > Sender: atmpost@matmos.hpl.hp.com > X-Info: Submissions to ip-atm@matmos.hpl.hp.com > X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com > X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm > X-Loop: ATM CLP.bit ON > Date: Wed, 10 Aug 1994 10:55:42 -0700 > From: Percy Khabardar > To: ebcbghp@ebc.ericsson.se > Cc: dino@cisco.com, ip-atm@matmos.hpl.hp.com > Subject: Multicasting over ATM draft > > > Bengt, > > > The only problem I have identified so far is some potential racing in the > > call setups (two new members attach to the network "simultainusly") but > > that should be solvable with a timer or procedureal rules. > > I think this could be solved by requiring the well known server to process > each "Join" request serially and completely before processing the next one. > > - Percy >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05502; 13 Aug 94 18:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05497; 13 Aug 94 18:37 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12395; 13 Aug 94 18:37 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA207702963; Sat, 13 Aug 1994 14:22:43 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from glare.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA207372961; Sat, 13 Aug 1994 14:22:41 -0700 Received: (percyk@localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id OAA10867; Sat, 13 Aug 1994 14:22:36 -0700 Date: Sat, 13 Aug 1994 14:22:36 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Percy Khabardar Message-Id: <199408132122.OAA10867@glare.cisco.com> To: ddp@fore.com Cc: ebcbghp@ebc.ericsson.se, dino@cisco.com, ip-atm@matmos.hpl.hp.com In-Reply-To: Drew Perkins's message of Sat, 13 Aug 94 17:12:18 EDT <9408132112.AA26874@marlin> Subject: Multicasting over ATM draft Drew, thanks for the comments. You're right about this (I thought of this condition of distance being a factor after I replied to the mail). - Percy A race condition exists which must be solved in the protocol somehow. Let's say two hosts, A and B, connect simultaneously. These requests will somehow be serialized by the time the server receives them (eg. in an ATM switch, in the OS, etc.). Let's say A is received first and processed to completion. I.e. the server will inform A of all preceding group members. But the group is large and A is far away so that it takes a while for the response to propagate to A. Now, the server receives and processes B's request. B is much closer with faster connectivity. B receives the address of A (A was processed first) and immediately establishes a connection to A, before A has received the response. The only indication that A will ever receive of B's membership is this connection request, so A had better be prepared to receive incoming connection requests for a group, after it has launched the request, but before it receives the response about group members.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06129; 13 Aug 94 19:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06125; 13 Aug 94 19:35 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13154; 13 Aug 94 19:35 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA226315529; Sat, 13 Aug 1994 15:05:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA225985525; Sat, 13 Aug 1994 15:05:25 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA08575; Sat, 13 Aug 94 18:07:30 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA12926; Sat, 13 Aug 94 18:05:02 EDT Received: by marlin (4.1/SMI-4.1) id AA26936; Sat, 13 Aug 94 18:05:01 EDT Date: Sat, 13 Aug 94 18:05:01 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408132205.AA26936@marlin> To: jmoy@alpo.casc.com, dino@cisco.com Subject: Re: Multicasting over ATM draft Cc: ip-atm@matmos.hpl.hp.com, percyk@cisco.com I'm afraid that separation of sender and receiver is NOT an easy modification of this proposal. In fact, if you want this separation, you have to completely throw out this proposal and start from scratch. What you have to do is allow senders to connect to the server and inform the server of their sender-only status. Receivers would also connect to the server to join the group. The server will then have to inform every sender with a reliable protocol (TCP or SSCOP perhaps) every time a new receiver joins, because the receiver will not be connecting to the senders. Alternatively, this proposal could be slightly less modified by allowing two types of hosts: sender-only and receiver/sender. A sender would connect to the server as in this proposal but would additionaly transfer its sender-only status to the server when it joins and gets the list of current receiver/senders. A receiver/sender would operate as in this proposal by retrieving the entire list and would then connect to all of the senders just to let them know they are there (as in this proposal). The receiver/sender would then drop the sender from the connection since it doesn't want to receive multicast data. Now we start having to deal with much more difficult proplems with maintaining state robustly in the face of communications failures. Another fact should be taken into consideration. IGMP currently requires all receivers to be senders as well in order to implement the group join operation. There has been talk of fixing this aspect of IGMP, but if that happens it is sometime off. Because of these two problems, I propose that Classical IP Multicast retain the equivalence of senders and receivers. This protocol also needs a reliable protocol for transferring information between server and group member/sender. We probably need to use TCP in order to get reasonable performance. As a default, the group address server should be the same as the Classical IP ATM ARP server. The discussion of backup nodes only informing "routers" of new incoming routers is more complicated than necessary and probably is completely unnecessary. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com > From atmpost@matmos.hpl.hp.com Wed Aug 10 13:39:09 1994 > Sender: atmpost@matmos.hpl.hp.com > X-Info: Submissions to ip-atm@matmos.hpl.hp.com > X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com > X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm > X-Loop: ATM CLP.bit ON > Date: Wed, 10 Aug 1994 10:04:18 -0700 > From: Dino Farinacci > To: jmoy@alpo.casc.com > Cc: ip-atm@matmos.hpl.hp.com, percyk@cisco.com > Subject: Multicasting over ATM draft > > >> A couple of quick comments about your draft. First, in the IP > >> multicast model a sender to a group does not have to be a member > >> of the group itself. Your proposal does not seem to support this, > >> although it could definitely be changed to do so. Second, if you > >> are going to use an ATM cloud as part of the MBONE, you really > >> want the IP multicast routers at the edge to listen promiscuously > >> to all groups. Again, your proposal does not address this, > >> although it could. > > John, as you state sender-only systems is easy to implement. Just need to > find out group membership and not required to join. > > Our intent here is to make a logical multicast mesh so routing protocols > and IP multicast can treat ATM as they would an Ethernet. Initially, we > envision all IP multicast packets are sent to a previously setup ATM > group (much the same way IP multicast is sent on Token Ring but it will > not involve every system on the ATM network). So, all routers do get > all multicasts. > > One item I should point out. This proposal is for general multicast on > ATM. It is not designed specifically for IP multicast but other forms > of single-hop multicast. In a second phase, we look at other methods > that make for scalable IP multicast over ATM. > > >> I also think that it would be clearer if you just replace "router" > >> with "group member" (or something) in the whole draft. There > >> really isn't anything specific to routers in the draft, and that's > >> just confusing the issue (in my opinion). > > We will make this change. Thanks for comments. > > Dino >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14084; 15 Aug 94 3:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14080; 15 Aug 94 3:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18100; 15 Aug 94 3:15 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA118910401; Sun, 14 Aug 1994 23:00:01 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from feta.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA118530399; Sun, 14 Aug 1994 22:59:59 -0700 Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA05397; Sun, 14 Aug 1994 22:59:52 -0700 Date: Sun, 14 Aug 1994 22:59:52 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dino Farinacci Message-Id: <199408150559.WAA05397@feta.cisco.com> To: ddp@fore.com Cc: ebcbghp@ebc.ericsson.se, percyk@cisco.com, ip-atm@matmos.hpl.hp.com In-Reply-To: Drew Perkins's message of Sat, 13 Aug 94 17:12:18 EDT <9408132112.AA26874@marlin> Subject: Multicasting over ATM draft >> Now, the server receives and processes B's request. B is much >> closer with faster connectivity. B receives the address of A (A was processed >> first) and immediately establishes a connection to A, before A has received >> the response. The only indication that A will ever receive of B's membership >> is this connection request, so A had better be prepared to receive incoming >> connection requests for a group, after it has launched the request, but before it >> receives the response about group members. Yes, A's willingness to be a member begins right after it sends the request, regardless if the the request was received by the server or the response was slow or lost. Dino   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00506; 15 Aug 94 4:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00502; 15 Aug 94 4:46 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa01534; 15 Aug 94 4:46 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA142316646; Mon, 15 Aug 1994 00:44:06 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hubbub.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA141986644; Mon, 15 Aug 1994 00:44:04 -0700 Received: from [198.92.30.75] (macip-dialup-29.cisco.com [198.92.30.75]) by hubbub.cisco.com (8.6.8+c/CISCO.GATE.1.1) with SMTP id AAA12855; Mon, 15 Aug 1994 00:43:52 -0700 Message-Id: <199408150743.AAA12855@hubbub.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Aug 1994 00:43:55 -0800 To: dave@corecom.com, ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anthony Alles Subject: Re: Real world multicasting Cc: gja@thumper.bellcore.com, Susan Symington , dino@cisco.com, percyk@glare.cisco.com Dave, I'm not sure that I really understand why cross LIS support for mutlicast, without having to go through intermediate routers, would not be a concern for NBMA networks. On ATM networks in particular (sorry, I don't get too excited about X.25) multicast will be an increasingly popular service since many of the newer applications for which people will deploy ATM will rely on pt-to-mpt or multicast connections. Surely this is a problem that ROLC should focus on, particularly since it will be (very) hard? This is not to say that we should lose focus on the current NHRP work, but that's also a long way from saying that multicast support is not important. Anthony At 9:07 AM 8/12/1994 -0400, David M. Piscitello wrote: >Multiprotocol routing over NBMA nets is somewhat orthogonal to the issue of >multicast support. NHRP does not need multicast (although the draft >Dave and I are working on suggests uses of multicast). We'll route IP >over ATM nicely without multicast support. > >Please don't interpret this to suggest I'm opposed to multicasting, >but I have been listening to folks express fears about building >dependencies on multicasting (group addressing) routing protocols >for NBMA networks, esp. WAN NBMA nets, where usage sensitive billing >may be applied. I'm not sure I agree with all the arguments, but I >will concede that if we can do routing efficiently without multicasting >we should explore the possibility. > >>connectivity. If 1577 and network layer solutions are to have any future >>over ATM (and I think that they should), then we need a solution *today* >>for multicast support that builds upon the signaling that exists *today* - >>i.e UNI 3.0/3.1, not something that may exist sometime in the future. >David M. Piscitello >Core Competence, Inc. >1620 Tuckerstown Road >Dresher, PA 19025 USA >dave@corecom.com >1.215.830.0692 _____________________________________________________________________ Anthony Alles Cisco Systems Product Manager: ATM Tel: 408-526-5424 email: aalles@cisco.com Fax: 408-526-7666 Mail: 170 West Tasman Drive, San Jose CA 95134-1706, USA. Cisco Location: Building D, San Jose Single Site.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09610; 15 Aug 94 14:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09606; 15 Aug 94 14:59 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13780; 15 Aug 94 14:59 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA210791906; Mon, 15 Aug 1994 10:31:46 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA210461903; Mon, 15 Aug 1994 10:31:43 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00194 for ip-atm@matmos.hpl.hp.com; Mon, 15 Aug 94 13:30:50 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA01929; Mon, 15 Aug 1994 10:30:07 -0700 Message-Id: <199408151730.KAA01929@aland.bbn.com> To: Drew Perkins Cc: dan@merlin.dev.cdx.mot.com, tjs@msc.edu, atm-nap@msc.edu, ip-atm@matmos.hpl.hp.com Subject: Re: ATM INAP DSU clarification In-Reply-To: Your message of Fri, 12 Aug 94 18:11:23 -0400. <9408122211.AA24067@marlin> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Mon, 15 Aug 94 10:30:05 -0700 Complaining about multiple encapsulations is like complaining that if someone gives you money you might have to figure out where to invest it! I hate when that happens :-). Drew: Tell that to the DQDB folks, who are widely considered to have a near dead spec because it chose the wrong encaps format (AAL 3/4 vs. AAL 5). Unnecessary multiple encapsulations are an invitation to market segmentation, diminished connectivity, and the downfall of civilization :-). Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09645; 15 Aug 94 15:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09641; 15 Aug 94 15:01 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13829; 15 Aug 94 15:01 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA240183110; Mon, 15 Aug 1994 10:51:50 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA239853106; Mon, 15 Aug 1994 10:51:46 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA05097 for ip-atm@matmos.hpl.hp.com; Mon, 15 Aug 94 13:51:19 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id KAA02038; Mon, 15 Aug 1994 10:50:37 -0700 Message-Id: <199408151750.KAA02038@aland.bbn.com> To: Drew Perkins Cc: craig@aland.bbn.com, dan@merlin.dev.cdx.mot.com, tjs@msc.edu, atm-nap@msc.edu, ip-atm@matmos.hpl.hp.com Subject: Re: ATM INAP DSU clarification In-Reply-To: Your message of Mon, 15 Aug 94 13:43:56 -0400. <9408151743.AA07869@marlin> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Mon, 15 Aug 94 10:50:35 -0700 They chose to have a SINGLE encapsulation, not MULTIPLE encapsulations. Unfortunately, they were ahead of the crowd and the crowd decided that they were Leming Leaders :-). Ah yes, but inevitably people have to choose from the menu if presented with a menu. So don't give 'em a menu. Fixed meals -- choose one format for everything. Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09803; 15 Aug 94 15:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09799; 15 Aug 94 15:11 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14014; 15 Aug 94 15:11 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA225642685; Mon, 15 Aug 1994 10:44:45 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA225312678; Mon, 15 Aug 1994 10:44:38 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA01994; Mon, 15 Aug 94 13:44:00 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA05325; Mon, 15 Aug 94 13:43:57 EDT Received: by marlin (4.1/SMI-4.1) id AA07869; Mon, 15 Aug 94 13:43:56 EDT Date: Mon, 15 Aug 94 13:43:56 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408151743.AA07869@marlin> To: craig@aland.bbn.com Subject: Re: ATM INAP DSU clarification Cc: dan@merlin.dev.cdx.mot.com, tjs@msc.edu, atm-nap@msc.edu, ip-atm@matmos.hpl.hp.com > Complaining > about multiple encapsulations is like complaining that if someone gives you > money you might have to figure out where to invest it! > I hate when that happens :-). > > Drew: > > Tell that to the DQDB folks, who are widely considered to have a near dead > spec because it chose the wrong encaps format (AAL 3/4 vs. AAL 5). They chose to have a SINGLE encapsulation, not MULTIPLE encapsulations. Unfortunately, they were ahead of the crowd and the crowd decided that they were Leming Leaders :-). > Unnecessary multiple encapsulations are an invitation to market > segmentation, diminished connectivity, and the downfall of civilization :-). You forgot an earth-shattering collision with a comet fragment :-). Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10043; 15 Aug 94 15:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10039; 15 Aug 94 15:22 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14258; 15 Aug 94 15:22 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA255624467; Mon, 15 Aug 1994 11:14:27 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from glare.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA255294465; Mon, 15 Aug 1994 11:14:25 -0700 Received: (percyk@localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA15370; Mon, 15 Aug 1994 11:14:16 -0700 Date: Mon, 15 Aug 1994 11:14:16 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Percy Khabardar Message-Id: <199408151814.LAA15370@glare.cisco.com> To: ddp@fore.com Cc: jmoy@alpo.casc.com, dino@cisco.com, ip-atm@matmos.hpl.hp.com In-Reply-To: Drew Perkins's message of Sat, 13 Aug 94 18:05:01 EDT <9408132205.AA26936@marlin> Subject: Multicasting over ATM draft > This protocol also needs a reliable protocol for transferring information > between server and group member/sender. We probably need to use TCP in order > to get reasonable performance. To keep thing simple I was thinking of using a simple request response protocol between the server and the group member/sender. A sender would issue a "join" request with a unique correlation id to the server. The server's response would contain the same correlation id. If no response is received the sender (after timing out) would issue another req with another correlation id. The timer would be sufficiently large that no response would indicate a loss message. > The discussion of backup nodes only informing "routers" of new incoming routers > is more complicated than necessary and probably is completely unnecessary. This was more of an optimization to reduce network traffic - once the hosts have received group member addresses they don't have further use of the server. So there was no point in again receiving group member addresses for already joined hosts from the backup server. (Only new incoming hosts require the services of the server). - Percy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12110; 15 Aug 94 17:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12105; 15 Aug 94 17:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17036; 15 Aug 94 17:18 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA276759912; Mon, 15 Aug 1994 12:45:12 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from wawa.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA276429908; Mon, 15 Aug 1994 12:45:08 -0700 Received: by wawa.ans.net (AIX 3.2/UCB 5.64/4.03) id AA17896; Mon, 15 Aug 1994 19:42:56 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <9408151942.AA17896@wawa.ans.net> To: Fong-Ching Liaw Cc: gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, curtis@wawa.ans.net Subject: Re: multicast In-Reply-To: (Your message of Tue, 09 Aug 94 11:55:29 EDT.) <9408091555.AA01059@pothole.fore.com> Date: Mon, 15 Aug 94 19:42:56 +0000 Since we're talking pragmatic and interim... > Another point about server approach: if we were to use a server > approach to implement IPmc, the server has to know every receivers, > and every host needs to register with server. This does not scale to > high bandwidth and large number of receivers. Extra hop from sender > to server introduces extra delay as well, it is harder to guarantee > Qos (not impossible). LANE does not have any delay requirement, so > they don't care if the packets are delayed by other traffic at server. > Assuming we let sender adds all receivers, and use ATMARP to find all > the receivers, it does not scale as IPmc. this server looks an awful lot like an mrouter with pruning and a lot of unicast tunnels. Of course you could have a hierarchy of mrouters, but this is even uglier than the present situation for ATM LANs since at least the LAN can currently support native multicast where the ATM LIS could not. For use of ATM in IP WAN connectivity the current level of ugliness is neither worsenned or improved. Maybe we need to concentrate on what this server does that mrouted does not already do when encapsulating over unicast tunnels. The obvious first problem that comes to mind is the amount of configuration associated with mrouted tunnels. Any others problems besides dynamically discovering tunnels on the LIS? Perhaps mrouted could just coreside with the ATM ARP server and be set up to set up vifs and try to establish unicast tunnels to all of the ARP entries? This would scale as long as RFC-1577 was used, LIS were kept to reasonable sizes and IP forwarding used to connect LIS. I did say maybe and perhaps... Am I overlooking something major that makes using a modified mrouted (or compatible tunneling) a very poor interim solution? (Other than mrouted doesn't do PIM or CBT). Given the constraint for the interim solution of using UNI 3.0, which only supports unicast (ptp) VC. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15718; 15 Aug 94 21:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15713; 15 Aug 94 21:16 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22097; 15 Aug 94 21:16 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA029775603; Mon, 15 Aug 1994 17:06:43 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA029445594; Mon, 15 Aug 1994 17:06:34 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA03585; Mon, 15 Aug 94 20:06:08 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA06478; Mon, 15 Aug 94 20:06:05 EDT Received: by marlin (4.1/SMI-4.1) id AA13115; Mon, 15 Aug 94 20:06:01 EDT Date: Mon, 15 Aug 94 20:06:01 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408160006.AA13115@marlin> To: fong@fore.com, curtis@wawa.ans.net Subject: Re: multicast Cc: gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com > I did say maybe and perhaps... Am I overlooking something major that > makes using a modified mrouted (or compatible tunneling) a very poor > interim solution? (Other than mrouted doesn't do PIM or CBT). Given > the constraint for the interim solution of using UNI 3.0, which only > supports unicast (ptp) VC. Curtis, I think you may be mis-informed. UNI 3.0 does support point-to-multipoint VCCs. But you are right, if you use a server, it does sound a lot like tunnels. Fong noticed that my much more complicated solution for sender/receiver separation begins to look a lot like PIM. Funny how we keep reinventing the wheel :-). Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15831; 15 Aug 94 21:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15827; 15 Aug 94 21:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22222; 15 Aug 94 21:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA016015288; Mon, 15 Aug 1994 17:01:28 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA015685284; Mon, 15 Aug 1994 17:01:24 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA03569; Mon, 15 Aug 94 20:01:04 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA06131; Mon, 15 Aug 94 20:01:00 EDT Received: by marlin (4.1/SMI-4.1) id AA13091; Mon, 15 Aug 94 20:01:00 EDT Date: Mon, 15 Aug 94 20:01:00 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408160001.AA13091@marlin> To: percyk@cisco.com Subject: Re: Multicasting over ATM draft Cc: jmoy@alpo.casc.com, dino@cisco.com, ip-atm@matmos.hpl.hp.com > > This protocol also needs a reliable protocol for transferring information > > between server and group member/sender. We probably need to use TCP in order > > to get reasonable performance. > > To keep thing simple I was thinking of using a simple request response protocol > between the server and the group member/sender. A sender would issue a "join" > request with a unique correlation id to the server. The server's response would > contain the same correlation id. If no response is received the sender (after > timing out) would issue another req with another correlation id. The timer > would be sufficiently large that no response would indicate a loss message. I'm not worried about the request from client to server, I'm worried about the response from server to client. If there are 10,000 group members, you could have quite a large response. This would undoubtedly be multi-packet. What if one packet got lost? Retransmit only that one packet or the entire request? This starts to become a complex protocol. You may as well use a protocol designed to do this (TCP or SSCOP). > > The discussion of backup nodes only informing "routers" of new incoming routers > > is more complicated than necessary and probably is completely unnecessary. > > This was more of an optimization to reduce network traffic - once the hosts have > received group member addresses they don't have further use of the server. So there > was no point in again receiving group member addresses for already joined hosts > from the backup server. (Only new incoming hosts require the services of the > server). If you expand on the procedures for doing this, I think you will quickly find that it is not worth it... Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17415; 15 Aug 94 22:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17411; 15 Aug 94 22:43 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa23260; 15 Aug 94 22:43 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA043546324; Mon, 15 Aug 1994 17:18:44 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA043216317; Mon, 15 Aug 1994 17:18:37 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id UAA28580; Mon, 15 Aug 1994 20:18:33 -0400 Message-Id: <199408160018.UAA28580@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: ip-atm@matmos.hpl.hp.com Cc: gja@thumper.bellcore.com Subject: YAAM draft (Yet Another ATM Multicast draft :-) Date: Mon, 15 Aug 94 20:18:31 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com I'd like to offer up this draft to the IP over ATM WG for consideration. It is a first start at sketching in my minds eye how we might modify the current rfc1112 IPmc model and mangle it to work with the rfc1577 LIS model. (That is, it has a very specific, limited scope). It is much more implementation specific than the draft released by Percy Khabardar & Dino Farinacci last week, and does take a different approach to the manner in which group membership information is distributed. It has not been released as a 'real' I-D, I'll do that for version 01 in light of feed-back here. This should have been out late last week, but life is like that. Its messy, has pieces missing, and will probably annoy someone....I'll blame it on jet-lag, or excess caffeine, or something. gja (who, of course, claims all responsibility, and announces to all and sundry that this document represents my own views alone and not those of my employer) --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635 Internet-Draft Grenville Armitage (Bellcore) August 15th, 1994 IP Multicast over UNI 3.0 based ATM Networks. Status of this Memo This document was submitted to the IETF IP over ATM WG. Publication of this document does not imply acceptance by the IP over ATM WG of any ideas expressed within. Comments should be submitted to the ip-atm@matmos.hpl.hp.com mailing list. Distribution of this memo is unlimited. This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This memo describes extensions to RFC1577 (Classical IP over ATM [1]) and RFC1112 (Host Extensions for IP Multicasting [2]) to allow present generation IP multicasting on ATM networks that support Version 3.0 of the ATM Forum's UNI signalling specification. As of version 00 this memo is incomplete. 1. Overview RFC 1112 introduces the concept of IP multicasting and defines the required behaviour of hosts desiring to send to, or receive from, IP multicast groups. The example link layer technology given in that RFC is Ethernet, a technology that directly supports multicasting. ATM is a new link layer technology being utilised to support IP subnets. RFC 1483 [3] defines a mechanism for encapsulating and transmitting IP packets using AAL5 over ATM Virtual Channels (VCs). RFC 1577 defines the basic 'Classical' model of IP subnets mapped to restricted groups of ATM-connected nodes - the Logical IP Subnet (LIS). The currently published signalling specification from the ATM Forum is Version 3.0 [4] (UNI 3.0). In addition to the Bidirectional Unicast VCs used to provide the basic Classical model, UNI 3.0 also provides support for Unidirectional, Point to Multipoint VCs. This memo will describe how IP multicasting within a LIS may be achieved using meshes of UNI 3.0 point to multipoint VCs. It will also describe how IP multicast routers may extend IP multicast beyond the LIS. The ARP Server's role in the LIS is extended to keep track of IP multicast groups that are active within the LIS. The operation of the Internet Group Management Protocol (IGMP) is modified, and a new IGMP message type is proposed, to support the distributed of IP group membership information. This memo assumes an understanding of concepts explained in greater detail in RFC 1112, RFC 1577, UNI 3.0, and . 2. Review of RFC 1112 and IP Multicast over Ethernet. In RFC 1112 the behaviour of the transmit and receive sides are quite independent. This makes the concept of being a 'member' of an IP multicast group imprecise at the link layer interface. The interface must support the transmission of IP packets to IP an multicast group addresses whether or not the node considers itself a 'member' of that group. Consequently, group membership is effectively irrelevant to the transmit side of the link layer interfaces. No address resolution is required to transmit packets - an algorithmic mapping from IP multicast address to Ethernet multicast address is performed locally before the packet is sent out the local interface in the same 'send and forget' manner as a unicast IP packet. Joining and Leaving an IP multicast group is more explicit on the receive side - with the primitives JoinLocalGroup and LeaveLocalGroup affecting what groups the local link layer interface should accept packets from. When the IP layer wants to receive packets from a group, it issues JoinLocalGroup. When it no longer wants to receive packets, it issues LeaveLocalGroup. The role of IGMP in RFC 1112 is to support IP multicast routers attached to a given subnet. Hosts issue IGMP Report messages when they perform a JoinLocalGroup, or in response to an IP multicast router sending an IGMP Query. The sole function is to allow routers to identify what IP multicast groups have non-zero membership on the subnet. A specific IP multicast address, 224.0.0.1, is allocated for the transmission of IGMP Query messages. All IP multicast hosts must issue JoinLocalGroup for 224.0.0.1 during their initialisation. Each host keeps a list of IP multicast groups it has been JoinLocalGroup'd to. When a router issues an IGMP Query on 224.0.0.1 each host begins to send IGMP Reports for each group it is a member of. IGMP Reports are sent to the group address, not 224.0.0.1, "so that other members of the same group on the same network can overhear the Report" and not bother sending one of their own. Under RFC 1112 multicast IP routers are expected to passively receive packets on all groups. IP multicast routers conclude that a group no longer has members on the subnet when IGMP Queries no longer elict replies for a group. 3. Model of an IP over ATM endpoint. LLC/SNAP encapsulated IP packets are the default specified by RFC 1577. This model implies that IP over ATM endpoints should be viewed as having LLC entities terminating VCs on behalf of higher layer protocols (e.g. IP or ARP). The LLC entity multiplexes out going packets according to RFC 1483, and demultiplexes incoming packets. It is a client of the endpoint's AAL and UNI 3.0 signalling services. Only VCs directed at ISO 8802/2 layer 2 endpoints are terminated on the LLC entity. ipatm0 / | \ --------- | --------- | | | .............................. . This draft's functionality . .............................. | | | IP.1 IP.2 IP.3 | | | +++++.......+++++........+++++ ---- LLC +L.1+ +L.2+ +L.3+ ====>| U | +++++.......+++++........+++++ | N | AAL to AAL-User | | | | I | interface VC.1 VC.2 VC.3 | | | | | | 3 | +++++.......+++++........+++++ | . | AAL +A5 + +A5 + +A5 + <====| 0 | +++++.......+++++........+++++ ---- | | | --------- | --------- \ | / atm Figure 1. A single IP interface may have multiple VCs open to different destinations. Each VC is mapped through separate instances of the LLC layer and AAL5 service. Figure 1 attempts to show this relationship, where IP.{1,2,3} are the IP addresses of destinations that the local interface is connected to through VC.{1,2,3}. In a unicast-only LIS these IP addresses map to a single endpoint, and the VCs allow bidirectional flow of IP packets. The goal of this memo is to add multicast support to the model shown in Figure 1 that closely resembles the spirit of RFC 1112. To complicate the discussion slightly, reference will be made to 'transmit' and 'receive' sides - these refer to sections of the LLC and IP interface that handle outgoing and incoming packets respectively. 4. Multicast VCs under UNI 3.0. This memo will describe its operation in terms of 'generic' functions that should be available to clients of a UNI 3.0 signalling entity in a given ATM endpoint. The most fundamental limitations of UNI 3.0's multicast support are: - only point to multipoint, unidirectional VCs may be established, and - only the root node of a given VC may add or remove leaf nodes. Within these constraints, multicast groups can be created by the use of full meshes, or a Multicast Server. With a mesh each transmitting host is the Root of a multicast tree that has every other host in the group as a Leaf. The Multicast Server model has every group member establish point to point VC to the Server. The server then receives packets from members and retransmits copies to all other members. This memo specifies the use of a point to multipoint mesh, because it removes the need to build a node dedicated to the role of the Multicast Server. The following generic signalling functions are presumed to be available to AAL Users: [mneumonics subject to change, they're "off the top of my head"] L_CALL_RQ - Establish a unicast VC to a specific endpoint. L_MULTI_RQ - Establish multicast VC to a specific endpoint. L_MULTI_ADD - Add new leaf node to previously established VC. L_MULTI_DROP - Remove specific leaf node from established VC. L_RELEASE - Release unicast VC, or all Leaves of a multicast VC. The UNI 3.0 signalling exchanges that occur as a consequence of these functions are described in Appendix A. The local information passed between AAL User and UNI 3.0 signalling entity with these functions is currently beyond the scope of this memo. The following indications are assumed to be available to AAL Users, generated by by the local UNI 3.0 signalling entity: L_REMOTE_CALL - A new VC has been established to the AAL User. ERR_L_RQFAILED - A remote ATM endpoint rejected an L_CALL_RQ, L_MULTI_RQ, or L_MULTI_ADD. ERR_L_RELEASE - A remote ATM endpoint has elected to terminate a pre-existing VC. The UNI 3.0 signalling exchanges that occur to cause these indications are described in Appendix A. The local information passed between UNI 3.0 signalling entity and AAL User by these indications is currently beyond the scope of this memo. For the rest of this memo the term 'ATM Address' will be used to mean either a single 'ATM Number' or an 'ATM Number' associated with an 'ATM Subaddress'. 5. Transmitting IP packets to Multicast groups. The IP layer must be able to send a packet to an IP multicast group at any time, without prior warning. This implies a mechanism for keeping track of group membership, because unlike Ethernet multicast the source must 'know' its destinations before transmissions. The RFC 1577 ARP Server is an ideal candidate for extension to provide this mechanism. It keeps a table of {IP,ATM} address pairs for all hosts in the LIS (including any routers to the wider world). It can either be configured with certain table entries, or 'learn' entries from the ARPing activity of hosts on the LIS. The extension for multicast is as follows: - Table entries for Class D IP addresses should be able to hold 1 or more ATM addresses, i.e. {IP, ATM.1, ATM.2, .... ATM.n} - A new ARP message type is added: ARP_MULTI, having exactly the same format as an ARP_REPLY. - Group address 224.0.0.1 is permanently configured as a special case with at least one member, the ARP Server itself. When a host is required to transmit a packet to a Class D address it issues an ARP_REQUEST to the ARP Server in exactly the same manner as for a unicast packet. If a match is found in the ARP Server's tables it returns addresses ATM.1 through ATM.(n-1) in a sequence of ARP_MULTIs. Address ATM.n is then sent in a normal ARP_REPLY, and the ATMARP process is considered complete. An L_MULTI_RQ is then issued for ATM.n, followed by an L_MULTI_ADD for every member of the set {ATM.1, ....ATM.(n-1)} (assuming the set is non-null). The packet is then transmitted over the newly created VC just as it would be for a unicast unicast VC. If the ARP Server had no mapping for the desired Class D address an ARP_NAK will be returned. In this case the IP packet MUST be discarded silently. After transmitting the packet the local interface holds the VC open in case subsequent outgoing packets are also destined for that Class D address. Multicast VCs have the potential to be expensive in their use of resources. Therefore each VC MUST have a configurable inactivity timer associated with it. If the timer expires, an L_RELEASE is issued for that VC, and the Class D address is no longer considered to have an active path out of the local host. Choice of timer period is beyond the scope of this memo. When establishing a new multicast VC is is possible that one or more ostensible group members may reject an L_MULTI_RQ or L_MULTI_ADD. If this occurs then the ATM address of the node responsible is dropped from the set {ATM.1, ATM.2, .... ATM.n} returned by the ARP Server, and the creation of the multicast VC continues. [Further action necessary?] During the life of a multicast VC an ERR_L_RELEASE may be received indicating that a leaf node has terminated its participation at the ATM level. Future versions of this memo may specify a useful response to such indications. However, they should currently just be ignored and the ATM endpoint associated with the ERR_L_RELEASE removed from the locally held set {ATM.1, ATM.2, .... ATM.n} associated with the VC. Section 6 describes how the ARP Server tracks current group membership. Section 7 describes what happens if group members changes while the VC is open. 6. Joining an IP Multicast Group to Receive packets. A host is a 'group member', in the sense that a member receives packets directed at the group, when its ATM address appears in the ARP Server's table entry for the group's IP address. The following extensions are required to manage the ARP Server table entries: - The ARP Server now includes an IGMP entity listening on 224.0.0.1. - A new IGMP message type is defined called ATMMC, with two subtypes JOIN and LEAVE. They carry an IP group address and a unicast ATM address. - All IGMP messages MUST be transmitted to address 224.0.0.1. The mechanism described in RFC 1112 for redundant transmission of IGMP Reports MUST be applied to ATMMC messages. - When an IGMP ATMMC_JOIN is seen by the ARP Server's IGMP entity, it adds the specified ATM address to the ARP entry for the specified Class D address. - When an IGMP ATMMC_LEAVE is seen by the ARP Server's IGMP entity, it removes the specified ATM address from the ARP entry for the specified Class D address. - JoinLocalGroup now results in two messages being transmitted: - IGMP Report, and - IGMP ATMMC_JOIN, identifying the IP group being joined, and the hosts ATM address. - LeaveLocalGroup now results in an IGMP ATMMC_LEAVE being transmitted, identifying the IP group being left, and the hosts ATM address. - IGMP entities ignore ATMMC_JOIN or ATMMC_LEAVE messages that simply confirm information already held by the entity. How this works may not immediately be apparent. Consider that the transmit side functions independently as described in section 5. The ARP Server always includes at least itself as a member of 224.0.0.1. When multicast hosts on the LIS start up RFC1112 requires that they join 224.0.0.1. The first host to execute JoinLocalGroup to 224.0.0.1 results in an IGMP ATMMC_JOIN sent to 224.0.0.1. The transmit side has no VC to this group, so it queries the ARP Server. The ARP Server returns itself as the only current group member. The host then establishes a multicast VC to the ARP Server for group 224.0.0.1. Finally the IGMP ATMMC_JOIN is sent over the VC. The ARP Server's IGMP entity sees it and adds the host to the list of members of 224.0.0.1. The second host to execute JoinLocalGroup for 224.0.0.1 will perform exactly the same procedure, except that the ARP Server will now return TWO ATM addresses, its own and that of the first host. The second host establishes a multicast VC, sends its own ATMMC_JOIN, and the ARP Server adds the second host's ATM address to the entry for 224.0.0.1. This process continues for all multicast-capable hosts on the LIS. Once IP hosts have joined 224.0.0.1 they may start joining other groups. This will result in more IGMP transmissions to group 224.0.0.1, which the ARP Server's IGMP entity will monitor in order to construct ARP table entries for other Class D addresses. 7. Adding A New Leaf to Outgoing Multicast VC. This section describes the addition of new members to groups that other hosts have already established multicast VCs to. The key is that the new member is immediately added as a Leaf node to all active VCs to other group members. In addition to the ARP Server, every host's IGMP entity must inspect ATMMC_JOIN and ATMMC_LEAVE messages arriving on 224.0.0.1. If an ATMMC_JOIN is seen that refers to an IP group for which the transmit side already has a VC open, the new member's ATM address is extracted and an L_MULTI_ADD issued locally. This ensures that hosts already sending to a given group will immediately add the new member to their list of recipients. 8. Leaving an IP Multicast Group. Leaving an IP multicast group involves removing the local hosts entry from the ARP Server, and ensuring that hosts stop sending to the leaving node. Both are the reverse of their respective 'join' operations described in section 6 and 7. For the ARP Server: LeaveLocalGroup results in ATMMC_LEAVE messages being sent to 224.0.0.1 using the same procedure as for ATMMC_JOIN. The ARP Server's IGMP entity notes the event, and removes the specified ATM address appropriately. If an IP multicast host issues a LeaveLocalGroup for 224.0.0.1 it will be considered to have ceased membership of all other groups for which it may have joined. The ARP Server MUST flush that hosts's ATM address from any Class D address entries it appears in. For an arbitrary host in the LIS: If an ATMMC_LEAVE is seen that refers to an IP group for which the transmit side already has a VC open, the leaving member's ATM address is extracted and an L_MULTI_DROP issued locally. This ensures that hosts already sending to a given group will immediately delete the old member from their list of recipients. If an ATMMC_LEAVE is seen that refers to group 224.0.0.1 then the ATM address of the host issuing the IGMP messages MUST be removed from every multicast VC on the local host that it may be a Leaf of. The transmit side of the interface MUST NOT shut down an active VC to a group for which the receive side has just executed a LeaveLocalGroup. This behaviour is consistent with the model of hosts transmitting to groups regardless of their own membership status. RFC 1112 requires all multicast IP hosts to be members of 224.0.0.1, so leaving 224.0.0.1 is considered to indicate cessation of support for IP multicasting. Normally this is not expected to happen. 9. Beyond the LIS - Multicast IP Router behaviour. Multicast routers are required for an IP multicast group to span more than the local LIS. The multicast router may be a tunneling router, or may have direct connection to another multicast-capable link layer. However, this memo only describes the behaviour of the multicast router from the perspective of the ATM LIS that it has an interface to. There is little difference between the behaviour of a traditional host and an IP multicast router. In fact it is presumed that the IP multicast router will be implemented over the same sort of IP-ATM interface that a normal host's IP layer would use. The router joins and monitors 224.0.0.1 to ascertain what groups have active members, and actively joins every group that has non-zero membership (excluding itself). It then passively receives copies of all packets sent to the group. Propagation of the packets beyond the LIS depends on router specific decisions beyond the scope of this memo. Consistent with RFC 1112, IP multicast routers retain the use of IGMP Query and IGMP Report messages to ascertain group membership. When an IGMP Report is received for a group that the router is not currently a member of it executes a JoinLocalGroup in the same way a host would. (Note that,as described in section 6, 224.0.0.1 is now a general purpose signalling group for IGMP Reports as well). When the router decides there are no more group members on the LIS, it executes a LeaveLocalGroup in the same way a host would. When the router needs to transmit a packet to a group within the LIS it opens a multicast VC in the same manner as a normal host would. Once a VC is open, the router's IGMP entity monitors 224.0.0.1 for IGMP ATMMC_JOIN and ATMMC_LEAVE messages to update the group of leaf nodes it sends to, as a normal host would. The IP multicast router's transmit side MUST implement in-activity timers to shut down idle outgoing VCs, as for normal hosts. Routing protocols between IP multicast routers (such as DVRMP [5]) are not covered in this memo, nor are they affected by it. As far as they wider IP world is concerned, the router is connected to a Classical IP subnet. 10. Summary of Key Decisions. The key decisions this memo proposes: o ATM multicast in a LIS is through mesh of Point to Multipoint VCs rather than a central Multicast Server. o ATM ARP Server role extended. - Class D IP addresses may be mapped to 0 or more ATM addresses. - Class D address 224.0.0.1 always has at least one address in it, the ATM address of the ARP Server. - New ARP message type, ARP_MULTI. ATM ARP_REQUESTS issued for Class D addresses may get 0 or more ARP_MULTI messages, followed by a normal ARP_REPLY as the ARP Server passes back all group member's ATM addresses. - IGMP entity added to ARP Server, with ability to modify ARP table entries. o IGMP protocol modified and extended. - All IGMP messages, from hosts or routers, are sent to 224.0.0.1. - Two new IGMP messages: - ATMMC_JOIN Indicates IP group being joined. Carries ATM address. - ATMMC_LEAVE Indicates IP group being left. Carries ATM address. - IGMP entities on all nodes monitor ATMMC_* traffic to add or remove leaf nodes to active, outgoing, multicast VCs. - IP multicast routers expect IGMP Reports on 224.0.0.1. o ATM endpoint model. - Attempted decoupling of IP-ATM interface, local UNI 3.0 signalling service, and local ATM/AAL service descriptions. - Explicitly identifies an LLC 'entity' that terminates or originates VCs for RFC 1483 compliant LLC/SNAP encapsulated traffic. 11. Open Issues. Some issues have not been addressed, although they may be in future revisions. o Quality of Service has not been addressed. It is implicitly left up to each hosts implementation to request of the ATM layer an appropriate QoS when originating a multicast VC. o No attempt has been made to reconcile or optimise the use of IGMP messages. ATMMC_JOIN and ATMMC_LEAVE contain a superset of the information in an IGMP Report. o Robustness of IGMP message exchange. Current mechanism inherits the RFC 1112 approach of "repeat it a couple of times, and pray". o ARP Server has no mechanism for realising group members have silently died. [This probably should be attended to as a priority]. o Using a mesh of point to multipoint VCs to connect group members places a high load on both the switch and the ATM reassembly engines of each host that is receiving group transmissions. When an IP host joins a group, every host transmitting to that group adds it as a new leaf. This results in a new incoming VC and reassembly instance at the receiver for every VC it has become a leaf to. If an IP host joins multiple groups the situation is exacerbated. Implementations might consider reusing VCs if a destination ATM node's IP interface is a member of multiple groups. o No attempt is made to utilise indications from the ATM layer that remote nodes have either added the local node as a leaf, or dropped themselves from a VC originating at the local node. o The future development of ATM Group Addresses and Leaf Initiated Join to ATM Forum's UNI specification has not been touched. The problems identified in this memo with respect to VC scarcity and impact on receive side reassembly engines will not be fixed by such developments in the signalling protocol. Security Consideration Security consideration are not addressed in this memo. Acknowledgments [...constructive comments will be handsomely rewarded with your name inscribed here - immortality! ] Author's Address Grenville Armitage MRE 2P340, 445 South Street Morristown, NJ, 07960-6438 USA Email: gja@thumper.bellcore.com References [1] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-Packard Laboratories, December 1993 [2] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, Standford University, August 1989. [3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, USC/Information Science Institute, July 1993. [4] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993 [5] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. Appendix A. UNI 3.0 Multicast Support - A Brief Overview. This section provides a summary of point-to-multipoint signaling procedures. Readers are referred to [4]. [...to be written. refer to for almost all UNI 3.0 IE and field values...] Appendix B. Formats of ARP_MULTI, ATMMC_JOIN, and ATMMC_LEAVE messages. B.1 ARP_MULTI The ATM ARP_MULTI message is an ARP_REPLY message with the 'operation type value' set to to ARP_MULTI. RFC 1577 must be consulted for the exact fields and their contents. The value for ARP_MULTI is 11 (decimal). B.2 ATMMC_JOIN and ATMMC_LEAVE. ".. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2." IGMP messages start with the following 4 byte header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Subtype | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version = 1 The Type field values shall be: 1 = Host Membership Query. (Subtype is ignored). 2 = Host Membership Report. (Subtype is ignored). 3 = DVMRP [5]. (4 subtypes defined). 4 = ATMMC. For ATMMC the Subtype field values shall be: 1 = JOIN. 2 = LEAVE. The ATMMC message contents follow immediately after the IGMP header in the IP packet. The format is exactly the same for ATMMC_JOIN and ATMMC_LEAVE. It borrows fields from the ATM ARP packet format in RFC 1577 to carry a single IP address, an ATM address, and (optionally) an ATM subaddress: Data: ar$shtl 8 bits Type & length of source ATM number (q). ar$sstl 8 bits Type & length of source ATM subaddress (r). ar$spa 32 bits Class D address of IP multicast group. ar$sha qoctets source ATM number (E.164 or ATM Forum NSAPA). ar$ssa roctets source ATM subaddress (ATM Forum NSAPA). Refer to RFC 1577, section 6.6 for the correct coding of the ar$shtl and ar$sstl fields.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23859; 16 Aug 94 0:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23855; 16 Aug 94 0:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24801; 16 Aug 94 0:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA069656693; Mon, 15 Aug 1994 20:11:33 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from glare.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA069326691; Mon, 15 Aug 1994 20:11:31 -0700 Received: (percyk@localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id UAA12411; Mon, 15 Aug 1994 20:11:27 -0700 Date: Mon, 15 Aug 1994 20:11:27 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Percy Khabardar Message-Id: <199408160311.UAA12411@glare.cisco.com> To: ddp@fore.com Cc: jmoy@alpo.casc.com, dino@cisco.com, ip-atm@matmos.hpl.hp.com In-Reply-To: Drew Perkins's message of Mon, 15 Aug 94 20:01:00 EDT <9408160001.AA13091@marlin> Subject: Multicasting over ATM draft > > This protocol also needs a reliable protocol for transferring information > > between server and group member/sender. We probably need to use TCP in order > > to get reasonable performance. > > To keep thing simple I was thinking of using a simple request response protocol > between the server and the group member/sender. A sender would issue a "join" > request with a unique correlation id to the server. The server's response would > contain the same correlation id. If no response is received the sender (after > timing out) would issue another req with another correlation id. The timer > would be sufficiently large that no response would indicate a loss message. I'm not worried about the request from client to server, I'm worried about the response from server to client. If there are 10,000 group members, you could have quite a large response. This would undoubtedly be multi-packet. What if one packet got lost? Retransmit only that one packet or the entire request? This starts to become a complex protocol. You may as well use a protocol designed to do this (TCP or SSCOP). The server could respond with multiple packets to a single client request however each packet would have the total number of group members and the last packet in the response would have the "M" (More) bit set to 0. (Also a particular ATM address should not be split across packet boundaries). If one of the packet gets lost then retransmit the entire response (client issues another join request). I am trying to avoid the overheads of TCP here. I don't think we can use SSCOP because of it's fixed timers - a dynamic protocol like TCP which could adapt to network conditions would be more appropriate (if we decide to use it). - Percy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24643; 16 Aug 94 1:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24639; 16 Aug 94 1:25 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa25576; 16 Aug 94 1:25 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA085990065; Mon, 15 Aug 1994 21:07:45 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from trillium.com (gandalf.trillium.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA085009446; Mon, 15 Aug 1994 20:57:26 -0700 Received: from gimli.trillium.com.trillium.com by trillium.com (5.0/SMI-SVR4) id AA05452; Mon, 15 Aug 1994 20:54:24 +0800 Received: by trillium.com (5.0/SMI-SVR4) id AA09957; Mon, 15 Aug 1994 19:56:38 +0800 Date: Mon, 15 Aug 1994 19:56:38 +0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: rajeev@trillium.com Message-Id: <9408160256.AA09957@trillium.com> To: af-all@atmforum.com, ip-atm@matmos.hpl.hp.com, comp.dcom.cell-relay@usenet.ucs.indiana.edu Subject: Private ATM Addresses vs NSAP addresses X-Sun-Charset: US-ASCII Content-Length: 0 The ATM Forum UNI 3.0/3.1 claims that the Private ATM address format is modelled after the format of an OSI NSAP, as specified in ISO 8348, and that it is always 20 octets [section 5.1.3.1]. It then goes on to specify 3 AFI values that may be used with Private ATM addresses: 39, 47, 45 [section 5.1.3.1.1]. I dug up ISO 8348, Addendum 2 (1987) and discovered that for the above AFI values, the corresponding NSAP address lengths are 17, 16 and 18 octets, respectively. I will summarize my findings and the apparent inconsistency with the UNI text. Perhaps, my analysis is wrong, so I would welcome corrections. All references below refer to ISO 8348, Addendum 2, 1987. NSAP address format ------------------- An NSAP address has three parts: AFI, IDI, DSP. The AFI and IDI are decimal digits whereas the DSP could be decimal or binary. To represent these values in protocol messages, the UNI specifies "preferred binary encoding" which encodes decimal values using BCD and binary values are encoded directly. Field Lengths ------------- AFI: Length is two decimal digits. Currently values 36-59 are assigned. [section 8.2.1.1, Table 1] IDI: Length depends on IDI format. [sections 8.2.1.2.2, 8.2.1.2.5, 8.2.1.2.6] DCC 3 decimal digits (fixed length) ICD 4 decimal digits (fixed length) E.164 upto 15 decimal digits (variable length) DSP: Length depends on AFI and whether it is binary or decimal. [section 8.2.3, Table 3] ---------------------------- IDI Decimal Binary format Digits Octets ---------------------------- DCC 35 14 ICD 34 13 E.164 23 9 ---------------------------- Now, the selection of the AFI value indicates the IDI format (for variable length IDIs, it specifies whether leading 0's are significant) as well as the abstract syntax for DSP. The values specified in the UNI imply the following [Table 2]: ----------------------------------------------------------------------- AFI value Implication ----------------------------------------------------------------------- 39 IDI = DCC; DSP is binary 47 IDI = ICD; DSP is binary 45 IDI = E.164, leading 0's not significant; DSP is binary ----------------------------------------------------------------------- Note that the specific choice of AFI values indicate that the DSP values are always binary, not decimal i.e. encoding is not BCD. Based on the above, we can calculate the length of the corresponding NSAP addresses [Table 5]: ---------------------------------------------------------------------------- AFI value AFI length IDI length DSP length Total length (octets) (octets) (octets) (octets) ---------------------------------------------------------------------------- 39 (DCC) 1 2 14 17 47 (ICD) 1 2 13 16 45 (E.164) 1 8 9 18 ---------------------------------------------------------------------------- The values above are calculated as follows: AFI: Two decimal digits represented as two semi-octets using BCD. IDI: Decimal digits represented as semi-octets using BCD, leading 0's used to fill IDI field, a single semi-octet 1111 used to obtain integral number of octets. DSP: Taken from [Table 3]. Clearly, this imples two things: 1. These NSAP addresses are not always 20 octets, as specified in the UNI. 2. The DSP does not consist of decimal digits encoded using BCD. There are two explanations: 1. Private ATM addresses are not NSAP addresses, or 2. The AFI values specified are wrong. If the AFI values were chosen to indicate that the DSP consists of decimal digits, then the NSAP addresses would indeed always be 20 octets. Here is the same calculation as above, this time using AFI values that indicate the DSP is decimal [Tables 2,3,5]: ---------------------------------------------------------------------------- AFI value AFI length IDI length DSP length Total length (digits) (digits) (digits) (digits) ---------------------------------------------------------------------------- 38 (DCC) 2 3 35 40 46 (ICD) 2 4 34 40 44 (E.164) 2 15 23 40 ---------------------------------------------------------------------------- Now, the total address length is 40 octets, which when represented using BCD, will fit in 20 octets. Also, the entire NSAP address is a string of decimal digits. Note, however, that the in the case of DCC and E.164, the IDI and DSP split on a semi-octet boundary. So the pictures in UNI 3.1 (5.1a and 5.1c) will be incorrect. Moreover, if the intention is for the ESI field to carry 48 bit IEEE MAC addresses, then clearly the DSP cannot be decimal. So, to be completely accurate, the UNI should be modified to do one of the following: 1. Change the AFI values to indicate DSP is decimal; change the pictures that show that the IDI and DSP split on an octet boundary. 2. Retain the existing AFIs but specify that the length of the NSAP address varies according to format. 3. Retain the existing AFIs and continue to claim that all private ATM addresses are 20 octets, but remove reference to NSAP addresses and ISO 8348. Comments are welcome. ------------------------------------------------------------------- Rajeev Gupta Email : rajeev@trillium.com Trillium Digital Systems, Inc. Voice (w) : (310) 479-0500 Los Angeles, CA 90025. Fax (w) : (310) 575-0172 * I speak only for myself, but make no claim to original thought * -------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04651; 16 Aug 94 10:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04641; 16 Aug 94 10:17 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07490; 16 Aug 94 10:17 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04632; 16 Aug 94 10:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04541; 16 Aug 94 10:13 EDT Received: from mac-50.cnri.reston.va.us by CNRI.Reston.VA.US id aa07382; 16 Aug 94 10:13 EDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Aug 1994 10:18:54 -0500 To: ietf@CNRI.Reston.VA.US, e2e-interest@isi.edu, ip-atm@hpl.hp.com X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Bonnie K. Brown" Subject: GIGABIT TESTBED JAMBOREE Message-ID: <9408161013.aa07382@CNRI.Reston.VA.US> The fifth Gigabit Testbed Workshop (aka Gigabit Testbed Jamboree) will be held November 2-4, 1994 at the Hyatt Regency Hotel in Reston, Virginia. This workshop will present results from the gigabit testbeds being sponsored under CNRI's Cooperative Agreement with the government, and in addition will provide a forum for technical interaction among attendees. The National Science Foundation and the Advanced Research Projects Agency are providing funding for the gigabit testbeds in conjunction with major support from industry. Attendance at this year's Jamboree has been expanded to accommodate a larger segment of the technical community than has been the case in past years. Space is limited, however, and registration will be on a first-come-first-served basis. You will receive notification within 2 to 3 weeks of sending in a registration form on whether you can be accommodated. The program will consist of a single track of presentations and panel sessions over the three days, with a focus on testbed work in the areas of network technology and the networking of applications at gigabit speeds. Topics will include testbed experiences in wide area transmission and switching using ATM and variable-length PTM approaches, gigabit-rate network I/O for supercomputer and workstation class computers, high speed protocols and distributed shared memory techniques, the interworking of gigabit technologies, and the investigation of distributed supercomputing and multimedia workstation applications over wide area gigabit networks. There will be a reception and buffet on Tuesday evening, November 1, starting at approximately 6:30pm. The workshop will include a continental breakfast and lunch each day. A reception and dinner is also planned for Wednesday evening, with Thursday evening free. The workshop will end at approximately 4:00pm on Friday. The registration fee is $325.00, which includes all workshop meals, receptions, and a copy of the proceedings. Each attendee is responsible for making his or her hotel reservations. A block of rooms is being held at the Hyatt Regency in Reston Town Center at the special rate of $110.00 plus tax per night single and $130.00 double occupancy. Reservations must be made by October 12 to obtain these rates. The Hyatt's reservation number is 703-709-1234; be sure and state that you are attending the CNRI Gigabit Testbed Workshop. If you would like to attend, please return the attached registration form to CNRI as soon as possible to ensure that space is reserved for you (a separate form is required for each person registering). Note that a higher registration fee of $360.00 will be charged for registration forms received after October 1. REGISTRATION FORM Fifth Gigabit Testbed Workshop November 2-4, 1994 Reston, VA (Please print or type) NAME (Mr/Dr/Ms/): ORGANIZATION: ADDRESS: CITY: STATE: ZIP CODE: TELEPHONE: FAX: EMAIL: Do you plan to attend the evening reception on Tuesday, November 1st? YES__NO__ $325.00 Registration Fee if registration form is received by October 1; $360.00 after that date. Method of payment: ___AMEX ___VISA ___MC ___DINERS ___Check enclosed If Check: U.S. dollars, drawn on a U.S. Bank payable to: Corporation for National Research Initiatives If Credit Card: ACCOUNT #: EXP DATE: CARDHOLDER NAME: Registration Forms can be sent via electronic mail, facsimile, or postal mail: Electronic: bbrown@cnri.reston.va.us Facsimile: 703-620-0913 Postal: Corporation for National Research Initiatives Accounting Department - Gigabit Workshop 1895 Preston White Drive, Suite 100 Reston, VA 22091-5434 USA IMPORTANT: - Register one person per form. - Purchase orders cannot be accepted. - (If your registration can be accommodated): Requests for refunds must be received by October 15, 1994, and are subject to a $50.00 service charge. - If space no longer exists at the time your registration is received, your credit card will not be charged or your check will be returned.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05025; 16 Aug 94 10:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05021; 16 Aug 94 10:35 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa07863; 16 Aug 94 10:35 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA157062359; Tue, 16 Aug 1994 06:06:00 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from nbkanata.newbridge.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA156692354; Tue, 16 Aug 1994 06:05:54 -0700 Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA11944; Tue, 16 Aug 94 09:01:00 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA07518; Tue, 16 Aug 94 09:00:59 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA12705; Tue, 16 Aug 94 09:00:18 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA12083; Tue, 16 Aug 1994 09:02:32 +0500 Date: Tue, 16 Aug 1994 09:02:32 +0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9408161302.AA12083@urchin.newbridge> To: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: YAAM draft (Yet Another ATM Multicast draft :-) X-Sun-Charset: US-ASCII Content-Length: 1698 Looking at this draft, I see a couple of problems. 1) There is a scaling problem in that every multicast participant in any group within a LIS will need a pt-mpt circuit to all other participants in any group within that LIS. In particular, these circuits will never be timed out, since the periodic transmission of IGMP messages will keep them alive. 2) The pt-mpt circuit for 224.0.0.1 is created at a new station by receiving a list of participants from the ARP Server. The ARP server sends these unreliably. If one is lost, there is no mechanism for getting that information later. (The new host is not in the lost members group, and because the lost member is not in the new hosts group, the new hosts IGMP will not get to the lost host.) Clearly, the ARP server can not get into periodic retransmission. 2a) There are obvious possibilities for race conditions when more than one participant is joining, depending on how list maintenance and transmission is done. 2b) If the list distribution is going to be reliable, then there is no need for a pt-mpt circuit mesh just for distributing the group membership information. To get the ARP portion to work, one will need a reliable mechanism with enough state to detect additions during transmission, etc. As such, that mechanism is no longer ARP, and is sufficient to replace the forwarding of IGMP membership messages to all hosts. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS The issues raised here are distinct from the question of whether a mesh of pt-mpt circuits among the participants in a given group is a good idea. My own opinion is that it is a bad but unavoidable technique.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05662; 16 Aug 94 11:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05658; 16 Aug 94 11:00 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08427; 16 Aug 94 11:00 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA173183833; Tue, 16 Aug 1994 06:30:33 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA172853831; Tue, 16 Aug 1994 06:30:31 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA07909; Tue, 16 Aug 1994 05:14:57 -0700 Received: from gatekeeper.mis.tridom.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA15258; Tue, 16 Aug 1994 05:14:56 -0700 Received: from eng.tridom.com (diamond.eng.tridom.com) by gatekeeper.mis.tridom.com with SMTP id AA21954 (5.65c/IDA-1.4.4 for ); Tue, 16 Aug 1994 07:47:22 -0400 Received: from seth.eng.tridom.com.tridom.com by eng.tridom.com (4.1/AT&T Tridom Eng 2.0) id AA16796; Tue, 16 Aug 94 08:20:18 EDT Date: Tue, 16 Aug 94 08:20:18 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen Thomas Message-Id: <9408161220.AA16796@eng.tridom.com> To: rajeev@trillium.com Subject: Re: Private ATM Addresses vs NSAP addresses Cc: af-all@atmforum.com, ip-atm@matmos.hpl.hp.com, comp.dcom.cell-relay@usenet.ucs.indiana.edu Rajeev: I'm only following the ATM list for informational purposes, as I'm not much of an ATM expert. I do have a fair bit of experience with ISO protocols and NSAP formats. > The ATM Forum UNI 3.0/3.1 claims that the Private ATM address format > is modelled after the format of an OSI NSAP, as specified in ISO 8348, > and that it is always 20 octets [section 5.1.3.1]. It then goes on to > specify 3 AFI values that may be used with Private ATM addresses: > 39, 47, 45 [section 5.1.3.1.1]. > > I dug up ISO 8348, Addendum 2 (1987) and discovered that for the above > AFI values, the corresponding NSAP address lengths are 17, 16 and 18 > octets, respectively. At this point, 8348/Ad2 is an obsolete specification. It has been replaced by 8348/Ad4, "Removal of the Preferred Decimal Encoding of the NSAP Address." I'm not sure whether 8348/Ad4 is IS or DIS status; perhaps someone who follows the standards process can shed more light. > ---------------------------- > IDI Decimal Binary > format Digits Octets > ---------------------------- > DCC 35 14 > ICD 34 13 > E.164 23 9 > ---------------------------- The latest values, from my early copy of 8348/Ad4: ---------------------------- IDI Decimal Binary format Digits Octets ---------------------------- DCC 35 17 ICD 34 17 E.164 23 11 ---------------------------- As I'm sure you'll notice, the revised values for binary encoding bring the NSAP length up to 20 octets in all cases. By now you may be feeling frustrated in that a lot of your effort in deciphering NSAP formats has been wasted. If it's any consolation, you are not the first to feel this way :( _____________________________________________ Stephen Thomas AT&T Tridom (404-514-3522) email: sat@eng.tridom.com, attmail!tridom!sat   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07288; 16 Aug 94 13:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07284; 16 Aug 94 13:06 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11168; 16 Aug 94 13:06 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA214471068; Tue, 16 Aug 1994 08:31:08 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA214041024; Tue, 16 Aug 1994 08:30:24 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA05367; Tue, 16 Aug 94 11:29:00 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA06836; Tue, 16 Aug 94 11:28:54 EDT Received: by marlin (4.1/SMI-4.1) id AA19706; Tue, 16 Aug 94 11:28:53 EDT Date: Tue, 16 Aug 94 11:28:53 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408161528.AA19706@marlin> To: percyk@cisco.com Subject: Re: Multicasting over ATM draft Cc: jmoy@alpo.casc.com, dino@cisco.com, ip-atm@matmos.hpl.hp.com > > > This protocol also needs a reliable protocol for transferring information > > > between server and group member/sender. We probably need to use TCP in order > > > to get reasonable performance. > > > > To keep thing simple I was thinking of using a simple request response protocol > > between the server and the group member/sender. A sender would issue a "join" > > request with a unique correlation id to the server. The server's response would > > contain the same correlation id. If no response is received the sender (after > > timing out) would issue another req with another correlation id. The timer > > would be sufficiently large that no response would indicate a loss message. > > I'm not worried about the request from client to server, I'm worried about the > response from server to client. If there are 10,000 group members, you could > have quite a large response. This would undoubtedly be multi-packet. What if > one packet got lost? Retransmit only that one packet or the entire request? > This starts to become a complex protocol. You may as well use a protocol > designed to do this (TCP or SSCOP). > > > The server could respond with multiple packets to a single client request however > each packet would have the total number of group members and the last packet in > the response would have the "M" (More) bit set to 0. (Also a particular ATM > address should not be split across packet boundaries). If one of the packet gets > lost then retransmit the entire response (client issues another join request). > I am trying to avoid the overheads of TCP here. I don't think we can use SSCOP > because of it's fixed timers - a dynamic protocol like TCP which could adapt to > network conditions would be more appropriate (if we decide to use it). Now you are starting to design a more complicated protocol. It's beginning to sound like EGP or something. There is a can of worms here that we already have protocols to solve. Let's not invent another. TCP is good enough for BGP, it is good enough for this. With relatively short-lived connections, I don't see a problem with TCP overhead. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08865; 16 Aug 94 14:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08861; 16 Aug 94 14:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12792; 16 Aug 94 14:24 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA239706150; Tue, 16 Aug 1994 09:55:50 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA239376145; Tue, 16 Aug 1994 09:55:45 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA05803; Tue, 16 Aug 94 12:54:12 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA13602; Tue, 16 Aug 94 12:54:06 EDT Received: by marlin (4.1/SMI-4.1) id AA20345; Tue, 16 Aug 94 12:54:05 EDT Date: Tue, 16 Aug 94 12:54:05 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408161654.AA20345@marlin> To: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com, jhalpern@newbridge.com Subject: Re: YAAM draft (Yet Another ATM Multicast draft :-) A problem you didn't really touch on is that routers must be members of all groups at all times. They don't hear IGMP Reports unless they are already a member of a group and therefore can't use them as an indication that they should join a group. However, your new ATMMC_JOIN message does solve this if the router listens to those and uses them as an indication of which groups to join. But, these messages MUST be reliable; they must be retransmitted periodically to make sure the routers hear them. This solution does not scale nearly as well as Percy and Dino's solution. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09341; 16 Aug 94 14:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09337; 16 Aug 94 14:48 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13268; 16 Aug 94 14:48 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA261337904; Tue, 16 Aug 1994 10:25:04 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA261007901; Tue, 16 Aug 1994 10:25:01 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id NAA14415; Tue, 16 Aug 1994 13:24:42 -0400 Message-Id: <199408161724.NAA14415@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Drew Perkins Cc: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com, jhalpern@newbridge.com, gja@thumper.bellcore.com Subject: Re: YAAM draft (Yet Another ATM Multicast draft :-) In-Reply-To: Your message of Tue, 16 Aug 94 12:54:05 -0400. <9408161654.AA20345@marlin> Date: Tue, 16 Aug 94 13:24:40 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com >>A problem you didn't really touch on is that routers must be members of all >>groups at all times. They don't hear IGMP Reports unless they are already a >>member of a group and therefore can't use them as an indication that they >>should join a group. Section 6 explicitly proposes the modification that _all_ IGMP messages (including Reports) are sent to 224.0.0.1, so receiving IGMP Reports doesn't require prior membership of any given group. Admittedly this loses the possibility of checking the group which the IGMP Report claims membership of against the group it arrived from/on (as rfc1112 allows). Beyond IGMP messages, the routers only need to be members of a group if they have some prior knowledge that group membership extends beyond the LIS, at which time they issue a JoinLocalGroup and become members. [..] >>This solution does not scale nearly as well as Percy and Dino's solution. I think scalability is going to run up against some real _implementation_ brick walls inherit in using pt-mp meshes (which we both use), well before the signalling mechanism becomes a limitation. Thanks for the comments. I'm still pondering Joel's earlier observation about reliable signalling on 224.0.0.1 too. gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09364; 16 Aug 94 14:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09360; 16 Aug 94 14:49 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13280; 16 Aug 94 14:49 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA254847221; Tue, 16 Aug 1994 10:13:41 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sirius.ctr.columbia.edu by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA254517216; Tue, 16 Aug 1994 10:13:36 -0700 Received: from rhea.ctr.columbia.edu (hiroshi@rhea.ctr.columbia.edu [128.59.74.27]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id NAA21350 for ; Tue, 16 Aug 1994 13:13:34 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hiroshi Esaki Received: (hiroshi@localhost) by rhea.ctr.columbia.edu (8.6.7/8.6.4.788743) id NAA21775; Tue, 16 Aug 1994 13:13:33 -0400 Date: Tue, 16 Aug 1994 13:13:33 -0400 Message-Id: <199408161713.NAA21775@rhea.ctr.columbia.edu> To: ip-atm@matmos.hpl.hp.com Subject: multicasting --- responds to the mail from susan@mitre dated on Aug.10 --- >> Some of the issues that we will need to tackle when >> defining an IPmc/ATMmc interface are : >> >> 1) Sender vs. Receiver-initiated joins : >> >> Membership in IPmc group is open to every entity on the >> network, at that entity's perogative and initiative. >> The sender has no control over who may or may not be in a >> particular multicast group. In fact, the sender is not even >> necassary aware of the number or identity of the endpoints of >> the IPmc transmission. It does not even make sense to say that >> the sender is or is not notified of group join requests, >> because with IPmc there is no notion of group having any >> particular sender. Anyone can transmit data to a particular >> multicast group, even entities that are not members of the >> group. Maybe, my understunding is wrong. When we see the ATM is as well as just data-link network segment and when the ATM networks are interconnected by the routers, essentially nothing is different. The routers and hosts, who would like to join (actually these are leaf) the IPmc it will join to the ATMmc regarding corresponding IPmc. When you try to arrange IPmc using a single ATMmc covering multiple Logical IP subnet topping on large could ATM network, you will have a problem. But, when you keep the architectual paradigm even in the ATM network, nothing will not be changed, essentially. Hiroshi Esaki (Toshiba Corp.) c/o CTR, Columbia University, 530 West, 120th Street, New York, NY., 10027   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09954; 16 Aug 94 15:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09947; 16 Aug 94 15:17 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13765; 16 Aug 94 15:17 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA283148821; Tue, 16 Aug 1994 10:40:21 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sirius.ctr.columbia.edu by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA282818818; Tue, 16 Aug 1994 10:40:18 -0700 Received: from rhea.ctr.columbia.edu (hiroshi@rhea.ctr.columbia.edu [128.59.74.27]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id NAA21737; Tue, 16 Aug 1994 13:40:14 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hiroshi Esaki Received: (hiroshi@localhost) by rhea.ctr.columbia.edu (8.6.7/8.6.4.788743) id NAA21827; Tue, 16 Aug 1994 13:40:12 -0400 Date: Tue, 16 Aug 1994 13:40:12 -0400 Message-Id: <199408161740.NAA21827@rhea.ctr.columbia.edu> To: fong@fore.com Cc: susan@backup.mitre.org, ip-atm@matmos.hpl.hp.com, ddp@fore.com In-Reply-To: Fong-Ching Liaw's message of Mon, 8 Aug 94 15:21:04 EDT Subject: Re : multicast > QOS is another aspect. Right now, all parameters must be the same for > all leaves. RSVP, on the other hand, allows different bandwidth for each > leaf. So, there is mismatch. Jonathan's point on IPmc routing and ATMmc > routing is anther aspect which I scratched the surface later. When you think IP(=ATM) subnet's are interconnected by the routers, there is NO mismatch with RSVP model. You may see as IP subnet as Logical IP subnet over large ATM (NBMA) network, but it is OK. Router can decide the researved bandwidth for ATMmc within the subnet, if necessary. Multicast tree should be generated among routers. ATMmc is available within the IP subnet, that all. Since arrangement of multicast tree can be done by hierarchically (conjunction with the structure of IP subnets), it can scale easily, as well as the current multicast arrangement. Just keep the architectural paradigm as same as the current Internet, even when you go into ATM. > I will be happy to share the basic idea of FORE's IPmc over ATMmc. > When a host join an IP group IP-G, the ATM driver recieves > an IP_MULTIADD ioctl, it then translates that to join ATM-G > (translation between IP-G and ATM-G is algorithmic). I can not understand why some algorithmic translation between IP-G and ATM-G is needed ? ATM is just data-link, therfore we should assume there is no co-relation between IP-G and ATM-G, basically. I think getting ATM-G from IP-G can be performed exactly the same procedure as ARP for pt-to-pt communication. Just ask tothe network what is the ATM-G corresponding to the IP-G. > One advantage (or limitation) FORE implementation is that the > ATM-SPANs net is treated as an IP subnet so scoping is not interpreted > (or used) at this point. When a router is to forward a multicast > packet to its ATM interface, it sets up a connection to the group, > and the connection is established to all > members registered. I think you should consider about the scaling issue. Someone seemed to pointed out in a following mail. > If there are routers attached on the ATM net, > it will receive the multicast packet and may forward it toward > other networks behind it (but not back on to the ATM net). > This approach relies on ATMmc to reach all registered IP members attached > on the connected ATM network, and routers to forward IPmc packets to other > type of local networks. The ATM network establishes connections to > IPmembers because the addresses used. How do you deal with the case IP subnet's are interconnected based on classical IP model ? When you arrange only one ATMmc for large ATM (NBMA) network to serve all of hosts belonging to Ligical IP subnet's, the router must understant he attached to the NBMA net only or not. > Assume we want to use ATMmc to reach members (on same subnet or not) > directly attached to ATM net, and routers to forward IPmc packets > to other nets. ATMmc would have to reach > > Regestered IP members (this can be done by the address mapping), > within IP scoping rules (ignore QOS issue for now). Once the router attached to NBMA net only forward IPmc using the ATMmc, the broadcast storm will occur. In order to avoid this, different IPmc tree arrangement algorithm, that will be very different from the conventional mc arrangement, must be required. I suggest that we should keep the architectural paradigm that is same as the current Internet, when it is related to IP subnet structure. Hiroshi Esaki (Toshiba Corp.) c/o CTR, Columbia University, 530 West, 120th Street, New York, NY., 10027   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11095; 16 Aug 94 16:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11091; 16 Aug 94 16:21 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15233; 16 Aug 94 16:21 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA002862751; Tue, 16 Aug 1994 11:45:51 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from tree.Stanford.EDU by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA002512749; Tue, 16 Aug 1994 11:45:49 -0700 Received: (from akyol@localhost) by tree.Stanford.EDU (8.6.8/8.6.6) id LAA04814; Tue, 16 Aug 1994 11:45:29 -0700 Date: Tue, 16 Aug 1994 11:45:29 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bora Aydin Akyol Message-Id: <199408161845.LAA04814@tree.Stanford.EDU> To: percyk@cisco.com, ddp@fore.com Subject: Re: Multicasting over ATM draft Cc: jmoy@alpo.casc.com, dino@cisco.com, ip-atm@matmos.hpl.hp.com X-Sun-Charset: US-ASCII The following is my humble opinion and maybe offensive to some. ------------------------------------------------------------------------ I have been following this mailing list for a while now, one thing I have noticed is that most of the time is being spent on how to port IP over ATM as per the name of the list. I am just curious if there is ANYONE out there who think about defining a native ATM API which will be independent of IP/TCP over ATM bandwagon and will actually take advantage of the strongholds of ATM technology like being connection oriented and have the ability to do statistical multiplexing, otherwise maybe we should have used PPP over SONET . Please do understand I support and understand the IP over ATM effort but there has to be a future goal for transmitting all sorts of traffic over ATM and IP is not appropriate for that. Bora Akyol Graduate Student Stanford University   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11290; 16 Aug 94 16:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11286; 16 Aug 94 16:30 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15391; 16 Aug 94 16:30 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA020263842; Tue, 16 Aug 1994 12:04:02 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA019933831; Tue, 16 Aug 1994 12:03:51 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA06542; Tue, 16 Aug 94 15:03:25 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA24948; Tue, 16 Aug 94 15:03:18 EDT Received: by marlin (4.1/SMI-4.1) id AA21864; Tue, 16 Aug 94 15:03:17 EDT Date: Tue, 16 Aug 94 15:03:17 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408161903.AA21864@marlin> To: gja@thumper.bellcore.com Subject: Re: YAAM draft (Yet Another ATM Multicast draft :-) Cc: ip-atm@matmos.hpl.hp.com, jhalpern@newbridge.com > >>This solution does not scale nearly as well as Percy and Dino's solution. > > I think scalability is going to run up against some real _implementation_ > brick walls inherit in using pt-mp meshes (which we both use), > well before the signalling mechanism becomes a limitation. > > Thanks for the comments. I'm still pondering Joel's earlier observation > about reliable signalling on 224.0.0.1 too. This is a very good point, I'm afraid. Many host adapters today support only 1K VCCs. I know of some which support only 128. I think this is one reason why LAN Emulation went with a central server (Keith, please comment). You have to use your VCCs very efficiently and limit your scope appropriately. I don't see that this proposal does either of these. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11827; 16 Aug 94 17:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11823; 16 Aug 94 17:16 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16412; 16 Aug 94 17:16 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA049005928; Tue, 16 Aug 1994 12:38:48 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA048675923; Tue, 16 Aug 1994 12:38:43 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA06759; Tue, 16 Aug 94 15:38:00 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA28310; Tue, 16 Aug 94 15:37:53 EDT Received: by marlin (4.1/SMI-4.1) id AA22634; Tue, 16 Aug 94 15:37:52 EDT Date: Tue, 16 Aug 94 15:37:52 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408161937.AA22634@marlin> To: percyk@cisco.com, akyol@leland.stanford.edu Subject: Re: Multicasting over ATM draft Cc: jmoy@alpo.casc.com, dino@cisco.com, ip-atm@matmos.hpl.hp.com The ATM Forum is working on a native ATM API. FORE has been shipping one for over three years now. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com > The following is my humble opinion and maybe offensive to some. > ------------------------------------------------------------------------ > I have been following this mailing list for a while now, one thing I have noticed > is that most of the time is being spent on how to port IP over ATM as per the name > of the list. I am just curious if there is ANYONE out there who think about defining > a native ATM API which will be independent of IP/TCP over ATM bandwagon and will > actually take advantage of the strongholds of ATM technology like being connection > oriented and have the ability to do statistical multiplexing, otherwise maybe we > should have used PPP over SONET . > Please do understand I support and understand the IP over ATM effort but there > has to be a future goal for transmitting all sorts of traffic over ATM and > IP is not appropriate for that. > > Bora Akyol > Graduate Student > Stanford University   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11974; 16 Aug 94 17:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11970; 16 Aug 94 17:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16575; 16 Aug 94 17:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA018183768; Tue, 16 Aug 1994 12:02:48 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from glare.cisco.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA017853767; Tue, 16 Aug 1994 12:02:47 -0700 Received: (percyk@localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id MAA04118; Tue, 16 Aug 1994 12:02:36 -0700 Date: Tue, 16 Aug 1994 12:02:36 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Percy Khabardar Message-Id: <199408161902.MAA04118@glare.cisco.com> To: ddp@fore.com Cc: jmoy@alpo.casc.com, dino@cisco.com, ip-atm@matmos.hpl.hp.com In-Reply-To: Drew Perkins's message of Tue, 16 Aug 94 11:28:53 EDT <9408161528.AA19706@marlin> Subject: Multicasting over ATM draft > Now you are starting to design a more complicated protocol. It's beginning to > sound like EGP or something. There is a can of worms here that we already have > protocols to solve. Let's not invent another. TCP is good enough for BGP, it > is good enough for this. With relatively short-lived connections, I don't see > a problem with TCP overhead. Ok, TCP it is... - Percy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12492; 16 Aug 94 18:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12488; 16 Aug 94 18:40 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18052; 16 Aug 94 18:40 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA082350555; Tue, 16 Aug 1994 13:55:55 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA082020551; Tue, 16 Aug 1994 13:55:51 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id QAA29611; Tue, 16 Aug 1994 16:55:30 -0400 Message-Id: <199408162055.QAA29611@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Drew Perkins Cc: gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, jhalpern@newbridge.com, gja@thumper.bellcore.com Subject: Re: YAAM draft (Yet Another ATM Multicast draft :-) In-Reply-To: Your message of Tue, 16 Aug 94 15:03:17 -0400. <9408161903.AA21864@marlin> Date: Tue, 16 Aug 94 16:55:28 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [..VCC limitations in host adaptors...] >>I think this is one reason >>why LAN Emulation went with a central server (Keith, please comment). You have >>to use your VCCs very efficiently and limit your scope appropriately. I don't >>see that this proposal does either of these. Actually, efficient VCC had to be a non-goal of my proposal, given the decision to use a pt-mp mesh as the fundamental data distribution mechanism :) One actual goal is to generate a proposal that 'speaks the language' of _existing_ IPmc and ATMunicast models, perhaps to prompt or provide framework for implementation work. The VCC usage is potentially tolerable under these restrictions, given likely RFC1577 LIS membership levels (e.g. A Class C LIS has < 255 members). ATMmc operates within the LIS, IPmc between routers outside each LIS (as noted by Hiroshi Esaki). gja   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12589; 16 Aug 94 18:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12585; 16 Aug 94 18:46 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18190; 16 Aug 94 18:46 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA096021319; Tue, 16 Aug 1994 14:08:39 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from alpha.xerox.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA095601317; Tue, 16 Aug 1994 14:08:37 -0700 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14653(6)>; Tue, 16 Aug 1994 14:08:02 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 16 Aug 1994 14:07:40 -0700 To: Bora Aydin Akyol Cc: ip-atm@matmos.hpl.hp.com, deering@parc.xerox.com Subject: Re: Multicasting over ATM draft In-Reply-To: akyol's message of Tue, 16 Aug 94 11:45:29 -0800. <199408161845.LAA04814@tree.Stanford.EDU> Date: Tue, 16 Aug 1994 14:07:27 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Deering Message-Id: <94Aug16.140740pdt.12171@skylark.parc.xerox.com> > a native ATM API which will...actually take advantage of the strongholds of > ATM technology like being connection oriented and have the ability to do > statistical multiplexing, The connection-orientedness of ATM is one of its *weaknesses*, not its strengths; it's the main cause of all the difficulty in mapping IP multicast to ATM multicast. As Van Jacobson points out, a "connection" is too high-level an abstraction -- it severly constrains what services can be supported by an infrastructure. IP does statistical multicasting. The fact that ATM uses fixed-size packets does not give it any magical powers with respect to statistical multipluxing. > ...there has to be a future goal for transmitting all sorts of traffic over > ATM and IP is not appropriate for that. Why set such a modest goal? If instead we work to support all sorts of traffic over IP, we will end up with a multi-services internet that is not locked into a single subnetwork technology. > ...maybe we should have used PPP over SONET. No doubt about it. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01144; 17 Aug 94 6:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01140; 17 Aug 94 6:00 EDT Received: from [15.255.176.33] by CNRI.Reston.VA.US id aa02422; 17 Aug 94 6:00 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA224608669; Wed, 17 Aug 1994 00:31:09 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from yankees.haninge.trab.se ([131.115.49.156]) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA224278666; Wed, 17 Aug 1994 00:31:06 -0700 Received: from redsox.haninge.trab.se by yankees.haninge.trab.se (4.1/SMI-4.1) id AA07366; Wed, 17 Aug 94 09:30:39 +0200 Date: Wed, 17 Aug 94 09:30:39 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Kim.Laraqui" Message-Id: <9408170730.AA07366@yankees.haninge.trab.se> To: rajeev@trillium.com, sat@eng.tridom.com Subject: Re: AF-ALL: Re: Private ATM Addresses vs NSAP addresses Cc: af-all@atmforum.com, ip-atm@matmos.hpl.hp.com, comp.dcom.cell-relay@usenet.ucs.indiana.edu >> At this point, 8348/Ad2 is an obsolete specification. It has been >> replaced by 8348/Ad4, "Removal of the Preferred Decimal Encoding >> of the NSAP Address." I'm not sure whether 8348/Ad4 is IS or DIS >> status; perhaps someone who follows the standards process can shed >> more light. Maybe we should establish a "global" list of ITU, Internet and ISO standards in force, within the ATM Forum, that directly affect the design of various elements we're specifying? --------------------------------------------- Kim Laraqui Telia Research, High-Performance Networking Haninge, Sweden   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07256; 17 Aug 94 12:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07252; 17 Aug 94 12:02 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09513; 17 Aug 94 12:01 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA009274211; Wed, 17 Aug 1994 07:36:51 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA008934209; Wed, 17 Aug 1994 07:36:49 -0700 Received: from tree.Stanford.EDU by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA25899; Wed, 17 Aug 1994 07:36:51 -0700 Received: (from akyol@localhost) by tree.Stanford.EDU (8.6.8/8.6.6) id HAA00954; Wed, 17 Aug 1994 07:28:10 -0700 Date: Wed, 17 Aug 1994 07:28:10 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bora Aydin Akyol Message-Id: <199408171428.HAA00954@tree.Stanford.EDU> To: deering@parc.xerox.com Subject: Re: Multicasting over ATM draft Cc: ip-atm@matmos.hpl.hp.com X-Sun-Charset: US-ASCII > From: Steve Deering > > > a native ATM API which will...actually take advantage of the strongholds of > > ATM technology like being connection oriented and have the ability to do > > statistical multiplexing, > > The connection-orientedness of ATM is one of its *weaknesses*, not its > strengths; it's the main cause of all the difficulty in mapping IP > multicast to ATM multicast. As Van Jacobson points out, a "connection" > is too high-level an abstraction -- it severly constrains what services > can be supported by an infrastructure. ATM is connection-oriented to support real-time traffic like voice and video, as you might accept voice and video will probably not survive well for a cross country link if we used store-and-forward techniques, although Radio Free VAT usually sounds acceptable. > > IP does statistical multicasting. The fact that ATM uses fixed-size packets > does not give it any magical powers with respect to statistical multipluxing. ATM uses fixed size packets for fast packet switching, the statistical multiplexing in ATM can be used to provide a QoS guarantee, IP traffic on the other hand is always best effort, and the layers above IP are responsible for guaranteeing delivery. ( As far as I know ) > > ...there has to be a future goal for transmitting all sorts of traffic over > > ATM and IP is not appropriate for that. > > Why set such a modest goal? If instead we work to support all sorts of > traffic over IP, we will end up with a multi-services internet that > is not locked into a single subnetwork technology. Supposing that IP is extended to support all the services in the world, won't we still use ATM as the transport protocol, if not then what are we going to use ? > > > ...maybe we should have used PPP over SONET. > > No doubt about it. > > Steve > > Bora Akyol   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07391; 17 Aug 94 12:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07387; 17 Aug 94 12:11 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09679; 17 Aug 94 12:11 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA024505738; Wed, 17 Aug 1994 08:02:18 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms2.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA024175736; Wed, 17 Aug 1994 08:02:16 -0700 Received: from hplms26.hpl.hp.com by hplms2.hpl.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3+HPL1.1I) id AA11067; Wed, 17 Aug 1994 06:20:44 -0700 Received: from uu2.psi.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA25446; Wed, 17 Aug 1994 06:20:45 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA17745 for ip-atm@matmos.hpl.hp.com; Wed, 17 Aug 94 09:17:59 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id GAA03327; Wed, 17 Aug 1994 06:17:13 -0700 Message-Id: <199408171317.GAA03327@aland.bbn.com> To: Bora Aydin Akyol Cc: ip-atm@matmos.hpl.hp.com Subject: Re: Multicasting over ATM draft In-Reply-To: Your message of Tue, 16 Aug 94 11:45:29 -0700. <199408161845.LAA04814@tree.Stanford.EDU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Wed, 17 Aug 94 06:17:12 -0700 Hi Bora: Yes there's work on a generic API for ATM. Sockets work just fine except for a small question of supporting QoS (see ongoing discussions on the POSIX, INT-SERV and IPNG lists). Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09114; 17 Aug 94 13:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09110; 17 Aug 94 13:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11323; 17 Aug 94 13:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA059419584; Wed, 17 Aug 1994 09:06:24 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA059089581; Wed, 17 Aug 1994 09:06:21 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA25275 for ip-atm@matmos.hpl.hp.com; Wed, 17 Aug 94 12:06:04 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id JAA03672; Wed, 17 Aug 1994 09:05:20 -0700 Message-Id: <199408171605.JAA03672@aland.bbn.com> To: Bora Aydin Akyol Cc: deering@parc.xerox.com, ip-atm@matmos.hpl.hp.com Subject: Re: Multicasting over ATM draft In-Reply-To: Your message of Wed, 17 Aug 94 07:28:10 -0700. <199408171428.HAA00954@tree.Stanford.EDU> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Wed, 17 Aug 94 09:05:16 -0700 Supposing that IP is extended to support all the services in the world, won't we still use ATM as the transport protocol, if not then what are we going to use ? Leased lines work fine as do some shared media network. There's a wide misconception that ATM, by virtue of fixed cell sizes and other features has some advantage over packet protocols in terms of being able to provide performance guarantees. As several discussions on comp.dcom.cell-relay, ATM has no advantages in this regard as bandwidths increase to megabit speeds and faster. (ATM can do better on Kb/s links if one is careful). This is not to say ATM's fixed cell size may not have advantages in achieving higher speeds. Personally I don't think the fixed cell size has a big advantage but there's considerable disagreement on this question. Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11039; 17 Aug 94 14:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11035; 17 Aug 94 14:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13278; 17 Aug 94 14:54 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA042848642; Wed, 17 Aug 1994 08:50:42 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from chocorua.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA042518636; Wed, 17 Aug 1994 08:50:36 -0700 Received: from localhost (perez@localhost) by chocorua.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id LAA06234 for ; Wed, 17 Aug 1994 11:50:31 -0400 Message-Id: <199408171550.LAA06234@chocorua.cmf.nrl.navy.mil> X-Authentication-Warning: chocorua.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ip-atm@matmos.hpl.hp.com Subject: draft-ietf-ipatm-sig-02.txt Date: Wed, 17 Aug 94 11:50:30 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Maryann Perez Maher Folks, Sorry for the delay in putting out this new version of the draft. Below is a summary of the main changes that were made as a result of people's comments. General: 0) Incorporated format changes suggested by Mark and Craig. 1) Mark suggested that "it be made very clear that this is an RFC1577 (and RFC1483) inplementaton reference". Some introductory text was added (contributed by Grenville) to make this point clearer and also to clarify the relationship between 1577 and signaling. 2) All references to Frame Relay interworking were moved to Appendix B. All references to UNI 3.1 were removed and a note made in the "Open Issues" section. References to other I-Ds were removed. Specific: 0) Text giving hints about the use of the CALL PROCEEDING message was added in Appendix A (Grenville's text). 1) RECOMMENDED 20 minutes as the idle VC timer. 2) A note about "what if the the network does not support Best Effort service" was added to Section 8.1. 3) Text about use of the Selector field in ATM addresses was added in Section 8.4 (Craig's concern) Please pay close attention to the new text and send us comments. thanks, Maryann -------------------------------------------------------------------- IP over ATM WG M. Perez, F. Liaw, D. Grossman, Internet-Draft A. Mankin, E. Hoffman, A. Malis Expires February 14, 1994 August 14, 1994 ATM Signaling Support for IP over ATM Status of this Memo This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts MAY be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC 1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI) Specifica- tion Version 3.0 [ATMF93]. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling enti- ties. This document is an implementors guide intended to foster interopera- bility among RFC 1577, RFC 1483, and UNI ATM signaling. It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNI Specification Version 3.0. Unless explicitly stated, no distinction is made between the Private and Public UNI. Perez et al. [Page 1] DRAFT ATM Signaling Support for IP over ATM August 1994 Note: An erratum to the UNI 3.0 specification has been produced by the ATM Forum, largely for reasons of alignment with Recommendation Q.2931. This memo does not assume the changes to the specification indicated in the erratum (see Open Issues). 2. Conventions The following language conventions are used in the items of specifi- cation in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item SHOULD generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and MAY be followed or ignored according to the needs of the implementor. 3. Overview In a Switched Virtual Connection (SVC) environment, ATM virtual chan- nel connections (VCCs) are dynamically established and released as needed. This is accomplished using the ATM call/connection control signaling protocol, which operates between ATM endsystems and the ATM network. The signaling entities use the signaling protocol to estab- lish and release calls (association between ATM endpoints) and con- nections (VCCs). Signaling procedures include the use of addressing to locate ATM endpoints and allocation of resource in the network for the connection. It also provides indication and negotiation between ATM endpoints for selection of end-to-end protocols and their parame- ters. This memo describes how the signaling protocol is used in sup- port of IP over ATM, and, in particular, the information exchanged in the signaling protocol to effect this support. IP address to ATM address resolution and routing issues are not in the scope of this I-D, and are treated as part of IP in figure 1. Perez et al. [Page 2] DRAFT ATM Signaling Support for IP over ATM August 1994 +--------------+ +------+ +----------+ | | | |<--->| IP / ARP | | |<--->| This | | RFC 1577 | | ATM | | I-D | +----------+ | signaling | | |<--->| RFC 1483 | | | +------+ +----------+ | | -------------> | AAL 5 | | | +----------+ | | -------------> | ATM | +--------------+ +----------+ Figure 1. Relationship of this I-D to IP, RFC 1483, ATM signaling, ATM and AAL5 4. Use of Protocol Procedures The following requirements are motivated to provide implementation guidelines on how multiple ATM connections between peer systems SHOULD be managed, to prevent connection thrashing and related prob- lems. 4.1. VC Establishment The owner of an existing VCC is defined to be the entity within the ATM endsystem that establishes the connection. An ATM endsystem MAY establish an ATM call when it has a datagram to send and either there is no existing VCC that it can use for this purpose, it chooses not to use an existing VCC, (e.g., for reasons of route optimization or quality of service), or the VCC owner does not allow sharing. 4.2. Multiprotocol Support on VCs When two ATM endsystems run multiple protocols, an ATM connection MAY be shared among two or more datagram protocol entities, as long as the VCC owner allows sharing, as well as if the encapsulation allows proper multiplexing and demultiplexing (i.e. the LLC/SNAP encapsula- tion). This indication of sharing a VCC MAY be by configuration or via an API. Similarly, the Internet layer supports multiplexing of multiple end-to-end transport session. To properly detect idle con- nections while sharing a VCC among more than one higher layer proto- col entities, the ATM endsystem SHALL monitor the traffic at the lowest multiplexing layer. Perez et al. [Page 3] DRAFT ATM Signaling Support for IP over ATM August 1994 4.3. Support for Multiple VCs An ATMARP server or client MAY establish an ATM call when it has a datagram to send and either there is no existing VCC that it can use for this purpose, it chooses not to use an existing VCC, or the owner of the VCC does not allow sharing. Note that there might be VCCs to the destination which are used for IP, but an ARP server might prefer to use a separate VCC for ARP only. The ATMARP server or client MAY maintain or release the call as specified in RFC1577. How- ever, if the VCC is shared among several protocol entities, the ATMARP client or server SHALL not disconnect the call as suggested in RFC1577. Systems MUST be able to support multiple connections between peer systems (without regard to which peer system initiated each connec- tion). They MAY be configured to only allow one such connection at a time. If a receiver accepts more than one call from a single source, that receiver MUST then accept incoming PDUs on the additional connection(s), and MAY transmit on the additional connections. Receivers SHOULD NOT accept the incoming call, only to close the con- nection or ignore PDUs from the connection. Because opening multiple connections is specifically allowed, algo- rithms to prevent connection call collision, such as the one found in section 8.4.3.5 of ISO/IEC 8473 [ISO8473], MUST NOT be implemented. While allowing multiple connections is specifically desired and allowed, implementations MAY choose (by configuration) to permit only a single connection to some destinations. Only in such a case, if a colliding incoming call is received while a call request is pending, the incoming call SHALL be rejected. Note that this MAY result in a failure to establish a connection. In such a case, each system MUST wait at least a configurable collision retry time in the range 1 to 10 seconds before retrying. Systems MUST add a random increment, with exponential backoff. 4.4. VC Teardown Either endsystem MAY close a connection. If the connection is closed or reset while a datagram is being transmitted, the datagram is lost. Systems SHOULD be able to configure a minimum holding time for con- nections to remain open as long as the endpoints are up. (Note that holding time, the time the connection has been open, differs from idle time.) A suggested default value for the minimum holding time is 60 seconds. Perez et al. [Page 4] DRAFT ATM Signaling Support for IP over ATM August 1994 Because some public networks MAY charge for connection holding time, and connections MAY be a scarce resource in some networks or endsys- tems, each system implementing a Public ATM UNI interface MUST sup- port the use of a configurable inactivity timer to clear connections that are idle for some period of time. The timer's range SHOULD include a range from a small number of minutes to "infinite". A default value of 20 minutes is RECOMMENDED. Systems which only imple- ment a Private ATM UNI interface SHOULD support the inactivity timer. If implemented, the inactivity timer SHALL monitor traffic of both receiving and transmitting activities. 5. Brief Overview of UNI Call Setup Signaling Procedures and Mes- sages This section provides a summary of point-to-point signaling pro- cedures. Readers are referred to [ATMF93]. UNI signaling messages used for point-to-point call/connection con- trol are the following: Call Setup Call Release ---------- ------------ SETUP RELEASE CALL PROCEEDING RELEASE COMPLETE CONNECT CONNECT ACKNOWLEDGE An ATM endpoint initiates a call request by sending a SETUP message to the network. The network processes the call request to determine if the call can be progressed. If so, the network indicates the value of the newly allocated VPCI/VCI in its first response to the the SETUP message, which is either a CALL PROCEEDING or CONNECT message. If a call cannot be accepted, by the network or destination ATM end- point, a RELEASE COMPLETE is sent. At the destination ATM endpoint, the network offers the call using the SETUP message. If the destina- tion endpoint is able to accept the call, it responds with a CONNECT message (which may be preceded by a CALL PROCEEDING); otherwise, it sends a RELEASE COMPLETE message. See Appendix A, Section 2 for gui- dance on the use of the CALL PROCEEDING message. Call release can be initiated by either endpoint or (rarely) by the network. When an endpoint wishes to release a call, it sends a RELEASE message to the network. The network responds with a RELEASE COMPLETE message, frees up resources associated with the call, and initiates clearing toward the other endpoint. The network initiates Perez et al. [Page 5] DRAFT ATM Signaling Support for IP over ATM August 1994 clearing by sending a RELEASE message to the ATM endpoint, which reponds by sending a RELEASE COMPLETE message. Upon receipt of the RELEASE COMPLETE message, the network frees any resources associated with the call. 6. Overview of Call Establishment Message Content Signaling messages are structured to contain mandatory and optional variable length information elements (IEs). IEs are further subdi- vided into octet groups, which in turn are divided into fields. IEs contain information related to the call, which is relevant to the network, the peer endpoint or both. Selection of optional IEs and the content of mandatory and optional IEs in a call establishment message determines the parties to and nature of the communication over the ATM connection. For example, the call establishment message for a call which will be used for constant bitrate video over AAL 1 will have different contents than a call which will be used for IP over AAL 5. A SETUP message which establishes an ATM connection to be used for IP and multiprotocol interconnection calls SHALL contain the following IE: AAL Parameters ATM User Cell Rate Broadband Bearer Capability Broadband Low Layer Information QoS Parameter Called Party Number Calling Party Number and MAY, under certain circumstance contain the following IEs : Calling Party Subaddress Called Party Subaddress Transit Network Selection In UNI 3.0 the AAL Parameters and the Broadband Low Layer Information IEs are optional in a SETUP message. However, in support of IP over ATM these two IEs MUST be included. Appendix A shows an example SETUP message coded in the manner indicated in this draft. 7. Information Elements with Endpoint to Endpoint Significance This section describes the coding of, and procedures surrounding, Perez et al. [Page 6] DRAFT ATM Signaling Support for IP over ATM August 1994 information elements in a SETUP message with significance only to the endpoints of an ATM call supporting IP. 7.1. ATM Adaption Layer Parameters The AAL Parameters IE (see section 5.4.5.5 and Annex F of [ATMF93]) carries information about the ATM Adaption Layer (AAL) to be used on the connection. RFC 1483 specifies encapsulation of IP over AAL 5. Thus, AAL 5 MUST be indicated in the "AAL type" field. Coding and procedure related to the 'Forward and Backward Maximum CPCS-SDU Size' fields are discussed in [ATKI94]. The 'mode' field SHOULD be omitted from the AAL Parameters IE and MUST be ignored by the destination endsystem. Ordinarily, no Service Specific Convergence Sublayer (SSCS) will be used for multiprotocol interconnect over AAL5. Therefore, the SSCS 'type' field SHOULD be absent or, if present, coded to Null SSCS. Format and field values of AAL Parameters IE ---------------------------------------------------------- | aal_parameters | ---------------------------------------------------------- | aal_type 5 (AAL 5) | | fwd_max_sdu_size_identifier 140 | | fwd_max_sdu_size 9188 (default IP MTU) | | bkw_max_sdu_size_identifier 129 | | bkw_max_sdu_size 9188 (default IP MTU) | | sscs_type identifier 132 | | sscs_type 0 (null SSCS) | ---------------------------------------------------------- 7.2. Broadband Low Layer Information Selection of an encapsulation to support IP over an ATM VCC is done using the Broadband Low Layer Information (B-LLI) IE, along with the AAL Parameters IE, and the B-LLI negotiation procedure. RFC 1577 specifies LLC/SNAP as the default encapsulation. Therefore LLC encapsulation MUST be indicated in the B-LLI as shown in figure D.3.1 of [ATMF93]. Signaling indication of other encapsulations, Perez et al. [Page 7] DRAFT ATM Signaling Support for IP over ATM August 1994 while not part of this implementation reference, are discussed in Appendix D, Section 4. Note that in this case only LLC is indicated in the B-LLI. It is up to the LLC layer to look into the encapsula- tion header of the packet. If the SNAP header indicates IP, it is the LLC layer's job to hand the packet up to IP. Format of B-LLI IE indicating LLC/SNAP encapsulation ---------------------------------------------------------- | bb_low_layer_information | ---------------------------------------------------------- | layer_2_id 2 | | user_information_layer 12 (lan_llc - ISO 8802/2) | ---------------------------------------------------------- 7.2.1. Framework for Protocol Layering The support of connectionless services from a connection oriented link layer exposes general problems of connection management, specif- ically the problems of connection acceptance, assignment of quality of service, and connection shutdown. For a connection to be associ- ated with the correct protocol on the called host, it is necessary for information about one or more layers of protocol identification to be associated with a connection "management entity" or "endpoint". This association is what we call a binding in this draft. In this section we attempt to describe a framework for a usable binding or service architecture given the available IEs in the ATM call control messages. It is important to distinguish between two basic uses of protocol identification elements present in the UNI setup message. The first is the description of the protocol encapsulation that will be used on the data packet over the virtual connection, the second is the entity that will be responsible for managing the call. All protocols present in various IEs SHOULD be used to encapsulate the call, but the most specific, or highest, layer specified SHOULD manage the call. This defines a hierarchy of services and provides a framework for applica- tions, including LLC and IP, to terminate calls. The hierarchy pro- vides a clear mechanism for support of higher level protocol and application bindings, when their use and specification is defined in the appropriate standards bodies. The B-LLI is the only information element currently available in UNI 3.0 for designating the application endpoint. It contains codepoints, which describe layer 2 and layer 3 protocols entities associated with Perez et al. [Page 8] DRAFT ATM Signaling Support for IP over ATM August 1994 the call. There are other information elements under consideration in the ATM Forum and ITU, which could come to play a significant role in the description of application to connection binding, but their use is not currently sanctioned by the Forum, and they are not part of the framework described by RFC1577. They include B-HLI, for contain- ing information for a higher layer protocol, Network Layer Informa- tion (NLI) to contain information for the network layer, and UUI, which is meant to carry information for use by the top level applica- tion. In general, it would be desirable to allow data packets to be stored directly into applications address space after connection is esta- blished. This is possible only if we have both forward and backward encapsulation indication in the signaling message. To support multiprotocol encapsulation, the LLC protocol management entity SHOULD accept all connections directed specifically to it. For each connection that is terminated at LLC, all protocols that are intended to be supported by this host through that interface SHOULD be made available. Termination of the call is at the discretion of the LLC connection management entity, based on the information it has available to it, specifically the perceived packet traffic and admin- istrative policies of the host. VC-multiplexed IP is specified by using only the layer 3 identifier in B-LLI using an ISO-TR-9577 protocol codepoint. Since no layer 2 is specified, frames produced by AAL processing will be given directly to IP. Since IP is highest specified protocol, it will be responsible for managing the connection. 8. Information Elements with Significance to the ATM Network This section describes the coding of, and procedures surrounding, information elements with significance to the ATM network, as well as the endpoints of an ATM call supporting multiprotocol operation. The standards, implementation agreements, research and experience surrounding such issues as traffic management, quality of service and bearer service description are still evolving. Much of this material is cast so as to give the greatest possible latitude to ATM network implementation and service offerings. ATM endsystems need to match the traffic contract and bearer service they request from the network to the capabilities offered by the network. Therefore, this memo can only offer what, at the present time, are the most appropriate and efficient coding rules to follow for setting up IP and ATMARP VCCs. Perez et al. [Page 9] DRAFT ATM Signaling Support for IP over ATM August 1994 8.1. ATM User Cell Rate The ATM Traffic descriptor is contained in the ATM User Cell Rate IE (called ATM Traffic Descriptor in UNI 3.1 erratum). It characterizes the ATM virtual connection in terms of peak cell rate (PCR), sustain- able cell rate (SCR), and maximum burst size. This information is used to allocate resources (e.g., bandwidth, buffering) in the net- work. In general, the ATM traffic descriptor for supporting mul- tiprotocol interconnection over ATM will be driven by factors such as the capacity of the network, conformance definition supported by the network, performance of the ATM endsystem and (for public networks) cost of services. The most convenient model of IP behavior corresponds to the Best Effort Capability (see section 3.6.2.4 of [ATMF93]). If this capabil- ity is offered by the ATM network(s), it SHOULD be requested by including the Best Effort Indicator, the peak cell rate forward (CLP=0+1) and peak cell rate backward (CLP=0+1) fields in the ATM User Cell Rate IE. Format and field values of ATM User Cell Rate IE ---------------------------------------------------------- | user_cell_rate | ---------------------------------------------------------- | fwd_peak_cell_rate_0+1_identifier 132 | | fwd_peak_cell_rate_0+1 (link rate) | | bkw_peak_cell_rate_0+1_identifier 133 | | bkw_peak_cell_rate_0+1 (link rate) | | best_effort_indication 190 | ---------------------------------------------------------- [ATMF93] does not provide any capability for negotiation of the ATM User Cell Rate. This means that: a) the calling endsystem SHOULD have a "pretty good idea" as to the traffic contract that will be acceptable to both the called endsystem and the network. b) if, in response to a SETUP message, a calling endsystem receive a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #51, User cell rate unavail- able, it MAY examine the diagnostic field of the Cause IE and reat- tempt the call after selecting smaller values for the parameter(s) indicated. If the RELEASE COMPLETE or RELEASE message is received with cause #73, Unsupported combination of traffic parameter, it MAY try other combinations from table 5-7 and 5-8 of [ATMF93]. Perez et al. [Page 10] DRAFT ATM Signaling Support for IP over ATM August 1994 c) the called endsystem SHOULD examine the ATM traffic descriptor IE in the SETUP message. If it is unable to process cells at the Forward PCR indicated, it SHOULD clear the call cause #51, User cell rate unavailable. If the network does not support Best Effort service, link rate SHOULD not be requested as the peak cell rate. Without any knowledge of the application, is is RECOMMENDED that to 2 Mbps be requested at the Private UNI and 64 Kbps at the Public UNI. 8.2. Broadband Bearer Capability Broadband Bearer Connection Oriented Service Type X (BCOB-X) or Type C (BCOB-C) are applicable for multiprotocol interconnection, depend- ing on the service(s) provided by the ATM network and the capabili- ties (e.g. for traffic shaping) of the ATM endsystem. The example coding of Broadband Bearer Capability in figure D.2.1 of [ATMF93] applies for BCOB-C. When BCOB-X is specified, the 'traffic type' and 'timing requirements' fields SHOULD both be set to "no indication". The 'susceptibility to clipping' and 'user plane traffic configura- tion' fields SHOULD be set to "not susceptible to clipping" and "point-to-point", respectively. Format and field values of Broadband Bearer Capability IE ---------------------------------------------------------- | bb_bearer_capability | ---------------------------------------------------------- | spare 0 | | bearer_class 16 (BCOC-X) | | spare 0 | | traffic_type 0 (no indication) | | timing_reqs 0 (no indication) | | susceptibility_to_clipping 0 (not suscept) | | spare 0 | | user_plane_configuration 0 (point_to_point) | ---------------------------------------------------------- [ATMF93] does not provide any capability for negotiation of the broadband bearer capability. This means that: a) the calling endsystem SHOULD have a "pretty good idea" as to the broadband bearer capability that will be acceptable to both the called endsystem and the network. b) if, in response to a SETUP message, a calling endsystem receives Perez et al. [Page 11] DRAFT ATM Signaling Support for IP over ATM August 1994 a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #57, bearer capability not authorized or #58 bearer capability not presently available, it MAY reattempt the call after selecting another bearer capability. 8.3. QoS Parameter The Unspecified QoS class (Class 0), the Specified QoS Class for Con- nection Oriented Data Transfer (Class 3) or the Specified QoS Class for Connectionless Data Transfer (Class 4) MAY be applicable to mul- tiprotocol over ATM. The available combination of QoS parameters with the ATM User Cell Rate and the Broadband Bearer Capability is specific to the ATM network. Format and field values of QoS Parameters IE ---------------------------------------------------------- | qos_parameter | ---------------------------------------------------------- | qos_class_fwd 0 (class 0) | | qos_class_bkw 0 (class 0) | ---------------------------------------------------------- [ATMF93] does not provide any capability for negotiation of Quality of Service parameters. This means that: a) the calling endsystem SHOULD have a "pretty good idea" as to the QoS classes offered by the ATM network in conjunction with the requested Broadband Bearer Service and traffic descriptor. b) if, in response to a SETUP message, a calling endsystem receives a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #49, Quality of Service una- vailable, it MAY reattempt the call after selecting another QoS class. 8.4. ATM Addressing Information ATM addressing information is carried in the Called Party Number, Calling Party Number, and, under certain circumstance, Called Party Subaddress, and Calling Party Subaddress IE. Section 5.1.3 and Annex A of [ATMF93] describes the syntax and semantics of ATM addressing information, including use of the subaddress IE. Section 5.8 of [ATMF93] provides the procedure for an ATM endsystem to learn its own Perez et al. [Page 12] DRAFT ATM Signaling Support for IP over ATM August 1994 ATM address from the ATM network, for use in populating the Calling Party Number IE. RFC 1577 RECOMMENDS that a router be able to provide multiple LIS support with a single physical ATM interface that may have one or more individual ATM endpoint addresses. Use of the Selector field in the NSAPAs and E.164 addresses (in the NSAP format) is identified as a way to differentiate up to 256 different LISs for the same ESI. Therefore, an IP router MAY associate the IP addresses of the various LISs it supports with distinct ATM addresses differentiated only by the SEL field. If an IP router does this association, then its sig- naling entity must carry in the SETUP message the ATM addresses corresponding to the particular IP entity requesting the call, and the IP entity it is requesting a call to. These ATM addresses are carried in the Calling and Called Party Number IEs respectively. Native E.164 addresses do not support a SEL field. For IP routers residing in a Public UNI where native E.164 addresses are used it is RECOMMENDED that multiple E.164 addresses be used to support multiple LISs. Note: multiple LIS support is the only recommended use of the SEL field. Use of this field is not recommended for selection of higher level applications. Resolution of IP addressed to ATM addresses is required of hosts and routers which are ATM endsystems that use ATM SVCs. RFC 1577 provides a mechanism for doing IP to ATM address resolution in the classical IP model. Format and field values of Called and Calling Party Number IE ---------------------------------------------------------- | called_party_number | ---------------------------------------------------------- | type_of_number (international number / unknown) | | addr_plan_ident (ISDN / ISO NSAPA) | | number (E.164 / OSI NSAPA) | ---------------------------------------------------------- ---------------------------------------------------------- | calling_party_number | ---------------------------------------------------------- | type_of_number (international number / unknown) | | addr_plan_ident (ISDN / ISO NSAPA) | | presentation_indic (presentation allowed) | | spare 0 | | screening_indic (user provided verified & passed) | | number (E.164 / OSI NSAPA) | ---------------------------------------------------------- Perez et al. [Page 13] DRAFT ATM Signaling Support for IP over ATM August 1994 9. Dealing with Failure of Call Establishment If an ATM call attempt fails with any of the following cause, the situation SHALL be treated as "network unreachable" (if the called ATM endsystem is a router) or "host unreachable" (if the called ATM endsystem is a host). # 1 unallocated (unassigned) number # 3 no route to destination # 17 user busy # 18 no user reponding # 27 destination out of order # 38 network out of order # 41 temporary failure # 47 resource unavailable, unspecified If an ATM call attempt fails with any of the following causes, the ATM endpoint MAY retry the call, changing (or adding) the IE(s) indi- cated by the cause code and diagnostic. # 2 no route to specified transit network # 21 call rejected # 22 number changed # 23 user rejects call with CLIR # 49 quality of service unavailable # 51 user cell rate unavailable # 57 bearer capability not authorized # 58 bearer capability not presently available # 65 bearer capability not implemented # 73 unsupported combination of traffic parameter # 88 incompatible destination # 91 invalid transmit network selection # 93 AAL parameter cannot be supported Any cause in the protocol error class (value 96 to 111) where the location is either private network serving the local user or public network serving the local user 10. Security Consideration Security consideration are not addressed in this memo. 11. Open Issues o This document version is specifically an RFC 1577/RFC 1483 imple- mentation document. Although RFC 1577 and RFC 1483 specify an Perez et al. [Page 14] DRAFT ATM Signaling Support for IP over ATM August 1994 LLC/SNAP encapsulation, which is inherently a multiprotocol encapsulation, it is beyond to scope of this document to go into any multiprotocol specifications other than to point out some examples (see Appendix B for an example of NLPID encapsulation). Furthermore, at the time of the writing of this draft, the ATM Forum is creating a Multiprotocol over ATM activity which we expect to be developed jointly with the IETF. o The erratum will be published as the UNI 3.1 Specification in the fall of 1994. Once UNI 3.1 is publicly available, this document will be updated to reflect the changes. 12. Acknowledgments The authors wish to thank the work of their colleagues who attend the IP over ATM working group; the ATM Forum Technical Committee; the ATM Signaling Subworking Group in ANSI-Accredited Technical Subcom- mittee T1S1; the ATM Access Signaling experts in ITU-T (formerly CCITT) Study Group 11. Rao Cherukuri (IBM) and Jeff Kiel (formerly with Bellcore, presently with BellSouth) were particularly valuable in coordinating among T1S1, ITU-T and the ATM Forum to make sure that the needs of multiprotocol over ATM could be expressed in the ATM signaling protocol. REFERENCES [ATKI94] Atkinson, R., "RFC 1626: IP MTU over ATM AAL5", Naval Research Laboratory, May 94 [ATMF93] ATM Forum, "ATM User-Network Interface Specification Version 3.0", [ATMF93] ATM Forum, "ATM User-Network Interface Specifica- tion Version 3.0", (Englewood Cliffs, NJ: Prentice Hall, 1993) [HEIN93] Heinanen, J., "Multiprotocol Encapsulation over ATM Adapta- tion Layer 5", RFC 1483, USC/Information Science Institute, July 1993. [ISO8473] ISO/IEC 8473, Information processing systems - Data commun- ications - Protocol for providing the connectionless-mode network service, 1988. [ISO9577] Information Technology - Telecommunication and information exchange between systems - Protocol identification in the network layer ISO/IEC TR9577 (International Standards Organization: Geneva, 1990) Perez et al. [Page 15] DRAFT ATM Signaling Support for IP over ATM August 1994 [LAUB93] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-Packard Laboratories, December 1993 [Q.2931] Broadband Integrated Service Digital Network (B-ISDN) Digi- tal Subscriber Signaling System No.2 (DSS2) User Network Inter- face Layer 3 Specification for Basic Call/Connection Control ITU-T Recommendation Q.2931, (International Telecommunication Union: Geneva, 1994) Authors' Addresses Maryann Perez Maher Phone: 202-404-7029 Kaman Sciences Corp. at NRL Email: perez@cmf.nrl.navy.mil Eric Hoffman Phone: 202-404-7019 Kaman Sciences Corp. at NRL Email: hoffman@cmf.nrl.navy.mil Allison Mankin Phone: 202-404-7030 Kaman Sciences Corp. at NRL Email: mankin@cmf.nrl.navy.mil Naval Research Lab 4555 Overlook Ave Building 35 Washinton D.C. 20375 Fong-Ching Liaw Phone: (412) 772-8668 FORE Systems, Inc. Email: fong@fore.com 174 Thorn Hill Road Warrendale, PA 15086-7535 Dan Grossman Phone: 617-821-7333 Motorola Codex Email: dan@merlin.dev.cdx.mot.com Andrew G. Malis Phone: (508) 266-4522 Ascom Timeplex, Inc. Email: malis@maelstrom.timeplex.com Advanced Products Business Unit 289 Great Road Suite 205 Acton, MA 01720 Perez et al. [Page 16] DRAFT ATM Signaling Support for IP over ATM August 1994 Appendix A. Sample Signaling Messages 1. SETUP and CONNECT messages This annex shows sample codings of the SETUP and CONNECT signaling messages. The fields in the IE header are not shown. +--------------------------------------------------------------------+ SETUP Information Elements/ Fields Value/(Meaning) -------------------- --------------- aal_parameters aal_type 5 (AAL 5) fwd_max_sdu_size_ident 140 fwd_max_sdu_size 9188 (default, send IP MTU value) bkw_max_sdu_size_ident 129 bkw_max_sdu_size 9188 (default, recv IP MTU value) mode identifier 131 * mode message * sscs_type identifier 132 sscs_type 0 (null SSCS) user_cell_rate fwd_peak_cell_rate_0_1_ident 132 fwd_peak_cell_rate_0_1 (link rate) bkw_peak_cell_rate_0_1_ident 133 bkw_peak_cell_rate_0_1 (link rate) best_effort_indication 190 bb_bearer_capability spare 0 bearer_class 16 (BCOC-X) spare 0 traffic_type 0 (no indication) timing_reqs 0 (no indication) susceptibility_to_clipping 0 (not susceptible to clipping) spare 0 user_plane_configuration 0 (point_to_point) bb_low_layer_information layer_2_id 2 user_information_layer 12 (lan_llc (ISO 8802/2) qos_parameter qos_class_fwd 0 (class 0) Perez et al. [Page 17] DRAFT ATM Signaling Support for IP over ATM August 1994 qos_class_bkw 0 (class 0) called_party_number type_of_number (international number / unknown) addr_plan_ident (ISDN / ISO NSAPA) number (E.164 / OSI NSAPA) calling_party_number type_of_number (international number / unknown) addr_plan_ident (ISDN / ISO NSAPA) presentation_indic (presentation allowed) spare 0 screening_indic (user_provided verified and passed) number (E.164 / OSI NSAPA) +--------------------------------------------------------------------+ Figure 1. Sample contents of SETUP message [* : optional, ignored if present] In IP over ATM environments the inclusion of the "AAL parameters" IE is *mandatory* to allow for MTU size negotiation between the source and destination. The "Broadband Low Layer Information" IE is also mandatory for specifying the IP encapsualtion scheme. Perez et al. [Page 18] DRAFT ATM Signaling Support for IP over ATM August 1994 +--------------------------------------------------------------------+ CONNECT Information Elements/ Fields Value -------------------- ----- aal_parameters aal_type 5 (AAL 5) fwd_max_sdu_size_ident 140 fwd_max_sdu_size 9188 (default, send IP MTU value) bkw_max_sdu_size_ident 129 bkw_max_sdu_size 9188 (default, recv IP MTU value) mode identifier 131 * mode message * sscs_type identifier 132 bb_low_layer_information layer_2_id 2 user_information_layer 12 (lan_llc (ISO 8802/2) connection identifier spare 0 vp_assoc_signaling 1 (explicit indication of VPCI) preferred_exclusive 0 (exclusive vpci/vci) vpci (assigned by network) vci (assigned by network) +--------------------------------------------------------------------+ Figure 2. Sample contents of CONNECT message As in the SETUP message, IP over ATM environments demand the inclu- sion of the "AAL parameters" IE so that the destination may specify the MTU size that it is willing to receive. 2. Hints on Use of CALL PROCEEDING Message Use of the CALL PROCEEDING message is beneficial in implementations where the called party's ATM signaling entity and AAL Users are decoupled. An arriving SETUP may result in an immediate CALL PROCEED- ING response from the called party's ATM signaling entity, while it locally queries the called IP-ATM entity to see if the SETUP's condi- tions are acceptable. The acceptance of the SETUP's conditions would then cause the ATM signaling entity to issue a CONNECT back to the switch. The two possible refusal modes at the called party then become: a) Called party has no IP-ATM entity resident. Issue RELEASE Perez et al. [Page 19] DRAFT ATM Signaling Support for IP over ATM August 1994 COMPLETE in response to SETUP. b) Called party has a resident IP-ATM entity, so CALL PROCEEDING was issued. The IP-ATM entity rejects the call request, so a RELEASE is issued instead (to be acknowledged by the network with RELEASE COMPLETE). Perez et al. [Page 20] DRAFT ATM Signaling Support for IP over ATM August 1994 Appendix B. Frame Relay Interworking 1. RFC 1490 over FR-SSCS vs. RFC 1483 over null-SSCS Procedures for Frame Relay to ATM signaling interworking have not yet been specified by ITU-T, the ATM Forum, or the Frame Relay Forum. If an ATM endsystem wishes to use FR-SSCS, FR-SSCS and RFC 1490 encapsu- lation must both be be specified in the SETUP message. Nevertheless, since neither LLC encapsulation nor VC-multiplexing will interoperate when used over FR-SSCS, these two encapsulations cannot be negotiated as alternatives to RFC 1490 encapsulation (see Section 4, Encapsula- tion Negotiation). In ATM environments the SSCS layer is part of the AAL functionality. The SSCS serves to coordinate the needs of a protocol above with the requirements of next lower layer, the Common Part Convergence Sub- layer (CPCS). For example, the UNI ATM signaling protocol runs on top of a signaling SSCS which among other things provides an assured transfer service for signaling messages. Since the SSCS is considered part of the AAL, the SSCS type is specified as one of the parameters in the AAL Parameters IE. To date there has not been an SSCS defined for data transmission in ATM and this type field is usually set to 'null'. The exception occurs when doing FR interworking where an ATM endsys- tem may choose to use the FR-SSCS over AAL 5 in order to communicate with a FR endsystem. In that case the SSCS type in the AAL Parame- ters IE of the SETUP message is set to 'FR-SSCS'. Also included in a SETUP message is an indication in the B-LLI IE of the protocol layers to be used above the AAL. In particular, ATM con- nections established to carry connectionless network interconnect traffic require a layer above the AAL for multiplexing multiple pro- tocols over a single VC [HEIN 93]. As mentioned above, RFC 1577 defines LLC as default multiplexing layer for IP over AAL5. Specification of the SSCS restricts the encapsulation protocol used over it, since RFC 1483 (in addition to applicable ITU standards) defines the use of RFC 1490 encapsulation over the FR-SSCS, and LLC or null encapsulation otherwise. The fact that it is not possible, in the UNI 3.0 signaling specification, to negotiate between the FR- SSCS and null-SSCS can result in interoperability restrictions between stations that implement and wish to use the FR-SSCS and those that do not, even though they both are using IP. The guidelines in the following section were developed to decrease the chance that such interoperability restrictions occur. 2. Scenarios for Interworking Perez et al. [Page 21] DRAFT ATM Signaling Support for IP over ATM August 1994 The following discussion uses the terms "network interworking" and "service interworking". "Network interworking" uses FR-SSCS over AAL5 between the InterWorking Unit (IWU) and the ATM endsystem, and the ATM endsystem is aware that the other endpoint is a FR/ATM Net- work IWU. "Service interworking" aims to make the operation tran- sparent to the ATM endsystem by adding encapsulation translation and other payload processing in the FR/ATM Service IWU to allow the ATM endsystem to operate as if it were talking to another ATM endsystem. The most common scenario where FR-SSCS could be negotiated is between an ATM endsystem and a FR/ATM network IWU to allow connectivity among an ATM endsystem and a FR endsystem residing behind a FR/ATM network IWU. -------- -------- ------- | | | | ------- | A | | FR/ATM | | ATM | | B | | (FR) |----->| IWU |----->| switch |----->| (ATM) | ------- | | | | ------- -------- -------- | | | | -----> ---------------------> FR call ATM call A network IWU can place a call to an ATM host (on behalf of a FR host) by signaling for FR-SSCS and assuming that the ATM endsystem supports FR-SSCS. The B-LLI IE SHALL be encoded to indicate RFC 1490 encapsulation and the SSCS type field of the AAL Parameters IE SHALL be coded to indicate FR-SSCS. If the FR-SSCS negotiation fails because the called ATM host does not support FR-SSCS, the IWU can retry the call negotiating for LLC encapsulation or VC-multiplexing. However, the IWU can only attempt the retry if it is able to do FR- ATM service interworking. Such service interworking adds extra pro- cessing overhead during the call. The even more problematic case occurs when a call is requested in the opposite direction, i.e. when an ATM host places a call to a host residing behind an IWU. -------- -------- ------- | | | | ------- | B | | FR/ATM | | ATM | | A | | (FR) |<-----| IWU |<-----| switch |<-----| (ATM) | ------- | | | | ------- -------- -------- Perez et al. [Page 22] DRAFT ATM Signaling Support for IP over ATM August 1994 | | | | <----- <--------------------- FR call ATM call Not knowing that the destination resides behind an IWU, the calling host will negotiate for the default LLC encapsulation (possibly requesting VC-multiplexing as an alternative). In this situation the IWU can accept the call and do the necessary service interworking or reject the call specifying 'AAL Parameters not supported'. If the IWU rejects the call it risks the possibility that calling host does not support FR-SSCS or simply does not retry and the call will never be established. 3. Possible Alternatives While Frame Relay interworking is possible, it is not possible to negotiate FR-SSCS with LLC encapsulation or VC-multiplexing, which decreases the chances of completing an ATM call. However, interoper- ability can be increased using the following alternatives: 1. Maintaining external knowledge that a particular destination uses FR-SSCS. This knowledge can be configured, or in the future added to some network host database. 2. In the absence of such external knowledge, an ATM endsystem is required to negotiate for the default LLC encapsulation (possibly requesting VC-multiplexing as an alternative). There are three sub- cases: 2a. The IWU supports service interworking and network interworking, and prefers service interworking. The IWU simply accepts the call using LLC encapsulation. 2b. The IWU supports service interworking and network interworking, and prefers network interworking. The IWU simply accepts the call, but attempts to open a parallel connection back to the original ATM endsystem negotiating the FR-SSCS use. If the connection is accepted, the IWU closes the service interworking connection. 2c. The IWU supports network interworking only. The IWU rejects the call specifying 'AAL Parameters not supported', and then attempts to open a connection back to the original ATM endsystem negotiating the FR-SSCS use. 4. Encapsulation negotiation Perez et al. [Page 23] DRAFT ATM Signaling Support for IP over ATM August 1994 The call/connection control signaling protocol includes a mechanism to support negotiation of encapsulation for endsystems that support more than one. This section describes the procedures for negotiation of an encapsulation. The B-LLI negotiation procedures (see Annex C of [ATMF93]) are ini- tiated by the calling ATM endsystem by including up to three instance of the B-LLI IE in the SETUP message in descending order of prefer- ence (following the rule for repeating IE in section 5.4.5.1 of [ATMF93]). The following is the list of the three possible combinations that B- LLI IE instances MAY be included in the SETUP message. Each instance is referred to by its encapsulation name as it appears in RFC 1483, and corresponding section labels from Appendix D of the ATM Forum UNI 3.0 specification. a) LLC/SNAP encapsulation (D.3.1) In this case, the calling ATM endsystem can only send and receive packets preceded by an LLC/SNAP identification. This I-D requires that hosts and routers which are ATM endsystems implement LLC/SNAP encapsulation. b) VC-multiplexing (D.3.2) and LLC/SNAP (D.3.1) The calling ATM endsystem prefers to use VC multiplexing, but is willing to agree to use LLC/SNAP encapsulation instead, if the called ATM endsytem only supports LLC/SNAP. c) RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS (D.3.3, omitting octets 7a and 7b and MUST have FR-SSCS in SSCS type of AAL Parameters IE.) The calling ATM endsystem can only send and receive packets using RFC 1490 encapsulation (NLPID multiplexing) over FRSSCS. Use of RFC 1490 encapsulation presently cannot be negotiated as an alternative to LLC encapsulation or VC-multiplexing If the B-LLI IE is encoded to indicate RFC 1490 encapsulation, the SSCS type field of the AAL Parameters IE SHALL coded to indicate FRSSCS. Note that the AAL Parameters IE can not be coded to indicate both NULL and FR-SSCS and neither LLC encapsulation nor VC-multiplexing will be interoperable when used over FR-SSCS. The called ATM endsystem SHALL select the encapsulation method it is able to support from the B-LLI IE present in SETUP message. If it supports more than one of the encapsulations indicated in the SETUP message, it MUST select the one which appears first in the SETUP Perez et al. [Page 24] DRAFT ATM Signaling Support for IP over ATM August 1994 message. The called ATM endsystem then includes the B-LLI IE content corresponding to the selected encapsulation in the CONNECT message. If the called endsystem does not support any encapsulation indicated in the incoming SETUP message, it SHALL clear the call with cause #88, incompatible destination. If the received SETUP message does not include the B-LLI IE, the call SHALL be cleared with cause #21, "call rejected", with diagnostics indicating rejection reason = information element missing and the B-LLI IE identifier. As described in Annex C of [ATMF93], if the calling ATM endpoint receives a CONNECT message that does not contain a B-LLI IE, it SHALL assume the encapsulation indicated in the first BLLI IE that it included in the SETUP message. Perez et al. [Page 25]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14006; 17 Aug 94 18:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14002; 17 Aug 94 18:01 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17599; 17 Aug 94 18:01 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA106554302; Wed, 17 Aug 1994 13:11:42 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from BBN.COM by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA106224299; Wed, 17 Aug 1994 13:11:39 -0700 Message-Id: <199408172011.AA106224299@matmos.hpl.hp.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lyman Chapin Subject: Re: Private ATM Addresses vs NSAP addresses To: rajeev@trillium.com Cc: af-all@atmforum.com, comp.dcom.cell-relay@usenet.ucs.indiana.edu, ip-atm@matmos.hpl.hp.com In-Reply-To: <9408160256.AA09957@trillium.com> Date: Wed, 17 Aug 94 15:51:42 EDT Mail-System-Version: Rajeev, Work on NSAPs after 1987 resulted in the elimination of the "preferred decimal encoding", which had artificially limited the practical maximum length of NSAPs (since all NSAPs had to be expressable in the "preferred decimal encoding" as a string of no more than 40 digits). The most recent standard (ISO/IEC 8348:1993) permits binary NSAPs to be a full 20 octets long. - Lyman >Date: Mon, 15 Aug 1994 19:56:38 +0800 >From: rajeev@trillium.com >To: af-all@atmforum.com, ip-atm@matmos.hpl.hp.com, > comp.dcom.cell-relay@usenet.ucs.indiana.edu >Subject: Private ATM Addresses vs NSAP addresses > > >The ATM Forum UNI 3.0/3.1 claims that the Private ATM address format >is modelled after the format of an OSI NSAP, as specified in ISO 8348, >and that it is always 20 octets [section 5.1.3.1]. It then goes on to >specify 3 AFI values that may be used with Private ATM addresses: >39, 47, 45 [section 5.1.3.1.1]. > >I dug up ISO 8348, Addendum 2 (1987) and discovered that for the above >AFI values, the corresponding NSAP address lengths are 17, 16 and 18 >octets, respectively. > >I will summarize my findings and the apparent inconsistency with the UNI >text. Perhaps, my analysis is wrong, so I would welcome corrections. All >references below refer to ISO 8348, Addendum 2, 1987. > >NSAP address format >------------------- > >An NSAP address has three parts: AFI, IDI, DSP. The AFI and IDI are decimal >digits whereas the DSP could be decimal or binary. To represent these >values in protocol messages, the UNI specifies "preferred binary encoding" >which encodes decimal values using BCD and binary values are encoded directly. > >Field Lengths >------------- > >AFI: Length is two decimal digits. Currently values 36-59 are assigned. > [section 8.2.1.1, Table 1] > >IDI: Length depends on IDI format. > [sections 8.2.1.2.2, 8.2.1.2.5, 8.2.1.2.6] > > DCC 3 decimal digits (fixed length) > ICD 4 decimal digits (fixed length) > E.164 upto 15 decimal digits (variable length) > >DSP: Length depends on AFI and whether it is binary or decimal. > [section 8.2.3, Table 3] > > ---------------------------- > IDI Decimal Binary > format Digits Octets > ---------------------------- > DCC 35 14 > ICD 34 13 > E.164 23 9 > ---------------------------- > >Now, the selection of the AFI value indicates the IDI format (for variable >length IDIs, it specifies whether leading 0's are significant) as well >as the abstract syntax for DSP. The values specified in the UNI imply >the following [Table 2]: > >----------------------------------------------------------------------- >AFI value Implication >----------------------------------------------------------------------- >39 IDI = DCC; DSP is binary >47 IDI = ICD; DSP is binary >45 IDI = E.164, leading 0's not significant; DSP is binary >----------------------------------------------------------------------- > >Note that the specific choice of AFI values indicate that the DSP >values are always binary, not decimal i.e. encoding is not BCD. > >Based on the above, we can calculate the length of the corresponding >NSAP addresses [Table 5]: > >---------------------------------------------------------------------------- >AFI value AFI length IDI length DSP length Total length > (octets) (octets) (octets) (octets) >---------------------------------------------------------------------------- >39 (DCC) 1 2 14 17 >47 (ICD) 1 2 13 16 >45 (E.164) 1 8 9 18 >---------------------------------------------------------------------------- > >The values above are calculated as follows: > >AFI: Two decimal digits represented as two semi-octets using BCD. >IDI: Decimal digits represented as semi-octets using BCD, leading 0's used > to fill IDI field, a single semi-octet 1111 used to obtain integral > number of octets. >DSP: Taken from [Table 3]. > >Clearly, this imples two things: > >1. These NSAP addresses are not always 20 octets, as specified in the UNI. >2. The DSP does not consist of decimal digits encoded using BCD. > >There are two explanations: > >1. Private ATM addresses are not NSAP addresses, or >2. The AFI values specified are wrong. > >If the AFI values were chosen to indicate that the DSP consists of >decimal digits, then the NSAP addresses would indeed always be 20 >octets. Here is the same calculation as above, this time using AFI >values that indicate the DSP is decimal [Tables 2,3,5]: > >---------------------------------------------------------------------------- >AFI value AFI length IDI length DSP length Total length > (digits) (digits) (digits) (digits) >---------------------------------------------------------------------------- >38 (DCC) 2 3 35 40 >46 (ICD) 2 4 34 40 >44 (E.164) 2 15 23 40 >---------------------------------------------------------------------------- > >Now, the total address length is 40 octets, which when represented using >BCD, will fit in 20 octets. Also, the entire NSAP address is a string of >decimal digits. > >Note, however, that the in the case of DCC and E.164, the IDI and DSP split >on a semi-octet boundary. So the pictures in UNI 3.1 (5.1a and 5.1c) will be >incorrect. Moreover, if the intention is for the ESI field to carry 48 bit >IEEE MAC addresses, then clearly the DSP cannot be decimal. > >So, to be completely accurate, the UNI should be modified to do one of >the following: > >1. Change the AFI values to indicate DSP is decimal; change the pictures > that show that the IDI and DSP split on an octet boundary. > >2. Retain the existing AFIs but specify that the length of the NSAP > address varies according to format. > >3. Retain the existing AFIs and continue to claim that all private ATM > addresses are 20 octets, but remove reference to NSAP addresses and > ISO 8348. > >Comments are welcome. > >------------------------------------------------------------------- >Rajeev Gupta Email : rajeev@trillium.com >Trillium Digital Systems, Inc. Voice (w) : (310) 479-0500 >Los Angeles, CA 90025. Fax (w) : (310) 575-0172 >* I speak only for myself, but make no claim to original thought * >-------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14685; 17 Aug 94 19:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14681; 17 Aug 94 19:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18905; 17 Aug 94 19:18 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA138301585; Wed, 17 Aug 1994 15:13:05 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA137971578; Wed, 17 Aug 1994 15:12:58 -0700 Date: Wed, 17 Aug 1994 15:12:58 -0700 Message-Id: <199408172212.AA137971578@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: 2nd Last Call round for signaling draft Due to the number of changes to the signalling draft, I'm setting another WG last call for 8/24/94 5PM PDT (close of working day, one week from today). Please try to read it and have your comments in to the list by that time. I've made it one week this time as we gave it three weeks last time and we've all pretty well commented on it. Thanks, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16082; 17 Aug 94 21:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16078; 17 Aug 94 21:28 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20982; 17 Aug 94 21:28 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA169949979; Wed, 17 Aug 1994 17:32:59 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA169619975; Wed, 17 Aug 1994 17:32:55 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA15085 for ip-atm@matmos.hpl.hp.com; Wed, 17 Aug 94 20:32:49 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id RAA04207; Wed, 17 Aug 1994 17:32:06 -0700 Message-Id: <199408180032.RAA04207@aland.bbn.com> To: Mark Laubach Cc: ip-atm@matmos.hpl.hp.com Subject: Re: 2nd Last Call round for signaling draft In-Reply-To: Your message of Wed, 17 Aug 94 15:12:58 -0700. <199408172212.AA137971578@matmos.hpl.hp.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Wed, 17 Aug 94 17:32:05 -0700 > Due to the number of changes to the signalling draft, I'm setting another > WG last call for 8/24/94 5PM PDT (close of working day, one week from > today). Please try to read it and have your comments in to the list > by that time. I've made it one week this time as we gave it three > weeks last time and we've all pretty well commented on it. Mark: Yes, but this is vacation season (I believe the French don't get back until Sept 1st and lots of folks take off a few weeks in August) so a lot of folks are out and had no reason to believe a draft would drop on their desk this soon. How about giving folks a little more time? (Note, I'm not asking for myself -- I can probably meet the 8/24 deadline). Craig   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16243; 17 Aug 94 21:57 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16239; 17 Aug 94 21:57 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21631; 17 Aug 94 21:57 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA185851958; Wed, 17 Aug 1994 18:05:58 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA185381946; Wed, 17 Aug 1994 18:05:46 -0700 Date: Wed, 17 Aug 1994 18:05:46 -0700 Message-Id: <199408180105.AA185381946@matmos.hpl.hp.com> To: Craig Partridge Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: 2nd Last Call round for signaling draft Cc: ip-atm@matmos.hpl.hp.com > Yes, but this is vacation season (I believe the French don't get back >until Sept 1st and lots of folks take off a few weeks in August) so a lot of >folks are out and had no reason to believe a draft would drop on their desk >this soon. How about giving folks a little more time? (Note, I'm not >asking for myself -- I can probably meet the 8/24 deadline). Will lengthening the window until the 1st work or should we just encourage them to participate during the IETF last call? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02313; 18 Aug 94 8:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02309; 18 Aug 94 8:11 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03894; 18 Aug 94 8:11 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA280747030; Thu, 18 Aug 1994 03:50:30 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from cccd.cc.titech.ac.jp by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA280237022; Thu, 18 Aug 1994 03:50:22 -0700 Received: from cc.titech.ac.jp by cccd.cc.titech.ac.jp (8.6.9/TM1.2) id TAA17170; Thu, 18 Aug 1994 19:49:24 +0900 Received: by cc.titech.ac.jp (5.61/cce-1.5/TM) id AA02692; Thu, 18 Aug 94 19:48:01 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Masataka Ohta Message-Id: <9408181048.AA02692@cc.titech.ac.jp> Subject: Re: Multicasting over ATM draft To: Steve Deering Date: Thu, 18 Aug 1994 19:47:59 +0900 (JST) Cc: akyol@leland.stanford.edu, ip-atm@matmos.hpl.hp.com, deering@parc.xerox.com In-Reply-To: <94Aug16.140740pdt.12171@skylark.parc.xerox.com> from "Steve Deering" at Aug 16, 94 02:07:27 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2113 > > a native ATM API which will...actually take advantage of the strongholds of > > ATM technology like being connection oriented and have the ability to do > > statistical multiplexing, > > The connection-orientedness of ATM is one of its *weaknesses*, not its > strengths; True. But as long as we don't use LIS, do use small, physically connected subnets, connection-orientedness of ATM at the link layer does not matter. > it's the main cause of all the difficulty in mapping IP > multicast to ATM multicast. No. Mapping difficulty, such as unscalable mesh of pt-mtp, comes from the lack of mappable architecture at the Internetwork layer in Classical or ROLC model. IP multicast maps completely well over the Conventional model of IP over ATM. > As Van Jacobson points out, a "connection" > is too high-level an abstraction -- it severly constrains what services > can be supported by an infrastructure. Connection orientedness of ATM is really harmfull if it is forced at the Internetwork layer with improper implementation of layering, which is the problem of LIS and NHRP model. But please don't misunderstand ATM is no good just because the classical model is no good. > IP does statistical multicasting. The fact that ATM uses fixed-size packets > does not give it any magical powers with respect to statistical multipluxing. With flows, we can do reservation-based assurred-bandwidth multicasting. The fact that some medium such as ATM or future 1Gbps-switched-Ethernet have connection-oriented assurred-bandwidth link layer will be useful then. Fixed-size packets is irrelevant. > > ...there has to be a future goal for transmitting all sorts of traffic over > > ATM and IP is not appropriate for that. > > Why set such a modest goal? If instead we work to support all sorts of > traffic over IP, we will end up with a multi-services internet that > is not locked into a single subnetwork technology. My goal is to transmit all sorts of traffic over IPv6 not necessarily over ATM. > > ...maybe we should have used PPP over SONET. > > No doubt about it. Maybe. Masataka Ohta   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06811; 18 Aug 94 12:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06801; 18 Aug 94 12:27 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10290; 18 Aug 94 12:27 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06780; 18 Aug 94 12:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06692; 18 Aug 94 12:24 EDT Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10170; 18 Aug 94 12:23 EDT Received: from dworkin.wustl.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Thu, 18 Aug 1994 08:52:38 -0700 Received: (from mm94@localhost) by dworkin.wustl.edu (8.6.8.1/8.6.6.yuck) id KAA17718; Thu, 18 Aug 1994 10:53:29 -0500 Date: Thu, 18 Aug 1994 10:53:29 -0500 X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ACM Multimedia 94 Message-Id: <199408181553.KAA17718@dworkin.wustl.edu> To: announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, ccrc@dworkin.wustl.edu, cip@bbn.com, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, icad-request@santafe.edu, ietf@isi.edu, iplpdn@CNRI.Reston.VA.US, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, s-comput%tcsvm.BITNET@wugate.wustl.edu, sig11@roses.stanford.edu, sigmedia@bellcore.com, sip-request@catarina.usc.edu, smds@CNRI.Reston.VA.US, sound@acm.org, tccc@cs.umass.edu, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com Subject: ADVANCE PROGRAM -- ACM MULTIMEDIA 94 ANNOUNCEMENT 2nd ANNUAL ACM MULTIMEDIA CONFERENCE AND EXPOSITION October 15-20, 1994 San Francisco, California Sponsored by the Association for Computing Machinery SIGBIO, SIGBIT, SIGCHI, SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, SIGMM, and SIGOIS and in cooperation with SIGAPP, SIGMOD, SIGOPS and the IEEE Communications Society. =================****=================****=================****============ MULTIMEDIA '94 WWW/MOSAIC AND FTP SITES The Multimedia '94 WWW home page contains the advance program, registration information, as well as other relevant details. The URL is: http://george.lbl.gov/MM94/MM94.html The advance program and registration form can also be retrieved by anonymous ftp: ftp://dworkin.wustl.edu/pub/MM94/program If you need more information about Multimedia'94 or the Advance Program, contact Danieli and O'Keefe (DOK), our conference management company. Address Danieli and O'Keefe 490 Boston Post Road Sudbury, MA 01776-9898 Phone numbers 800-524-1851, or 508-443-3330, Ext. 1214 Email multimedia.dok@notes.compuserve.com or ACMHELP@ACM.org =================****=================****=================****============ CONFERENCE HIGHLIGHTS * Why ACM Multimedia '94? The second ACM Multimedia Conference will present an exciting mixture of technology and art. Sessions will focus on what will be the standards of the future; not what is happening today. The program of papers, panels, courses, demonstrations, videos, and exhibits will explore the breadth and diversity of this ever-changing technology. * You should be there! This conference will be vital for researchers, technical staff, software engineers, educators and artists working in any and all aspects of multimedia research and production. ACM Multimedia will draw attendees and presenters from both academia and industry, including telecommunications, fine arts, engineering, software development, multimedia production, electronic publishing, digital libraries, computer graphics, user interfaces, broadcast media, and networking. * Opening and Closing Plenaries The technical program kicks off with a debate by industry leaders from LucasArts, Philips Electronics and the new Mosaic Communications, moderated by Dr. R.W. Lucky, of Bellcore. They will debate their differing views on the evolution of the Multimedia industry. At the Closing Plenary, Tom Holman, the award-winning designer of the THX sound system and Corporate Technical Director of LucasFilm, discusses presentations standards for sound and graphics and Scott Marden, of Philips Media will give his perspective on the emerging multimedia industry. See page 14 for more details. * The Ubiquitous Art Zone The Ubiquitous Art Zone is that part of Multimedia '94 that presents the creations of artists working in multimedia. The art work ranges from "immersive environments" and "garage VR" to narrative works on interactive CD ROM and hard drive. By their use of interactive interface technologies, the artists invite the visitors to become participants in a shared experience. Come celebrate the emergence of the art made possible by the digital revolution. * Ubiquitous Art Zone/Exhibit Reception Please join us Tuesday evening for a reception that allows you to experience the full range of the arts in multimedia, as well as to spend some unhurried time in the exhibit hall. * Exhibit Hall This is the best opportunity to see and learn from companies who will share their multimedia experiences with you. Digital Equipment Corp. and IBM are just two of the companies who are eager to show their products and services. * Electronic Proceedings The conference proceedings will be available on a CD-ROM and on electronic network. Both media will include the text of the papers being presented, video clips from the video program and other material. * Conference Videotape The ACM Multimedia '94 video will feature videotapes of multimedia systems in action, and other topics relevant to the conference. The videos have been selected based on their relevance, technical content, originality, presentation quality, and clarity. The videotape will be available for purchase at the conference. * Demonstrations Program The demonstration program will feature novel research prototypes that demonstrate the latest advances in multimedia computing and communications technologies. These juried and working prototypes will be exhibited at regular intervals by their creators. Time will be provided for personal interaction with the systems. * Best Paper Awards Both the best paper and the best student paper will be presented in a special session on Thursday afternoon. Come hear the best of the best! * Vendor Track A special venue has been provided for exhibitor presentations on their products and services. This is a unique opportunity to find out about the tools and products that can help you be more productive. =================****=================****=================****============ CONFERENCE COMMITTEE CO-CHAIRS M. Blattner, Lawrence Livermore National Laboratory and University of California, Davis J. O. Limb, Georgia Institute of Technology, Atlanta ADVISORY COMMITTEE E. Fox, Virginia Polytechnic Institute and SU TREASURER R. B. Allen, Bellcore PROCEEDINGS J. J. Garcia-Luna, University of California, Santa Cruz WORKSHOPS S. Wilbur, Queen Mary & Westfield College, UK DEMONSTRATIONS T. Little, Boston University VIDEO M. Brown, Digital Equipment Corporation D. Redell, Digital Equipment Corporation ELECTRONIC PUBLISHING R. Rada, University of Liverpool, UK PANELS A. Kuchinsky, Hewlett-Packard S. Bulick, US WEST Technologies COURSES E. P. Glinert, Rensselaer Polytechnic Institute D. McIntyre, Morgan, Stanley & Co. K. Wittenburg, Bell Communications Research, LOCAL ARRANGEMENTS J. D. Smith, Lawrence Livermore National Laboratory PUBLICITY G. Parulkar, Washington University in St. Louis EXHIBITS P. Mantey, University of California, Santa Cruz AUDIO/VISUAL N. Johnston, Lawrence Berkeley Laboratory UBIQUITOUS ART ZONE Beverly Reiser PROGRAM COMMITTEE Chair D. Ferrari, University of California, Berkeley CO-CHAIRS S. Ahuja, AT&T Bell Laboratories F. Kitson, Hewlett-Packard T. Kunii, University of Aizu, Japan R. Phillips, Los Alamos National Laboratory R. Rada, University of Liverpool, UK R. Sacks-Davis, the Royal Melbourne Institute of Technology. =================****=================****=================****============   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09001; 18 Aug 94 14:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08997; 18 Aug 94 14:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12754; 18 Aug 94 14:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA050907787; Thu, 18 Aug 1994 09:36:27 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from chocorua.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA050497785; Thu, 18 Aug 1994 09:36:25 -0700 Received: from localhost (perez@localhost) by chocorua.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id MAA08171; Thu, 18 Aug 1994 12:34:33 -0400 Message-Id: <199408181634.MAA08171@chocorua.cmf.nrl.navy.mil> X-Authentication-Warning: chocorua.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: goldstein@carafe.enet.dec.com Cc: ip-atm@matmos.hpl.hp.com Subject: Re: draft-ietf-ipatm-sig-02.txt In-Reply-To: Your message of "Thu, 18 Aug 94 10:50:46 EDT." <9408181450.AA26733@us1rmc.bb.dec.com> Date: Thu, 18 Aug 94 12:34:29 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Maryann Perez Maher ] Nice draft. However, I do still get a little queasy whenever I see ] the term "best effort" used in context of ATM, since it literally means ] "worst effort" and indeed reference is made to Traffic Class X (UBR). ] I realize that Traffic Class Y (ABR) isn't done yet but if people ] take this too seriously, they might expect that Class X really will ] perform well enough (which I seriously doubt) and thus won't need ] Class Y. ] Well, there's always the Class C option with a defined SCR. Unfortunately, in UNI 3.0 the only applicable Bearer Service Classes (BCS) are BCS-C and BCS-X (BCS-A, the third BCS, is solely a CBR transport service). Folks thought BCS-X was more "flexible" since the timing requirements are 'user-defined' instead of the set 'no-end-to-end timing requirements' in BSC-C. (Although, the recommendation was that if BCS-X is specified, the timing requirements be set to 'no indication'.) This part of the signaling draft was one of the more difficult to pin down because of the many open issues and ambiguities in the UNI 3.0 traffic management specification. Maybe we should put a statement in the "Open Issues" section about the future Class Y service.... Maryann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09010; 18 Aug 94 14:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09002; 18 Aug 94 14:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12753; 18 Aug 94 14:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA041997342; Thu, 18 Aug 1994 09:29:02 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from inet-gw-3.pa.dec.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA041517319; Thu, 18 Aug 1994 09:28:39 -0700 Received: from flashy.tay2.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA12250; Thu, 18 Aug 94 07:20:11 -0700 Received: by flashy.tay2.dec.com (5.65/MS-081993); id AA10996; Thu, 18 Aug 1994 10:19:03 -0400 Date: Thu, 18 Aug 1994 09:45:28 -0400 Message-Id: <94081809452784@carafe.tay2.dec.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: goldstein@carafe.tay2.dec.com To: ip-atm@matmos.hpl.hp.com Subject: Re: draft-ietf-ipatm-sig-02.txt X-Vms-To: US1RMC::"perez@cmf.nrl.navy.mil" X-Vms-Cc: SMTP%"ip-atm@matmos.hpl.hp.com" Nice draft. However, I do still get a little queasy whenever I see the term "best effort" used in context of ATM, since it literally means "worst effort" and indeed reference is made to Traffic Class X (UBR). I realize that Traffic Class Y (ABR) isn't done yet but if people take this too seriously, they might expect that Class X really will perform well enough (which I seriously doubt) and thus won't need Class Y. Well, there's always the Class C option with a defined SCR. fred   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12640; 18 Aug 94 17:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12636; 18 Aug 94 17:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16519; 18 Aug 94 17:23 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA099470499; Thu, 18 Aug 1994 13:08:19 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA099100484; Thu, 18 Aug 1994 13:08:04 -0700 Date: Thu, 18 Aug 1994 13:08:04 -0700 Message-Id: <199408182008.AA099100484@matmos.hpl.hp.com> To: Maryann Perez Maher Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: draft-ietf-ipatm-sig-02.txt Cc: ip-atm@matmos.hpl.hp.com, goldstein@carafe.enet.dec.com I suggest we leave the term "best effort" in this current draft and change the term when the draft rolls from proposed -> draft. By that time, we should have an accepted definition. Mark >] Nice draft. However, I do still get a little queasy whenever I see >] the term "best effort" used in context of ATM, since it literally means >] "worst effort" and indeed reference is made to Traffic Class X (UBR). >] I realize that Traffic Class Y (ABR) isn't done yet but if people >] take this too seriously, they might expect that Class X really will >] perform well enough (which I seriously doubt) and thus won't need >] Class Y. >] Well, there's always the Class C option with a defined SCR. > >Unfortunately, in UNI 3.0 the only applicable Bearer Service Classes (BCS) >are BCS-C and BCS-X (BCS-A, the third BCS, is solely a CBR transport >service). Folks thought BCS-X was more "flexible" since the timing >requirements are 'user-defined' instead of the set 'no-end-to-end timing >requirements' in BSC-C. (Although, the recommendation was that if >BCS-X is specified, the timing requirements be set to 'no indication'.) >This part of the signaling draft was one of the more difficult to pin >down because of the many open issues and ambiguities in the UNI 3.0 traffic >management specification. > >Maybe we should put a statement in the "Open Issues" section about the >future Class Y service.... > > >Maryann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13067; 18 Aug 94 17:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13063; 18 Aug 94 17:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa17117; 18 Aug 94 17:54 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA114821028; Thu, 18 Aug 1994 13:17:08 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA114471021; Thu, 18 Aug 1994 13:17:01 -0700 Date: Thu, 18 Aug 1994 13:17:01 -0700 Message-Id: <199408182017.AA114471021@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: last call moved to August 31st. Cc: Maryann Perez Maher Due to vacations and such, and some feedback I've received, let's move the last call due date for the signaling draft to August 31st, 5PM PDT. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14311; 18 Aug 94 19:52 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14307; 18 Aug 94 19:52 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18847; 18 Aug 94 19:52 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA150499835; Thu, 18 Aug 1994 15:43:55 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA150169833; Thu, 18 Aug 1994 15:43:53 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id SAA03488; Thu, 18 Aug 1994 18:43:13 -0400 Message-Id: <199408182243.SAA03488@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Maryann Perez Maher Cc: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: draft-ietf-ipatm-sig-02.txt In-Reply-To: Your message of Wed, 17 Aug 94 11:50:30 -0400. <199408171550.LAA06234@chocorua.cmf.nrl.navy.mil> Date: Thu, 18 Aug 94 18:43:12 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com Maryann (et al), I think the draft is looking good. I have some suggested alterations to a few sections: >> 4.2. Multiprotocol Support on VCs >> >> When two ATM endsystems run multiple protocols, an ATM connection MAY >> be shared among two or more datagram protocol entities, as long as >> the VCC owner allows sharing, as well as if the encapsulation allows >> proper multiplexing and demultiplexing (i.e. the LLC/SNAP encapsula- >> tion). "...VCC owner allows sharing <, as well as if> and the encapsulation mechanism allows..." [..] >> 4.4. VC Teardown "VC" hasn't been defined. "VCC" is used in section text. [Same observation applies to some other section headings]. [..] >> If implemented, the inactivity timer SHALL monitor traffic of both >> receiving and transmitting activities. Something I should have noted earlier - what about situations where both ends simultaneously opened VCCs to each other, and one end ungracefully dies (so no Q.2931 messages are sent to indicate a RELEASE from the dead end)? The inactivity timer should also be applied to VCCs originated remotely, but with a longer timeout period. If a locally originated VCC is idle for 20 min we issue a RELEASE, if a remotely originated VCC is idle for (e.g.) 30 min we also issue a RELEASE (on the assumption of catastrophy) so that at least some of the associated ATM level resources are freed. [..] >> 7.2.1. Framework for Protocol Layering I think section 7.2.1 makes good points. >> 8.1. ATM User Cell Rate [..] >> b) if, in response to a SETUP message, a calling endsystem receive >> a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by >> a RELEASE COMPLETE message, [..] >> 8.2. Broadband Bearer Capability [..] >> b) if, in response to a SETUP message, a calling endsystem receives >> a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by >> a RELEASE COMPLETE message, [..] >> 8.3. QoS Parameter [..] >> b) if, in response to a SETUP message, a calling endsystem receives >> a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by >> a RELEASE COMPLETE message, It is my understanding that RELEASE COMPLETE is only acceptable for call rejection if it is the first response to a SETUP. If the called endpoint has already issued CALL PROCEEDING and then decides to reject the SETUP request it must issue a RELEASE instead (and then wait for the RELEASE COMPLETE reply from the network/calling party). (Section 5.5.4.2 of UNI 3.0) This impacts on the above three subsections, and probably the text of section 5. [I didn't look at the FR appendix in detail, but it has made the main body much cleaner.] regards, gja   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14321; 18 Aug 94 19:53 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14317; 18 Aug 94 19:53 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18859; 18 Aug 94 19:53 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA149479761; Thu, 18 Aug 1994 15:42:41 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ccc.casc.com (casc.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA149149758; Thu, 18 Aug 1994 15:42:38 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jmoy@alpo.casc.com Received: from alpo.casc.com ([192.9.200.2]) by ccc.casc.com (4.1/3.1.012693-Cascade) Message-Id: <9408182242.AA27374@ccc.casc.com> Date: Thu, 18 Aug 94 18:34:16 EDT Received: by apollo13.cascade (4.1/SMI-4.1) id AA00570; Thu, 18 Aug 94 18:12:24 EDT To: gja@thumper.bellcore.com Cc: ddp@fore.com, ip-atm@matmos.hpl.hp.com, jhalpern@newbridge.com In-Reply-To: <199408161724.NAA14415@thumper.bellcore.com> (gja@thumper.bellcore.com) Subject: Re: YAAM draft (Yet Another ATM Multicast draft :-) Grenville- I read your document "IP Multicast over UNI 3.0 based ATM Networks" with interest. It seems to me that to implement the full IP multicast model for UNI 3.0, a scheme like yours is what we'd end up with (the alternative that Dino and Percy are describing I think of as more of a "broadcast service" than an IP multicast service). As for whether it will scale, I don't know. But with the tools at hand, it seems the best that we could do. One comment about your statement in a message to Drew: > Beyond IGMP messages, the routers only > need to be members of a group if they have some prior knowledge > that group membership extends beyond the LIS, at which time they > issue a JoinLocalGroup and become members. Some IP multicast routing protocols, such as MOSPF, don't require that group membership be sent throughout the whole routing domain (for scaling reasons). This is implemented by having some routers be "wild-card multicast receivers" -- and as a result not all routers have advance knowledge of just what multicast destinations they will be forwarding, UNTIL they actually receive a multicast datagram. You now have a chicken-and-egg problem... As far as acheiving reliable signalling on 224.0.0.1, you might try implementing this group (and this group only) as Pt-to-pt connections to the ARP server and a pt-to-multipoint back to all the IP multicast hosts (ala LAN emulation). This way only the ARP server needs to know the 224.0.0.1 members, which gets around Joel's problems. The disadvantages of doing this (traffic concentration and forwarding load on the ARP server) are probably not too bad, since traffic on 224.0.0.1 should be relatively light? John   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14589; 18 Aug 94 20:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14584; 18 Aug 94 20:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19273; 18 Aug 94 20:24 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA182472013; Thu, 18 Aug 1994 16:20:13 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA182142010; Thu, 18 Aug 1994 16:20:10 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id TAA05447; Thu, 18 Aug 1994 19:19:11 -0400 Message-Id: <199408182319.TAA05447@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: jmoy@alpo.casc.com Cc: gja@thumper.bellcore.com, ddp@fore.com, ip-atm@matmos.hpl.hp.com, jhalpern@newbridge.com, gja@thumper.bellcore.com Subject: Re: YAAM draft (Yet Another ATM Multicast draft :-) In-Reply-To: Your message of Thu, 18 Aug 94 18:34:16 -0400. <9408182242.AA27374@ccc.casc.com> Date: Thu, 18 Aug 94 19:19:09 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com John, Thanks for the comments. [..] >>Some IP multicast routing protocols, such as MOSPF, don't require that >>group membership be sent throughout the whole routing domain (for >>scaling reasons). This is implemented by having some routers be "wild-card >>multicast receivers" -- and as a result not all routers have advance >>knowledge of just what multicast destinations they will be forwarding, >>UNTIL they actually receive a multicast datagram. You now have a >>chicken-and-egg problem... Good issue. One solution would be for IPmc routers running such protocols as you describe to 'behave promiscuously' by issuing a JoinLocalGroup for each group it sees another node within the LIS joining (by watching for IGMP ATMMC_JOIN messages on 224.0.0.1). This would ensure the ARP Server (from that point on) always considers the IPmc router to be a group member, even during times when membership of that group by hosts within the LIS drops to zero. (Some mechanism for 'flushing' groups might be needed here too). Such behaviour can be tweaked and modified at the IP router layer without changing the generic services of the IP-ATM interface layer described in the draft. What do you think of it? >>As far as acheiving reliable signalling on 224.0.0.1, you might try >>implementing this group (and this group only) as Pt-to-pt connections >>to the ARP server and a pt-to-multipoint back to all the IP multicast >>hosts (ala LAN emulation). [..] Yes, I'm pondering something in this line. Will try and get a solution out by early next week. gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15256; 18 Aug 94 21:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15251; 18 Aug 94 21:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20240; 18 Aug 94 21:23 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA203245343; Thu, 18 Aug 1994 17:15:43 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightning.synoptics.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA202915341; Thu, 18 Aug 1994 17:15:41 -0700 Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA10849; Thu, 18 Aug 94 17:14:57 PDT Received: from milliways (milliways.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA10878; Thu, 18 Aug 94 17:13:25 PDT Received: by milliways (4.1/2.0N) id AA02806; Thu, 18 Aug 94 17:12:38 PDT Message-Id: <9408190012.AA02806@milliways> Date: Thu, 18 Aug 94 17:12:38 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: ip-atm@matmos.hpl.hp.com Subject: Comments on draft-ietf-ipatm-sig-02 I wanted to raise some general points as well as some inconsistencies between the usage of UNI3.0 signaling by the latest signaling draft (called "IETF" here) and the current ATM Forum LAN Emulation draft (called "ATMF" here). I think it would be advantageous if the 2 were in sync with each other as many implementations will be running both protocols over the same signaling stack. 7.1 AAL parameters. IETF: says 'mode' field should be omitted. ATMF says 'mode' = 1 to indicate "message mode". Who is correct? 7.2 Whilst it seems odd that ATMF uses B-LLI layer 3 codes to indicate "LAN Emulation" and IETF uses B-LLI layer 2 codes to indicate "LLC", I guess this is correct. 8.1 ATM User Cell Rate: the negotiation mechanism proposed in IETF is kind of ugly. The clause (a) with phrases like "pretty good idea" is somewhat meaningless in the context of best/worst effort in UNI3.0. A calling system has absolutely no idea, unless we provide some better guidelines here, of whether a network or called party is able to accept line rate peak cell rate or not! The calling party does not know whether the called party is sitting on the end of a 155Mbps or a 2Mbps pipe. Clause (b) would be more helpful for interoperability if it gave advice on how to pick a better peak cell rate e.g. divide by 2 each time. Clause (c) ought to provide more hints on what policy for resource allocation we are encouraging IP end-stations to adopt: obviously, they have to overallocate b/w (since most calls will request line-rate) and must accept all "Best Effort" calls offered, at least up to some point. How should they choose such a point in a "Best Effort" environment? Is the current wording of clause (c) meant to imply such a dynamic decision on new calls offered or was it only intended to cover the case of mis-matched line-rates? Such guidelines are really needed to have any chance of interoperability. Is it clear from the reason codes returned that it was the *network*, rather than the called party that rejected a call because it does not support Best Effort? The paragraph after (c) implies that a calling party can tell the difference. ATMF has some words about not rejecting a call just because it does *not* specify line rate, but it does not have any more help on what to do when a called party cannot do the requested line rate. 8.2 QoS: ATMF has some words to the effect that a called party must not reject a call just because it does not ask for Service Class 0. Would it be helpful to put such a rule into the IETF doc? 9. Failure codes. ATMF: uses code 31 "normal, unspecified" to indicate that a end- point deliberately dropped a VCC e.g. because of inactivity. The IETF signaling draft should probably also specify which reason code to use when VCCs are deliberately dropped. The end of this section sort of drifts off onto nowhere: was there meant to be some more text here (or at least a .) ?? Do any signaling gurus have any recommendations as to what to do on these points? Is it worth cleaning up some of the guidelines in the interest of fewer late nights at InterOp '99 ??? Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Distributed Network Systems Group FAX: +1 408 988 5525 SynOptics Communications Inc. E-m: asmith@synoptics.com ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12597; 19 Aug 94 17:49 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12593; 19 Aug 94 17:49 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20662; 19 Aug 94 17:49 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA082527456; Fri, 19 Aug 1994 13:17:36 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from chocorua.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA082197453; Fri, 19 Aug 1994 13:17:33 -0700 Received: from localhost (perez@localhost) by chocorua.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id QAA09238; Fri, 19 Aug 1994 16:17:26 -0400 Message-Id: <199408192017.QAA09238@chocorua.cmf.nrl.navy.mil> X-Authentication-Warning: chocorua.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: gja@thumper.bellcore.com Cc: ip-atm@matmos.hpl.hp.com Subject: Re: draft-ietf-ipatm-sig-02.txt In-Reply-To: Your message of "Thu, 18 Aug 94 18:43:12 EDT." <199408182243.SAA03488@thumper.bellcore.com> Date: Fri, 19 Aug 94 16:17:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Maryann Perez Maher ] >> If implemented, the inactivity timer SHALL monitor traffic of both ] >> receiving and transmitting activities. ] ] Something I should have noted earlier - what about situations where ] both ends simultaneously opened VCCs to each other, and one end ] ungracefully dies (so no Q.2931 messages are sent to indicate a RELEASE ] from the dead end)? The inactivity timer should also be applied ] to VCCs originated remotely, but with a longer timeout period. ] If a locally originated VCC is idle for 20 min we issue a RELEASE, ] if a remotely originated VCC is idle for (e.g.) 30 min ] we also issue a RELEASE (on the assumption of catastrophy) so that ] at least some of the associated ATM level resources are freed. What we mean here, and Andy can correct me if I'm wrong, is that both* ends of a VC must monitor the traffic. Whichever end notices the VC as being idle for 20 minutes can initiate the RELEASE. In the case you describe, the 'surviving' end would teardown both VCs. Even if my thinking is not correct here, at least the receiving end is presumably not paying for the VC that the originating end failed to teardown properly (but yes, it would still cause the receiver to use up its resources). ] >> 8.3. QoS Parameter ] [..] ] >> b) if, in response to a SETUP message, a calling endsystem receives ] >> a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by ] >> a RELEASE COMPLETE message, ] ] It is my understanding that RELEASE COMPLETE is only acceptable for ] call rejection if it is the first response to a SETUP. If the called ah, yes, this is correct. thanks, Maryann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13333; 19 Aug 94 19:09 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13329; 19 Aug 94 19:09 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22161; 19 Aug 94 19:09 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA122063718; Fri, 19 Aug 1994 15:01:58 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA121323715; Fri, 19 Aug 1994 15:01:55 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.3-7 #2740) id <01HG3P9ZQZCW8Y7TWR@sys30.timeplex.com>; Fri, 19 Aug 1994 18:04:13 EDT Received: from enigma by maelstrom.timeplex.com (4.1/SMI-4.1) id AA16347; Fri, 19 Aug 94 18:02:08 EDT Date: Fri, 19 Aug 1994 18:02:05 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: draft-ietf-ipatm-sig-02.txt In-Reply-To: Your message of "Fri, 19 Aug 1994 16:17:22 EDT." <199408192017.QAA09238@chocorua.cmf.nrl.navy.mil> To: Maryann Perez Maher Cc: gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, malis@maelstrom.timeplex.com Message-Id: <9408192202.AA16347@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Maryann wrote: > ] >> If implemented, the inactivity timer SHALL monitor traffic of both > ] >> receiving and transmitting activities. > What we mean here, and Andy can correct me if I'm wrong, is that both* > ends of a VC must monitor the traffic. Whichever end notices the > VC as being idle for 20 minutes can initiate the RELEASE. > In the case you describe, the 'surviving' end would teardown both VCs. Yes, the intent is that both ends run an inactivity timer. Perhaps we can make this statement clearer. Cheers, Andy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13400; 19 Aug 94 19:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13396; 19 Aug 94 19:22 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa22339; 19 Aug 94 19:22 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA108413562; Fri, 19 Aug 1994 14:59:22 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightning.synoptics.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA108083560; Fri, 19 Aug 1994 14:59:20 -0700 Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA15849; Fri, 19 Aug 94 14:58:35 PDT Received: from milliways (milliways.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA16759; Fri, 19 Aug 94 14:57:03 PDT Received: by milliways (4.1/2.0N) id AA03430; Fri, 19 Aug 94 14:56:16 PDT Message-Id: <9408192156.AA03430@milliways> Date: Fri, 19 Aug 94 14:56:16 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: ip-atm@matmos.hpl.hp.com Subject: Inactivity VCC teardown > From atmpost@matmos.hpl.hp.com Fri Aug 19 13:54:13 1994 > X-Authentication-Warning: chocorua.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol > To: gja@thumper.bellcore.com > Cc: ip-atm@matmos.hpl.hp.com > Subject: Re: draft-ietf-ipatm-sig-02.txt > In-Reply-To: Your message of "Thu, 18 Aug 94 18:43:12 EDT." > <199408182243.SAA03488@thumper.bellcore.com> > Date: Fri, 19 Aug 94 16:17:22 -0400 > From: Maryann Perez Maher > Content-Length: 1639 > Maryann, > ] >> If implemented, the inactivity timer SHALL monitor traffic of both > ] >> receiving and transmitting activities. > What we mean here, and Andy can correct me if I'm wrong, is that both* > ends of a VC must monitor the traffic. Whichever end notices the > VC as being idle for 20 minutes can initiate the RELEASE. > In the case you describe, the 'surviving' end would teardown both VCs. Isn't the important issue here that at least one of the inactivity timers at either end must monitor both Tx and Rx traffic? If a VCC were being used unidirectionally (and this will be a common scenario - talk to the router guys), the receiver must not initiate teardown just because it never transmitted a packet on that VCC. In practice, interoperability demands that both ends check both Tx and Rx activity. Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Distributed Network Systems Group FAX: +1 408 988 5525 SynOptics Communications Inc. E-m: asmith@synoptics.com ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06801; 22 Aug 94 14:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06797; 22 Aug 94 14:27 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12069; 22 Aug 94 14:27 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA228112349; Mon, 22 Aug 1994 09:19:09 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA227782344; Mon, 22 Aug 1994 09:19:04 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.3-7 #2740) id <01HG7JX5M1DS8Y5S6L@sys30.timeplex.com>; Mon, 22 Aug 1994 12:14:15 EDT Received: from michdry. (michdry.timeplex.com) by louie.timeplex.com (4.1/SMI-4.1) id AA26264; Mon, 22 Aug 94 11:07:12 CDT Date: Mon, 22 Aug 1994 11:07:12 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Gaddis Subject: Re: draft-ietf-ipatm-sig-02.txt To: perez@cmf.nrl.navy.mil Cc: ip-atm@matmos.hpl.hp.com Message-Id: <9408221607.AA26264@louie.timeplex.com> Content-Transfer-Encoding: 7BIT > > >] Nice draft. However, I do still get a little queasy whenever I see > >] the term "best effort" used in context of ATM, since it literally means > >] "worst effort" and indeed reference is made to Traffic Class X (UBR). > >] I realize that Traffic Class Y (ABR) isn't done yet but if people > >] take this too seriously, they might expect that Class X really will > >] perform well enough (which I seriously doubt) and thus won't need > >] Class Y. > >] Well, there's always the Class C option with a defined SCR. > > > >Unfortunately, in UNI 3.0 the only applicable Bearer Service Classes (BCS) > >are BCS-C and BCS-X (BCS-A, the third BCS, is solely a CBR transport > >service). Folks thought BCS-X was more "flexible" since the timing > >requirements are 'user-defined' instead of the set 'no-end-to-end timing > >requirements' in BSC-C. (Although, the recommendation was that if > >BCS-X is specified, the timing requirements be set to 'no indication'.) > >This part of the signaling draft was one of the more difficult to pin > >down because of the many open issues and ambiguities in the UNI 3.0 traffic > >management specification. > > > >Maybe we should put a statement in the "Open Issues" section about the > >future Class Y service.... > > > > > >Maryann > > Your commentary points up a separate problem not associated with the Class X versus Y debate enjoined here. That is, the ambiguities in UNI 3.0 that were "corrected" in UNI 3.1. While far from perfect, the updated 3.1 specification disambiguates many of the really gross inconsistencies with the BBC service classes that existed in UNI 3.0. For instance, BBC service class X may take three forms (or two, depending on your point of view). Class X with traffic type = "No Indication" (NI) or VBR and Timing requirements = NI or NO indicates a Class X data service and traffic type = CBR with a required timing indication of YES indicates a circuit service. Futhermore, "Best Effort" (which I agree is really worst effort) is indicated by the Traffic Descriptor IE by setting the best effort flag. Therefore, equating Class X as the ATMF best effort service is technically incorrect under some circumstances, in fact, as I've shown, you can specify a non-best effort circuit service as a Class X service. Also your description of the flexibility of the Timing indicators on class X are no longer true. Once again, I recommend using 3.1 as your target, using 3.0 makes little sense unless the network service is all just one service, best (worst) effort (probably with peak only) allocate data with no QoS interpretation. If the implementers choose PCR = Link Cell Rate than this is broken, plain and simple. I would wait for 3.1 even if that means delaying the draft status. Mike Gaddis Director, Software Development Ascom Timeplex, Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07088; 22 Aug 94 14:46 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07084; 22 Aug 94 14:46 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12457; 22 Aug 94 14:46 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA244955170; Mon, 22 Aug 1994 10:06:10 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from chocorua.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA244625167; Mon, 22 Aug 1994 10:06:07 -0700 Received: from localhost (perez@localhost) by chocorua.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id NAA09850; Mon, 22 Aug 1994 13:05:49 -0400 Message-Id: <199408221705.NAA09850@chocorua.cmf.nrl.navy.mil> X-Authentication-Warning: chocorua.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: Mike Gaddis Cc: ip-atm@matmos.hpl.hp.com Subject: Re: draft-ietf-ipatm-sig-02.txt In-Reply-To: Your message of "Mon, 22 Aug 94 11:07:12 CDT." <9408221607.AA26264@louie.timeplex.com> Date: Mon, 22 Aug 94 13:05:38 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Maryann Perez Maher > > >Unfortunately, in UNI 3.0 the only applicable Bearer Service Classes (BCS) > > >are BCS-C and BCS-X (BCS-A, the third BCS, is solely a CBR transport > > >service). Folks thought BCS-X was more "flexible" since the timing > > >requirements are 'user-defined' instead of the set 'no-end-to-end timing > > >requirements' in BSC-C. (Although, the recommendation was that if > > >BCS-X is specified, the timing requirements be set to 'no indication'.) > > >This part of the signaling draft was one of the more difficult to pin > > >down because of the many open issues and ambiguities in the UNI 3.0 > > >trafficmanagement specification. > > > > > >Maybe we should put a statement in the "Open Issues" section about the > > >future Class Y service.... > > > > > >Maryann > > Your commentary points up a separate problem not associated with the Class X > versus Y debate enjoined here. That is, the ambiguities in UNI 3.0 that were > "corrected" in UNI 3.1. While far from perfect, the updated 3.1 specificatio > n > disambiguates many of the really gross inconsistencies with the BBC service c > lasses > that existed in UNI 3.0. For instance, BBC service class X may take three fo > rms (or two, > depending on your point of view). Class X with traffic type = "No Indication" > (NI) > or VBR and Timing requirements = NI or NO indicates a Class X data service an > d > traffic type = CBR with a required timing indication of YES indicates a circu > it service. > Futhermore, "Best Effort" (which I agree is really worst effort) is indicated > by the > Traffic Descriptor IE by setting the best effort flag. Therefore, equating > Class X as the ATMF best effort service is technically incorrect under some > circumstances, in fact, as I've shown, you can specify a non-best effort circ > uit service > as a Class X service. Also your description of the flexibility of the Timing > indicators on class X are no longer true. In the draft we do not equate best effort with Class X. In fact, we say that either Class X or C can be used. In my comment above I tried to clarify why the group had chosen to recommend specifying Class X. > > Once again, I recommend using 3.1 as your target, using 3.0 makes little > sense unless the network service is all just one service, best (worst) effort > (probably with peak only) allocate data with no QoS interpretation. If the > implementers choose PCR = Link Cell Rate than this is broken, plain and > simple. I don't quite see how choosing PCR = Link Cell Rate (in the User Cell Rate IE) and a BSC-X with 'no indications' is broken with UNI 3.0? > I would wait for 3.1 even if that means delaying the draft status. It was decided that we can only base the draft on UNI 3.0 because it is the only publicly available spec right now. We agreed to make the modifications to the draft once 3.1 is out. Currently, UNI 3.0 is being implemented and deployed now and therefore this draft needs to first specify how to work with 3.0. > > Mike Gaddis Maryann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11341; 22 Aug 94 21:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11336; 22 Aug 94 21:12 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20481; 22 Aug 94 21:12 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA040594085; Mon, 22 Aug 1994 15:21:25 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from milpitas.adaptec.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA040264081; Mon, 22 Aug 1994 15:21:21 -0700 Received: from eng.adaptec.com ([162.62.20.6]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA19873; Mon, 22 Aug 94 15:18:38 PDT Received: from benicia by eng.adaptec.com (4.1/SMI-4.1) id AA01868; Mon, 22 Aug 94 15:19:51 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sam Ghandchi X-3420 Message-Id: <9408222219.AA01868@eng.adaptec.com> Subject: ATM Industry Testbeds To: ip-atm@matmos.hpl.hp.com Date: Mon, 22 Aug 1994 15:21:19 -0700 (PDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1473 Please Ignore if not interested in Testing and pardon me for the inconvenience. ****************************************** Hello, I know there are a number of ATM Test Beds currently available in the industry. I am in touch with Bellcore, UNH, Fort Huacha Interop Center in Arizona, MCNC lab (ATL), Amoco and Gigabit Test Bed in Virginia. I am also in contact with some of the Switch vendors who offer Test Beds in partnerships. I cannot disclose names. My interest is to test our ATM Adaptor Board in major industry Test Beds. Our board is 155 mbs and we support both MMF and UTP-5 for both SBUS and PCI. We support variety of OSs. I cannot disclose specific OSs and any release dates. We comply with atm94-230, atm94-616, atm94-229, atm94-300, atm 94-0543 for PHY, ATM Layer, AAL5, and Signaling. We also do SNMP Agent, Add Reg, ILMI, ip_over_atm, LAN Emulation, and Native API. I was wondering if there are any other Test Beds that would be of interest to us. I noticed in Craig Partridge's book the mention of ATT Luckynet and BAGNET in San Francisco Bay Area. I have not been able to contact either one. Any info would be highly appreciated. TIA, - Sam Ghandchi --------------------------------------------------------------- Sam Ghandchi ATM Software QA ADAPTEC 691 S. Milpitas Blvd. MS 180 Milpitas, CA 95035 (408) 945-8600 X.3420 (Voice) (408) 262-2533 (Fax) samg@netcom.com ---------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11477; 22 Aug 94 21:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11473; 22 Aug 94 21:32 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20732; 22 Aug 94 21:32 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA073860705; Mon, 22 Aug 1994 17:11:45 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA073530685; Mon, 22 Aug 1994 17:11:25 -0700 Date: Mon, 22 Aug 1994 17:11:25 -0700 Message-Id: <199408230011.AA073530685@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: announcement 5th Intl Wshop on Digital Audui and Video >------------------------------------------------------------ > 5th International Workshop on >Network and Operating System Support for Digital Audio and Video > (NOSSDAV '95) > > CALL FOR PAPERS > > April 19, 20, 21, 1995 > Durham, New Hampshire, USA > > Sponsored by the IEEE Communications Society > >In cooperation with ACM SIGCOMM, SIGOPS, SIGMM, SIGGRAPH, and SIGIR > >Network and operating system support for digital audio and video >are becoming increasingly important with the convergence of the >computer, the TV, and communications. Innovation in this field is >fueling the industry developments in interactive multimedia services >to the home. In the past, research in this domain has largely >originated as adaptations of specific technologies to support audio >and video. This work has lead to an understanding of common >cross-disciplinary problems. Increasingly, this work encompasses >and integrates the diverse technology necessary to achieve end-to-end >systems. To this end, research leading to complete solutions is >viewed as particularly important to the workshop. > >The workshop is intended to bring together practitioners from a >variety of areas, including communications and networks, operating >systems, real-time systems and distributed computing. It is intended >that an outcome of the workshop will be a statement of the the >state of the art in this field, highlighting the major areas >requiring future research. > >Relevant topics for the workshop include: > > High-speed/ATM networks > Multimedia-oriented desk, local, and wide area networks > Workstation architectures for multimedia > Cell-based system architectures > Multimedia network interfaces > Communication protocols for multimedia > Multicast > Micro-kernel and OS support for real-time communications > Resource management and reservation in the OS and network > End-to-end admission control > Quality of service and synchronization frameworks > Multimedia storage, server, and I/O architectures > Distributed multimedia systems > APIs and CM programming abstractions for multimedia > Community networking > TV set-top device communication > >Instructions for Submitting Papers: > >Two types of submissions are solicited: position papers and research >papers. For the purpose of paper review, position papers are >restricted to three single-spaced ASCII pages. Research papers are >restricted to an extended abstract no longer than five formatted >postscript pages. Papers should be electronically mailed to >nossdav95@spiderman.bu.edu > >Only if electronic submission is impossible, papers may be sent >to: Prof. T.D.C. Little, Multimedia Communications Laboratory, >Department of Electrical, Computer and Systems Engineering, Boston >University, 44 Cummington Street, Boston, MA 02215 USA. >Tel: +1 617 353-9877 Fax: +1 617 353-6440 tdcl@bu.edu. > >The proceedings of the workshop will be published by Springer-Verlag >and the best papers will be forwarded to selected journals for >publication. > >Important Dates: > > Abstracts due: December 12, 1994 > Acceptance notification: January 25, 1995 > Final paper due: March 8, 1995 > Workshop: April 19, 1995 > >Program Co-Chairs: > >Riccardo Gusella, HP Labs, USA >T.D.C. Little, Boston University, USA > >Program Committee: > >Stavros Christodoulakis, Technical University of Crete >Domenico Ferrari, University of California, Berkeley >Ralf Herrtwich, IBM Creative Multimedia Studios >Andy Hopper, Olivetti & University of Cambridge >Kevin Jeffay, University of North Carolina at Chapel Hill >Chuck Kalmanek, AT&T Bell Laboratories >Jim Kurose, University of Massachusetts at Amherst >Aurel Lazar, Columbia University >Derek McAuley, Cambridge University >Duane Northcutt, Sun Microsystems Laboratories >Guru Parulkar, Washington University >Steve Pink, Swedish Institute of Computer Science >Radu Popescu-Zeletin, GMD-FOKUS >K.K. Ramakrishnan, Digital Equipment Corporation >P. Venkat Rangan, University of California, San Diego >Jon Rosenberg, Bell Communications Research >Eve Schooler, USC/Information Sciences Institute >Doug Shepherd, Lancaster University >Cormac Sreenan, AT&T Bell Laboratories >Jean-Bernard Stefani, France Telecom/CNET >Daniel Swinehart, Xerox PARC >Hideyuki Tokuda, Carnegie Mellon University/Keio University >Jon Walpole, Oregon Graduate Institute of Science & Technology >Raj Yavatkar, University of Kentucky > >This CFP is on-line at http://spiderman.bu.edu. > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11539; 22 Aug 94 21:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11535; 22 Aug 94 21:38 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20846; 22 Aug 94 21:38 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA092331777; Mon, 22 Aug 1994 17:29:37 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA091981761; Mon, 22 Aug 1994 17:29:21 -0700 Date: Mon, 22 Aug 1994 17:29:21 -0700 Message-Id: <199408230029.AA091981761@matmos.hpl.hp.com> To: Andy Malis Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: Editorial pass on draft-ietf-ipatm-sig-02.txt Cc: ip-atm@matmos.hpl.hp.com >Mark, > >I included two notes below to you (regarding 1577). > >Cheers, >Andy Noted and will be saved for the rewrite. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04918; 23 Aug 94 13:26 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04914; 23 Aug 94 13:26 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11408; 23 Aug 94 13:26 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA013916177; Tue, 23 Aug 1994 08:36:17 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from tenet.ICSI.Berkeley.EDU by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA013586175; Tue, 23 Aug 1994 08:36:15 -0700 Received: (from bmah@localhost) by tenet.ICSI.Berkeley.EDU (8.6.9/8.6.6) id IAA08228; Tue, 23 Aug 1994 08:36:10 -0700 Date: Tue, 23 Aug 1994 08:36:10 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Bruce A. Mah" Message-Id: <199408231536.IAA08228@tenet.ICSI.Berkeley.EDU> To: Sam Ghandchi X-3420 Cc: ip-atm@matmos.hpl.hp.com Subject: ATM Industry Testbeds In-Reply-To: <9408222219.AA01868@eng.adaptec.com> References: <9408222219.AA01868@eng.adaptec.com> Sam Ghandchi X-3420 writes: > I was wondering if there are any other Test Beds > that would be of interest to us. I noticed > in Craig Partridge's book the mention of ATT Luckynet > and BAGNET in San Francisco Bay Area. I have not > been able to contact either one. Any info would > be highly appreciated. Hi Sam-- The contact people for BAGNet are: Bill Johnston, Lawrence Berkeley Laboratory (wejohnston@lbl.gov) Marjory Johnson, RIACS / NASA Ames Research Center (mjj@riacs.edu) Dan Swinehart, Xerox Palo Alto Research Center (swinehart.parc@xerox.com) For more info, point a WWW browser at http://george.lbl.gov/BAGNet.html. Bruce.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07168; 23 Aug 94 15:57 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07164; 23 Aug 94 15:57 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15895; 23 Aug 94 15:57 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA041866989; Tue, 23 Aug 1994 11:36:29 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from uu2.psi.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA041536986; Tue, 23 Aug 1994 11:36:26 -0700 Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA01726 for ip-atm@matmos.hpl.hp.com; Tue, 23 Aug 94 14:35:56 -0400 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id LAA08949; Tue, 23 Aug 1994 11:35:02 -0700 Message-Id: <199408231835.LAA08949@aland.bbn.com> To: Maryann Perez Maher Cc: ip-atm@matmos.hpl.hp.com Subject: re: draft-ietf-ipatm-sig-02.txt Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Craig Partridge Date: Tue, 23 Aug 94 11:35:00 -0700 Hi Maryann: It looks very good. All I caught were typos on this round (in the appended list). One comment -- I know I suggested that we recommend that folks request a fraction of the link rate (such as 2 Mbps and 64 Kbps). I'm also comfortable with simply suggesting that applications request a fraction of the link bandwidth (say 1/10th or some such) if people prefer that. My goal was simply that in the absence of any knowledge, we have some default guesttimate for folks to work with. Craig > ever, if the VCC is shared among several protocol entities, the > ATMARP client or server SHALL not disconnect the call as suggested in SHALL not -> SHALL NOT > tion endpoint is able to accept the call, it responds with a CONNECT > message (which may be preceded by a CALL PROCEEDING); otherwise, it may -> MAY > If the network does not support Best Effort service, link rate SHOULD > not be requested as the peak cell rate. Without any knowledge of the > application, is is RECOMMENDED that to 2 Mbps be requested at the > Private UNI and 64 Kbps at the Public UNI. that to 2 Mbps -> that 2 Mbps > the SEL field. If an IP router does this association, then its sig- > naling entity must carry in the SETUP message the ATM addresses must->MUST There's also a mention of Appendix D, section 4, which should be Appendix B, section 4 (I believe).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07973; 23 Aug 94 16:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07969; 23 Aug 94 16:35 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16786; 23 Aug 94 16:35 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA059169601; Tue, 23 Aug 1994 12:20:01 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from chocorua.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA058839598; Tue, 23 Aug 1994 12:19:58 -0700 Received: from localhost (perez@localhost) by chocorua.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id PAA12072; Tue, 23 Aug 1994 15:19:39 -0400 Message-Id: <199408231919.PAA12072@chocorua.cmf.nrl.navy.mil> X-Authentication-Warning: chocorua.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: Craig Partridge Cc: ip-atm@matmos.hpl.hp.com Subject: Re: draft-ietf-ipatm-sig-02.txt In-Reply-To: Your message of "Tue, 23 Aug 94 11:35:00 PDT." <199408231835.LAA08949@aland.bbn.com> Date: Tue, 23 Aug 94 15:19:38 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Maryann Perez Maher Craig, ] It looks very good. All I caught were typos on this round (in the ] appended list). Thanks for passing those along. ] ] One comment -- I know I suggested that we recommend that folks request ] a fraction of the link rate (such as 2 Mbps and 64 Kbps). I'm also ] comfortable with simply suggesting that applications request a fraction ] of the link bandwidth (say 1/10th or some such) if people prefer that. Yea, I was somewhat hesitant on recommending such exact values knowing that ATM networks will support a wide range of link bandwidths. I'll reword this to specify a fraction unless others oppose. Does 1/10th seem reasonable to folks? Maryann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03782; 24 Aug 94 10:41 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03771; 24 Aug 94 10:41 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08100; 24 Aug 94 10:41 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA159331116; Wed, 24 Aug 1994 05:25:16 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ace (ace.mid.net) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA159001113; Wed, 24 Aug 1994 05:25:13 -0700 Received: by ace (5.0/SMI-SVR4) id AA04246; Wed, 24 Aug 1994 07:26:43 +0600 Date: Wed, 24 Aug 1994 07:26:43 +0600 Message-Id: <9408241226.AA04246@ace> To: akyol@leland.stanford.edu Subject: Re: Multicasting over ATM draft Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Earl E. McCoy" Reply-To: emccoy@tra.com Cc: deering@parc.xerox.com, ip-atm@matmos.hpl.hp.com Content-Length: 3137 I have started to think of ATM much like Steve Deering, namely 1. If AAL5 CO-VBR is all the *user* needs from ATM (and MPEG-2 "constant quality/VBR" video is OK here) and 2. A datagram router can be made as fast/inexpensive as an ATM switch, and 3. IP Multicasting can be done without dependence on any layer 2, and 4. Call Admission Control, a datagram schedular, and priorities in the routers via RSVP (which is all ATM does), and 5. Transaction TCP is adopted (the last "real world" weakness of TCP/IP, then Go back to the *original pre-LAN* network model, nothing but point-to-point links between/among host computers and routers, period. PPP over SONET. The common carriers will have a SONET-only service offering; let's use it! ATM may solve a network provide problem, but I can't see why the user needs it. ************************************************************* > From: Steve Deering > > > a native ATM API which will...actually take advantage of the strongholds of > > ATM technology like being connection oriented and have the ability to do > > statistical multiplexing, > > The connection-orientedness of ATM is one of its *weaknesses*, not its > strengths; it's the main cause of all the difficulty in mapping IP > multicast to ATM multicast. As Van Jacobson points out, a "connection" > is too high-level an abstraction -- it severly constrains what services > can be supported by an infrastructure. ATM is connection-oriented to support real-time traffic like voice and video, as you might accept voice and video will probably not survive well for a cross country link if we used store-and-forward techniques, although Radio Free VAT usually sounds acceptable. > > IP does statistical multicasting. The fact that ATM uses fixed-size packets > does not give it any magical powers with respect to statistical multipluxing. ATM uses fixed size packets for fast packet switching, the statistical multiplexing in ATM can be used to provide a QoS guarantee, IP traffic on the other hand is always best effort, and the layers above IP are responsible for guaranteeing delivery. ( As far as I know ) > > ...there has to be a future goal for transmitting all sorts of traffic over > > ATM and IP is not appropriate for that. > > Why set such a modest goal? If instead we work to support all sorts of > traffic over IP, we will end up with a multi-services internet that > is not locked into a single subnetwork technology. Supposing that IP is extended to support all the services in the world, won't we still use ATM as the transport protocol, if not then what are we going to use ? > > > ...maybe we should have used PPP over SONET. > > No doubt about it. > > Steve > > Bora Akyol ******************************************************************** Earl E. McCoy PhD emccoy@tra.com Senior Consultant 312-587-7323 Telecommunications Research Associates usual disclaimer   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05616; 24 Aug 94 12:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05612; 24 Aug 94 12:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11188; 24 Aug 94 12:23 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA179529695; Wed, 24 Aug 1994 07:48:15 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from clouso.crim.ca by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA179199693; Wed, 24 Aug 1994 07:48:13 -0700 Received: from gdc.ca by clouso.crim.ca (4.1/SMI-4.1) id AA04086; Wed, 24 Aug 94 10:48:08 EDT Received: from sunken.gdc.ca by gdc.ca (5.0/SMI-SVR4) id AA01231; Wed, 24 Aug 1994 10:46:14 +0500 Received: by sunken.gdc.ca (4.1/SMI-4.1) id AA04468; Wed, 24 Aug 94 10:47:01 EDT Date: Wed, 24 Aug 94 10:47:01 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ken Message-Id: <9408241447.AA04468@sunken.gdc.ca> To: ip-atm@matmos.hpl.hp.com Subject: JPEG/MPEG MIB Content-Length: 409 Hi folks, Anyone aware of a MIB definition for JPEG and or MPEG over ATM ? -------------------------------------------------------------------------------- Ken McVey General DataComm Ltd. Phone: 514 335-3015 Fax: 514 335-1614 email: kmcvey@gdc.ca   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11138; 25 Aug 94 16:58 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11134; 25 Aug 94 16:58 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15527; 25 Aug 94 16:58 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA281051941; Thu, 25 Aug 1994 12:12:21 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA280721929; Thu, 25 Aug 1994 12:12:09 -0700 Date: Thu, 25 Aug 1994 12:12:09 -0700 Message-Id: <199408251912.AA280721929@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Request for help in getting involved. FYI for all DOD people out there. Mark >Date: Wed, 24 Aug 94 15:41:27 EST >From: "Greg Scott" >Subject: Request for help in getting involved. > >Hello, > >I am the current chair of the DoD's Data Communications Protocol >Standards Technical Management Panel Lower Layer Working Group >(DTMP WG1). With the possible policy change regarding GOSIP and >the Internet Protocol Suite, we have been directed to develop >working relationships with the IETF. The mailing list of this >message consists of those identified as chairs of several IETF >working groups addressing lower layer issues. > >What I am asking for is to be put in contact with or directed to >any individuals from DoD organizations that are participating in >your WG. These individuals will be asked to serve as the eyes, >ears and voice for those DTMP WG1 members who do not have the >funding available to attend the IETF itself. > >I understand that anyone agreeing to do this would not be >recognized within the IETF as the DoD Rep or as presenting the DoD >position. However, the point of this is not to get the IETF to >recognize the DoD as an organization. Rather its to have someone >serve as a conduit for technical information exchange between the >DTMP and the IETF. > >Thanks for any help you may be able to give, > >Greg Scott >DISA, JIEO, CFS >908-532-7726 > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04674; 26 Aug 94 15:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04670; 26 Aug 94 15:12 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa13710; 26 Aug 94 15:13 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA067561360; Fri, 26 Aug 1994 10:16:00 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com ([140.174.223.21]) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA067131356; Fri, 26 Aug 1994 10:15:56 -0700 Received: from [199.35.143.77] (laubach.slip.netcom.com [199.35.143.77]) by terra.com21.com (8.6.5/8.6.5) with SMTP id KAA06307 for ; Fri, 26 Aug 1994 10:10:39 -0700 Date: Fri, 26 Aug 1994 10:10:39 -0700 Message-Id: <199408261710.KAA06307@terra.com21.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Signaling Draft and UNI 3.1 IP-ATM'ers: At the Toronto meeting we elected to have the draft focus on UNI 3.0 and include UNI 3.1 as part of the proposed -> draft status rewrite. Our decision was based on the uncertainty of when UNI 3.1 would be publically available. Andy Malis has been in touch with the ATM Forum Executive Director and we have new information. UNI 3.1 is expected to be ratified at the September 23rd meeting of the Forum. The ballots are going out early next week. It is expected to be ratified at the meeting and the document will become publically available sometime in October. Due to this clarification, I want to open the timing again with the WG. We have a couple options: 1) Proceed as per our current decisions and publish with UNI 3.0 only: i.e., go *now* Timing notes: we can proceed directly to the IESG with the current draft after this last call closes. 2) Aim the document at UNI 3.1, with treatment for UNI 3.0 relegated to an appendix, or similar; i.e., wait and go with 3.1 and 3.0. Timing notes: we have to hold the current draft until the September 23rd ratification date, then go through another last call before submitting to the IESG. This will delay the draft becoming an RFC until sometime in mid-late November. So to reopen the question to the WG, the options are: Go with 3.0 now. Wait and go with 3.1 and 3.0. This is an email based WG issue. Please respond back to the list with a simple "go" or "wait" or similar and any short clarification questions. This is not a vote, but I will give a general summary of how the consensus is running at the end of day September 1. Thanks, Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05993; 26 Aug 94 16:56 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05989; 26 Aug 94 16:56 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16061; 26 Aug 94 16:57 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA084846996; Fri, 26 Aug 1994 11:49:56 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from inet2.tek.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA084516993; Fri, 26 Aug 1994 11:49:53 -0700 Received: from tektronix.tek.com by inet2.tek.com id ; Fri, 26 Aug 1994 11:49:52 -0700 Received: from dtl.labs.tek.com (crl.labs.tek.com) by tektronix.TEK.COM (4.1/8.2) id AA27318; Fri, 26 Aug 94 11:49:39 PDT Received: from icebox.LABS.TEK.COM (icebox.TEK) by dtl.labs.tek.com (4.1/8.0) id AA05385; Fri, 26 Aug 94 11:49:11 PDT Received: from icebox (localhost) by icebox.LABS.TEK.COM (5.0/SMI-SVR4) id AA03897; Fri, 26 Aug 1994 11:49:06 +0800 Message-Id: <9408261849.AA03897@icebox.LABS.TEK.COM> To: ken@sunken.gdc.ca Cc: ip-atm@matmos.hpl.hp.com Subject: Re: JPEG/MPEG MIB In-Reply-To: Your message of Wed, 24 Aug 1994 07:47:01 -0700. <9408241447.AA04468@sunken.gdc.ca> Date: Fri, 26 Aug 1994 11:49:05 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ted Brunner Content-Length: 509 > Anyone aware of a MIB definition for JPEG and or MPEG over ATM ? There is work in the atmf SAA group on how to put MPEG-2 over atm. However they had not yet got the full answer. What they do have involves H.222, which is not fully defined. Until they have the decisions made, they'll have nothing to mib-ify. So nothing from that quarter yet... Ted Brunner Communication Systems Research Lab Tektronix MS 50-370 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06034; 26 Aug 94 16:59 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06030; 26 Aug 94 16:59 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16103; 26 Aug 94 16:59 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA091567276; Fri, 26 Aug 1994 11:54:36 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from relay.fore.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA091237273; Fri, 26 Aug 1994 11:54:33 -0700 Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA11670; Fri, 26 Aug 94 14:55:25 EDT Received: from marlin by dolphin.fore.com (4.1/SMI-4.1) id AA26612; Fri, 26 Aug 94 14:54:22 EDT Received: by marlin (4.1/SMI-4.1) id AA20528; Fri, 26 Aug 94 14:54:21 EDT Date: Fri, 26 Aug 94 14:54:21 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Perkins Message-Id: <9408261854.AA20528@marlin> To: ip-atm@matmos.hpl.hp.com, laubach@netcom.com Subject: Re: Signaling Draft and UNI 3.1 > publically available. Andy Malis has been in touch with the ATM > Forum Executive Director and we have new information. UNI 3.1 > is expected to be ratified at the September 23rd meeting of > the Forum. The ballots are going out early next week. It is > expected to be ratified at the meeting and the document will > become publically available sometime in October. Mark, I believe this information is incomplete. As I understand it, the ATM Forum does not ratify documents at the Technical Committee meetings. All final votes are taken through mailed ballots. I don't know what the Sept 23 date is. It may be either a target for one phase of the mailed-vote process, or perhaps the Technical Committee will have one final chance to modify the final document before it is mailed for a vote. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06984; 26 Aug 94 18:45 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06980; 26 Aug 94 18:45 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18084; 26 Aug 94 18:46 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA132647333; Fri, 26 Aug 1994 14:42:13 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA132317332; Fri, 26 Aug 1994 14:42:12 -0700 Received: from thumper.bellcore.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA24736; Fri, 26 Aug 1994 14:42:21 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id OAA16780; Fri, 26 Aug 1994 14:35:00 -0400 Message-Id: <199408261835.OAA16780@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Mark Laubach Cc: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of Fri, 26 Aug 94 10:10:39 -0700. <199408261710.KAA06307@terra.com21.com> Date: Fri, 26 Aug 94 14:34:55 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com [..] >>1) Proceed as per our current decisions and publish with >> UNI 3.0 only: i.e., go *now* The information we need is just what changes are wrought by 3.1 that make any material difference to the draft? I saw a posting to comp.dcom.cell-relay (can't remember who by) saying that the changes were primarily in the SSCOP protocol - which is quite immaterial to the draft we are looking at. If this is the case, proceed, and let implementers figure out that differences between 3.0 and 3.1 have no effect on this draft. gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07046; 26 Aug 94 18:51 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07042; 26 Aug 94 18:51 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18158; 26 Aug 94 18:51 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA146068011; Fri, 26 Aug 1994 14:53:31 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from igate1.melpar.esys.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA145738007; Fri, 26 Aug 1994 14:53:27 -0700 Received: by igate1.melpar.esys.com id AA12818 (5.67a/IDA-1.5 for ip-atm@matmos.hpl.hp.com); Fri, 26 Aug 1994 17:53:16 -0400 Received: from igate2.melpar.esys.com(198.4.96.2) by igate1.melpar.esys.com via smap (V1.0mjr) id sma012793; Fri Aug 26 17:52:54 1994 Received: from coolpro.advt.melpar.esys.com by igate5.isp.melpar.esys.com with SMTP id AA17323 (5.67a/IDA-1.5 for ip-atm@matmos.hpl.hp.com); Fri, 26 Aug 1994 17:52:56 -0400 Received: from stpc65.advt.melpar.esys.com by coolpro.advt.melpar.esys.com with SMTP (5.65/25-eef) id AA01962; Fri, 26 Aug 94 17:52:53 -0400 Date: Fri, 26 Aug 1994 17:52:53 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Tom Tofigh To: laubach@netcom.com Subject: Re: Signaling Draft and UNI 3.1 Cc: ip-atm@matmos.hpl.hp.com Message-Id: In-Reply-To: <199408261710.KAA06307@terra.com21.com> ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 1 X-Sun-Content-Length: 24 GO WITH UNI 3.1 AND 3.0   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07223; 26 Aug 94 19:10 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07219; 26 Aug 94 19:10 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18437; 26 Aug 94 19:10 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA119336616; Fri, 26 Aug 1994 14:30:16 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from hplms26.hpl.hp.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA119006613; Fri, 26 Aug 1994 14:30:13 -0700 Received: from thumper.bellcore.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA24599; Fri, 26 Aug 1994 14:30:14 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id PAA23026; Fri, 26 Aug 1994 15:54:07 -0400 Message-Id: <199408261954.PAA23026@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: ip-atm@matmos.hpl.hp.com Cc: gja@thumper.bellcore.com Subject: draft-armitage-ipatm-IPmc-01.txt Date: Fri, 26 Aug 94 15:54:04 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com Here's a significantly revised version of the draft I posted around 2 weeks ago. I've attempted to address the issues raised by people who followed-up on the first draft. Key changes are: - Group 224.0.0.1 is handled using a multicast server model, while all other groups are pt-mp meshes. - IP multicast routers may be 'promiscuous' members of every Class D group address. - Added new capability to be promiscuous over a _subset_ of the Class D address space. - ARP response mechanism modified. - IGMP Reports now sent as per rfc1112 again. The scope is still constrained to be merging rfc1112 and rfc1577 environments, nothing more. At this stage it has not been properly submitted as an I-D. Expressions of support (or otherwise, if merited) would be much appreciated :-) regards, gja -------------------------------------------------------------------------- Internet-Draft Grenville Armitage Bellcore Issued: August 26th, 1994 IP Multicast over UNI 3.0 based ATM Networks. Status of this Memo This document was submitted to the IETF IP over ATM WG. Publication of this document does not imply acceptance by the IP over ATM WG of any ideas expressed within. Comments should be submitted to the ip-atm@matmos.hpl.hp.com mailing list. Distribution of this memo is unlimited. This memo is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This memo describes extensions to RFC1577 (Classical IP over ATM [1]) and RFC1112 (Host Extensions for IP Multicasting [2]) to allow present generation IP multicasting on ATM networks that support Version 3.0 of the ATM Forum's UNI signalling specification. As of version 01 this memo is incomplete. 1. Overview RFC 1112 introduces the concept of IP multicasting and defines the required behaviour of hosts desiring to send to, or receive from, IP multicast groups. The example link layer technology given in that RFC is Ethernet, a technology that directly supports multicasting. ATM is a new link layer technology being utilised to support IP subnets. RFC 1483 [3] defines a mechanism for encapsulating and transmitting IP packets using AAL5 over ATM Virtual Channels (VCs). RFC 1577 defines the basic 'Classical' model of IP subnets mapped to restricted groups of ATM-connected nodes - the Logical IP Subnet (LIS). The currently published signalling specification from the ATM Forum is Version 3.0 [4] (UNI 3.0). In addition to the Bidirectional Unicast VCs used to provide the basic Classical model, UNI 3.0 also provides support for Unidirectional, Point to Multipoint VCs. This memo will describe how IP multicasting within a LIS may be achieved using meshes of UNI 3.0 point to multipoint VCs. It will also describe how IP multicast routers may extend IP multicast beyond the LIS. The ARP Server's role in the LIS is extended to keep track of IP multicast groups that are active within the LIS. The operation of the Internet Group Management Protocol (IGMP) is modified, and a new IGMP message type is proposed, to support the distribution of IP group membership information. A multicast-server architecture is used to distribute IGMP messages within the LIS. Each multicast host establishes a VC to the ARP Server, and the ARP Server establishes a multicast VC back to all multicast hosts in the LIS. This memo assumes an understanding of concepts explained in greater detail in RFC 1112, RFC 1577, UNI 3.0, and . 2. Review of RFC 1112 and IP Multicast over Ethernet. In RFC 1112 the behaviour of the transmit and receive sides are quite independent. This makes the concept of being a 'member' of an IP multicast group imprecise at the link layer interface. The interface must support the transmission of IP packets to IP an multicast group addresses whether or not the node considers itself a 'member' of that group. Consequently, group membership is effectively irrelevant to the transmit side of the link layer interfaces. No address resolution is required to transmit packets - an algorithmic mapping from IP multicast address to Ethernet multicast address is performed locally before the packet is sent out the local interface in the same 'send and forget' manner as a unicast IP packet. Joining and Leaving an IP multicast group is more explicit on the receive side - with the primitives JoinLocalGroup and LeaveLocalGroup affecting what groups the local link layer interface should accept packets from. When the IP layer wants to receive packets from a group, it issues JoinLocalGroup. When it no longer wants to receive packets, it issues LeaveLocalGroup. The role of IGMP in RFC 1112 is to support IP multicast routers attached to a given subnet. Hosts issue IGMP Report messages when they perform a JoinLocalGroup, or in response to an IP multicast router sending an IGMP Query. The sole function is to allow routers to identify what IP multicast groups have non-zero membership on the subnet. A specific IP multicast address, 224.0.0.1, is allocated for the transmission of IGMP Query messages. All IP multicast hosts must issue JoinLocalGroup for 224.0.0.1 during their initialisation. Each host keeps a list of IP multicast groups it has been JoinLocalGroup'd to. When a router issues an IGMP Query on 224.0.0.1 each host begins to send IGMP Reports for each group it is a member of. IGMP Reports are sent to the group address, not 224.0.0.1, "so that other members of the same group on the same network can overhear the Report" and not bother sending one of their own. Under RFC 1112 multicast IP routers are expected to passively receive packets on all groups. IP multicast routers conclude that a group no longer has members on the subnet when IGMP Queries no longer elict replies for a group. 3. Model of an IP over ATM endpoint. LLC/SNAP encapsulated IP packets are the default specified by RFC 1577. This model implies that IP over ATM endpoints should be viewed as having LLC entities terminating VCs on behalf of higher layer protocols (e.g. IP or ARP). The LLC entity multiplexes outgoing packets according to RFC 1483, and demultiplexes incoming packets. It is a client of the endpoint's AAL and UNI 3.0 signalling services. Only VCs directed at ISO 8802/2 layer 2 endpoints are terminated on the LLC entity. ipatm0 / | \ --------- | --------- | | | .............................. . This draft's functionality . .............................. | | | IP.1 IP.2 IP.3 | | | +++++.......+++++........+++++ ---- LLC +L.1+ +L.2+ +L.3+ ====>| U | +++++.......+++++........+++++ | N | AAL to AAL-User | | | | I | interface VC.1 VC.2 VC.3 | | | | | | 3 | +++++.......+++++........+++++ | . | AAL +A5 + +A5 + +A5 + <====| 0 | +++++.......+++++........+++++ ---- | | | --------- | --------- \ | / atm Figure 1. A single IP interface may have multiple VCs open to different destinations. Each VC is mapped through separate instances of the LLC layer and AAL5 service. Figure 1 attempts to show this relationship, where IP.{1,2,3} are the IP addresses of destinations that the local interface is connected to through VC.{1,2,3}. In a unicast-only LIS these IP addresses map to a single endpoint, and the VCs allow bidirectional flow of IP packets. The goal of this memo is to add multicast support to the model shown in Figure 1 that closely resembles the spirit of RFC 1112. References to 'transmit' and 'receive' sides refer to sections of the LLC and IP interface that handle outgoing and incoming packets respectively. 4. Multicast VCs under UNI 3.0. This memo will describe its operation in terms of 'generic' functions that should be available to clients of a UNI 3.0 signalling entity in a given ATM endpoint. The most fundamental limitations of UNI 3.0's multicast support are: - only point to multipoint, unidirectional VCs may be established, and - only the root node of a given VC may add or remove leaf nodes. Within these constraints, multicast group members can communicate by the use of full meshes, or a Multicast Server. With a mesh each transmitting host is the Root of an ATM multicast tree that has every other host in the group as a Leaf. The Multicast Server model has every group member establish a point to point VC to the Server. The Server then receives packets from members and retransmits copies to all other members. This memo utilises both models. The ARP Server functions as a 'multicast server' for traffic on the 224.0.0.1 group, in a manner transparent to the IP hosts on the LIS. All other IP multicast groups are supported by meshes of point to multipoint VCs. This avoids the need to implement a new node to function as a multicast server for conventional multicast data traffic. The following generic signalling functions are presumed to be available to AAL Users: [mneumonics subject to change, they're "off the top of my head"] L_CALL_RQ - Establish a unicast VC to a specific endpoint. L_MULTI_RQ - Establish multicast VC to a specific endpoint. L_MULTI_ADD - Add new leaf node to previously established VC. L_MULTI_DROP - Remove specific leaf node from established VC. L_RELEASE - Release unicast VC, or all Leaves of a multicast VC. The UNI 3.0 signalling exchanges that occur as a consequence of these functions are described in Appendix A. The local information passed between AAL User and UNI 3.0 signalling entity with these functions is currently beyond the scope of this memo. The following indications are assumed to be available to AAL Users, generated by by the local UNI 3.0 signalling entity: L_REMOTE_CALL - A new VC has been established to the AAL User. ERR_L_RQFAILED - A remote ATM endpoint rejected an L_CALL_RQ, L_MULTI_RQ, or L_MULTI_ADD. ERR_L_RELEASE - A remote ATM endpoint has elected to terminate a pre-existing VC. The UNI 3.0 signalling exchanges that occur to cause these indications are described in Appendix A. The local information passed between UNI 3.0 signalling entity and AAL User by these indications is currently beyond the scope of this memo. UNI 3.0 defines two ATM address formats - E.164 and ISO NSAP. UNI 3.0 defines an 'ATM Number' to identify an ATM endpoint using either format. Some public networks may only understand E.164 formatted addresses, so the ISO NSAP formatted address is included as an additional 'ATM Subaddress'. For the rest of this memo the term 'ATM Address' will be used to mean either a single 'ATM Number' or an 'ATM Number' combined with an 'ATM Subaddress'. 5. Transmitting IP packets to Multicast groups. The IP layer must be able to send a packet to an IP multicast group at any time, without prior warning. This implies a mechanism for keeping track of group membership, because unlike Ethernet multicast the source must 'know' its destinations before transmissions. The RFC 1577 ARP Server is an ideal candidate for extension to provide this mechanism. It keeps a table of {IP,ATM} address pairs for all IP endpoints in the LIS (hosts, or routers with other interfaces outside the LIS). It can either be configured with certain table entries, or 'learn' entries from the ARPing activity of hosts on the LIS. The extension for multicast is as follows: - Table entries for Class D IP addresses should be extended to hold 1 or more ATM addresses, i.e. {IP, ATM.1, ATM.2, .... ATM.n} - A new ARP message type is added - ARP_MULTI. This is based on ARP_REPLY but includes two new fields. - Group address 224.0.0.1 is permanently configured as a special case with only one member, the ARP Server itself. 5.1 Retrieving Group Membership from the ARP Server. When a host is required to transmit a packet to a Class D address it issues an ARP_REQUEST to the ARP Server in exactly the same manner as for a unicast packet. If the ARP Server had no mapping for the desired Class D address an ARP_NAK will be returned. In this case the IP packet MUST be discarded silently. If a match is found in the ARP Server's tables it proceeds to return addresses ATM.1 through ATM.n in a sequence of ARP_MULTIs. A simplistic mechanism is used to detect and recover from loss of ARP_MULTI messages. Each ARP_MULTI carries a new boolean field x, and a 31 bit integer field y - expressed as ARP_MULTI(x,y). Field y acts as a sequence number, starting at 1 and incrementing for each ARP_MULTI sent. Field x acts as an 'end of reply' marker. When x == 1 the ARP procedure is considered complete. For a group with n members the following sequence would occur: ARP_MULTI(0,1) carries back ATM.1 ARP_MULTI(0,2) carries back ATM.2 ....... ARP_MULTI(1,n) carries back ATM.n If n == 1 then only ARP_MULTI(1,1) is sent. Typical failure mode will be losing one or more of ARP_MULTI(0,1) through ARP_MULTI(0,n-1). This is detected when y jumps by more than one between consecutive ARP_MULTI's. An alternative failure mode is losing ARP_MULTI(1,n). A timer MUST be implemented to flag the failure of the last ARP_MULTI to arrive. [timer value to be decided]. If a 'sequence jump' is detected, the host MUST wait for the ARP_MULTI(1,n), discard all results, and repeat the ARP REQUEST. If a timeout occurs, the host MUST discard all results, and repeat the ARP_REQUEST. 5.2 Format of the ARP_MULTI message. The ATM ARP_MULTI message is based on the ARP_REPLY message, with an additional 32 bit field to hold x and y. An ARP_MULTI is indicated by an 'operation type value' of 11 (decimal). The message format is: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shtl 8 bits Type & length of source ATM number (q) ar$sstl 8 bits Type & length of source ATM subaddress (r) ar$op 16 bits Operation code (request, reply, or NAK) ar$spln 8 bits Length of source protocol address (s) ar$thtl 8 bits Type & length of target ATM number (x) ar$tstl 8 bits Type & length of target ATM subaddress (y) ar$tpln 8 bits Length of target protocol address (z) ar$seqxy 32 bits Boolean flag x and sequence number y. ar$sha qoctets source ATM number ar$ssa roctets source ATM subaddress ar$spa soctets source protocol address ar$tha xoctets target ATM number ar$tsa yoctets target ATM subaddress ar$tpa zoctets target protocol address ar$seqxy is coded with flag x in the leading bit, and sequence number y coded as an unsigned integer in the remaining 31 bits. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x| y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 6.6 of RFC 1577 should be consulted for specific details and coding of all other fields. 5.3 Establishing the Multicast VC. An L_MULTI_RQ is then issued for ATM.n, followed by an L_MULTI_ADD for every member of the set {ATM.1, ....ATM.(n-1)} (assuming the set is non-null). The packet is then transmitted over the newly created VC just as it would be for a unicast VC. After transmitting the packet the local interface holds the VC open and marks it as the active path out of the host for any subsequent IP packets being sent to that Class D address. When establishing a new multicast VC is is possible that one or more ostensible group members may reject an L_MULTI_RQ or L_MULTI_ADD. If this occurs then the ATM address of the node responsible is dropped from the set {ATM.1, ATM.2, .... ATM.n} returned by the ARP Server, and the creation of the multicast VC continues. [Further action necessary?] 5.4 Managing the Multicast VC. Multicast VCs have the potential to be expensive in their use of resources. Therefore each VC MUST have a configurable inactivity timer associated with it. If the timer expires, an L_RELEASE is issued for that VC, and the Class D address is no longer considered to have an active path out of the local host. Choice of timer period is beyond the scope of this memo. During the life of a multicast VC an ERR_L_RELEASE may be received indicating that a leaf node has terminated its participation at the ATM level. The ATM endpoint associated with the ERR_L_RELEASE MUST be removed from the locally held set {ATM.1, ATM.2, .... ATM.n} associated with the VC. Special handling of packets transmitted to 224.0.0.1 is left up to the ARP Server. ARP_REQUESTS for this group receive the ARP Server's own ATM address in response, resulting in the ARPing host creating a unidirectional VC to the ARP Server's IP layer. From the host's perspective it is the root of a normal multicast VC, although it has only one leaf. Section 6 describes how the ARP Server handles 224.0.0.1 and tracks current group membership. Section 7 describes what happens if group membership changes while the VC is open. 6. Joining an IP Multicast Group to Receive packets. A host is a 'group member', in the sense that a member receives packets directed at the group, when its ATM address appears in the ARP Server's table entry for the group's IP address. The 224.0.0.1 multicast group plays a key role in distributing information about group membership to the ARP Server and multicast capable hosts in the LIS. For this reason the 224.0.0.1 group is constructed differently. The ARP Server takes an active role and establishes itself as a multicast server for this group, rather than allowing the IP hosts to construct a point to point mesh. RFC1112 expects that routers are capable of behaving 'promiscuously'. This is achieved by allowing routers to register with the ARP Server to be returned as 'wild card' members of all Class D addresses. However, a problem inherent in the current ATM model is that such behaviour may be wasteful of reassembly resources on the router's ATM interface. This draft proposes a generalisation to the notion of 'wild card' entries, enabling routers to limit themselves to 'blocks' of the Class D address space. The application of this facility is described in greater detail in Section 9. A block can be as small as 1 (a single group) or as large as the entire Class D address space (default 'promiscuous' behaviour). The key extensions required to manage the ARP Server table entries are: - A new IGMP message type is defined called ATMMC, with two subtypes: - ATMMC_JOIN carries a Class D IP address and 32 bit mask (to specify a contiguous block of groups being joined) and a unicast ATM address (of the node joining). - ATMMC_LEAVE carries a Class D IP address and 32 bit mask (to specify a contiguous set of groups being left) and a unicast ATM address (of the node leaving). - IGMP ATMMC messages MUST be transmitted to address 224.0.0.1. The mechanism described in RFC 1112 for redundant transmission of IGMP Reports MUST be applied to IGMP ATMMC messages. - The ARP Server contains an IP layer, with an IGMP entity and exception handling for packets received for group 224.0.0.1. - JoinLocalGroup allows only a single group to be joined at a time. Two IGMP messages are transmitted: - IGMP Report, and - IGMP ATMMC_JOIN, identifying the IP group being joined, and the hosts ATM address. - LeaveLocalGroup now results in an IGMP ATMMC_LEAVE being transmitted, identifying the IP group being left, and the host's ATM address. - IP endpoints with special requirements (e.g. IP multicast routers) may directly issue IGMP ATMMC_JOINs and ATMMC_LEAVEs specifying groups of Class D addresses. An IGMP Report cannot be issued for such an operation. - When an IGMP ATMMC_JOIN is received by the ARP Server's IGMP entity, it adds the specified ATM address to the ARP entry for the specified Class D address(es). This includes ATMMC_JOINs for group 224.0.0.1, although these are never reported in response to ARP_REQUESTs. - When an IGMP ATMMC_LEAVE is received by the ARP Server's IGMP entity, it removes the specified ATM address(es) from the ARP entry for the specified Class D address. - The ARP Server maintains a single Point to Multipoint VC out to every IP multicast host. When they join group 224.0.0.1 they are added as a leaf, when they leave group 224.0.0.1 they are dropped. - Most IGMP messages arriving from individual hosts are processed locally AND retransmitted on the Point to Multipoint VC. - ATMMC_JOINs for group 224.0.0.1 are NOT retransmitted by the ARP Server's IGMP entity. - IGMP entities ignore ATMMC_JOIN or ATMMC_LEAVE messages that simply confirm information already held by the entity. 6.1 Format of the IGMP ATMMC Messages. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. IGMP messages start with the following 4 byte header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Subtype | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version = 1 The Type field values are: 1 = Host Membership Query. (Subtype is ignored). 2 = Host Membership Report. (Subtype is ignored). 3 = DVMRP [5]. (4 subtypes defined). 4 = ATMMC. (2 subtypes defined) For ATMMC the Subtype field values shall be: 1 = JOIN. 2 = LEAVE. The ATMMC message contents follow immediately after the IGMP header in the IP packet. The format of ATMMC_JOIN and ATMMC_LEAVE are exactly the same. It borrows fields from the ATM ARP packet format in RFC 1577 to carry a single IP address, an IP address mask, an ATM address, and (optionally) an ATM subaddress: Data: ar$shtl 8 bits Type & length of source ATM number (q). ar$sstl 8 bits Type & length of source ATM subaddress (r). ar$spa 32 bits Class D address of IP multicast group. ar$mask 32 bits Mask defining block of Class D addresses. ar$sha qoctets source ATM number (E.164 or ATM Forum NSAPA). ar$ssa roctets source ATM subaddress (ATM Forum NSAPA). Refer to RFC 1577, section 6.6 for the coding of the ar$shtl and ar$sstl fields. 6.1.1 Construction of the Class D address and Mask. The field ar$spa specifies a base address of a block containing one or more Class D addresses. Class D addresses are in the range 224.0.0.0 to The high-order four bits of ar$spa MUST be set to "1110". No bit in ar$spa may be set to 1 if the corresponding bit in ar$mask is set to 0. The high-order four bits in ar$mask MUST be set to "1111". A 'block' is the set of IP addresses that conform to the following equation: (IP address) AND (ar$mask) == (ar$spa) Some examples: ar$spa = 224.0.0.32 and ar$mask = 255.255.255.224 refers to the block between 224.0.0.32 and 224.0.0.63. ar$spa = 224.0.0.0 and ar$mask = 255.255.255.224 refers to the block between 224.0.0.0 and 224.0.0.31. ar$spa = 224.0.20.0 and ar$mask = 255.255.252.0 refers to the block between 224.0.20.0 and 224.0.23.255. 6.1.2 Important Default Values. JoinLocalGroup and LeaveLocalGroup MUST specify a mask value of 255.255.255.255. An ATMMC_JOIN with the following field values refers to a single Class D address X: ar$spa = X and ar$mask = 255.255.255.255 A router choosing to behave strictly in accordance with RFC1112 MUST specify a mask value of 240.0.0.0. The following field values encompass the entire Class D space: ar$spa = 224.0.0.0 and ar$mask = 240.0.0.0 The exception is group 224.0.0.1, which the ARP Server will ONLY ever return its own ATM address for. The use of alternative mask values is discussed in Section 9. 6.2 Establishing the 224.0.0.1 signalling group. Consider that the transmit side functions independently, as described in section 5. The ARP Server only returns itself as a member of 224.0.0.1, no matter what additional hosts it actually knows about. When multicast hosts on the LIS start up RFC1112 requires that they join 224.0.0.1. The first host to execute JoinLocalGroup to 224.0.0.1 must send an IGMP ATMMC_JOIN sent to 224.0.0.1. The transmit side has no VC to this group, so it queries the ARP Server. The ARP Server returns itself as the only group member. The host then establishes a multicast VC to the ARP Server, marking it as the VC for traffic to 224.0.0.1. (The reason for a multicast VC is explained at the end of this subsection). Finally the IGMP ATMMC_JOIN is sent over the VC. The ARP Server's IGMP entity receives the ATMMC_JOIN and adds the host to its list of members of 224.0.0.1. The ARP Server maintains a multicast VC out to all members of 224.0.0.1, and it adds the new host as a new leaf node. The ATMMC_JOIN message is not propagated. The second host to execute JoinLocalGroup for 224.0.0.1 will perform exactly the same procedure, with the ARP Server still only returning itself as the only member of 224.0.0.1. The second host establishes a multicast VC to the ARP Server and sends the IGMP ATMMC_JOIN for 224.0.0.1. As for the first host, this results in the second host being added to the ARP Server's list of 224.0.0.1 members. The new host is also added as a leaf node of the ARP Server's 224.0.0.1 multicast VC. The second host's ATMMC_JOIN message is not propagated. This process continues for all IP multicast hosts on the LIS (including IP multicast routers). Once initialised, each IP multicast host on the LIS will have a multicast VC to the ARP Server marked as '224.0.0.1', and an incoming VC from the ARP Server on which IGMP traffic from other hosts will arrive. The VC to the ARP Server for 224.0.0.1 traffic is established as a 'multicast' VC for two reasons: - The transmit side of each host does not need 'special case' code to handle 224.0.0.1 any differently from other Class D addresses. - A multicast VC uses no reverse path resources, which is reasonable as the reverse path is handled by the multicast VC originating from the ARP Server. 6.3 Joining A General Group X. When a host joins any other IP multicast group it sends an IGMP ATMMC_JOIN to 224.0.0.1. Now the ARP Server's IGMP entity handles things slightly differently. It updates the ARP tables (as before) AND retransmits the IGMP message to all other members of 224.0.0.1. This behaviour is used in section 7 to allow nodes that are already members of a given group to note the new member. The transmission of an IGMP Report to the group being joined causes an ARP request to be issued and the establishment of a VC out the group being joined. If the local host does not transmit to the group for a period of time the inactivity timer will trigger the closure of the VC. This will not alter the hosts 'membership' of the group. 6.4 Redundant IGMP Messages. As a weak form of protection from loss, IGMP messages MUST be retransmitted twice. Host and Router IGMP entities MUST silently discard incoming IGMP messages that appear redundant (e.g.declaring a new host has left a group when that host is not listed as being a member). The ARP Server's IGMP entity MUST propagate all IGMP messages (except as noted in section 6.2). 7. Adding A New Leaf to Outgoing Multicast VC. Updating the ARP Server's tables does not account for hosts who have already established multicast VCs for transmission to the group's previous members. The solution to this problem is for every host's IGMP entity to inspect ATMMC_JOIN and ATMMC_LEAVE messages arriving on 224.0.0.1. If an ATMMC_JOIN is seen that refers to (or encompasses) an IP group for which the transmit side already has a VC open, the new member's ATM address is extracted and an L_MULTI_ADD issued locally. This ensures that hosts already sending to a given group will immediately add the new member to their list of recipients. It also ensures that routers joining a 'block' of groups are added by all hosts sending to groups within the block. Blocking the propagation of ATMMC_JOINs to 224.0.0.1 by the ARP Server's IGMP entity ensures the 224.0.0.1 group remains a special case. 8. Leaving an IP Multicast Group. Leaving an IP multicast group involves removing the local hosts entry from the ARP Server, and ensuring that hosts stop sending to the leaving node. Both are the reverse of the 'join' operations described in section 6 and 7. The ARP Server's response: LeaveLocalGroup results in ATMMC_LEAVE messages being sent to 224.0.0.1 using the same procedure as for ATMMC_JOIN. The ARP Server's IGMP entity notes the event, and removes the specified ATM address appropriately. If an IP multicast host issues a LeaveLocalGroup for 224.0.0.1 it will be considered to have ceased membership of all other groups for which it may have joined. The ARP Server MUST flush that hosts's ATM address from any Class D address entries it appears in. Response of an arbitrary host in the LIS: If an ATMMC_LEAVE is seen that refers to (or encompasses) an IP group for which the transmit side already has a VC open, the leaving member's ATM address is extracted and an L_MULTI_DROP issued locally. This ensures that hosts already sending to a given group will immediately delete the leaving member from their list of recipients (leaf nodes). If an ATMMC_LEAVE is seen that refers to group 224.0.0.1 then the ATM address of the host issuing the IGMP messages MUST be removed from every multicast VC on the local host that it may be a Leaf of. The transmit side of the interface MUST NOT shut down an active VC to a group for which the receive side has just executed a LeaveLocalGroup. This behaviour is consistent with the model of hosts transmitting to groups regardless of their own membership status. RFC 1112 requires all multicast IP hosts to be members of 224.0.0.1, so leaving 224.0.0.1 is considered to indicate cessation of support for IP multicasting. Normally this is not expected to happen. 9. Beyond the LIS - Multicast IP Router behaviour. Multicast routers are required for an IP multicast group to span more than the local LIS. The multicast router may be a tunneling router, or may have direct connection to another multicast-capable link layer. Decisions by routers to receive packets from given multicast groups will depend on algorithms or policies beyond the scope of this memo (e.g. DVMRP [5]). It is assumed that the IP multicast router will be implemented over the same sort of IP-ATM interface that a multicast host's IP layer would use. They will use the basic services described in the preceeding sections to join and leave IP multicast groups as necessary. 9.1 Sending to a Group. If the router needs to transmit a packet to a group within the LIS it opens a multicast VC in the same manner as a normal host would. Once a VC is open, the router's IGMP entity monitors 224.0.0.1 for IGMP ATMMC_JOIN and ATMMC_LEAVE messages to update the set of leaf nodes it sends to, as a normal host would. The IP multicast router's transmit side MUST implement inactivity timers to shut down idle outgoing VCs, as for normal hosts. As with normal host, the router does not need to be a member of a group it is sending to. 9.2 Promiscuously Joining Groups. Once initialised, the simplest model of router operation is that it issues an ATMMC_JOIN encompassing the entire Class D address space. In effect it becomes 'promiscuous', as it will be a leaf node to all present and future multicast VCs established on the LIS. How a router chooses which groups to propagate outside the LIS are beyond the scope of this memo. Consistent with RFC 1112, IP multicast routers may retain the use of IGMP Query and IGMP Report messages to ascertain group membership. 9.3 Forward Multicast Traffic Across the LIS. Under some circumstances the LIS may simply be another hop between IP subnets that have participants in a multicast group. [LAN.1] ----- IPmcR.1 -- [LIS] -- IPmcR.2 ----- [LAN.2] LAN.1 and LAN.2 are subnets (such as Ethernet) with attached hosts that are members of group X. IPmcR.1 and IPmcR.2 are multicast routers with interfaces to the LIS. A traditional solution would be to treat the LIS as a unicast subnet, and use tunneling routers. However, this would not allow hosts on the LIS to participate in the cross-LIS traffic. Assume IPmcR.1 is receiving packets promiscuously on its LAN.1 interface. Assume further it is configured to propagate multicast traffic to all attached interfaces. In this case that means the LIS. When a packet for group X arrives on its LAN.1 interface, IPmcR.1 simply sends the packet to group X on the LIS interface as a normal host would (ARPing for group X, creating the VC, sending the packet). Assuming IPmcR.2 initialised itself as a wild-card entry in the ARP Server's tables, it will have been returned as a member of X, even if no other nodes on the LIS were members. All packets for group X received on its LIS interface may be retransmitted on LAN.2. If IPmcR.1 is similarly initialised the reverse process will apply for multicast traffic from LAN.2 to LAN.1, for any multicast group. 9.4 Restricted 'promiscous' Operation. Both Unicast and Multicast IP routers have a common problem. Each will suffer from limitations on the number of reassembly engines available at their ATM interfaces. For the unicast router this will limit the number of destinations outside the RFC 1577 LIS that hosts may be sending to at any one time. Each destination IP address results in a new VC to the router (and because of the bidirectional nature of a unicast VC, this consumes a segmentation engine too). The problem is magnified in the multicast situation. Being 'promiscuous' in the RFC 1112 sense means that for every M hosts sending to N groups, the router's ATM interface will have M*N incoming reassembly engines tied up. It is not hard to envisage situations where a number of multicast groups are active within the LIS but are not required to be propagated beyond the LIS itself. An example might be a distributed simulation system specifically designed to use the high speed IP/ATM environment. There may be no practical way its traffic could be utilised on 'the other side' of the multicast router, yet under the conventional scheme the router would have to be a leaf to each participating host anyway. In this situation the LIS administrator might configure their multicast routers to exclude sections of the Class D address space when issuing ATMMC_JOIN(s). Another scenario involves the product M*N exceeding the capacity of a single router's interface (especially if the same interface must also support a unicast IP router service). A LIS administrator may choose to add a second node, to function as a parallel IP multicast router to the same 'out of LIS' networks. Each router would be configured to be 'promiscuous' over separate parts of the Class D address space, thus sharing the load. This sharing would be completely transparent to IP hosts within the LIS. Restricted promiscuous mode does not break RFC 1112's use of IGMP Report messages. If the router is configured to serve a given block of Class D addresses, it will receive the IGMP Report. If the router is not configured to support a given block, then the existence of an IGMP Report for a group in that block is irrelevant. All routers are able to track membership changes through the IGMP ATMMC traffic on 224.0.0.1 anyway. Mechanisms for establishing these modes of operation are beyond the scope of this memo. 10. ARP Server Implementation Issues. This memo specifies the ARP Server's required behaviour, without direct reference to internal architecture or implementation. The ARP tables must be carefully constructed to support 'wild card' entries. Interaction between the IGMP entity, the ARP tables, and the retransmission of IGMP messages on the 224.0.0.1 VC has the potential to generate 'race' conditions if implemented poorly. The ARP Server may need to serialise its processing of 'simultaneous' ARP_REQUEST and IGMP messages, to ensure all multicast nodes remain aware of changes to group memberships. 11. Summary of Key Decisions. The key decisions this memo proposes: o General IP multicast in the LIS is through mesh of Point to Multipoint VCs rather than a central Multicast Server. The one exception is group 224.0.0.1, for which the ARP Server transparently establishes itself as a Multicast Server. o ATM ARP Server role extended. - Class D IP addresses may be mapped to 0 or more ATM addresses. - Class D address 224.0.0.1 returns only the ARP Server's address. - New ARP message type, ARP_MULTI. ATM ARP_REQUESTS issued for Class D addresses may get 1 or more ARP_MULTI messages as the ARP Server passes back all group member's ATM addresses. - IGMP entity added to ARP Server, with ability to modify ARP table entries. - Specific handling of 224.0.0.1 membership to create a 'multicast server' architecture. - 'wild card' ARP table entries possible, where a single ATM address is simultaneously associated with blocks of Class D addresses. o IGMP protocol modified and extended. - Two new IGMP messages: - ATMMC_JOIN Indicates IP group(s) being joined. Carries ATM address. - ATMMC_LEAVE Indicates IP group(s) being left. Carries ATM address. - All IGMP ATMMC messages, from hosts or routers, are sent to 224.0.0.1. - IGMP entities on all nodes monitor ATMMC traffic to add or remove leaf nodes to active, outgoing, multicast VCs. o ATM endpoint model. - Attempted decoupling of IP-ATM interface, local UNI 3.0 signalling service, and local ATM/AAL service descriptions. - Explicitly identifies an LLC 'entity' that terminates or originates VCs for RFC 1483 compliant LLC/SNAP encapsulated traffic. 12. Open Issues. Some issues have not been addressed, although they may be in future revisions. o Quality of Service has not been addressed. This is a current issue for both unicast and multicast IP over ATM. o No attempt has been made to reconcile or optimise the use of IGMP messages. ATMMC_JOIN and ATMMC_LEAVE contain a superset of the information in an IGMP Report. o Robustness of IGMP message exchange. Current mechanism inherits the RFC 1112 approach of "repeat it a couple of times, and pray". o ARP Server has no mechanism for realizing group members have silently died. [This probably should be attended to as a priority]. o Using a mesh of point to multipoint VCs to connect group members places a high load on both the switch and the ATM reassembly engines of each host receiving group transmissions. When an IP host joins a group, every host transmitting to that group adds it as a new leaf. This results in a new incoming VC and reassembly instance at the receiver for every VC it has become a leaf to. If an IP host joins multiple groups the situation is exacerbated. Implementations might consider reusing VCs if a destination ATM node's IP interface is a member of multiple groups. o No attempt is made to utilise indications from the ATM layer that remote nodes have either added the local node as a leaf, or dropped themselves from a VC originating at the local node. o The future development of ATM Group Addresses and Leaf Initiated Join to ATM Forum's UNI specification has not been addressed. The problems identified in this memo with respect to VC scarcity and impact on receive side reassembly engines will not be fixed by such developments in the signalling protocol. Security Consideration Security consideration are not addressed in this memo. Acknowledgments I would like to thank John Moy of Cascade Communications Corp. for initially suggesting the idea of wild-card entries in the ARP Server. Author's Address Grenville Armitage MRE 2P340, 445 South Street Morristown, NJ, 07960-6438 USA Email: gja@thumper.bellcore.com References [1] Laubach, M., "Classical IP and ARP over ATM", RFC1577, Hewlett-Packard Laboratories, December 1993 [2] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, Standford University, August 1989. [3] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaption Layer 5", RFC 1483, USC/Information Science Institute, July 1993. [4] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993 [5] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. Appendix A. UNI 3.0 Multicast Support - A Brief Overview. This section provides a summary of point-to-multipoint signaling procedures. Readers are referred to [4]. [...to be written. refer to for almost all UNI 3.0 IE and field values...]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03597; 29 Aug 94 11:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03593; 29 Aug 94 11:24 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08871; 29 Aug 94 11:24 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA081627226; Mon, 29 Aug 1994 06:33:46 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA081297213; Mon, 29 Aug 1994 06:33:33 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.3-10 #7256) id <01HGH6G08TLS8Y5O06@sys30.timeplex.com>; Mon, 29 Aug 1994 09:35:43 -0400 (EDT) Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA08073; Mon, 29 Aug 94 09:33:41 EDT Date: Mon, 29 Aug 1994 09:33:38 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Forwarded messages from the ip-atm list To: ip-atm@matmos.hpl.hp.com Cc: malis@maelstrom.timeplex.com, hunt@maelstrom.timeplex.com, hunt_doug@corp.timeplex.com Message-Id: <9408291333.AA08073@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT These four messages are from the ip-atm mail archive. I didn't get the messagefrom Mark and Drew, so I'm forwarding them in case you folks didn't get them either. I've been pushing Mark to go with UNI 3.1 rather than 3.0. I'll be sending a clarification to the list this morning. Andy ------- Forwarded Messages Date: Fri, 26 Aug 1994 10:10:39 -0700 Message-Id: <199408261710.KAA06307@terra.com21.com> To: ip-atm@matmos.hpl.hp.com From: Mark Laubach Subject: Signaling Draft and UNI 3.1 IP-ATM'ers: At the Toronto meeting we elected to have the draft focus on UNI 3.0 and include UNI 3.1 as part of the proposed -> draft status rewrite. Our decision was based on the uncertainty of when UNI 3.1 would be publically available. Andy Malis has been in touch with the ATM Forum Executive Director and we have new information. UNI 3.1 is expected to be ratified at the September 23rd meeting of the Forum. The ballots are going out early next week. It is expected to be ratified at the meeting and the document will become publically available sometime in October. Due to this clarification, I want to open the timing again with the WG. We have a couple options: 1) Proceed as per our current decisions and publish with UNI 3.0 only: i.e., go *now* Timing notes: we can proceed directly to the IESG with the current draft after this last call closes. 2) Aim the document at UNI 3.1, with treatment for UNI 3.0 relegated to an appendix, or similar; i.e., wait and go with 3.1 and 3.0. Timing notes: we have to hold the current draft until the September 23rd ratification date, then go through another last call before submitting to the IESG. This will delay the draft becoming an RFC until sometime in mid-late November. So to reopen the question to the WG, the options are: Go with 3.0 now. Wait and go with 3.1 and 3.0. This is an email based WG issue. Please respond back to the list with a simple "go" or "wait" or similar and any short clarification questions. This is not a vote, but I will give a general summary of how the consensus is running at the end of day September 1. Thanks, Mark ------- Message 2 Date: Fri, 26 Aug 94 14:54:21 EDT From: Drew Perkins Message-Id: <9408261854.AA20528@marlin> To: ip-atm@matmos.hpl.hp.com, laubach@netcom.com Subject: Re: Signaling Draft and UNI 3.1 > publically available. Andy Malis has been in touch with the ATM > Forum Executive Director and we have new information. UNI 3.1 > is expected to be ratified at the September 23rd meeting of > the Forum. The ballots are going out early next week. It is > expected to be ratified at the meeting and the document will > become publically available sometime in October. Mark, I believe this information is incomplete. As I understand it, the ATM Forum does not ratify documents at the Technical Committee meetings. All final votes are taken through mailed ballots. I don't know what the Sept 23 date is. It may be either a target for one phase of the mailed-vote process, or perhaps the Technical Committee will have one final chance to modify the final document before it is mailed for a vote. Drew - ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com ------- Message 3 To: Mark Laubach Cc: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of Fri, 26 Aug 94 10:10:39 -0700. <199408261710.KAA06307@terra.com21.com> Date: Fri, 26 Aug 94 14:34:55 -0400 From: gja@thumper.bellcore.com [..] >>1) Proceed as per our current decisions and publish with >> UNI 3.0 only: i.e., go *now* The information we need is just what changes are wrought by 3.1 that make any material difference to the draft? I saw a posting to comp.dcom.cell-relay (can't remember who by) saying that the changes were primarily in the SSCOP protocol - which is quite immaterial to the draft we are looking at. If this is the case, proceed, and let implementers figure out that differences between 3.0 and 3.1 have no effect on this draft. gja - --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635 ------- Message 4 Date: Fri, 26 Aug 1994 17:52:53 From: Tom Tofigh To: laubach@netcom.com Subject: Re: Signaling Draft and UNI 3.1 Cc: ip-atm@matmos.hpl.hp.com Message-Id: In-Reply-To: <199408261710.KAA06307@terra.com21.com> - ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 1 X-Sun-Content-Length: 24 GO WITH UNI 3.1 AND 3.0 ------- End of Forwarded Messages   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04106; 29 Aug 94 11:59 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04102; 29 Aug 94 11:59 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09560; 29 Aug 94 11:59 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA099411016; Mon, 29 Aug 1994 07:36:56 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA099081009; Mon, 29 Aug 1994 07:36:49 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.3-10 #7256) id <01HGH8JDXPYO8Y5PEF@sys30.timeplex.com>; Mon, 29 Aug 1994 10:35:43 -0400 (EDT) Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA10010; Mon, 29 Aug 94 10:33:40 EDT Date: Mon, 29 Aug 1994 10:33:40 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of "Fri, 26 Aug 1994 14:54:21 EDT." <9408261854.AA20528@marlin> To: Drew Perkins , laubach@netcom.com, gja@thumper.bellcore.com Cc: ip-atm@matmos.hpl.hp.com, malis@maelstrom.timeplex.com Message-Id: <9408291433.AA10010@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Drew, Grenville, Mark, IP-ATMers, Let me clarify some questions I've seen on the list. > I believe this information is incomplete. As I understand it, the > ATM Forum does not ratify documents at the Technical Committee meetings. > All final votes are taken through mailed ballots. I don't know what the > Sept 23 date is. It may be either a target for one phase of the mailed-vote > process, or perhaps the Technical Committee will have one final chance to > modify the final document before it is mailed for a vote. Here is the exact information I got from the Forum: The 3.1 spec and ballot are to be mailed to the ATM Forum membership early this week (today or tomorrow). All ballots will have to be received by 9/23. The results of the vote will be given to the board of directors by COB on 9/23. Assuming the vote is positive (which is a pretty safe assumption, given the amount of work that's gone into it), the board will direct that the vote be announced and the document be released. The vote will probably be announced at the Tech. Committee meeting on 9/26. Once the ratification is announced, the document can be referenced by the signaling spec. My own preference is that we do the right thing now (going with 3.1, which has some pretty important improvements from 3.0), before too much code gets written and set in stone out in the field, which will happen as soon as the signaling spec is published as an RFC. It'll be October by the time an RFC could get published, anyway, which means if we go with 3.0 the spec will already out of date as soon as it hits the street. > I saw a posting to comp.dcom.cell-relay (can't remember who > by) saying that the changes were primarily in the SSCOP > protocol - which is quite immaterial to the draft we > are looking at. > If this is the case, proceed, and let implementers figure > out that differences between 3.0 and 3.1 have no effect on > this draft. While SSCOP did change between 3.0 and 3.1 (thanks to the ITU, not the ATM Forum), that is far from the entire scope of the changes. Here are some of the changes that are more relevant to the signaling spec (just about all of these are for alignment with changes to Q.2931 since UNI 3.0 came out): o In the SETUP message, the ATM User Cell Rate IE has been replaced by the ATM Traffic Descriptor IE. o Some of the IE coding rules have been changed or clarified. o Changes to the ATM ALL Parameters IE, including removing the Mode Identifier. o Changes to B-LLI and B-HLI codings. o New Cause values. o Complete replacement of the section describing the Quality of Service Parameter IE. o Major changes to Annex F, ATM Adaptation Layer Parameters Negotiation. o Corrections to typos in Appendix D, Example Signalling Codings (note that these examples are heavily relied upon by our signaling spec). o A brand new Appendix F, Guidelines on the Use of Bearer Class, Traffic Parameters, and QoS. This new Appendix has some pretty important information on the allowed combinations of Bearer Capabilities, Traffic Parameters, and QoS. In short, the changes really improve the quality of the UNI spec in areas that are crucial to the signaling draft, as well as bring the UNI spec into Q.2931 conformance, and I think we would do doing the community a grave misservice if we waited well over at least six months, and after a large number of implementations have been written, before conforming with these changes. Thanks, Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04248; 29 Aug 94 12:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04244; 29 Aug 94 12:07 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09787; 29 Aug 94 12:07 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA112331218; Mon, 29 Aug 1994 07:40:18 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA111841210; Mon, 29 Aug 1994 07:40:10 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.3-10 #7256) id <01HGH8K8YXV48Y5P7D@sys30.timeplex.com>; Mon, 29 Aug 1994 10:36:25 -0400 (EDT) Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA10024; Mon, 29 Aug 94 10:34:23 EDT Date: Mon, 29 Aug 1994 10:34:22 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: I just sent the following to the ip-atm list To: ip-atm@matmos.hpl.hp.com Cc: malis@maelstrom.timeplex.com, hunt@maelstrom.timeplex.com, hunt_doug@corp.timeplex.com Message-Id: <9408291434.AA10024@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT ------- Forwarded Message Return-Path: malis@maelstrom.timeplex.com Return-Path: Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA10010; Mon, 29 Aug 94 10:33:40 EDT Message-Id: <9408291433.AA10010@maelstrom.timeplex.com> To: Drew Perkins , laubach@netcom.com, gja@thumper.bellcore.com Cc: ip-atm@matmos.hpl.hp.com, malis@maelstrom.timeplex.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of "Fri, 26 Aug 1994 14:54:21 EDT." <9408261854.AA20528@marlin> Date: Mon, 29 Aug 1994 10:33:40 -0400 From: Andy Malis Drew, Grenville, Mark, IP-ATMers, Let me clarify some questions I've seen on the list. > I believe this information is incomplete. As I understand it, the > ATM Forum does not ratify documents at the Technical Committee meetings. > All final votes are taken through mailed ballots. I don't know what the > Sept 23 date is. It may be either a target for one phase of the mailed-vote > process, or perhaps the Technical Committee will have one final chance to > modify the final document before it is mailed for a vote. Here is the exact information I got from the Forum: The 3.1 spec and ballot are to be mailed to the ATM Forum membership early this week (today or tomorrow). All ballots will have to be received by 9/23. The results of the vote will be given to the board of directors by COB on 9/23. Assuming the vote is positive (which is a pretty safe assumption, given the amount of work that's gone into it), the board will direct that the vote be announced and the document be released. The vote will probably be announced at the Tech. Committee meeting on 9/26. Once the ratification is announced, the document can be referenced by the signaling spec. My own preference is that we do the right thing now (going with 3.1, which has some pretty important improvements from 3.0), before too much code gets written and set in stone out in the field, which will happen as soon as the signaling spec is published as an RFC. It'll be October by the time an RFC could get published, anyway, which means if we go with 3.0 the spec will already out of date as soon as it hits the street. > I saw a posting to comp.dcom.cell-relay (can't remember who > by) saying that the changes were primarily in the SSCOP > protocol - which is quite immaterial to the draft we > are looking at. > If this is the case, proceed, and let implementers figure > out that differences between 3.0 and 3.1 have no effect on > this draft. While SSCOP did change between 3.0 and 3.1 (thanks to the ITU, not the ATM Forum), that is far from the entire scope of the changes. Here are some of the changes that are more relevant to the signaling spec (just about all of these are for alignment with changes to Q.2931 since UNI 3.0 came out): o In the SETUP message, the ATM User Cell Rate IE has been replaced by the ATM Traffic Descriptor IE. o Some of the IE coding rules have been changed or clarified. o Changes to the ATM ALL Parameters IE, including removing the Mode Identifier. o Changes to B-LLI and B-HLI codings. o New Cause values. o Complete replacement of the section describing the Quality of Service Parameter IE. o Major changes to Annex F, ATM Adaptation Layer Parameters Negotiation. o Corrections to typos in Appendix D, Example Signalling Codings (note that these examples are heavily relied upon by our signaling spec). o A brand new Appendix F, Guidelines on the Use of Bearer Class, Traffic Parameters, and QoS. This new Appendix has some pretty important information on the allowed combinations of Bearer Capabilities, Traffic Parameters, and QoS. In short, the changes really improve the quality of the UNI spec in areas that are crucial to the signaling draft, as well as bring the UNI spec into Q.2931 conformance, and I think we would do doing the community a grave misservice if we waited well over at least six months, and after a large number of implementations have been written, before conforming with these changes. Thanks, Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04345; 29 Aug 94 12:23 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04341; 29 Aug 94 12:23 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10087; 29 Aug 94 12:23 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA127772751; Mon, 29 Aug 1994 08:05:51 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA127442748; Mon, 29 Aug 1994 08:05:48 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id LAA06585; Mon, 29 Aug 1994 11:04:21 -0400 Message-Id: <199408291504.LAA06585@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: Andy Malis Cc: Drew Perkins , laubach@netcom.com, gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of Mon, 29 Aug 94 10:33:40 -0400. <9408291433.AA10010@maelstrom.timeplex.com> Date: Mon, 29 Aug 94 11:04:20 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com Andy, >>I think we would do doing the >>community a grave misservice if we waited well over at least six >>months, and after a large number of implementations have been written, >>before conforming with these changes. I agree with your observation about the changes. One point that may bother implementors from 'outside' the ATMF is just where will they be able to get copies of 3.1 in time to start work when the RFC appears (or we agree to have the draft based on 3.1). I know I could probably get the text, but "Dr Uni-Researcher" might not know where to start. gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04582; 29 Aug 94 12:51 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04578; 29 Aug 94 12:51 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10731; 29 Aug 94 12:51 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA144593854; Mon, 29 Aug 1994 08:24:14 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA144263851; Mon, 29 Aug 1994 08:24:11 -0700 Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.3-10 #7256) id <01HGHAAK58HC8Y5PUL@sys30.timeplex.com>; Mon, 29 Aug 1994 11:25:52 -0400 (EDT) Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA11377; Mon, 29 Aug 94 11:23:52 EDT Date: Mon, 29 Aug 1994 11:23:51 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of "Mon, 29 Aug 1994 11:04:20 EDT." <199408291504.LAA06585@thumper.bellcore.com> To: gja@thumper.bellcore.com Cc: Andy Malis , Drew Perkins , laubach@netcom.com, ip-atm@matmos.hpl.hp.com Message-Id: <9408291523.AA11377@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Grenville, > I agree with your observation about the changes. One point that > may bother implementors from 'outside' the ATMF is just where > will they be able to get copies of 3.1 in time to start work > when the RFC appears (or we agree to have the draft based on > 3.1). I know I could probably get the text, but "Dr Uni-Researcher" > might not know where to start. I can't speak for the Forum on this issue, of course, but once it is approved, it would probably be seen to be in the Forum's best interest to get it distibuted as quickly and widely as possible. It is available now to Forum members in both hardcopy and postscript forms in the form of updates to UNI 3.0. Cheers, Andy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04625; 29 Aug 94 12:53 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04621; 29 Aug 94 12:53 EDT Received: from lists.psi.com by CNRI.Reston.VA.US id aa10755; 29 Aug 94 12:53 EDT Received: by lists.psi.com (5.65b/SMI-4.1.3-PSI) id AA09759; Mon, 29 Aug 94 12:12:44 -0400 Return-Path: Received: from psi.com by lists.psi.com (5.65b/SMI-4.1.3-PSI) id AA09729; Mon, 29 Aug 94 12:11:53 -0400 Received: from relay2.UU.NET by psi.com (4.1/2.1-PSI/PSINet) id AA08924; Mon, 29 Aug 94 12:10:06 EDT Received: from bell.com by relay2.UU.NET with SMTP id QQxfbk23468; Mon, 29 Aug 1994 12:09:57 -0400 Received: by bell.com (4.1/SMI-4.1) id AA06826; Mon, 29 Aug 94 12:07:34 EDT Date: Mon, 29 Aug 1994 12:00:48 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jeff Richards Subject: re: congestion fees To: hes@unity.ncsu.edu Cc: com-priv@psi.com, "Glenn O. Hatmaker" , Robert Stewart , Paula Reinman , ISA , Bill Burrington , Wm McCloskey In-Reply-To: <9408290102.AA02564@hes.unity.ncsu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I agree with Henry's point -- which doesn't negate Hal's. User information and control at the point charges happen is crucial to wide acceptence. I recollect that 'near-real-time' feedback and overall household control was one of the keystones of electric power demand pricing residential trials by -- among others -- Hydro Quebec and Southern California Edison. Jeff Richards MFJ Task Force Internet: richards@bell.com +1 202 973-5307 voice 1133-21st NW #700 +1 202 973-5351 TDD Washington DC 20036-3349 +1 202 973-5341 fax "Representing my own opinion as an information services industry participant" On Sun, 28 Aug 1994 hes@unity.ncsu.edu wrote: > Hal Varian writes: > > ... > >This is one of the big advantages of congestion pricing. If the > >network isn't congested 90% of the time, then there is no need for > >accounting 90% of the time. You only have to keep track of who is > >using network resources when those network resources are scarce; then > >use the money from the congestion fees to increase capacity at the > >bottlenecks. > > From the users' point of view this is incomplete and quite unsatisfactory > in this incomplete form. There has to be a way that the user is > informed about these congestion charges in real time and has a way to > respond in a reasonable way. (E.g. the user can continue the use, > decrease it, or perhaps stop at that time - depending on the importance > of those packets vs. the congestion fee for them.) > > Very few of us would care to use a net in which the charges are only > knowable after they've been incurred - and when these charges can vary > from (close to) zero to a very high rate depending on circumstances > which we don't know at the time. > > --henry schaffer >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08288; 29 Aug 94 17:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08284; 29 Aug 94 17:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05112; 29 Aug 94 17:36 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA182382350; Mon, 29 Aug 1994 13:32:30 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from terra.com21.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA182052345; Mon, 29 Aug 1994 13:32:25 -0700 Received: from [199.35.143.77] (laubach.slip.netcom.com [199.35.143.77]) by terra.com21.com (8.6.5/8.6.5) with SMTP id NAA14071 for ; Mon, 29 Aug 1994 13:27:56 -0700 Date: Mon, 29 Aug 1994 13:27:56 -0700 Message-Id: <199408292027.NAA14071@terra.com21.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: administrivia for San Jose FYI all, As a placeholder, I've put in a request for one meeting session for IPATM for the San Jose meeting. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08887; 29 Aug 94 18:14 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08883; 29 Aug 94 18:14 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa05929; 29 Aug 94 18:14 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA197274820; Mon, 29 Aug 1994 14:13:40 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightstream.LightStream.COM by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA196944816; Mon, 29 Aug 1994 14:13:36 -0700 Received: from dungeon.LightStream.COM by lightstream.LightStream.COM (4.1/SMI-4.1) id AA13954; Mon, 29 Aug 94 17:13:08 EDT Received: by dungeon.LightStream.COM (4.1/SMI-4.1) id AA25976; Mon, 29 Aug 94 17:12:26 EDT Message-Id: <9408292112.AA25976@dungeon.LightStream.COM> To: Andy Malis Cc: Drew Perkins , laubach@netcom.com, gja@thumper.bellcore.com, ip-atm@matmos.hpl.hp.com, swallow@lightstream.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of "Mon, 29 Aug 1994 10:33:40 EDT." <9408291433.AA10010@maelstrom.timeplex.com> Date: Mon, 29 Aug 1994 17:12:25 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Swallow I strongly agree with Andy that we should incorporate UNI 3.1 as soon as possible. UNI 3.0 and 3.1 are not compatible. The further that 3.0 gets out into the world, the larger teh conversion headaches will be for all users. The dynamics of the Forum's balloting process is that the Straw Vote is when final changes and edits are made. This occurred at the Irvine meeting in July. The final Vote is a simple up/down. Its extremely unlikely that this vote won't succeed. By definition there are no changes if it does. As a result, its safe to be making any adjustements to the Signalling Draft based on the output of the Irvine meeting (that is the version which is to be mailed this week). ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10816; 29 Aug 94 21:00 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10812; 29 Aug 94 21:00 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08883; 29 Aug 94 21:00 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA221004433; Mon, 29 Aug 1994 16:53:53 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightning.synoptics.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA220674431; Mon, 29 Aug 1994 16:53:51 -0700 Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA00618; Mon, 29 Aug 94 16:53:05 PDT Received: from milliways (milliways.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA09149; Mon, 29 Aug 94 16:51:28 PDT Received: by milliways (4.1/2.0N) id AA05947; Mon, 29 Aug 94 16:50:36 PDT Message-Id: <9408292350.AA05947@milliways> Date: Mon, 29 Aug 94 16:50:36 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: ip-atm@matmos.hpl.hp.com Subject: Re: Signaling Draft and UNI 3.1 > From atmpost@matmos.hpl.hp.com Mon Aug 29 14:27:48 1994 > To: Andy Malis > Cc: Drew Perkins , laubach@netcom.com, gja@thumper.bellcore.com, > ip-atm@matmos.hpl.hp.com, swallow@LightStream.COM > Subject: Re: Signaling Draft and UNI 3.1 > In-Reply-To: Your message of "Mon, 29 Aug 1994 10:33:40 EDT." > <9408291433.AA10010@maelstrom.timeplex.com> > Date: Mon, 29 Aug 1994 17:12:25 -0400 > From: George Swallow > Content-Length: 711 > > I strongly agree with Andy that we should incorporate UNI 3.1 as soon > as possible. UNI 3.0 and 3.1 are not compatible. The further that > 3.0 gets out into the world, the larger teh conversion headaches will > be for all users. George, Unfortunately, reality is that UNI 3.0 implementations are being shipped today and will continue to be for some number of months into the future. So, any RFC published during the next 6 months (at minimum) has to deal adequately with UNI 3.0. To take the time now to include equivalent mappings/usage for UNI 3.1 is also essential at this point, from a technical/practical point of view. One of the other pieces of missing information is what time frames vendors and users expect to be deploying UNI 3.1 implementations: in the absence of this information, the only viable way forward is the mixed 3.0/3.1 approach. This dual-version situation might, however, add to Joe Public's impression that ATM standardisation is kind of messed up, which may be a message that does not want to be spread too far and it maybe more politic to publish the two as seperate revisions. Any professional politicians out there ??? > ...George > Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Engineering Group Leader FAX: +1 408 988 5525 Distributed Network Systems E-m: asmith@synoptics.com SynOptics Communications Inc. Santa Clara, CA ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10879; 29 Aug 94 21:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10875; 29 Aug 94 21:11 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09030; 29 Aug 94 21:11 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA235925416; Mon, 29 Aug 1994 17:10:16 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA235595412; Mon, 29 Aug 1994 17:10:12 -0700 Received: from andes.bellcore.com (andes.bellcore.com [128.96.33.195]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id UAA15777 for ; Mon, 29 Aug 1994 20:10:10 -0400 Received: by andes.bellcore.com (8.6.9/SMI-SVR4) id UAA02245; Mon, 29 Aug 1994 20:10:10 -0400 Date: Mon, 29 Aug 1994 20:10:10 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mauricio Arango Message-Id: <199408300010.UAA02245@andes.bellcore.com> To: ip-atm@matmos.hpl.hp.com Subject: alternate approach to IP/ATM control I'm aware that this group already has a very good solution for handling IP over ATM, as described in RFC 1577. However, I would like to raise some issues regarding the way ATM networks will be deployed that may allow handling of some of the control aspects of IP over ATM in a different way. As I understand it, classical IP and ARP over ATM assumes that within an ATM LIS (logical IP subnetwork) its endpoint IP routers can only communicate via the corresponding ATM network. It is through this ATM network that routers talk to the ATMARP server in order to register and to obtain a router's ATM address given its IP address. I believe that a very common scenario when deploying ATM is to add IP routers with ATM interfaces to existing IP networks. In many cases the motivation to utilize ATM is handling of high-bandwidth, real-time traffic (video, high-resolution graphics, etc). The addition of ATM connectivity to a certain IP network doesn't necessarily imply that the existing IP infrastructure (other routers and links) are going to be removed. The point I want to make is that IP/ATM routers (or their corresponding controllers) can communicate among them via a regular (legacy) IP network. Given this assumption ATMARP and any other negotiation between endpoint ATM routers can be done using the regular internet to which the are attached. Existing organizations with IP networks will continue running crucial IP traffic (like email) through routers linked by non-ATM transport services, and this infrastructure can be utilized for handling IP/ATM control messages. There could be some cases where interconnection between IP domains takes place only via ATM, as assumed in RFC 1577, but this could be the exception. The approach I'm suggesting simplifies IP/ATM deployment because ATM ARP can be handled as a protocol over existing IP infrastructure. In the diagram below, if router R1 in LAN1 needs to setup a connection with router R4 in LAN2, it sends a request to router R4 (via the legacy internet) to provide its ATM address. If host A (eg. videoconferencing) requires communication with an application in host E via ATM it will use router R1 for traffic going to LAN2, this requires modification of host A and host E's routing tables. When there is no more need to have high-bandwidth connectivity between A and E the connection between R1 and R2 is released, the routing tables modified and traffic between LAN1 and LAN2 continues through the legacy internet. This approach allows negotiation of other aspects like security and billing without having to use ATM Q.2931. All the control is done over IP and ATM signaling is used only for setting up the circuit between the two routers. Another advantage is that the exact same solution can be applied to ISDN. ISDN (PRI and BRI) is being increasingly used for on-demand IP traffic and the same problems including IP address to ISDN number resolution need to be resolved. Also, ISDN is being used as an evolutionary trasport service for WANs, given that ATM is not as widespread as ISDN in the WAN domain. Several vendors including cisco, Ascend, Xyplex, and Digiboard have routers with PRI and BRI interfaces. Another advantage of this proposal is that it could scale-up better than a solution with an ATM ARP server, even if such server is distributed. In terms of software it would require every LAN to run a manager process that has information on its routers and corresponding WAN addresses. Each host runs a daemon that interacts with its local manager. When host A wants to open an ATM route to host E, A's daemon sends a request to B's daemon to provide the ATM address for its ATM router (any other parameters that neeed to be negotiated are handled by this protocol). A LAN's manager only knows about its own routers and ATM interfaces and therefore this can be simpler to implement and maintain. This approach could be viewed as complementary to RFC 1577. When a LAN's unique connection to other LANs is via ATM then RFC 1577 is the solution, when there is alternate connectivity via a legacy internet then a solution such as the above could be used. LAN1 LAN2 +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | A | | B | | C | | D | | E | +---+ +---+ +---+ +---+ +---+ | | | | | --------------------------- ------------------------- | | | | +----+ +----+ +----+ +----+ | | | | | | | | | R1 | | R2 | __________ | R3 | | R4 | | | | | ( ) | | | | +----+ +----+ ( Legacy ) +----+ +----+ | | ( internet ) | | | +-----------( )---------+ | | (__________) | | | | | | __________ | | ( ) | +------------------------( ATM )---------------------+ ( network ) ( ) (__________) Any comments are welcome. Thanks. Mauricio Arango Bellcore MRE 2A-281 Tel: (201) 829-4409 445 South St. Fax: (201) 829-5889 Morristown, NJ 07960 email: arango@thumper.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01341; 30 Aug 94 7:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01336; 30 Aug 94 7:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa03239; 30 Aug 94 7:18 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA288211229; Tue, 30 Aug 1994 03:07:09 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from funet.fi by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA287881224; Tue, 30 Aug 1994 03:07:04 -0700 Received: from relevantum.fi by funet.fi with SMTP (PP); Tue, 30 Aug 1994 13:06:59 +0300 Received: by relevantum.fi (4.1/SMI-4.1-MHS-7.0) id AA24133; Tue, 30 Aug 94 13:06:52 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Raimo Harju Message-Id: <9408301006.AA24133@relevantum.fi> Subject: Re: Signaling Draft and UNI 3.1 To: ip-atm@matmos.hpl.hp.com Date: Tue, 30 Aug 1994 13:06:51 +0300 (EET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1765 Grenville, > I agree with your observation about the changes. One point that > may bother implementors from 'outside' the ATMF is just where > will they be able to get copies of 3.1 in time to start work > when the RFC appears (or we agree to have the draft based on > 3.1). I know I could probably get the text, but "Dr Uni-Researcher" > might not know where to start. I can't speak for the Forum on this issue, of course, but once it is approved, it would probably be seen to be in the Forum's best interest to get it distibuted as quickly and widely as possible. It is available now to Forum members in both hardcopy and postscript forms in the form of updates to UNI 3.0. Cheers, Andy Grenville and Andy I'm happy to see these opinions here. I have been wondering for a long time why ATMF decided to organise the mass delivery of standards using old fashioned and time consuming book format. The agreement with a publishing house can not be a big business to the forum. There are hundreds of hang arounders like me who would like to use the time available to preach about ATM instead of hunting and waiting information about it. So ATMF, please, put the documents in the net as well. I'm not asking the service for free. I talked to the ATM representative about this at the CeBIT ATM World about this and he listened to me carefully but I have not seen any results yet. If you feel the same, please, talk to your friends inside the Forum. Raimo Harju Senior Telecomm Consultant -- Raimo Harju Relevantum rami@relevantum.fi Nasilinnankatu 24 D tel. +358 31 2147200 33210 Tampere, Finland fax. +358 31 2147402   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04390; 30 Aug 94 11:15 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04386; 30 Aug 94 11:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08191; 30 Aug 94 11:15 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA023644108; Tue, 30 Aug 1994 06:41:48 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lightstream.LightStream.COM (lightstream.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA023314104; Tue, 30 Aug 1994 06:41:44 -0700 Received: from dungeon.LightStream.COM by lightstream.LightStream.COM (4.1/SMI-4.1) id AA03079; Tue, 30 Aug 94 09:41:11 EDT Received: by dungeon.LightStream.COM (4.1/SMI-4.1) id AA04655; Tue, 30 Aug 94 09:40:31 EDT Message-Id: <9408301340.AA04655@dungeon.LightStream.COM> To: Andrew Smith Cc: ip-atm@matmos.hpl.hp.com, swallow@lightstream.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of "Mon, 29 Aug 1994 16:50:36 PDT." <9408292350.AA05947@milliways> Date: Tue, 30 Aug 1994 09:40:30 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: George Swallow ATM standardiation messed up?! Bah! Humbug! I think the Emporer's clothes look just fine... It's unfortunate that UNI 3.0 was rushed out ahead of Q.2931. I hope the Forum has learned from this mistake. I wasn't suggesting that we drop 3.0 from the draft; just that we include 3.1. That is we should publish a dual version. That the Forum messed up here is pretty well known. I don't think the IETF of all folks should be trying to cover the trail. ...George   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05626; 30 Aug 94 12:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05622; 30 Aug 94 12:22 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa09645; 30 Aug 94 12:22 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA041398942; Tue, 30 Aug 1994 08:02:22 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA041068940; Tue, 30 Aug 1994 08:02:20 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA22626; Tue, 30 Aug 1994 10:02:15 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1) id AA03194; Tue, 30 Aug 1994 10:02:12 -0500 Received: from dbg.dev.cdx.mot.com (dbg.dev.cdx.mot.com [134.33.32.39]) by merlin.dev.cdx.mot.com (8.6.9/8.6.9) with ESMTP id LAA24134; Tue, 30 Aug 1994 11:02:10 -0400 Received: from localhost (localhost [127.0.0.1]) by dbg.dev.cdx.mot.com (8.6.9/8.6.5) with SMTP id LAA04774; Tue, 30 Aug 1994 11:02:09 -0400 Message-Id: <199408301502.LAA04774@dbg.dev.cdx.mot.com> X-Authentication-Warning: dbg.dev.cdx.mot.com: Host localhost didn't use HELO protocol To: George Swallow Cc: dan@merlin.dev.cdx.mot.com, ip-atm@matmos.hpl.hp.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of "Tue, 30 Aug 94 09:40:30 EDT." <9408301340.AA04655@dungeon.LightStream.COM> Date: Tue, 30 Aug 94 11:02:07 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp > ATM standardiation messed up?! Bah! Humbug! I think the Emporer's > clothes look just fine... > > It's unfortunate that UNI 3.0 was rushed out ahead of Q.2931. I hope > the Forum has learned from this mistake. I wasn't suggesting that we > drop 3.0 from the draft; just that we include 3.1. That is we should > publish a dual version. That the Forum messed up here is pretty well > known. I don't think the IETF of all folks should be trying to cover > the trail. You took the words out of my mouth, except that I'd just as soon see UNI 3.0 dropped. In particular, UNI 3.1 corrects a couple of flipped bits in the coding examples which are directly referenced by the draft, and which would be fatal to any possibility of interoperability. You can't have it both ways. If you're going to rush implementation agreements into publication before the base standards are complete, and before you've thoroughly vetted the text, then you've got to accept breakage. There was an explicit agreement in the Forum to do exactly that. Now the chickens have come home to roost. UNI 3.1 should be regarded as obsoleting UNI 3.0.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08230; 30 Aug 94 14:54 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08226; 30 Aug 94 14:54 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12764; 30 Aug 94 14:54 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA066898209; Tue, 30 Aug 1994 10:36:49 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA066548200; Tue, 30 Aug 1994 10:36:40 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.3-10 #7256) id <01HGIQK19TEO8WW8BH@sys30.timeplex.com>; Tue, 30 Aug 1994 12:22:26 -0400 (EDT) Received: from michdry. (michdry.timeplex.com) by louie.timeplex.com (4.1/SMI-4.1) id AA04410; Tue, 30 Aug 94 11:20:03 CDT Date: Tue, 30 Aug 1994 11:20:03 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Gaddis Subject: Re: Signaling Draft and UNI 3.1 To: dan@merlin.dev.cdx.mot.com Cc: ip-atm@matmos.hpl.hp.com Message-Id: <9408301620.AA04410@louie.timeplex.com> Content-Transfer-Encoding: 7BIT > > > ATM standardiation messed up?! Bah! Humbug! I think the Emporer's > > clothes look just fine... > > > > It's unfortunate that UNI 3.0 was rushed out ahead of Q.2931. I hope > > the Forum has learned from this mistake. I wasn't suggesting that we > > drop 3.0 from the draft; just that we include 3.1. That is we should > > publish a dual version. That the Forum messed up here is pretty well > > known. I don't think the IETF of all folks should be trying to cover > > the trail. > You took the words out of my mouth, except that I'd just as soon see UNI 3.0 > dropped. In particular, UNI 3.1 corrects a couple of flipped bits in the coding > examples which are directly referenced by the draft, and which would be fatal to > any possibility of interoperability. > > You can't have it both ways. If you're going to rush implementation agreements > into publication before the base standards are complete, and before you've > thoroughly vetted the text, then you've got to accept breakage. There was an > explicit agreement in the Forum to do exactly that. Now the chickens have come home to roost. UNI 3.1 should be regarded as > obsoleting UNI 3.0. > Fully agree. Mike Gaddis Director Software Development Ascom Timeplex, Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08312; 30 Aug 94 15:00 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08308; 30 Aug 94 15:00 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa12879; 30 Aug 94 15:00 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA067258210; Tue, 30 Aug 1994 10:36:50 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA066528200; Tue, 30 Aug 1994 10:36:40 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.3-10 #7256) id <01HGIQM0E1M88WW7S1@sys30.timeplex.com>; Tue, 30 Aug 1994 12:24:02 -0400 (EDT) Received: from michdry. (michdry.timeplex.com) by louie.timeplex.com (4.1/SMI-4.1) id AA04418; Tue, 30 Aug 94 11:21:49 CDT Date: Tue, 30 Aug 1994 11:21:49 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mike Gaddis Subject: Re: Multicasting over ATM draft To: akyol@leland.stanford.edu, emccoy@tra.com Cc: deering@parc.xerox.com, ip-atm@matmos.hpl.hp.com Message-Id: <9408301621.AA04418@louie.timeplex.com> Content-Transfer-Encoding: 7BIT Earl, Bora, Steve, Without substantial qualifications as to the type of service you desire, the claims in your collective emails (attached) are largely unsupportable. I understand that when one looks at today's ATM cell "mux'es" that one can come away largely unimpressed. With little to distinguish them from routers and, in some ways, arguably worse in scalable performance. These are implementation flaws, not fundemental technology flaws. Its never been about ATM per se. It is, however, at a very fundemental level, about fixed length cells and connections. If you care about end-to-end delay and delay variance *guarantees* and you care about true integrated services on a single wire (circuits, packets) then you must consider some aspects of ATM as necessary to accomplish those goals. If, on the other hand, you are concerned only with higher speed support of a data communications type of QoS, where delay quarantees are only loosely supported and where large statistical gains (aggregate network performance) outweighs the importance of individual data flow guarantees, then you have a point. My problem with the later appraoch is that I do not believe that scalable multimedia integrated with data and legacy circuit traffic will work unless we have fixed cells and known data flow paths through the network (i.e. connections). Why fixed packets/cell lengths? Its so simple as to be obvious, *but* only if you care about *real* delay and delay variation guarantees! Thats why it is so important to declare delay as a requirement or not. Predictible length packets/cells are the only way I know to fine tune delay--the laws of physics rule here. Packet/cell quantization delay on a serial wire (regardless of speed) is fixed for each packet cell depending on size (that is also why the ATM cell length is a compromise, not so good for data, not so good for lower speed circuits). Given this fixed delay you can deterministically manage delay (notice that I said *could*, *very* few of today's cell mux'es are very good at that). If you allow unconstrained variable length packets/cells then this delay is not deterministic (the wire is, by its nature, serial and head-of-line blocking is intrinsic to the nature of the beast). For example, on a link running at 155Mbps with the ATM cell it takes about 2.735 usecs to get the last bit off the wire after the first bit arrived. If, at any time, a larger packet could be gated in front of our delay sensitive cell, say 4096 bytes one time and 8192 another time, then the cell cannot be processed until those packets have been served. That means that a delay of about 211.41 usecs for the 4096 byte packet and 422.82 usecs for the 8192 packet. The delay for delay sensitive packets would be all over the map because asynchronous traffic flows are perturbing the delay sensitive stuff. (Granted, highbrids can be constructed to allow a set of packet/cell sizes but this must still observe the above principles and is still fundementally a fixed cell/delay paradigm.) Why Connections? (Isn't that obvious :) since I'm personally involved in connection setup stuff this can be pretty self-serving...) Anyway, again, *IF* you care about bandwidth, delay and delay variation quarantees to *individual* data flows--especially if these guarantees are not statistical, which IMHO, is an oxymoron i.e. "statistical guarantee" ;) *and* you run a network at many Mbps to an aggregate of many Gbps, *then* real-time data path routing must be performed in hardware. Known paths through the network make this problem (guarantees) tractible. Scaling multipoint at these speeds means it better be channelized (not source routed). The physics on this one are harder to prove, so some faith is required. Trust me :) ****** Ya gotta declare more requirements so that we talk about the same solution space or agree to disagree on our fundemental requirements. This prevents us from thrashing on tactics while ignoring the strategic goals. Now: How to support low-latency, infrequent datagrams and/or fast start IP flows on a connection oriented ATM network (without incuring the cost of SVC setup latencies).... piece-of-cake, gotta minute? .... :) Mike Gaddis Director, Software Development Ascom Timeplex, Inc. > > I have started to think of ATM much like Steve Deering, namely > > 1. If AAL5 CO-VBR is all the *user* needs from ATM (and MPEG-2 > "constant quality/VBR" video is OK here) and > > 2. A datagram router can be made as fast/inexpensive as an ATM switch, and > > 3. IP Multicasting can be done without dependence on any layer 2, and > > 4. Call Admission Control, a datagram schedular, and priorities in > the routers via RSVP (which is all ATM does), and > > 5. Transaction TCP is adopted (the last "real world" weakness of > TCP/IP, then > > Go back to the *original pre-LAN* network model, nothing but > point-to-point links between/among host computers and routers, period. > PPP over SONET. > > The common carriers will have a SONET-only service offering; let's > use it! ATM may solve a network provide problem, but I can't see why > the user needs it. > ************************************************************* > > From: Steve Deering > > > > > a native ATM API which will...actually take advantage of the strongholds of > > > ATM technology like being connection oriented and have the ability to do > > > statistical multiplexing, > > > > The connection-orientedness of ATM is one of its *weaknesses*, not its > > strengths; it's the main cause of all the difficulty in mapping IP > > multicast to ATM multicast. As Van Jacobson points out, a "connection" > > is too high-level an abstraction -- it severly constrains what services > > can be supported by an infrastructure. > > ATM is connection-oriented to support real-time traffic like voice and video, > as you might accept voice and video will probably not survive well for a cross > country link if we used store-and-forward techniques, although Radio Free VAT > usually sounds acceptable. > > > > > IP does statistical multicasting. The fact that ATM uses fixed-size packets > > does not give it any magical powers with respect to statistical multipluxing. > > ATM uses fixed size packets for fast packet switching, the statistical multiplexing > in ATM can be used to provide a QoS guarantee, IP traffic on the other hand is always > best effort, and the layers above IP are responsible for guaranteeing delivery. ( > As far as I know ) > > > > ...there has to be a future goal for transmitting all sorts of traffic over > > > ATM and IP is not appropriate for that. > > > > Why set such a modest goal? If instead we work to support all sorts of > > traffic over IP, we will end up with a multi-services internet that > > is not locked into a single subnetwork technology. > > Supposing that IP is extended to support all the services in the world, > won't we still use ATM as the transport protocol, if not then what are we > going to use ? > > > > > > ...maybe we should have used PPP over SONET. > > > > No doubt about it. > > > > Steve > > > > > Bora Akyol > > ******************************************************************** > Earl E. McCoy PhD emccoy@tra.com > Senior Consultant 312-587-7323 > Telecommunications Research Associates usual disclaimer > >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09528; 30 Aug 94 16:03 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09524; 30 Aug 94 16:03 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa14347; 30 Aug 94 16:03 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA250361727; Tue, 30 Aug 1994 11:35:27 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from motgate.mot.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA250031724; Tue, 30 Aug 1994 11:35:24 -0700 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA22253; Tue, 30 Aug 1994 13:35:23 -0500 Received: from merlin.dev.cdx.mot.com by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1) id AA07749; Tue, 30 Aug 1994 13:35:20 -0500 Received: from dbg.dev.cdx.mot.com (dbg.dev.cdx.mot.com [134.33.32.39]) by merlin.dev.cdx.mot.com (8.6.9/8.6.9) with ESMTP id OAA01921; Tue, 30 Aug 1994 14:35:17 -0400 Received: from localhost (localhost [127.0.0.1]) by dbg.dev.cdx.mot.com (8.6.9/8.6.5) with SMTP id OAA04853; Tue, 30 Aug 1994 14:35:16 -0400 Message-Id: <199408301835.OAA04853@dbg.dev.cdx.mot.com> X-Authentication-Warning: dbg.dev.cdx.mot.com: Host localhost didn't use HELO protocol To: George Swallow Cc: dan@merlin.dev.cdx.mot.com, ip-atm@matmos.hpl.hp.com Subject: Re: Signaling Draft and UNI 3.1 In-Reply-To: Your message of "Tue, 30 Aug 94 09:40:30 EDT." <9408301340.AA04655@dungeon.LightStream.COM> Date: Tue, 30 Aug 94 14:35:15 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com X-Mts: smtp > ATM standardiation messed up?! Bah! Humbug! I think the Emporer's > clothes look just fine... > > It's unfortunate that UNI 3.0 was rushed out ahead of Q.2931. I hope > the Forum has learned from this mistake. I wasn't suggesting that we > drop 3.0 from the draft; just that we include 3.1. That is we should > publish a dual version. That the Forum messed up here is pretty well > known. I don't think the IETF of all folks should be trying to cover > the trail. You took the words out of my mouth, except that I'd just as soon see UNI 3.0 dropped. In particular, UNI 3.1 corrects a couple of flipped bits in the coding examples which are directly referenced by the draft, and which would be fatal to any possibility of interoperability. You can't have it both ways. If you're going to rush implementation agreements into publication before the base standards are complete, and before you've thoroughly vetted the text, then you've got to accept breakage. There was an explicit agreement in the Forum to do exactly that. Now the chickens have come home to roost. UNI 3.1 should be regarded as obsoleting UNI 3.0.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12890; 30 Aug 94 21:26 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12886; 30 Aug 94 21:26 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa20451; 30 Aug 94 21:26 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA287781544; Tue, 30 Aug 1994 17:05:44 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA287451538; Tue, 30 Aug 1994 17:05:38 -0700 Date: Tue, 30 Aug 1994 17:05:38 -0700 Message-Id: <199408310005.AA287451538@matmos.hpl.hp.com> To: ip-atm@matmos.hpl.hp.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Tentative IPATM WG schedule at San Jose The IPATM WG is tentatively scheduled for the Tuesday, 1600-1800 slot at the San Jose IETF meeting. Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04509; 31 Aug 94 11:44 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04505; 31 Aug 94 11:44 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa08800; 31 Aug 94 11:44 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA071511302; Wed, 31 Aug 1994 06:55:02 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from lobster.wellfleet.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA071181300; Wed, 31 Aug 1994 06:55:00 -0700 Received: from pobox (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA18148; Wed, 31 Aug 94 09:50:41 EDT Received: from godiva.wellfleet by pobox (4.1/SMI-4.1) id AA02553; Wed, 31 Aug 94 09:49:11 EDT Date: Wed, 31 Aug 94 09:49:11 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9408311349.AA02553@pobox> To: ip-atm@matmos.hpl.hp.com Subject: signaling draft 3.0 or 3.1 Add another vote for basing the signaling RFC on UNI 3.1. I agree that UNI 3.0 is out there and people have existing systems which causes a problem. Perhaps we should post the draft based on 3.0 as an experimental or informational RFC? If we did that, could UNI 3.1 be referenced? If not by name, at lease mention the fact that another version was on the way? Caralyn Brown cbrown@wellfleet.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05239; 31 Aug 94 12:46 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05234; 31 Aug 94 12:46 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa10521; 31 Aug 94 12:46 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA086052506; Wed, 31 Aug 1994 07:15:06 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from sys30 (corp.timeplex.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA085632498; Wed, 31 Aug 1994 07:14:58 -0700 Received: from louie.timeplex.com by sys30.timeplex.com (PMDF V4.3-10 #7256) id <01HGK0HFTM288WWDYO@sys30.timeplex.com>; Wed, 31 Aug 1994 10:17:28 -0400 (EDT) Received: from mich.timeplex.com by louie.timeplex.com (4.1/SMI-4.1) id AA07144; Wed, 31 Aug 94 09:15:26 CDT Date: Wed, 31 Aug 1994 09:15:26 -0500 (CDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Pete Flugstad Subject: comments on ip over atm signaling draft To: ip-atm@matmos.hpl.hp.com Cc: pete@louie.timeplex.com, rick@louie.timeplex.com, gaddis@louie.timeplex.com, malis@maelstrom.louie.timeplex.com, hunt@maelstrom.louie.timeplex.com, hal@maelstrom.louie.timeplex.com Message-Id: <9408311415.AA07144@louie.timeplex.com> Content-Transfer-Encoding: 7BIT To IP-ATMers: These comments are directed at draft-ietf-ipatm-sig-02. They address concerns over the proposed bandwidth model presented in that text, and the examples given. Sections indented with a ">" represent direct quotes from the draft. The basic problem is that the proposed model of traffic, one of Best Effort, Class X, QoS Class 0, is not a good one at all. It gives the network virtually no information about the connection at all, and as a result, makes it difficult to route and allocate resources for the connections (especially when PCR = link rate, which is REALLY BAD). It is likely that the resulting connections will exhibit heavy cell loss (and with SAR, heavy PDU loss), and while IP is designed for heavy loss and high delay, most people using IP don't like this, and they would like to see little or no cell (and hence PDU) loss, and good delay. The UNI 3.0 spec provides several other models to use, including standard Peak, Sustained, and Max Burst Size. It is appropriate to give these models coverage, in addition and in preference to Best Effort. Additionally, some applications may be generating a constant bit rate, and may wish to use CBR features available from the network. While it may be true that this specification is only meant to be a guideline, most implementations based upon it will not deviate from it at all for many reasons, mostly due to ignorance of other capabilities. By presenting other models in conjunction with the Best Effort model, implementors will be able to better decide what to implement, and have a better chance of being able to implement something that is useful and does what is wanted. Anyway, here are the detailed comments: > 8. Information Elements with Significance to the ATM Network > > This section describes the coding of, and procedures surrounding, > information elements with significance to the ATM network, as well as > the endpoints of an ATM call supporting multiprotocol operation. > > The standards, implementation agreements, research and experience > surrounding such issues as traffic management, quality of service and > bearer service description are still evolving. Much of this material > is cast so as to give the greatest possible latitude to ATM network > implementation and service offerings. ATM endsystems need to match > the traffic contract and bearer service they request from the network > to the capabilities offered by the network. Therefore, this memo can > only offer what, at the present time, are the most appropriate and > efficient coding rules to follow for setting up IP and ATMARP VCCs. Given the statement: > Much of this material is cast so as to give the greatest possible > latitude to ATM network implementation and service offerings. in this paragraph, the parameters proposed in this draft (to use the "Best Effort" capability, with Broadband Bearer Class X, and Quality of Service Class 0) seem quite contradictory. This combination of parameters and classes does NOT "give the greatest possible latitude" to anyone, especially the network provider. In fact, it gives the network provider virtually no information about the expected traffic patterns, and unnecessarily hampers efforts to provide any type of quality of service at all. It makes allocating buffers for this traffic impossible, and makes routing the connection in such a way as to provide the requested quality of service extremely difficult. It also makes it difficult to multiplex this traffic with any other type of traffic (circuit emulation or even VBR video), because of the traffic's unpredictability. In short, "Best Effort" is truly "Worst Effort", and it should not be used by any application that wishes to use an ATM network in a useful or realistic fashion. This is especially true for IP traffic where a single cell loss (most likely very common with Best Effort) results in the loss of a whole PDU. Best Effort is probably the worst traffic model to be used by IP over ATM implementations. In addition, future revisions of the ATMF UNI signaling protocol are expected to depreciate Quality of Service Classes (if not eliminate them all together - see ATM Forum 94-0671) because of their ambiguity. They will be replaced with Information Elements that allow the user to more accurately describe expected traffic patterns to the network. The point of moving to a connection-oriented network, such as ATM, is to be able to provide predictable quality of service, bandwidth, and latency guarantees for connections. This draft, with its proposed codings, does exactly the opposite. Section 8.1 - 8.3, which discuss possible codings for the Information Elements, should be expanded to include discussion of other possible options. I have included SAMPLE text below, including several other options for the encoding of the UCR IE, BBC IE, and QoS IE. Obviously some of the options will need to be "pruned". In addition, version 3.1 of [ATMF93] will be available soon. We propose that this draft be revised to conform with version 3.1, as it makes several clarifications to the allowable combinations of traffic parameters. The sample text below is (mostly) compatible with 3.1, except for the name change of ATM User Cell Rate Information Element to ATM Traffic Descriptor Information Element. --- SAMPLE TEXT ONLY --- 8.1. ATM User Cell Rate The ATM User Cell Rate IE contains a series of Traffic Descriptors (TDs). It characterizes the ATM virtual connection in terms of peak cell rate (PCR), sustainable cell rate (SCR), and maximum burst size (MBS), in both directions of the connection. This information is used to allocate resources (e.g., bandwidth, buffering) in the network, as well as to route the connection between endpoints. In general, the ATM traffic descriptor for supporting multiprotocol interconnection over ATM will be driven by factors such as the capacity of the network, conformance definition supported by the network, performance of the ATM endsystem and (for public networks) cost of services. The ATM UCR IE provides for several models of traffic, based upon the type of connection required. For IP connections, one of the following capabilities should be appropriate. 8.1.1 Bursty Data Traffic Under this capability, the calling endsystem indicates the Peak Cell Rate(CLP=0+1) for the connection, as well as the Sustained Cell Rate (CLP=0+1) and Maximum Burst Size (CLP=0+1) for both directions. This capability should be used the majority of the time, as the calling endsystem should have a "pretty good idea" as the traffic it will be generating. All three parameters, PCR(0+1), SCR(0+1), and MBS(0+1) are used by the network to allocate resources for the connection. Values for these parameters should be selected based upon the expected traffic pattern of the connection. If the expected traffic pattern is unknown, then these values should be selected based upon such parameters as processor, operating system, kernel buffers, hardware buffers, etc. These parameters are usually known by the calling endsystem, and can be used to determine appropriate values for the TDs. If information is known about the called endsystem, that information should be used as well. The PCR indicates the maximum rate at which the endsystem may transmit data. It should NOT normally be set equal to the link rate, as this requires the network to allocate resources commensurate with that rate, thereby potentially preventing other connections from being established. The SCR is the expected average rate at which the endsystem will transmit data. It corresponds to guaranteed bandwidth from the network, and MUST be less than or equal to the PCR. The MBS is used by the network to allocate buffers to the connection, and should be selected based on endsystem and application characteristics, such as the maximum frame size to be transmitted. By selecting appropriate and accurate values for these fields, the network is able to setup a connection that meets the needs of the endsystem, as well as preventing interference between this connection and other connections. Appropriate values for these parameters can help an endsystem realize low or no loss connections, and the network may realize better link utilization. Here is an example format and field values for the ATM User Cell Rate IE for this capability: ------------------------------------------------------------ | user_cell_rate | ------------------------------------------------------------ | fwd_peak_cell_rate_0+1_identifier 132 | | fwd_peak_cell_rate_0+1 (estimated rate) | | bkw_peak_cell_rate_0+1_identifier 133 | | bkw_peak_cell_rate_0+1 (estimated rate) | | | | fwd_sustained_cell_rate_0+1_identifier 144 | | fwd_sustained_cell_rate_0+1 (estimated rate) | | bkw_sustained_cell_rate_0+1_identifier 145 | | bkw_sustained_cell_rate_0+1 (estimated rate) | | | | fwd_maximum_burst_size_0+1_identifier 176 | | fwd_maximum_burst_size_0+1 (estimated rate) | | bkw_maximum_burst_size_0+1_identifier 177 | | bkw_maximum_burst_size_0+1 (estimated rate) | ------------------------------------------------------------ Additionally, the Quality of Service (QOS) IE and Broadband Bearer Capability (BBC) IE may be used to give the network more information about this connection. 8.1.2 Best Effort Capability This capability provides the network the least amount of information, indicating only the PCR forward (CLP=0+1) and PCR backward (CLP=0+1) fields, in addition to the Best Effort Indicator. This capability may be used if the type of type of traffic to be carried is completely unknown. No guarantees are provided by the network, and in fact, throughput may be zero at any time. Also, the end system may exceed its PCR at any time. This capability may be appropriate for bulk transfer connections, where some cell loss (and the corresponding PDU loss), and delays can be tolerated. As with PCR above, the value for this parameter should be selected based upon the expected traffic pattern of the connection. If the expected traffic pattern is unknown, then this value should be selected based upon such parameters as processor, operating system, kernel buffers, hardware buffers, etc. These parameters are usually known by the calling endsystem, and can be used to determine an appropriate values for this TD. If information is known about the called endsystem, that information should be used as well. Here is an example format and field values for the ATM User Cell Rate IE for this capability: ------------------------------------------------------------ | user_cell_rate | ------------------------------------------------------------ | fwd_peak_cell_rate_0+1_identifier 132 | | fwd_peak_cell_rate_0+1 (estimated rate) | | bkw_peak_cell_rate_0+1_identifier 133 | | bkw_peak_cell_rate_0+1 (estimated rate) | | best_effort_indication 190 | ------------------------------------------------------------ Quality of Service Class 0 and Broadband Bearer Class X (VBR) are required when BE capability is requested. 8.1.3 Constant Rate Traffic Under this capability, the calling system indicates only the PCR(0+1) for the connection. This capability should be used when the calling system expects to generate a constant stream of traffic, of a certain bandwidth, with little or no variation, and wishes to have guarantees from the network that the traffic will be delivered with little or no cell loss. The PCR indicates the rate at which the endsystem will transmit data. The network allocates resources based upon receiving traffic at this rate. Here is an example format and field values for the ATM User Cell Rate IE for this capability: ------------------------------------------------------------ | user_cell_rate | ------------------------------------------------------------ | fwd_peak_cell_rate_0+1_identifier 132 | | fwd_peak_cell_rate_0+1 (estimated rate) | | bkw_peak_cell_rate_0+1_identifier 133 | | bkw_peak_cell_rate_0+1 (estimated rate) | ------------------------------------------------------------ Additionally, the Broadband Bearer Class and Quality of Service Class may be used to further identify this connection as a "Constant Bit Rate" or CBR connection (see below). 8.1.4 Further Guidelines [ATMF93] does not provide any capability for negotiation of the ATM User Cell Rate. This means that: a) if, in response to a SETUP message, a calling endsystem receive a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #51, User cell rate unavailable, it MAY examine the diagnostic field of the Cause IE and re-attempt the call after selecting smaller values for the parameter(s) indicated in the diagnostic. If the RELEASE COMPLETE or RELEASE message is received with cause #73, Unsupported combination of traffic parameters, it MAY try on of the other capabilities given above, or other combinations from table 5-7 and 5-8 of [ATMF93]. b) the called endsystem SHOULD examine the ATM user cell rate IE in the SETUP message. If it is unable to process cells at the Forward PCR indicated, it SHOULD clear the call with cause #51, User cell rate unavailable. If it must transfer cells at higher than the Reverse PCR or SCR, it SHOULD likewise clear the call. 8.2. Broadband Bearer Capability The Broadband Bearer Capability IE allows the endsystem to signal to the network the type of bearer service it wishes. Three basic types of services are supported. Type A (BCOC-A) is associated with Constant Bit Rate (CBR) services. It indicates to the network that it may inspect other IEs of the Setup message (such as the AAL Parameters IE), and may provide further service (such as interworking) based upon their values. Type C (BCOC-C) is associated with Variable Bit Rate (VBR) services. Again, it indicates that the network may provide an enhanced service. Type X is slightly different, in that it indicates to the network that it should NOT attempt any enhanced service, and should simply transport the data. Type X, however, has two additional fields that are not normally present for Type A or C. The 'traffic type' field may be used by the endsystem to indicate the type of traffic to the network, either CBR or VBR. This indication is in addition to whatever parameters are given in the UCR IE. The other field is the 'end-to-end timing requirements' field. This field refers to some systems' requirements that the clocks be synchronized between endsystems, and should be set to 'end-to-end timing NOT required'. Both 'traffic type' and 'timing requirements' are allowed to be empty ('no indication'). This is not recommended, as it provides the network little information about the connection, and may result in an unacceptable connection. Two other fields are always present. 'Susceptibility to clipping' is used to indicate that the connection should not be signaled as 'up' until a complete end-to-end connection has been established. This is to prevent the first few cells sent from being lost. This field should always be set to 'not susceptible to clipping'. 'User plane configuration' is used to indicate to this network whether this connection will be point-to-point or point-to-multipoint. This field should always be set to 'Point-to-Point'. The calling endsystem should select appropriate values for these fields, based upon the expected connection type. For a connection that was classified as "Bursty Data Traffic" or "Best Effort" above, Bearer Class X, with traffic type VBR is most appropriate. Bearer Class C may also be indicated if the endsystem wants the network to attempt some kind of enhanced service (possibly based upon AAL information). For a "Constant Bit Rate" connection, Bearer Class X with traffic type CBR should be indicated. Here is an example format and field values for the Broadband Bearer Capability IE for a "Bursty Data Traffic" or "Best Effort" connection: ---------------------------------------------------------- | bb_bearer_capability | ---------------------------------------------------------- | spare 0 | | bearer_class 16 (BCOC-X) | | spare 0 | | traffic_type 2 (VBR) | | timing_reqs 0 (not required) | | susceptibility_to_clipping 0 (not susceptible) | | spare 0 | | user_plane_configuration 0 (point_to_point) | ---------------------------------------------------------- [ATMF93] does not provide any capability for negotiation of the broadband bearer capability. This means that: if, in response to a SETUP message, a calling endsystem receives a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #57, bearer capability not authorized or #58 bearer capability not presently available, it MAY reattempt the call after selecting another bearer capability. 8.3. QoS Parameter The Quality of Service (QoS) Information Element is used by the calling end system to indicate the QoS Class that this connection requires. There are 4 Quality of Service Classes, and one Unspecified QoS Class. The QoS Class of the connection affects Quality of Service Parameters such as Cell Transfer Delay, Cell Delay Variation, and Cell Loss Ratio. QoS Class 1 is used to request a QoS appropriate for Circuit Emulation or Constant Bit Rate Video. QoS Class 2 is used to request a QoS appropriate for Variable Bit Rate Audio and Video. QoS Classes 3 and 4 are used to request a QoS corresponding to that of Connection-Oriented and Connectionless Data Transfer, respectively. For Bursty Data connections, QoS Class 3 or QoS Class 4 may be used. QoS Class 2 may also be used, where applicable. For Best Effort connections, QoS Class 0 (Unspecified) must be used, and this results in no guarantees at all about the Quality of Service of the connection. For Constant Bit Rate connections, QoS Class 1 would be appropriate. Not all QoS Classes may be available, and their availability is specific to the ATM network being used. Only QoS Class 0 is required to be supported. Hence, applications should be adaptable to these limitations. Here is an example format and field values for the QoS Parameters IE for an "unspecified" coding: ---------------------------------------------------------- | qos_parameter | ---------------------------------------------------------- | qos_class_fwd 0 (class 0) | | qos_class_bkw 0 (class 0) | ---------------------------------------------------------- Future releases of [ATMF93] will most likely deprecate the use of QoS Classes, in favor of explicit indication of the parameters. This will be done using extensions to the QoS IE, and by introducing new IEs. [ATMF93] does not provide any capability for negotiation of Quality of Service parameters. This means that: if, in response to a SETUP message, a calling endsystem receives a RELEASE COMPLETE message, or a CALL PROCEEDING message followed by a RELEASE COMPLETE message, with cause #49, Quality of Service unavailable, it MAY reattempt the call after selecting another QoS class. Appendix A. Sample Signaling Messages 1. SETUP and CONNECT messages This annex shows sample codings of the SETUP and CONNECT signaling messages. The fields in the IE header are not shown. +--------------------------------------------------------------------+ SETUP Information Elements/ Fields Value/(Meaning) -------------------- --------------- aal_parameters aal_type 5 (AAL 5) fwd_max_sdu_size_ident 140 fwd_max_sdu_size 9188 (default, send IP MTU value) bkw_max_sdu_size_ident 129 bkw_max_sdu_size 9188 (default, recv IP MTU value) mode identifier 131 * mode message * sscs_type identifier 132 sscs_type 0 (null SSCS) user_cell_rate fwd_peak_cell_rate_0_1_ident 132 fwd_peak_cell_rate_0_1 (estimated rate) bkw_peak_cell_rate_0_1_ident 133 bkw_peak_cell_rate_0_1 (estimated rate) fwd_sustained_cell_rate_0_1_ident 144 fwd_sustained_cell_rate_0_1 (estimated rate) bkw_sustained_cell_rate_0_1_ident 145 bkw_sustained_cell_rate_0_1 (estimated rate) fwd_maximum_burst_size_0_1_ident 176 fwd_maximum_burst_size_0_1 (estimated rate) bkw_maximum_burst_size_0_1_ident 177 bkw_maximum_burst_size_0_1 (estimated rate) bb_bearer_capability spare 0 bearer_class 16 (BCOC-X) spare 0 traffic_type 2 (VBR) timing_reqs 0 (not required) susceptibility_to_clipping 0 (not susceptible to clipping) spare 0 user_plane_configuration 0 (point_to_point) bb_low_layer_information layer_2_id 2 user_information_layer 12 (lan_llc (ISO 8802/2) qos_parameter qos_class_fwd 4 (class 4) qos_class_bkw 4 (class 4) called_party_number type_of_number (international number / unknown) addr_plan_ident (ISDN / ISO NSAPA) number (E.164 / OSI NSAPA) calling_party_number type_of_number (international number / unknown) addr_plan_ident (ISDN / ISO NSAPA) presentation_indic (presentation allowed) spare 0 screening_indic (user_provided verified and passed) number (E.164 / OSI NSAPA) +--------------------------------------------------------------------+ Figure 1. Sample contents of SETUP message [* : optional, ignored if present] In IP over ATM environments the inclusion of the "AAL parameters" IE is *mandatory* to allow for MTU size negotiation between the source and destination. The "Broadband Low Layer Information" IE is also mandatory for specifying the IP encapsulation scheme.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05530; 31 Aug 94 13:18 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05526; 31 Aug 94 13:18 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11081; 31 Aug 94 13:18 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA095622910; Wed, 31 Aug 1994 07:21:50 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from cssun.mathcs.emory.edu by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA095212904; Wed, 31 Aug 1994 07:21:44 -0700 Received: from shangchun.mathcs.emory.edu (shangchun [128.140.50.17]) by cssun.mathcs.emory.edu (8.6.9/8.6.9-940818.01cssun) with ESMTP id KAA12466 for ; Wed, 31 Aug 1994 10:21:42 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shun Yan Cheung Received: (cheung@localhost) by shangchun.mathcs.emory.edu (8.6.9/8.6.9) id KAA03706 for ip-atm@matmos.hpl.hp.com; Wed, 31 Aug 1994 10:21:41 -0400 Date: Wed, 31 Aug 1994 10:21:41 -0400 Message-Id: <199408311421.KAA03706@shangchun.mathcs.emory.edu> To: ip-atm@matmos.hpl.hp.com Subject: UNI 3.x and Q.2931 X-Sun-Charset: US-ASCII There was recently some discussion on UNI 3.1 that fixes some problems in UNI 3.0. We are currently looking into purchasing an ATM (LAN). Would we be doing the wrong thing by purchasing UNI3.0 based products ? What is exactly wrong in UNI 3.0 anyway ? Thanks for any clarification. shun yan cheung@mathcs.emory.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05719; 31 Aug 94 13:34 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05713; 31 Aug 94 13:34 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa11369; 31 Aug 94 13:34 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA119919131; Wed, 31 Aug 1994 09:05:31 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from [199.35.143.77] (laubach.slip.netcom.com) by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA119569120; Wed, 31 Aug 1994 09:05:20 -0700 Date: Wed, 31 Aug 1994 09:05:20 -0700 Message-Id: <199408311605.AA119569120@matmos.hpl.hp.com> To: Caralyn Brown Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Laubach Subject: Re: signaling draft 3.0 or 3.1 Cc: ip-atm@matmos.hpl.hp.com >Add another vote for basing the signaling RFC on UNI 3.1. I agree that UNI 3.0 >is out there and people have existing systems which causes a problem. Perhaps >we should post the draft based on 3.0 as an experimental or informational RFC? > >If we did that, could UNI 3.1 be referenced? If not by name, at lease mention >the fact that another version was on the way? Interesting idea on the experimental/informational. Would this preclude having an appendix covering 3.0 in the proposed draft? Mark   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09527; 31 Aug 94 16:36 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09523; 31 Aug 94 16:36 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa15567; 31 Aug 94 16:36 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA145276652; Wed, 31 Aug 1994 11:10:52 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from nbkanata.newbridge.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA144946650; Wed, 31 Aug 1994 11:10:50 -0700 Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA15261; Wed, 31 Aug 94 14:05:37 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA24769; Wed, 31 Aug 94 14:05:33 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA17170; Wed, 31 Aug 94 14:04:45 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA15769; Wed, 31 Aug 1994 14:06:57 +0500 Date: Wed, 31 Aug 1994 14:06:57 +0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9408311806.AA15769@urchin.newbridge> To: ip-atm@matmos.hpl.hp.com, pete@louie.timeplex.com Subject: Re: comments on ip over atm signaling draft X-Sun-Charset: US-ASCII Content-Length: 1093 'as the calling endsystem should have a "pretty good idea" as the traffic it will be generating.' This sentence is the key problem I have with this proposal. Experience with bridge/routers and with end-stations indicates that systems using IP very rarely have any idea how much traffic they will be sourcing. Bridge/routers have no information at all. End-systems, where one might expect some knowledge, turn out to be unable in most cases to characterise the traffic they will generate or receive. The result is that asking systems to provide values for SCR and MBS is not a useful technique. This is why the ATM Forum TM group is working so hard on ABR. I understand that we need a definition that will work now, not wait until ABR/flow control is defined and used. But asking systems to provide information that they do not have is not an answer. The specific parameters suggested to drive the selection, such as processor, OS, kernel buffering, etc are at best loosely coupled to the intended behavior. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10463; 31 Aug 94 17:12 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10459; 31 Aug 94 17:12 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa16291; 31 Aug 94 17:12 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA160828709; Wed, 31 Aug 1994 11:45:09 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from riker.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA160498706; Wed, 31 Aug 1994 11:45:06 -0700 Received: from localhost (perez@localhost) by riker.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id OAA05651 for ; Wed, 31 Aug 1994 14:44:55 -0400 Message-Id: <199408311844.OAA05651@riker.cmf.nrl.navy.mil> X-Authentication-Warning: riker.cmf.nrl.navy.mil: Host localhost didn't use HELO protocol To: ip-atm@matmos.hpl.hp.com Subject: RE: comments on ip over atm signaling draft Date: Wed, 31 Aug 94 14:44:54 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Maryann Perez Maher Folks, Pete recently sent out a message which comments on the traffic management section of the signaling draft (meaning the section that discusses the User Cell Rate, Broadband Bearer Capability, and QoS Parameters IEs). A general point of his text is that the User Cell Rate IE should be used, when possible, to carry more "informative" information than just specifying a peak cell rate and indicating best effort. This extra information may help the network make more intelligent decisions on how resources are allocated. In this new text IP traffic is described as fitting into one of the following categories: Bursty Data Traffic, Best Effort, Constant Rate Traffic, and states that the majority of the time, the bursty data traffic capability be used. When using this capability, the peak cell rate, sustained cell rate, and maximum burst size are specified (with no best effort indication). In the text it says, "Values for these parameters should be selected based upon the expected traffic pattern of the connection." I'm confused about how estimates for these values are generated. How does IP know the 'expected pattern' of the traffic it supports? IP knows it is carrying TCP, UDP, etc, but has no notion of the specific resource needs of these streams. In previous mail exchanges we discussed the difficulties of specifying/ "guessing" a peak cell rate. I think that estimating/"guessing" on sustained and max burst rates might be even harder... The text does go on to say: ] If the expected traffic pattern is unknown, then ] these values should be selected based upon such parameters as ] processor, operating system, kernel buffers, hardware buffers, etc. ] these parameters are usually known by the calling endsystem, and can be ] used to determine appropriate values for the TDs. If information is ] known about the called endsystem, that information should be used as well. How are estimates made if these resources should be shared among an unknown number of IP connections? I apologize for my gross summarization of this text. These thoughts are just off the top of my head after a first quick reading. I'm hoping others will read Pete's text and comment. On another note, I like the idea of putting this draft out now as informational and waiting a month or two to put out an RFC version based on UNI 3.1 (with an appendix on the relevant differences with 3.0). Maryann   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12301; 31 Aug 94 19:05 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12297; 31 Aug 94 19:05 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa18508; 31 Aug 94 19:05 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA202458976; Wed, 31 Aug 1994 14:36:16 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from thumper.bellcore.com by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA202128974; Wed, 31 Aug 1994 14:36:14 -0700 Received: from localhost (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id RAA20655 for ; Wed, 31 Aug 1994 17:36:11 -0400 Message-Id: <199408312136.RAA20655@thumper.bellcore.com> X-Authentication-Warning: thumper.bellcore.com: Host localhost didn't use HELO protocol To: ip-atm@matmos.hpl.hp.com Subject: RE: comments on ip over atm signaling draft Date: Wed, 31 Aug 94 17:36:10 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gja@thumper.bellcore.com I like the idea of making the 3.0 based draft and informational release, and having a 3.1 based version become more formal later. I'm not sure Pete's concerns wrt QoS are enough to warrant a rewrite for the 3.0 version. My gut feel is that IP endsystems simply cannot estimate their link requirements sufficiently well. >>The point of moving to a connection-oriented network, such as ATM, is >>to be able to provide predictable quality of service, bandwidth, and >>latency guarantees for connections. This draft, with its proposed >>codings, does exactly the opposite. Is this a fair view? The signalling draft simply follows IP's traditional model of 'send and see'. IP (old style) services simply don't _need_ the 'predictable' quality of service. Are you sure the desire that IP sources be 'knowable' is not because current ATM switches are hopeless at bursty traffic handling? gja --- Grenville Armitage, Member of Technical Staff, Bellcore. MRE 2P-340, 445 South Street, Morristown, NJ, 07960-6438, USA Internet: gja@thumper.bellcore.com Voice: +1 201 829 2635   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13374; 31 Aug 94 19:57 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13370; 31 Aug 94 19:57 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19335; 31 Aug 94 19:57 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA188557697; Wed, 31 Aug 1994 14:14:57 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from gw1.att.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA188227695; Wed, 31 Aug 1994 14:14:55 -0700 Received: from hoserve.ho.att.com by ig1.att.att.com id AA25615; Wed, 31 Aug 94 17:13:40 EDT Received: from hopaw32 ([135.16.35.52]) by hoserve.ho.att.com (4.1/EMS-1.1 SunOS) id AA18136; Wed, 31 Aug 94 17:16:15 EDT Received: by hopaw32 (4.1/EMS-1.1 SunOS) id AA06922; Wed, 31 Aug 94 17:17:00 EDT Date: Wed, 31 Aug 94 17:17:00 EDT Message-Id: <9408312117.AA06922@hopaw32> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Enrique Hernandez-Valencia To: ip-atm@matmos.hpl.hp.com Subject: Re: comments on ip over atm signaling draft In-Reply-To: <9408311806.AA15769@urchin.newbridge> References: <9408311806.AA15769@urchin.newbridge> Reply-To: Enrique Hernandez-Valencia >>>>> "Joel" == Joel Halpern writes: Joel> >> 'as the calling endsystem should have a "pretty good idea" Joel> >> as the traffic it will be generating.' Joel> This sentence is the key problem I have with this proposal. Joel> Experience with bridge/routers and with end-stations Joel> indicates that systems using IP very rarely have any idea Joel> how much traffic they will be sourcing. Bridge/routers have Joel> no information at all. End-systems, where one might expect Joel> some knowledge, turn out to be unable in most cases to Joel> characterise the traffic they will generate or receive. Experience with frame relay indicates that when using wide-area links many network managers, if not end-users/end-systems, do have a good idea of what "substainable" rates and "maximum burst" sizes are adequate to them. ABR ("worst effort service"?) will most likely be quite different from the "best effort service" that the internet community is used to (at the very least more stringent flow control) Traffic descriptors can afford them with better quality of service from their service provider at a more "reasonable" cost than otherwise (which is the typical case today with frame-relay). Needs for WANs and LANs are not quite the same, nor all users are equally sophisticated. Some traffic information will be better than no information at all. Perhaps the disagreement is in the procedures rather than the principle. Enrique ----------------------------- Enrique J. Hernandez-Valencia enrique@hoserve.att.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13653; 31 Aug 94 20:35 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13649; 31 Aug 94 20:35 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa19998; 31 Aug 94 20:35 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA218360851; Wed, 31 Aug 1994 15:07:31 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from tesuji.cmf.nrl.navy.mil by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA218030849; Wed, 31 Aug 1994 15:07:29 -0700 Received: (from hoffman@localhost) by tesuji.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id SAA03331; Wed, 31 Aug 1994 18:07:27 -0400 Date: Wed, 31 Aug 1994 18:07:27 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eric Hoffman Message-Id: <199408312207.SAA03331@tesuji.cmf.nrl.navy.mil> To: ip-atm@matmos.hpl.hp.com Subject: Re: comments on ip over atm signaling draft in response to enrique@hoserve.att.com: > Needs for WANs and LANs are not quite the same, nor all users > are equally sophisticated. Some traffic information will be > better than no information at all. Perhaps the disagreement > is in the procedures rather than the principle. I believe (although there is no question Joel can speak for himself) the disagreement stems from the problem that no one: not the manager, the user, the application writer, or the router, has any idea whatsoever or what these numbers should be. It's just not part of the model. They should average less than the link rate. To make any decent estimate all the operating system, application, and networking code would need to be lumped together and be constantly fed data about the loss and delay it will expect to see in the future so it can predict it's own adaptive behaviour, and all of the IP components of a network would need to keep each other updated as to the current predicted load. which is better, no information at all or completely unfounded guesses?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14755; 31 Aug 94 22:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14751; 31 Aug 94 22:07 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21462; 31 Aug 94 22:07 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA241247404; Wed, 31 Aug 1994 16:56:44 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from wawa.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA240917402; Wed, 31 Aug 1994 16:56:42 -0700 Received: by wawa.ans.net (AIX 3.2/UCB 5.64/4.03) id AA10400; Wed, 31 Aug 1994 23:52:24 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <9408312352.AA10400@wawa.ans.net> To: Joel Halpern Cc: ip-atm@matmos.hpl.hp.com, pete@louie.timeplex.com, curtis@wawa.ans.net Subject: Re: comments on ip over atm signaling draft In-Reply-To: (Your message of Wed, 31 Aug 94 14:06:57 R.) <9408311806.AA15769@urchin.newbridge> Date: Wed, 31 Aug 94 23:52:24 +0000 > 'as the calling endsystem should have a "pretty good idea" as the > traffic it will be generating.' > > This sentence is the key problem I have with this proposal. Experience > with bridge/routers and with end-stations indicates that systems using IP > very rarely have any idea how much traffic they will be sourcing. > Bridge/routers have no information at all. End-systems, where one might > expect some knowledge, turn out to be unable in most cases to characterise > the traffic they will generate or receive. > > The result is that asking systems to provide values for SCR and MBS is > not a useful technique. This is why the ATM Forum TM group is working > so hard on ABR. I understand that we need a definition that will work > now, not wait until ABR/flow control is defined and used. But asking > systems to provide information that they do not have is not an answer. > > The specific parameters suggested to drive the selection, such as > processor, OS, kernel buffering, etc are at best loosely coupled to the > intended behavior. > > Thank you, > Joel M. Halpern jhalpern@newbridge.com > Newbridge Networks Inc. I agree with Joel entirely. A year ago the ATMF TM WG did not acknowlege the existance of any type of service other than CBR or VBR, neither of which todays data applications fit. The proposal suggests that we take an enormous step backwards and return to that model. If the work of the int-serv influences the ATMF, then perhaps we may have ATM traffic characterizations that and underlying support that actually match application needs rather than artificially constraining elastic applications to commit to an upper bandwidth with no information on which to estimate what bandwidth is reasonable to request. For elastic applications the only reasonable traffic characterization is "all I can get, just let me know when I'm sending too much" and perhaps a minimum bandwidth threshhold. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15873; 31 Aug 94 22:29 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15869; 31 Aug 94 22:29 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa21757; 31 Aug 94 22:29 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA258621382; Wed, 31 Aug 1994 18:03:02 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from wawa.ans.net by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA258291379; Wed, 31 Aug 1994 18:02:59 -0700 Received: by wawa.ans.net (AIX 3.2/UCB 5.64/4.03) id AA12978; Thu, 1 Sep 1994 01:00:31 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Curtis Villamizar Message-Id: <9409010100.AA12978@wawa.ans.net> To: Enrique Hernandez-Valencia Cc: ip-atm@matmos.hpl.hp.com, curtis@wawa.ans.net Subject: Re: comments on ip over atm signaling draft In-Reply-To: (Your message of Wed, 31 Aug 94 17:17:00 EDT.) <9408312117.AA06922@hopaw32> Date: Thu, 01 Sep 94 01:00:31 +0000 Joel> >> 'as the calling endsystem should have a "pretty good idea" Joel> >> as the traffic it will be generating.' Joel> This sentence is the key problem I have with this proposal. Joel> Experience with bridge/routers and with end-stations Joel> indicates that systems using IP very rarely have any idea Joel> how much traffic they will be sourcing. Bridge/routers have Joel> no information at all. End-systems, where one might expect Joel> some knowledge, turn out to be unable in most cases to Joel> characterise the traffic they will generate or receive. Experience with frame relay indicates that when using wide-area links many network managers, if not end-users/end-systems, do have a good idea of what "substainable" rates and "maximum burst" sizes are adequate to them. ABR ("worst effort service"?) will most likely be quite different from the "best effort service" that the internet community is used to (at the very least more stringent flow control) Traffic descriptors can afford them with better quality of service from their service provider at a more "reasonable" cost than otherwise (which is the typical case today with frame-relay). The experience I'm aware of with FR seems to be different than your experience. The fact that someone bought the service and specified a CIR doesn't mean the model fit their problem very well or at all. IP over FR end users more typically know how much they are willing to pay for (ie: 56 kb/s). The IP providers with T1 access simply carve out 56 kb/s CIRs and seriously underutilize them (ie: a small percent utilization most of the time, occasionally saturated for sustained periods). Other go the even cheaper route and request a smaller CIR. These suffer from either inadequate queueing on the FR switches and poor utilization or too much queueing and enormous queueing delays. In either case, the CIR is an estimate of the willingness to pay for bandwidth from a small site to the rest of the Internet, not a per application estimate of bandwidth needs. FR is used only in the periphery of the Internet, is regarded as suitable for very low speed access, and is generally regarded as less desirable than a leased line of comperable speed, unless the price is sufficiently lower. Using ATM as in the first case above using FR has been proposed. This just makes ATM the next generation of leased line technology and puts the intellegence in IP, TCP, RSVP, and friends. If you are using ATM as next generation leased lines, you might as well use PVCs and state your bandwidth needs when you sign up for service. Using ATM as in the second case is also proposed. The same problems with too little or too much queueing can arise when you exceed a reservation or prediction and the additional problem of dropping cells from large AAL frames arises. ABR as currently defined is similar to the FR practice today of requesting a zero CIR and hoping that there is either an excess of bandwidth, or a reasonable amount of queueing. These are among the pitfalls. The idea is to recognize them and address the problems. I suggest you look at the work of the IETF int-serv WG as a place to start. (IMO) The ATM Forum seems to be interested in providing a service class that will work well for data applications and offering ABR is a step in that direction though working well with existing end-to-end congestion avoidance has yet to be addressed. Curtis   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22862; 1 Sep 94 0:57 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22858; 1 Sep 94 0:57 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa24121; 1 Sep 94 0:57 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA276947223; Wed, 31 Aug 1994 19:40:23 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from archimedes.inoc.sj.nec.com (archimedes.inoc.sj.nec.com) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA276617221; Wed, 31 Aug 1994 19:40:21 -0700 Received: by inoc.sj.nec.com (8.6.8.1/YDL1.7-930126.17) id TAA26482(archimedes.inoc.sj.nec.com ); Wed, 31 Aug 1994 19:40:16 -0700 Received: by nec-gw.nec.com (8.6.8.1/YDL1.7-911107.16) id TAA21431(nec-gw.nec.com ); Wed, 31 Aug 1994 19:40:21 -0700 Received: by nwk.cl.nec.co.jp (5.65c/6.4JAIN-nwk-gw+2.1) id AA16019; Thu, 1 Sep 1994 11:40:10 +0900 Received: by localhost in nwk (4.1/6.4J.6-nwk_slave_1.5) id AA00283; Thu, 1 Sep 94 11:40:20 JST Message-Id: <9409010240.AA00283@giri.nwk.cl.nec.co.jp> To: ip-atm@matmos.hpl.hp.com Subject: Re: draft-ietf-ipatm-sig-02.txt Date: Thu, 01 Sep 94 11:40:19 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ethan Spiegel I hope that it is not too late for comments on the ip-atm signalling draft. In light of the changes in UNI 3.1, the issue of which Bearer Service Class should be specified for IP over ATM should be reopened. > > > > >] Nice draft. However, I do still get a little queasy whenever I see > > >] the term "best effort" used in context of ATM, since it literally means > > >] "worst effort" and indeed reference is made to Traffic Class X (UBR). > > >] I realize that Traffic Class Y (ABR) isn't done yet but if people > > >] take this too seriously, they might expect that Class X really will > > >] perform well enough (which I seriously doubt) and thus won't need > > >] Class Y. > > >] Well, there's always the Class C option with a defined SCR. According to the clarifications made in UNI 3.1, BCOB-X does *not* mean UBR. The Best Effort Indicator may be set when using either BCOB-X or BCOB-C. For VBR or UBR connections, either BCOB-X or BCOB-C may be specified. > > > > > >Unfortunately, in UNI 3.0 the only applicable Bearer Service Classes (BCS) > > >are BCS-C and BCS-X (BCS-A, the third BCS, is solely a CBR transport > > >service). Folks thought BCS-X was more "flexible" since the timing > > >requirements are 'user-defined' instead of the set 'no-end-to-end timing > > >requirements' in BSC-C. (Although, the recommendation was that if > > >BCS-X is specified, the timing requirements be set to 'no indication'.) > > >This part of the signaling draft was one of the more difficult to pin > > >down because of the many open issues and ambiguities in the UNI 3.0 traffic > > >management specification. > > > > > >Maybe we should put a statement in the "Open Issues" section about the > > >future Class Y service.... > > > > > > > > >Maryann > > > > Your commentary points up a separate problem not associated with the Class X > > versus Y debate enjoined here. That is, the ambiguities in UNI 3.0 that were > > "corrected" in UNI 3.1. While far from perfect, the updated 3.1 specificatio > > n > > disambiguates many of the really gross inconsistencies with the BBC service c > > lasses > > that existed in UNI 3.0. For instance, BBC service class X may take three fo > > rms (or two, > > depending on your point of view). Class X with traffic type = "No Indication" > > (NI) > > or VBR and Timing requirements = NI or NO indicates a Class X data service an > > d > > traffic type = CBR with a required timing indication of YES indicates a circu > > it service. > > Futhermore, "Best Effort" (which I agree is really worst effort) is indicated > > by the > > Traffic Descriptor IE by setting the best effort flag. Therefore, equating > > Class X as the ATMF best effort service is technically incorrect under some > > circumstances, in fact, as I've shown, you can specify a non-best effort circ > > uit service > > as a Class X service. Also your description of the flexibility of the Timing > > indicators on class X are no longer true. There is a much more important clarification on the use of Bearer Service Classes in UNI 3.1. For BCOB-C, "The network interworking function may look at the AAL and provide service based on it." For BCOB-X, "When the user specifies BCOB-X, the user is requesting an ATM only service from the network. In this case, the network shall not process any higher layer protocols (e.g. AAL protocols)." If AAL5 is to be used for IP over ATM, BCOB-C may be used, but BCOB-X can *not* be used. No AALs can be supported when using BCOB-X. So, for UNI 3.1 and later versions, BCOB-C should be mandatory for IP over ATM. > > In the draft we do not equate best effort with Class X. In fact, we say that > either Class X or C can be used. In my comment above I tried to clarify > why the group had chosen to recommend specifying Class X. Mickey Spiegel NEC Corporation   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04761; 1 Sep 94 11:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04754; 1 Sep 94 11:07 EDT Received: from [15.255.176.33] by CNRI.Reston.VA.US id aa08156; 1 Sep 94 11:07 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA034025969; Thu, 1 Sep 1994 06:26:09 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from nbkanata.newbridge.com by matmos.hpl.hp.com with SMTP (1.37.109.10G/HPL42.42) id AA033695966; Thu, 1 Sep 1994 06:26:06 -0700 Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA10289; Thu, 1 Sep 94 09:21:12 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA13100; Thu, 1 Sep 94 09:21:09 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA19361; Thu, 1 Sep 94 09:20:04 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA15892; Thu, 1 Sep 1994 09:22:15 +0500 Date: Thu, 1 Sep 1994 09:22:15 +0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joel Halpern Message-Id: <9409011322.AA15892@urchin.newbridge> To: ip-atm@matmos.hpl.hp.com, enrique@hoserve.ho.att.com Subject: Re: comments on ip over atm signaling draft X-Sun-Charset: US-ASCII Content-Length: 1760 Having built and installed routers supporting Frame Relay, I have to disagree that the devices or customers have a good idea of what the sustainable rates and maximum burst sizes are adequate. With FR, the network manager decides what he is willing to pay for. The "MBS" is a side effect of the Peak and Sustained rates that he uses, and the timing that the provider is interested in supporting. We had customer knobs for all of these, and the customers were confused by it. (For reference, this was at a previous company. I have no idea what Newbridge's experience has been.) The conclusion I can reach is that it is sometimes useful to allow the customer to set a value to be used. But having the machinery "know" what values are needed (which is what the proposal suggested) has never been known to work. The choice of what values an administrator will set are tied to total traffic needs, tarrifs, and many other things. They are slowly driven to a useful values if the customer traffic exhibits long term stability. This works nicely with PVCs. It is really hard to map will to SVCs. In no way does this relate to "the end system should have a pretty good idea as to the traffic it will be generating". I apologies to those who feel I am being repetitive. I believe that this distinction historically has been one of the differences in perspective between LAN and WAN. In the LAN, we try to support the traffic the machine wants. Traditionally, the WAN has supported the traffic the customer is willing to pay for, and the sources are forced to match that. There is a lack of correlation between these two models, and trying to just ignore it produces trouble. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01739; 24 Aug 94 8:15 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01735; 24 Aug 94 8:15 EDT Received: from matmos.hpl.hp.com by CNRI.Reston.VA.US id aa04205; 24 Aug 94 8:15 EDT Received: by matmos.hpl.hp.com (1.37.109.10G/HPL42.42) id AA126202872; Wed, 24 Aug 1994 03:07:52 -0700 Errors-To: atmpost@matmos.hpl.hp.com X-Orig-Sender: atmpost@matmos.hpl.hp.com X-Info: Submissions to ip-atm@matmos.hpl.hp.com X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm X-Loop: ATM CLP.bit ON Precedence: bulk Received: from ktik3 (ktik3.ethz.ch) by matmos.hpl.hp.com with ESMTP (1.37.109.10G/HPL42.42) id AA125872869; Wed, 24 Aug 1994 03:07:49 -0700 Received: from ktik0 (ktik0 [129.132.66.1]) by ktik3 (8.6.8.1/8.6.6) with ESMTP id MAA06360 for ; Wed, 24 Aug 1994 12:07:47 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Patrick Droz Received: (droz@localhost) by ktik0 (8.6.8.1/8.6.6) id MAA10940 for ip-atm@matmos.hpl.hp.com; Wed, 24 Aug 1994 12:07:45 +0200 Date: Wed, 24 Aug 1994 12:07:45 +0200 Message-Id: <199408241007.MAA10940@ktik0> Content-Type: text Content-Length: 556 Apparently-To: ip-atm@matmos.hpl.hp.com Does somebody have a list of different traffic types such as video, voice, data and so on with a statistical description of their behavior? The statistical parameters I am looking for are peak cell rate sustainable cell rate and the mean burst size (ATM traffic descriptor). I would also be interested in finding a list that quantifies the set of traffic types for different environments such as a bank or hospital environment. Any kind of information would be very welcomed. Regards Patrick Droz -- droz@ktik0.ethz.ch ETH Zurich   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03746; 25 Aug 94 10:17 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03742; 25 Aug 94 10:17 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06337; 25 Aug 94 10:17 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03733; 25 Aug 94 10:17 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03724; 25 Aug 94 10:17 EDT Received: from ncc.ripe.net by CNRI.Reston.VA.US id aa06332; 25 Aug 94 10:17 EDT Received: from rijp.ripe.net by ncc.ripe.net with SMTP id AA00199 (5.65a/NCC-2.3); Thu, 25 Aug 1994 16:13:53 +0200 Received: from localhost.ripe.net by rijp.ripe.net with SMTP id AA20030 (5.65a/NCC-2.2); Thu, 25 Aug 1994 16:12:02 +0200 Message-Id: <9408251412.AA20030@rijp.ripe.net> To: Hostcount Recipients: @ripe.net:; Subject: RIPE DNS Hostcount July 1994 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marten Terpstra X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5064 X-Fax: +31 20 592 5090 Date: Thu, 25 Aug 1994 16:11:15 +0200 X-Orig-Sender: Marten.Terpstra@ripe.net [ Some people may have received some old mail from us over the last minutes or so. Due to an error, we have resent some mail that was originally sent in May this year. Apologies. ] Folks, Here is the (belated) hostcount for July 1994. Due to holidays the results are only available now, but the data was actually gathered at the end of July. - A few countries show a slightly lower count this month. Due to my absense I have not been able to re-count them. - Overall an increase of over 29,000 (or 3.8%) to almost 790,000 machines in the European part of the DNS. - Those who want to pick up some data from the usual place (ftp.ripe.net:ripe/hostcount) have to hurry up, because the files will be replaced by the August hostcount next week. Sorry. Cheers, -Marten ----- RIPE DNS Hostcount Previous Count : Thu Jun 30 1994 This Count : Sun Jul 31 1994 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 2 0 0 0 0 at 415 21758 740 21018 + 1404 az 1 0 0 0 0 be 161 13027 224 12803 + 688 bg 2 15 5 10 - 71 by 1 0 0 0 0 ch 308 48901 373 48528 + 2113 cs 54 1916 133 1783 - 521 cy 204 2920 137 2783 + 2745 cz 142 7370 114 7256 - 70 de 2101 158019 4498 153521 +11394 dk 201 12894 497 12397 + 259 dz 2 9 0 9 + 2 ee 30 692 4 688 + 50 eg 4 57 0 57 0 es 385 21698 184 21514 - 227 fi 412 51407 1006 50401 + 3477 fo 1 0 0 0 0 fr 863 74369 1097 73272 + 4671 gb 1 22 0 22 + 1 ge 1 0 0 0 0 gr 2 17 0 17 - 2781 hr 59 783 13 770 - 58 hu 90 5596 29 5567 + 149 ie 25 1873 11 1862 - 680 il 168 8857 156 8701 + 530 is 68 3350 24 3326 + 165 it 590 21975 472 21503 - 2010 li 4 30 3 27 0 lt 8 52 0 52 - 1 lu 22 426 2 424 + 10 lv 15 214 1 213 + 26 ma 1 0 0 0 0 mk 1 0 0 0 0 mt 1 0 0 0 0 nl 602 62783 1023 61760 + 2374 no 621 38297 413 37884 - 904 pl 341 7102 209 6893 - 291 pt 143 4609 60 4549 + 237 ro 28 460 3 457 + 43 ru 59 679 67 612 + 159 se 769 58346 1111 57235 + 1500 si 30 1151 24 1127 + 291 sk 74 1226 16 1210 + 153 su 213 3688 165 3523 + 300 tn 2 35 1 34 - 12 tr 51 1356 28 1328 + 122 ua 56 436 47 389 + 112 uk 1394 181146 16924 164222 + 4013 va 0 0 0 0 0 yu 3 0 0 0 0 ============================================================ 10731 819561 29814 789747 +29362 This is an overview of the History of the RIPE hostcounts. It only contains the totals. The totals for 1990-1991 should be considered rather unstable and unreliable because the program used then was not really tuned, plus the count was not done as regular as it is now. Count : total hostcount for all European top level domains Delta : delta since previous count Delta % : delta as percentage of previous count Q Delta : delta over the past quarter Q Delta%: delta over last quarter as percentage of end of last quarter count For the Q Deltas I have not calculated those back before 1992, because the figures for 1990-1991 are not too reliable. *) Dec 1991 hostcount estimated at 135,000. Count Delta Delta % Q Delta Q Delta % ------------------------------------------------------------------- Oct 1990 31724 Nov 1990 33665 + 1941 + 6.1% Dec 1990 29230 - 4435 - 13.2% Jan 1991 43832 + 14602 + 50.0% Feb 1991 - Mar 1991 44506 + 674 + 1.5% Apr 1991 46948 + 2442 + 5.5% May 1991 - Jun 1991 63267 + 16319 + 34.8% Jul 1991 - Aug 1991 73069 + 9802 + 15.5% Sep 1991 92834 + 19765 + 27.0% Oct 1991 104824 + 11990 + 12.9% Nov 1991 129652 + 24828 + 23.7% Dec 1991 - Jan 1992 141308 + 11656 + 9.0% Feb 1992 161434 + 20126 + 14.2% Mar 1992 167939 + 6505 + 4.0% + 32939 *) + 24.4% *) Apr 1992 170050 + 2111 + 1.3% May 1992 182528 + 12478 + 7.3% Jun 1992 196758 + 14230 + 7.8% + 28819 + 17.2% Jul 1992 213017 + 16259 + 8.3% Aug 1992 221951 + 8934 + 4.2% Sep 1992 232522 + 10571 + 4.8% + 35764 + 18.2% Oct 1992 254585 + 22063 + 9.5% Nov 1992 271795 + 17210 + 6.8% Dec 1992 284374 + 12579 + 4.6% + 51852 + 22.3% Jan 1993 303828 + 19454 + 6.8% Feb 1993 322902 + 19074 + 6.3% Mar 1993 355140 + 32238 + 10.0% + 70766 + 24.9% Apr 1993 366164 + 11024 + 3.1% May 1993 385522 + 19358 + 5.3% Jun 1993 404930 + 19408 + 5.0% + 49790 + 14.0% Jul 1993 426827 + 21897 + 5.4% Aug 1993 451116 + 24289 + 5.7% Sep 1993 469356 + 18240 + 4.0% + 64424 + 15.9% Oct 1993 500018 + 30662 + 6.5% Nov 1993 533701 + 33683 + 6.7% Dec 1993 553357 + 19656 + 3.7% + 84001 + 17.9% Jan 1994 587135 + 33778 + 6.1% Feb 1994 623158 + 36023 + 6.1% Mar 1994 655164 + 32006 + 5.1% +101807 + 18.4% Apr 1994 693346 + 38182 + 5.8% May 1994 735317 + 41971 + 6.1% Jun 1994 760385 + 25076 + 3.4% +105221 + 16.1% Jul 1994 789747 + 29362 + 3.8%   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00596; 26 Aug 94 4:44 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00592; 26 Aug 94 4:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01531; 26 Aug 94 4:44 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00583; 26 Aug 94 4:44 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00579; 26 Aug 94 4:44 EDT Received: from ncc.ripe.net by CNRI.Reston.VA.US id aa01526; 26 Aug 94 4:44 EDT Received: from rijp.ripe.net by ncc.ripe.net with SMTP id AA06840 (5.65a/NCC-2.3); Fri, 26 Aug 1994 10:43:51 +0200 Received: from localhost.ripe.net by rijp.ripe.net with SMTP id AA21166 (5.65a/NCC-2.2); Fri, 26 Aug 1994 10:43:50 +0200 Message-Id: <9408260843.AA21166@rijp.ripe.net> To: Panagiotis Tzounakis Subject: Re: RIPE DNS Hostcount July 1994 error... Cc: Hostcount Recipients: @ripe.net:; In-Reply-To: Your message of Fri, 26 Aug 1994 10:54:17 +0300. <199408260754.AA05619@info.forthnet.gr> X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marten Terpstra X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5064 X-Fax: +31 20 592 5090 Date: Fri, 26 Aug 1994 10:43:48 +0200 X-Orig-Sender: Marten.Terpstra@ripe.net Panagiotis Tzounakis writes * Marten, * I think Cyprus and Greece were accidentally swaped in the * RIPE DNS Hostcount July 1994.... Indeed they were. Post-holiday blues I guess. Please all find below the corrected hostcount. I have not included the history because the total figures have not changed. All files on ftp.ripe.net have been corrected as well. -Marten RIPE DNS Hostcount Previous Count : Thu Jun 30 1994 This Count : Sun Jul 31 1994 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 2 0 0 0 0 at 415 21758 740 21018 + 1404 az 1 0 0 0 0 be 161 13027 224 12803 + 688 bg 2 15 5 10 - 71 by 1 0 0 0 0 ch 308 48901 373 48528 + 2113 cs 54 1916 133 1783 - 521 cy 2 17 0 17 - 21 cz 142 7370 114 7256 - 70 de 2101 158019 4498 153521 +11394 dk 201 12894 497 12397 + 259 dz 2 9 0 9 + 2 ee 30 692 4 688 + 50 eg 4 57 0 57 0 es 385 21698 184 21514 - 227 fi 412 51407 1006 50401 + 3477 fo 1 0 0 0 0 fr 863 74369 1097 73272 + 4671 gb 1 22 0 22 + 1 ge 1 0 0 0 0 gr 204 2920 137 2783 - 15 hr 59 783 13 770 - 58 hu 90 5596 29 5567 + 149 ie 25 1873 11 1862 - 680 il 168 8857 156 8701 + 530 is 68 3350 24 3326 + 165 it 590 21975 472 21503 - 2010 li 4 30 3 27 0 lt 8 52 0 52 - 1 lu 22 426 2 424 + 10 lv 15 214 1 213 + 26 ma 1 0 0 0 0 mk 1 0 0 0 0 mt 1 0 0 0 0 nl 602 62783 1023 61760 + 2374 no 621 38297 413 37884 - 904 pl 341 7102 209 6893 - 291 pt 143 4609 60 4549 + 237 ro 28 460 3 457 + 43 ru 59 679 67 612 + 159 se 769 58346 1111 57235 + 1500 si 30 1151 24 1127 + 291 sk 74 1226 16 1210 + 153 su 213 3688 165 3523 + 300 tn 2 35 1 34 - 12 tr 51 1356 28 1328 + 122 ua 56 436 47 389 + 112 uk 1394 181146 16924 164222 + 4013 va 0 0 0 0 0 yu 3 0 0 0 0 ============================================================ 10731 819561 29814 789747 +29362   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02623; 26 Aug 94 12:16 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02619; 26 Aug 94 12:16 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa10311; 26 Aug 94 12:16 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qe3v5-000MPca; Fri, 26 Aug 94 09:14 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe3v3-000MPYC; Fri, 26 Aug 94 09:14 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe3v2-000MPeC; Fri, 26 Aug 94 09:14 PDT Received: from ludwig.intel.com by hermes.intel.com (5.65/10.0i); Fri, 26 Aug 94 09:12:36 -0700 Received: by Ludwig.intel.com (4.1/SMI-4.1) id AA12784; Fri, 26 Aug 94 08:44:56 PDT Date: Fri, 26 Aug 94 08:44:56 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sally Hambridge Message-Id: <9408261544.AA12784@Ludwig.intel.com> To: ietf-run@mailbag.intel.com Subject: Test msg X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk Hello all - this is a test to see if the mailing list is working. I hope to get our revised charter out today. Joyce - will you need anything more to take to IESG? Sally sallyh@ludwig.intel.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03228; 26 Aug 94 13:30 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03224; 26 Aug 94 13:30 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa11682; 26 Aug 94 13:30 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qe568-000MNZa; Fri, 26 Aug 94 10:29 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe565-000MNaC; Fri, 26 Aug 94 10:29 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe564-000MNZC; Fri, 26 Aug 94 10:29 PDT Received: from ludwig.intel.com by hermes.intel.com (5.65/10.0i); Fri, 26 Aug 94 10:27:57 -0700 Received: by Ludwig.intel.com (4.1/SMI-4.1) id AA12888; Fri, 26 Aug 94 10:24:54 PDT Date: Fri, 26 Aug 94 10:24:54 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sally Hambridge Message-Id: <9408261724.AA12888@Ludwig.intel.com> To: ietf-run@mailbag.intel.com Subject: Administrivia X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk OK - the list seems to be working - although I did manage to mis-spell martyne's name, so the first msg to her bounced. Some administrivia before the charter: This list is ietf-run@mailbag.intel.com It is the mailing list for the (potential) IETF Working Group on Responsible Use of the Net. This is a majordomo administered list, so messages concerning subscribing, unsubscribing, etc. should be sent to majordomo@mailbag.intel.com Messages to the entire list go to ietf-run@mailbag.intel.com Current Co-Chairs: Gary Malkin gmalkin@xylogics.com Sally Hambridge sallyh@ludwig.intel.com Area - User Services Area Director - Joyce K Reynolds jkrey@isi.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03258; 26 Aug 94 13:32 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03254; 26 Aug 94 13:32 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa11722; 26 Aug 94 13:32 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qe58E-000MNea; Fri, 26 Aug 94 10:32 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe58C-000MNlC; Fri, 26 Aug 94 10:32 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe58B-000MNeC; Fri, 26 Aug 94 10:31 PDT Received: from ludwig.intel.com by hermes.intel.com (5.65/10.0i); Fri, 26 Aug 94 10:29:58 -0700 Received: by Ludwig.intel.com (4.1/SMI-4.1) id AA12900; Fri, 26 Aug 94 10:26:19 PDT Date: Fri, 26 Aug 94 10:26:19 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sally Hambridge Message-Id: <9408261726.AA12900@Ludwig.intel.com> To: ietf-run@mailbag.intel.com Subject: First Round Charter X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk Here-s the slightly revised charter. Any discussion? ------------------------------------------------------------ Reflecting the needs of the Internet community, we see a need to create a code of conduct for Internet users. The Working Group will develop an FYI RFC on responsible use of the Internet and its tools. GOALS AND MILESTONES DEC 94 - Internet Draft of Bibliography of available literature MARCH 95 - Internet Draft of AUP/Code of Conduct/Netiquette Guide JULY 95 - Final Draft FYI RFC of AUP/Code of Conduct/Netiquette Guide   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03628; 26 Aug 94 14:01 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03622; 26 Aug 94 14:01 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa12204; 26 Aug 94 14:01 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qe5Zn-000MNua; Fri, 26 Aug 94 11:00 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe5Zl-000MOXC; Fri, 26 Aug 94 11:00 PDT Received: from SSD.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qe5Zk-000MNuC; Fri, 26 Aug 94 11:00 PDT Received: from atlas.xylogics.com by SSD.intel.com (4.1/SMI-4.1) id AA18862; Fri, 26 Aug 94 11:00:21 PDT Received: by atlas.xylogics.com id AA06855 (5.65c/UK-2.1-940401); Fri, 26 Aug 1994 13:56:28 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gary Scott Malkin Date: Fri, 26 Aug 1994 13:56:28 -0400 Message-Id: <6855.199408261756@atlas.xylogics.com> To: sallyh@ludwig.intel.com Cc: ietf-run@mailbag.intel.com In-Reply-To: Sally Hambridge's message of Fri, 26 Aug 94 10:26:19 PDT <9408261726.AA12900@Ludwig.intel.com> Subject: First Round Charter X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk My only comment is that we should remove references to AUP for the same reason we took "Policy" out of the "Site Security Handbook" title. We can't set policy, just make suggestions. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07556; 27 Aug 94 23:19 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07552; 27 Aug 94 23:19 EDT Received: from lists.psi.com by CNRI.Reston.VA.US id aa13903; 27 Aug 94 23:19 EDT Received: by lists.psi.com (5.65b/SMI-4.1.3-PSI) id AA23057; Sat, 27 Aug 94 22:40:49 -0400 Return-Path: Received: from psi.com by lists.psi.com (5.65b/SMI-4.1.3-PSI) id AA23049; Sat, 27 Aug 94 22:40:31 -0400 Received: from netcom17.netcom.com by psi.com (4.1/2.1-PSI/PSINet) id AA05562; Sat, 27 Aug 94 22:40:27 EDT Received: by netcom17.netcom.com (8.6.8.1/Netcom) id TAA09004; Sat, 27 Aug 1994 19:40:44 -0700 Date: Sat, 27 Aug 1994 19:40:43 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Arthur R. McGee" Subject: Building the NII from the Bottom Up (fwd) To: communet@uvmvm.uvm.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- Date: Sat, 27 Aug 1994 16:35:26 -0700 >From: Phil Agre To: Arthur R. McGee Subject: Building the NII from the Bottom Up -------------------------------------------------------------------- T H E N E T W O R K O B S E R V E R VOLUME 1, NUMBER 8 AUGUST 1994 -------------------------------------------------------------------- This file contains a single article from the August 1994 issue of The Network Observer. To fetch the entire file, send a message that looks like this: To: rre-request@weber.ucsd.edu Subject: archive send tno-august-1994 To fetch an index for the rest of the RRE archive, send a message that looks like this: To: rre-request@weber.ucsd.edu Subject: archive send index -------------------------------------------------------------------- Building the NII From The Bottom Up: A Strategy For Working Through Local Organizations. Steven E. Miller CPSR National Board smiller@mecn.mass.edu By definition, an infrastructure is something that lays the foundation for something else. The coming National Information Infrastructure (NII) will lay the foundation for -- and thereby help shape -- new forms of production, consumption, culture, social interaction, and citizenship. The kind of future the NII helps shape depends, in part, on the visions it is intended to achieve and the strategies used to implement those goals. Industry spokespeople describe the NII as a vehicle for movies on demand, home shopping, and sit-com reruns, with the "serious" content provided by endless infomercials. Clinton Administration liberals stress the NII's educational importance of allowing access to endless information, as well as its potential to spur private sector economic development. Many cybernauts are most enthused about the creation of virtual communities and the coming together of the global village. But for those of us whose pleasure in the technology is matched by a growing concern about the tendency of the NII to further divide our society (and the world) into "haves" and "have nots," these visions -- and the NII implementation strategies they imply -- are woefully inadequate. To those of us who see the NII as a critical tool for the revitalization of democracy, the strengthening of neighborhoods, the release of grass-roots cultural creativity, and the revival of mutual aid, these visions are a painful warning of opportunities we hope are not yet lost. These visions fail because they won't lead to the achievement of universal service in a meaningful way. While an estimated third of American homes have a computer, only about 3% are regularly online. In fact, as a result of price increases caused by deregulation, a growing number of Americans -- up to 20% of some low-income communities -- don't even have home telephones. Even if the "NII access device" of the future is built into TV sets, cable set-top boxes, video game controllers, or other "everyday" devices, and even if they eventually drop in price, it will be a long time before the entire population will be able to afford them -- if ever. In addition, no matter how friendly computers get, they will still require some level of skill and expertise. In a nation which has a 40% high school drop out rate, a 20% adult illiteracy rate, a permanently unemployed underclass, and a segmented labor market that tracks a significant proportion of the working population into dead-end, unskilled, and short-term jobs -- it is likely that many people will never get taught the skills needed to do more than the most basic types of (probably consumption oriented) activities. Social transformation requires social participation, and a totally market-driven NII is not likely to achieve it. Second, these visions fail because they are too focused on individuals. For all the importance of individual responsibility and effort, societal power (political, economic, and cultural) overwhelmingly operates through institutions. Individual empowerment can lead to upward mobility. But the "trickling up" of particular people doesn't change the structural hierarchies and inequalities of our society. Social justice, the provision of the basic necessities of life for everyone, the inclusion of all groups in a democratic governing process -- all these require the poor and powerless to aggregate their individual efforts into organizations and collective campaigns. AN ORGANIZATIONAL STRATEGY These criticisms of the most common visions of NII implementation imply another approach: combining NII deployment with local organizational development. And not just any organizations, but specifically those that serve, advocate for, and are run by people from the parts of our society that are least likely to be able to buy their way into a market-driven NII that rations access according to personal income. In this context, people who are creating civic networks as a way of anchoring NII development in the needs and realities of local communities must go beyond making their facilities available to large numbers of individuals, even if those individuals are low-income, non-white, non-English speaking, or any of the other politically correct categories. We need to adopt a strategy of working through and with grassroots organizations. An organizational strategy has many advantages. Organizations usually have greater financial resources than individuals, particularly low-income people. Non-profit organizations are much more capable than individuals of soliciting donations or applying for grants to pay for a couple of computers and modems. In fact, most Internet users already get supplied with equipment and access through organizations -- universities and corporations. To include other populations, we need to work through the organizations that impact their lives. But simply having the equipment is not enough. Few of us learned all we know by ourselves. When we go to a library, we start by asking the librarian for help. In terms of computers, most of us learned from others at our schools or workplaces. We all need intermediaries to get us started and support us through the inevitable problems of learning to enter and wander through cyberspace. Local organizations can provide the vital connection between ordinary people and the on-line universe. Organizations are multipliers. Training individuals helps individuals. Training people in an organization means that the skills are likely to be passed on to others, and that the community will retain an institutional capability even as individuals pass in and out of activity. Working through local organizations also makes it easier to connect to people. Instead of trying to convince people to come to the network, the network goes to where the people are already being gathered together to serve their own needs. These are the groups that are already fighting to empower their members, it will be no small accomplishment if we can help them finds ways to use telecommunications to increase their chances of success. The strengthening and success of local citizen's groups, self-help neighborhood associations, locally run service agencies, and other community-based organizations is crucial to any larger strategy for increased equality and justice in our world, of which preventing the creation of "information haves and have nots" is just one aspect. Rooting cyberspace in the social realities of neighborhood organizations increases the odds that the needs and priorities of those "have not" areas will be effectively aggregated and expressed. If we want to impact NII policy, we have to build a grassroots base as well as advocate at the federal level. Washington-based public interest advocacy is vitally important. But it is only one part of the picture. Local understanding of the issues based on concrete efforts to use telecommunications for community improvement is just as important, perhaps in some ways even more important. This is another way that organizations multiply individual impact. TECHNOLOGY HELPS ORGANIZATIONS People support or join groups because membership brings some amount of personal benefits such as learning new skills, access to resources, exposure to a broader world, getting useful services, etc.; because the group provides a way to be connected with other people who share similar interests; and because they see the group as an effective vehicle for dealing with personal or societal problems. Technology can help organizations attract and keep loyal members, a vital ingredient for success. The value of membership increases if organizations are the vehicle for computer skills training and for access to the world of on-line resources. At the same time, local organizations will be better than some central group at recruiting network users from a broad range of the population. Technology also makes groups more effective. Internally, groups can use word processing to create funding proposals, write reports and petitions about important issues, create membership letters and other materials, prepare newsletters and flyers, and more. Databases are vital for keeping membership lists and addresses, tracking contributions, client tracking, etc. And financial software for bookkeeping and fund accounting helps with one of the biggest headaches in the non-profit world. Externally, telecomputing allows organizations to gather data on funding opportunities, on issues they address, and on the population they serve. It allows them to more easily communicate with their peers in other organizations to share experiences and build coalitions. It allows them to gain greater exposure and establish increased credibility by participating in national forums and acting as "issue experts" for community networks. In this sense, local groups act as "information providers" rather than as information consumers -- exactly the kind of bottom-up activism that will be needed if the NII is more than an overwhelming and hegemonic waterfall of top-down data flow. Networks augment the ability of those who already know about and talk with each other offline to share large amounts of information over greater distances with less concern about "real time" coordination. Broad based local and national networks help bring together those who share similar interests, or could simply be helpful to each other, but whose paths do not otherwise cross. In this way, people and groups can join with others who are "like us." IMPLICATIONS FOR COMMUNITY NETWORKS An organizational strategy has important implications for creating community networks. While most local network organizers are already doing some of these activities, the absence of an explicit strategy has forced many of them to discover these ideas on their own and hindered fully effective sharing of experience. First, it implies that the first step in creating a local network is talking to local neighborhood leaders and building a coalition of local community groups. These groups should be treated as full partners in the design process rather than as clients to be served. Since few of these groups will have enormous resources or technical expertise, this process also requires a deep commitment to some type of participatory design approach. A successful PD effort needs a combination of talking about general needs and opportunities to use and comment upon functional models. Here, in fact, is where the technically knowledgeable people in the group play a key role, iteratively creating prototypes and then incorporating insights from group critiques. In this way technically sophisticated people can help non-techies understand the general possibilities of available technology so that the newcomers can inject their specific needs and realities into the design. Without working prototypes, group discussions can get lost in galactic visions beyond local capabilities. Without group input, technical development can easily forget that it is only the vehicle for achieving other goals. Local groups should be seen as a primary vehicle for public access, equally or even more important than libraries, city hall, and shopping malls. But, more importantly, network organizers should welcome, rather than feel unease, about the inevitable tendency of local groups to see the network as a vehicle for serving their own organizational needs. The success of the local groups is the success of the network, even though it will often feel as if there is a tension between the two. -------------------------------------------------------------------- Phil Agre, editor pagre@ucsd.edu Department of Communication University of California, San Diego +1 (619) 534-6328 La Jolla, California 92093-0503 FAX 534-7315 USA -------------------------------------------------------------------- The Network Observer is distributed through the Red Rock Eater News Service. To subscribe to RRE, send a message to the RRE server, rre-request@weber.ucsd.edu, whose subject line reads "subscribe firstname lastname", for example "Subject: subscribe Jane Doe". For more information about the Red Rock Eater, send a message to that same address with a subject line of "help". For back issues etc, use a subject line of "archive send index". -------------------------------------------------------------------- Copyright 1994 by the editor. You may forward this issue of The Network Observer electronically to anyone for any non-commercial purpose. Comments and suggestions are always appreciated. --------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05194; 29 Aug 94 13:47 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05190; 29 Aug 94 13:47 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa11714; 29 Aug 94 13:47 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qfAk5-000MOTa; Mon, 29 Aug 94 10:43 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfAk3-000MOXC; Mon, 29 Aug 94 10:43 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfAjz-000MO2C; Mon, 29 Aug 94 10:43 PDT Received: from ludwig.intel.com by hermes.intel.com (5.65/10.0i); Mon, 29 Aug 94 10:43:29 -0700 Received: by Ludwig.intel.com (4.1/SMI-4.1) id AA15951; Mon, 29 Aug 94 09:09:34 PDT Date: Mon, 29 Aug 94 09:09:34 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sally Hambridge Message-Id: <9408291609.AA15951@Ludwig.intel.com> To: ietf-run@mailbag.intel.com Subject: Charter, take 2 X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk OK - I've tried to point out what I think needs some word-smithing here. Put thinking caps on - and let's get some discussion going. --------- Reflecting the needs of the Internet community, we see a need to ^^ should we say "IETF" instead? create a code of conduct for Internet users. The Working Group will develop an FYI RFC on responsible use of the Internet and its tools. GOALS AND MILESTONES DEC 94 - Internet Draft of Bibliography of available literature MARCH 95 - Internet Draft of Code of Conduct/Netiquette Guide ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Which of these do we like? ISOC is calling what they're doing a Code of Conduct. Should we use the same term for consistency's sake? Or do we get a full divorce? Notice that AUP is gone. JULY 95 - Final Draft FYI RFC of Code of Conduct/Netiquette Guide Any comments? Sally sallyh@ludwig.intel.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05415; 29 Aug 94 14:02 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05411; 29 Aug 94 14:01 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa12149; 29 Aug 94 14:01 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qfB0t-000MO7a; Mon, 29 Aug 94 11:00 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfB0r-000MNuC; Mon, 29 Aug 94 11:00 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfB0i-000MO7C; Mon, 29 Aug 94 11:00 PDT Received: from osi-east.es.net by hermes.intel.com (5.65/10.0i); Mon, 29 Aug 94 11:00:46 -0700 Received: from donner.nersc.gov by osi-east.es.net via ESnet SMTP service id <02721-0@osi-east.es.net>; Mon, 29 Aug 1994 10:59:28 +0000 Received: by donner.nersc.gov (4.1/ESnet-1.2) id AA02303; Mon, 29 Aug 94 10:59:26 PDT Date: Mon, 29 Aug 94 10:59:26 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Suzanne Medeiros-Smith Message-Id: <9408291759.AA02303@donner.nersc.gov> To: ietf-run@mailbag.intel.com Subject: Re: Charter, take 2 X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk I prefer "Netiquette Guide" to Code of Conduct/Netiquette Guide. It sounds less formal. It seems to model our approach better. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suzanne M. Smith Network Information & User Services Energy Sciences Network (ESnet) Lawrence Livermore National Laboratory Phone : 1-800-33-ESnet P.O. Box 5509, Mail-Stop L-561 (or) : 1-510-423-9557 Livermore, CA 94551 USA FAX : 1-510-422-0435 Internet: ssmith@es.net X.400 : /PN=Suzanne Smith/P=ESnet/A= /C=US/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MARCH 95 - Internet Draft of Code of Conduct/Netiquette Guide ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Which of these do we like? ISOC is calling what they're doing a Code of Conduct. Should we use the same term for consistency's sake? Or do we get a full divorce? Notice that AUP is gone. JULY 95 - Final Draft FYI RFC of Code of Conduct/Netiquette Guide Any comments? Sally sallyh@ludwig.intel.com ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07293; 29 Aug 94 16:24 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07289; 29 Aug 94 16:24 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa03435; 29 Aug 94 16:24 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qfDEC-000MNra; Mon, 29 Aug 94 13:22 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfDEA-000MNsC; Mon, 29 Aug 94 13:22 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfDEA-000MNrC; Mon, 29 Aug 94 13:22 PDT Received: from atlas.xylogics.com by hermes.intel.com (5.65/10.0i); Mon, 29 Aug 94 13:22:27 -0700 Received: by atlas.xylogics.com id AA08578 (5.65c/UK-2.1-940401); Mon, 29 Aug 1994 16:20:15 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gary Scott Malkin Date: Mon, 29 Aug 1994 16:20:15 -0400 Message-Id: <8578.199408292020@atlas.xylogics.com> To: sallyh@ludwig.intel.com Cc: ietf-run@mailbag.intel.com In-Reply-To: Sally Hambridge's message of Mon, 29 Aug 94 09:09:34 PDT <9408291609.AA15951@Ludwig.intel.com> Subject: Charter, take 2 X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk > MARCH 95 - Internet Draft of Code of Conduct/Netiquette Guide > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Which of these do we like? ISOC is calling what they're doing > a Code of Conduct. Should we use the same term for consistency's > sake? Or do we get a full divorce? Notice that AUP is gone. A Code of Conduct would be a more formal document. One could almost envision it engraved on stone tablets, or written in legalese. A Netiquette Guide would be a friendlier document, sort of like the Tao of IETF, with some humorous material added to keep readers interested. I think we should write the Netiquette Guide. Then, if the ISOC wants something short and formal, we could strip the Guide down to create the Code of Conduct. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07789; 29 Aug 94 17:04 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07785; 29 Aug 94 17:04 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa04484; 29 Aug 94 17:04 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qfDrw-000MNZa; Mon, 29 Aug 94 14:03 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfDru-000MOGC; Mon, 29 Aug 94 14:03 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfDru-000MNZC; Mon, 29 Aug 94 14:03 PDT Received: from venera.isi.edu by hermes.intel.com (5.65/10.0i); Mon, 29 Aug 94 14:03:51 -0700 Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Mon, 29 Aug 1994 11:02:42 -0700 Date: Mon, 29 Aug 1994 11:03:08 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: jkrey@isi.edu Posted-Date: Mon, 29 Aug 1994 11:03:08 -0700 Message-Id: <199408291803.AA05254@akamai.isi.edu> Received: by akamai.isi.edu (5.65c/4.0.3-4) id ; Mon, 29 Aug 1994 11:03:08 -0700 To: sallyh@ludwig.intel.com Subject: Re: Charter, take 2 Cc: ietf-run@mailbag.intel.com X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk Hally, I vote for: "IETF" usage, instead of "we". This is the flavoring that most of the charters have. In the goals/milestones, I would prefer the use of "Netiquette Guide". ISOC is persuing its own "Code of Conduct", but I do not want the fiasco starting up again between them, the IESG, and this group that transpired in Toronto. I think it is good that we work with ISOC if they would like advice from the IETF, or the RUN WG in writing their Code of Conduct, but I feel we do need a full divorce from our two endeavors, so not to cause any more confusion. My two bits. Hoyce   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07009; 31 Aug 94 14:27 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07005; 31 Aug 94 14:27 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa12707; 31 Aug 94 14:27 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qfuJk-000MNma; Wed, 31 Aug 94 11:23 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfuJi-000MOZC; Wed, 31 Aug 94 11:23 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfuJd-000MNmC; Wed, 31 Aug 94 11:23 PDT Received: from ludwig.intel.com by hermes.intel.com (5.65/10.0i); Wed, 31 Aug 94 11:23:20 -0700 Received: by Ludwig.intel.com (4.1/SMI-4.1) id AA18441; Wed, 31 Aug 94 11:21:06 PDT Date: Wed, 31 Aug 94 11:21:06 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sally Hambridge Message-Id: <9408311821.AA18441@Ludwig.intel.com> To: ietf-run@mailbag.intel.com Subject: Charter Chatter - are we there yet? X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk Hello - here's this revised yet one more time. Are we there yet? Sally sallyh@ludwig.intel.com ----------------------- Reflecting the needs of the Internet community, the IETF sees a need to create an etiquette (Netiquette, in Network parlance) guide for Internet users. The Working Group will develop an FYI RFC on responsible use of the Internet and its tools. GOALS AND MILESTONES DEC 94 - Internet Draft of Bibliography of available literature MARCH 95 - Internet Draft of Netiquette Guide JULY 95 - Final Draft FYI RFC of Netiquette Guide   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08282; 31 Aug 94 15:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08278; 31 Aug 94 15:28 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa14100; 31 Aug 94 15:28 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qfvIn-000MO0a; Wed, 31 Aug 94 12:26 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfvIl-000MOmC; Wed, 31 Aug 94 12:26 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfvIh-000MO0C; Wed, 31 Aug 94 12:26 PDT Received: from atlas.xylogics.com by hermes.intel.com (5.65/10.0i); Wed, 31 Aug 94 12:26:18 -0700 Received: by atlas.xylogics.com id AA06832 (5.65c/UK-2.1-940401); Wed, 31 Aug 1994 15:24:40 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Gary Scott Malkin Date: Wed, 31 Aug 1994 15:24:40 -0400 Message-Id: <6832.199408311924@atlas.xylogics.com> To: sallyh@ludwig.intel.com Cc: ietf-run@mailbag.intel.com In-Reply-To: Sally Hambridge's message of Wed, 31 Aug 94 11:21:06 PDT <9408311821.AA18441@Ludwig.intel.com> Subject: Charter Chatter - are we there yet? X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk Yes, we're there. ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09545; 31 Aug 94 16:37 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09541; 31 Aug 94 16:37 EDT Received: from ormail.intel.com by CNRI.Reston.VA.US id aa15581; 31 Aug 94 16:37 EDT Received: by ormail.intel.com (Smail3.1.28.1 #12) id m0qfwNL-000MOMa; Wed, 31 Aug 94 13:35 PDT X-Orig-Sender: owner-ietf-run@ormail.intel.com Received: from ormail.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfwNJ-000MOKC; Wed, 31 Aug 94 13:35 PDT Received: from hermes.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #12) id m0qfwNE-000MOMC; Wed, 31 Aug 94 13:35 PDT Received: from osi-east.es.net by hermes.intel.com (5.65/10.0i); Wed, 31 Aug 94 13:35:07 -0700 Received: from donner.nersc.gov by osi-east.es.net via ESnet SMTP service id <19475-0@osi-east.es.net>; Wed, 31 Aug 1994 13:33:38 +0000 Received: by donner.nersc.gov (4.1/ESnet-1.2) id AA02101; Wed, 31 Aug 94 13:33:37 PDT Date: Wed, 31 Aug 94 13:33:37 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Suzanne Medeiros-Smith Message-Id: <9408312033.AA02101@donner.nersc.gov> To: ietf-run@mailbag.intel.com Subject: Charter X-Orig-Sender: owner-ietf-run@mailbag.intel.com Precedence: bulk I think we're there! ----- Begin Included Message ----- >From owner-ietf-run@ormail.intel.com Wed Aug 31 11:28:17 1994 Sender: owner-ietf-run@ormail.intel.com Date: Wed, 31 Aug 94 11:21:06 PDT From: sallyh@Ludwig.intel.com (Sally Hambridge) To: ietf-run@mailbag.intel.com Subject: Charter Chatter - are we there yet? Sender: owner-ietf-run@mailbag.intel.com Content-Length: 559 Hello - here's this revised yet one more time. Are we there yet? Sally sallyh@ludwig.intel.com ----------------------- Reflecting the needs of the Internet community, the IETF sees a need to create an etiquette (Netiquette, in Network parlance) guide for Internet users. The Working Group will develop an FYI RFC on responsible use of the Internet and its tools. GOALS AND MILESTONES DEC 94 - Internet Draft of Bibliography of available literature MARCH 95 - Internet Draft of Netiquette Guide JULY 95 - Final Draft FYI RFC of Netiquette Guide ----- End Included Message -----   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01444; 2 Sep 94 8:33 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01440; 2 Sep 94 8:33 EDT Received: from [192.160.253.66] by CNRI.Reston.VA.US id aa04470; 2 Sep 94 8:33 EDT Return-path: 0002544290@mcimail.com Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HGMI75G9J499DH7D@INNOSOFT.COM>; Fri, 02 Sep 1994 05:06:11 -0700 (PDT) Received: from glengoyne.isode.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HGMI70F0NK99DHD0@INNOSOFT.COM>; Fri, 02 Sep 1994 05:06:06 -0700 (PDT) Resent-date: Fri, 02 Sep 1994 13:07:18 +0100 Date: Wed, 31 Aug 1994 17:50 -0500 (EST) Resent-from: Steve Kille Sender:ietf-archive-request@isode.com From: Electronic Messaging Association <0002544290@mcimail.com> Subject: EMA Alert #4 (8-31-94) To: "s.kille" Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Resent-message-id: <2619.778507638@glengoyne.isode.com> Message-id: <40940831225004/0002544290NA3EM@mcimail.com> Content-transfer-encoding: 7BIT Delivery-date: Thu, 01 Sep 1994 08:04:48 +0100 Prev-Resent: Thu, 01 Sep 1994 08:13:17 +0100 Prev-Resent: ic-dev Prev-Resent: Richard Kiely Old-Received: from gatekeeper.mcimail.com by glengoyne.isode.com with SMTP (PP); Thu, 1 Sep 1994 08:04:37 +0100 Old-Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA16004; Thu, 1 Sep 94 08:05:16 +0100 Old-Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ap04744; 1 Sep 94 0:46 GMT +----------------------------------------------------------+ ##### # # # # # ##### #### ##### # ## ## # # # # # # # # # ### # # # # # # # # # ### #### # # # # # ####### ####### # # # # # ##### # # # # # # ##### ##### # # # +----------------------------------------------------------+ -> EMA ALERT <- News For and About the Members of the ELECTRONIC MESSAGING ASSOCIATION ============================================================ September 1, 1994 -- Number 4 <----------------------------------------------------------> IN THIS EDITION: - MADMAN Embraced For Message Management - Leading Messaging Vendors Join EMA Message Attachment Transfer Test - Groupware Deployment Guide Planned - New Directories White Papers Due By October - INDUSTRY NEWS & LEADERS - 27 Running For EMA Board <----------------------------------------------------------> MADMAN EMBRACED FOR MESSAGE MANAGEMENT EMA's Messaging Management Committee's Technical Sub- Committee (TSC) is developing a specification set of common data to be collected by messaging management systems for monitoring and auditing (tracking and accounting) MTAs and Gateways. For dynamic monitoring, the TSC agreed to use the MADMAN MIB (RFCs 1565 and 1566) as one mechanism for MTA message monitoring. They also agreed to develop additional data elements (and possibly propose another RFC) for tracking and accounting. The TSC will meet monthly to draft a technical specification by the end of 1994. For more information contact Paul Moniz at EMA (see below). LEADING MESSAGING VENDORS JOIN EMA MESSAGE ATTACHMENT TRANSFER TEST The Electronic Messaging Association's Message Attachment Work Group (MAWG) is testing the feasibility of the File Transfer Body Part (FTBP) for sending message attachments via X.400. Pending successful bilateral testing of the FTBP's suitability, EMA plans to recommend that vendors support it in upcoming product releases. EMA member vendors that have agreed to date to participate in the test are Advantis, AT&T EasyLink Services, BT North America, CompuServe, Control Data Systems, Digital Equipment, EICON Technology, France Telecom Transpac, GE Information Services, Hewlett-Packard, Infonet Software Solutions, ISOCOR, ISODE Consortium, Lotus, Lotus ICG (formerly Soft*Switch), Microsoft, Motorola, Novell, WordPerfect, and Worldtalk. Additional participants are welcome and encouraged. For more information contact Paul Moniz at EMA (see below). GROUPWARE DEPLOYMENT GUIDE PLANNED EMA's Groupware Committee plans to begin working on a Deployment Guide for companies planning to use groupware products. The guide will include technical examples, technical and organizational issues to consider when implementing groupware, pitfalls to avoid, and next steps (i.e., how to add functionality, expand deployment, address additional business process problems). For more information, contact Victoria Dawes at EMA (see below). NEW DIRECTORIES WHITE PAPERS DUE BY OCTOBER EMA's Directories Committee is currently working on several white papers to help companies maximize the benefits of messaging directories: an X.500 paper, a Directory Synchronization Frequently Asked Questions (FAQ) paper, a Directory Management and Administration paper, and a Directory User Requirements paper. Detailed outlines for the X.500 and User Requirements papers will be available by October, as will first drafts of the Directory Synchronization FAQ and Directory Management and Administration papers. For more information contact Paul Moniz at EMA (see below). INDUSTRY NEWS & LEADERS - 27 RUNNING FOR EMA BOARD A record number (27) of candidates have been nominated to run for election to two-year terms on the EMA Board of Directors: Eurael Bell, Vice President, Enhanced Services & Business Systems, ADVANTIS; Ric Towell, Manager, Messaging and Information Services, AMERITECH; George Cunningham, Vice President, Business Planning, Strategy and Business Development, AT&T EASYLINK SERVICES; Eugene Lee, Director, Messaging Product Management, BANYAN SYSTEMS; Roger K. Mizumori, Manager, Messaging Services Planning, THE BOEING COMPANY; Rob Mainor, Vice President of Product Marketing and Business Information Services, COMPUSERVE; David B. Folsom, General Manager, Electronic Messaging and Commerce, CONTROL DATA SYSTEMS; Bert Amato, Executive Vice President, , DELRINA; Joyce Graff, Senior Product Manager Groupware Messaging, DIGITAL EQUIPMENT CORPORATION; Victor E. Trevino, Chairman of the Board, EKONOM; Bill Wyatt, Administrator, Electronic Messaging, FLUOR CORPORATION; Gary Cannon, Principal Consultant, North American Sales & Services, GE INFORMATION SERVICES; Korak Mitra, Messaging Business Manager Cooperative Computing Systems Division, HEWLETT-PACKARD; Peter W. Donaghy, Manager, Network Architecture & Technology Development, INTEL; Stewart P. Kerr, Manager, Communications Access Capacity and Planning, INTELSAT; Jackie DeSalvo, X.400 & Directory Service Owner, ELI LILLY & CO.; Mike Zisman, Vice President, LOTUS; Robert D. Kentworthy , Manager, Electronic Messaging, MONSANTO; Stewart Nelson, Vice President of Development, Novell GroupWare Division, NOVELL; Steven W. Mahaney, Manager, Electronic Mail Infrastructure, SMITHKLINE BEECHAM; David Winkler, Director, Product Marketing, Electronic Commerce Services, STERLING SOFTWARE; Jean-Pierre Baudouin, Director , SUNSOFT; Warren Goodsmith, Manager Information Systems, TEXACO; Ron Sherman, X.400 Project Manager, U S WEST; Hank Leingang, Senior Vice President, Chief Information Officer, VIACOM INTERNATIONAL; Kathy Carlson, Director of Enhanced Services , WORLDLINX TELECOMMUNICATIONS; and Mark Jung, President & CEO, WORLDTALK CORPORATION. EMA members will cast ballots during September and the newly elected and/or reelected Directors will take office in October during the EMA's Messaging Leadership Conference (Oct. 12-14 in Washington, DC). ------------------------------------------------------------ EMA ALERT is published and copyrighted (1994) by the Electronic Messaging Association. Permission to reproduce and/or redistribute with attribution is hereby given to all EMA members. For more information about anything in EMA ALERT, contact EMA via e-mail - use either X.400 (S=info; O=ema; A=mci; C=us) or Internet (info@ema.org) address, facsimile (1-703-524-5558), or telephone (1-703-524-5550). Any EMA staff member can be addressed directly via e-mail by using, for X.400, G=; S=; O=ema; A=mci; C=us, and, for Internet, @ema.org. EMA's postal address is 1655 N. Fort Myer Dr. #850, Arlington, VA 22209 USA. EMA thanks Computer Mail Services, Inc., of Southfield, Michigan, publisher of MailPlus, for their assistance in the preparation and distribution of this edition of EMA ALERT. If you received this publication by fax, and wish to receive it by e-mail, contact Mike Sayers at EMA. ------------------------------------------------------------