Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01720; 5 Oct 93 8:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01716; 5 Oct 93 8:47 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01657; 5 Oct 93 8:47 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01593; 5 Oct 93 8:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01589; 5 Oct 93 8:41 EDT Received: from MACARTHUR.BBN.COM by CNRI.Reston.VA.US id aa01275; 5 Oct 93 8:41 EDT To: iplpdn@CNRI.Reston.VA.US Subject: Please UNSUBSCRIBE ME Date: Tue, 05 Oct 93 08:33:16 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gwirth@bbn.com Message-ID: <9310050841.aa01275@CNRI.Reston.VA.US> Thank You   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07092; 5 Oct 93 12:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07084; 5 Oct 93 12:41 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07808; 5 Oct 93 12:41 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07039; 5 Oct 93 12:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07035; 5 Oct 93 12:39 EDT Received: from relay1.UU.NET by CNRI.Reston.VA.US id aa07760; 5 Oct 93 12:39 EDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA01961; Tue, 5 Oct 93 12:40:03 -0400 Received: from telenet.UUCP by uucp3.uu.net with UUCP/RMAIL (queueing-rmail) id 123853.7970; Tue, 5 Oct 1993 12:38:53 EDT Received: from everest.telenet.com by telenet.telenet.com (4.1/SMI-3.2) id AA09185; Tue, 5 Oct 93 12:37:01 EDT Received: by everest.telenet.com (4.1/SMI-4.0) id AA00234; Tue, 5 Oct 93 12:37:02 EDT Date: Tue, 5 Oct 93 12:37:02 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Wu Message-Id: <9310051637.AA00234@everest.telenet.com> To: uunet!CNRI.Reston.VA.US!iplpdn@uunet.uu.net Subject: Please UNSUBSCRIBE ME Please unsubscribe me. Thanks.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25479; 11 Oct 93 14:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25474; 11 Oct 93 14:48 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02501; 11 Oct 93 14:48 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25389; 11 Oct 93 14:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25385; 11 Oct 93 14:45 EDT Received: from bulkrate.cc.bellcore.com by CNRI.Reston.VA.US id aa02416; 11 Oct 93 14:45 EDT Received: from prefect.UUCP by bulkrate.cc.bellcore.com id AA28675 (5.65c/IDA-1.4.4 for cnri.reston.va.us!iplpdn); Mon, 11 Oct 1993 14:47:21 -0400 Message-Id: <199310111847.AA28675@bulkrate.cc.bellcore.com> X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "queiro,eufemio h" To: iplpdn@CNRI.Reston.VA.US Date: 11 Oct 1993 14:38 EDT Subject: LAT over SMDS Hi folks, Has anyone runned LAT over SMDS or Frame Relay. If you did, could you provide me with information on the configuration and if you experienced any difficulties. Anything you know will be appreciated. Henry Queiro (908) 758-2207 eeq@prefect.cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17639; 21 Oct 93 14:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17635; 21 Oct 93 14:59 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21338; 21 Oct 93 14:58 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17550; 21 Oct 93 14:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17546; 21 Oct 93 14:54 EDT Received: from crl.dec.com by CNRI.Reston.VA.US id aa21183; 21 Oct 93 14:54 EDT Received: by crl.dec.com; id AA16922; Thu, 21 Oct 93 14:54:13 -0400 Received: by dsmail.lkg.dec.com (5.57/Ultrix2.4-C)id AA11234; Thu, 21 Oct 93 14:54:30 -0400 Received: by libeb.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA09496; Thu, 21 Oct 1993 14:54:07 -0400 Message-Id: <9310211854.AA09496@libeb.lkg.dec.com> To: iplpdn@CNRI.Reston.VA.US Cc: gunner@libeb.lkg.dec.com Subject: a question on routing protocols over Frame Relay Date: Thu, 21 Oct 93 14:54:06 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "(Chris Gunner)" X-Mts: smtp Folks, To those of you who have implemented routing protocols over Frame Relay: I'm not aware of any definition of how to run DECnet Phase IV or ISIS over Frame Relay. The same issues arise here that we resolved in the PPP case - neither protocol defined how to operate over an unreliable point to point link service. In the PPP case, DECnet phase IV uses its broadcast link algorithm while ISIS uses its point to point link algorithm (which turns out to work OK for unreliable links). In the interests of interworking, has anybody implemented either of these over Frame Relay and if you did, how did you do it ? If there's a specification which I've overlooked then can you point me at it ? Thanks, Chris Gunner Digital Equipment Corp.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23312; 21 Oct 93 17:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23308; 21 Oct 93 17:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26235; 21 Oct 93 17:53 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23294; 21 Oct 93 17:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23288; 21 Oct 93 17:52 EDT Received: from monk.proteon.com by CNRI.Reston.VA.US id aa26203; 21 Oct 93 17:52 EDT Received: from ironside.proteon.com by monk.proteon.com (5.65/1.8) id AA17586; Thu, 21 Oct 93 17:54:09 -0400 Received: by ironside.proteon.com (4.1/SMI-4.1) id AA14668; Thu, 21 Oct 93 17:52:35 EDT Date: Thu, 21 Oct 93 17:52:35 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "John A. Shriver" Message-Id: <9310212152.AA14668@ironside.proteon.com> To: gunner@libeb.lkg.dec.com Cc: iplpdn@CNRI.Reston.VA.US In-Reply-To: <9310211854.AA09496@libeb.lkg.dec.com> (gunner@libeb.lkg.dec.com) Subject: Re: a question on routing protocols over Frame Relay Well, obviously the first issue is whether each FR circuit is a DECnet circuit, or whether the entire FR network (DECnet line) is one DECnet circuit. (The gaping unsettled ambiguity in the Multiprotocol Interconnect over Frame Relay RFC. Well, they settled it for Bridging, but it's open for discussion otherwise.) Of course, with DECnet being an adjacency based route-to-node protocol, there may well not be any effective difference between treating the FR network as one circuit or many circuits. (Other than system and configuration overhead.) There is no circuit identifier in the hellos. I don't think the circuit per circuit end would be particularly surprised if the R/S list in the Router Hello message has extra nodes, so long as he's in it. We (Proteon) have done Phase IV over Frame Relay, using the broadcast hello and routing protocols, treating the Frame Relay network as one DECnet circuit. We use iterated transmit over all the VC's to simulate the multicasts needed. We do use the correct SNAP based ID for DECnet (NLPID 80, SNAP PID 00-00-00-60-03.) I suppose we would interoperate with you. What a concept!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07113; 22 Oct 93 11:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07108; 22 Oct 93 11:39 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13618; 22 Oct 93 11:39 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07006; 22 Oct 93 11:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07000; 22 Oct 93 11:35 EDT Received: from lobster.wellfleet.com by CNRI.Reston.VA.US id aa13562; 22 Oct 93 11:35 EDT Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA07623; Fri, 22 Oct 93 11:25:36 EDT Received: from godiva.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA04374; Fri, 22 Oct 93 11:32:47 EDT Date: Fri, 22 Oct 93 11:32:47 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9310221532.AA04374@pobox.wellfleet> To: gunner@libeb.lkg.dec.com, jas@proteon.com Subject: Re: a question on routing protocols over Frame Relay Cc: iplpdn@CNRI.Reston.VA.US > > Well, obviously the first issue is whether each FR circuit is a DECnet > circuit, or whether the entire FR network (DECnet line) is one DECnet > circuit. (The gaping unsettled ambiguity in the Multiprotocol > Interconnect over Frame Relay RFC. Well, they settled it for > Bridging, but it's open for discussion otherwise.) > > Of course, with DECnet being an adjacency based route-to-node > protocol, there may well not be any effective difference between > treating the FR network as one circuit or many circuits. (Other than > system and configuration overhead.) There is no circuit identifier in > the hellos. I don't think the circuit per circuit end would be > particularly surprised if the R/S list in the Router Hello message has > extra nodes, so long as he's in it. > > We (Proteon) have done Phase IV over Frame Relay, using the broadcast > hello and routing protocols, treating the Frame Relay network as one > DECnet circuit. We use iterated transmit over all the VC's to > simulate the multicasts needed. > > We do use the correct SNAP based ID for DECnet (NLPID 80, SNAP PID > 00-00-00-60-03.) > > I suppose we would interoperate with you. What a concept! > You are correct that RFC 1490 (and 1294) do not state how to treat the frame relay interface with regard to each protocol. I assume that most of those involved with the document, thought as I did, that the treatment of the VCs depended on what the network topology was. If the fr network is fully meshed, why waste a network address for each PVC? Just treat them all as destinations on a single subnet. If the fr network is not fully meshed, but the traffic pattern is such that remote (non directly connected) stations do not need to communicate, you can still make a single subnet work. The list goes on and on. As John pointed out, their Phase IV implementation treats the fr network as a single circuit. No problem. We did the same thing. Perhaps this is worth some more discussion in Houston? Though it has not been formally announced (I'm working on it though), it was suggested that the IPLPDN be resurrected to talk about Keith Sklower's parameter negotiation over frame relay and also to talk about expanding InverseArp. Should we add this to the list also? c   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07746; 22 Oct 93 12:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07741; 22 Oct 93 12:09 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14562; 22 Oct 93 12:08 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07701; 22 Oct 93 12:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07695; 22 Oct 93 12:07 EDT Received: from crl.dec.com by CNRI.Reston.VA.US id aa14519; 22 Oct 93 12:07 EDT Received: by crl.dec.com; id AA22015; Fri, 22 Oct 93 12:07:58 -0400 Received: by dsmail.lkg.dec.com (5.57/Ultrix2.4-C)id AA12323; Fri, 22 Oct 93 12:08:10 -0400 Received: by libeb.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA12895; Fri, 22 Oct 1993 12:07:44 -0400 Message-Id: <9310221607.AA12895@libeb.lkg.dec.com> To: Caralyn Brown Cc: gunner@libeb.lkg.dec.com, iplpdn@CNRI.Reston.VA.US Subject: Re: a question on routing protocols over Frame Relay In-Reply-To: Your message of "Fri, 22 Oct 93 11:32:47 EDT." <9310221532.AA04374@pobox.wellfleet> Date: Fri, 22 Oct 93 12:07:44 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "(Chris Gunner)" X-Mts: smtp Caralyn, I would like to have a discussion of routing protocol operation over Frame Relay at Houston as you suggest. Can we get an iplpdn meeting scheduled and add this to the agenda ? Chris > > > > Well, obviously the first issue is whether each FR circuit is a DECnet > > circuit, or whether the entire FR network (DECnet line) is one DECnet > > circuit. (The gaping unsettled ambiguity in the Multiprotocol > > Interconnect over Frame Relay RFC. Well, they settled it for > > Bridging, but it's open for discussion otherwise.) > > > > Of course, with DECnet being an adjacency based route-to-node > > protocol, there may well not be any effective difference between > > treating the FR network as one circuit or many circuits. (Other than > > system and configuration overhead.) There is no circuit identifier in > > the hellos. I don't think the circuit per circuit end would be > > particularly surprised if the R/S list in the Router Hello message has > > extra nodes, so long as he's in it. > > > > We (Proteon) have done Phase IV over Frame Relay, using the broadcast > > hello and routing protocols, treating the Frame Relay network as one > > DECnet circuit. We use iterated transmit over all the VC's to > > simulate the multicasts needed. > > > > We do use the correct SNAP based ID for DECnet (NLPID 80, SNAP PID > > 00-00-00-60-03.) > > > > I suppose we would interoperate with you. What a concept! > > > > You are correct that RFC 1490 (and 1294) do not state how to treat the > frame relay interface with regard to each protocol. I assume that most of > those involved with the document, thought as I did, that the treatment of > the VCs depended on what the network topology was. If the fr network is > fully meshed, why waste a network address for each PVC? Just treat them > all as destinations on a single subnet. If the fr network is not fully meshed, > but the traffic pattern is such that remote (non directly connected) stations > do not need to communicate, you can still make a single subnet work. > > The list goes on and on. As John pointed out, their Phase IV implementation > treats the fr network as a single circuit. No problem. We did the same thing. > > Perhaps this is worth some more discussion in Houston? Though it has not been > formally announced (I'm working on it though), it was suggested that the > IPLPDN be resurrected to talk about Keith Sklower's parameter negotiation over > frame relay and also to talk about expanding InverseArp. Should we add this > to the list also?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09913; 22 Oct 93 13:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09909; 22 Oct 93 13:57 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17213; 22 Oct 93 13:57 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09896; 22 Oct 93 13:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09892; 22 Oct 93 13:56 EDT Received: from monk.proteon.com by CNRI.Reston.VA.US id aa17187; 22 Oct 93 13:56 EDT Received: from ironside.proteon.com by monk.proteon.com (5.65/1.8) id AA22158; Fri, 22 Oct 93 13:58:21 -0400 Received: by ironside.proteon.com (4.1/SMI-4.1) id AA20188; Fri, 22 Oct 93 13:56:42 EDT Date: Fri, 22 Oct 93 13:56:42 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "John A. Shriver" Message-Id: <9310221756.AA20188@ironside.proteon.com> To: cbrown@wellfleet.com Cc: iplpdn@CNRI.Reston.VA.US In-Reply-To: <9310221532.AA04374@pobox.wellfleet> (cbrown@wellfleet.com) Subject: Re: a question on routing protocols over Frame Relay Yeah, it sure would be nice if there was more discussion of that issue. Of course, to a degree, it is a decision to be made by the owners of the protocol. Still, more discussion of this in the RFC, even it it's only informational, would warn people what to think about. (Yes, the section of bridging in RFC 1490 does bring the issue more out into the open.) All our existing Frame Relay encapsulations assume one network layer protocol network per Frame Relay network. We nominally assumed a mesh. We may not have imagined anyone would run less than a mesh. (Of course, our recently installed international Frame Relay backbone is a non-mesh, so we've been addressing the problem there!) As I noted, this does seem to be the most likely way to run IP. On the other hand, it appears that this is dead opposite of the approach Novell is taking for IPX. To my understanding, they plan to use the network per circuit model, handing out the network numbers with IPXWAN. Our IPX over Frame Relay and theirs will either argue with each other, or more possibly (due to IPXWAN negotiation failing) ignore each other. I'm not necessarily sure that there should be multiple models for a given protocol. Isn't that just another thing for our struggling users, drowning in complexity, to confgure right?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10922; 22 Oct 93 14:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10918; 22 Oct 93 14:54 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19071; 22 Oct 93 14:54 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10909; 22 Oct 93 14:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10905; 22 Oct 93 14:53 EDT Received: from vangogh.CS.Berkeley.EDU by CNRI.Reston.VA.US id aa19058; 22 Oct 93 14:53 EDT Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.1C/6.32) id LAA09345; Fri, 22 Oct 1993 11:53:40 -0700 Date: Fri, 22 Oct 1993 11:53:40 -0700 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199310221853.LAA09345@vangogh.CS.Berkeley.EDU> To: iplpdn@CNRI.Reston.VA.US Subject: would-be internet draft on encapsulation determination (nee multiproto over isdn) This never got filed due to the ``on hiatus'' status of iplpdn; Caralyn Brown asked me to post it to the list. Draft Encapsulation Determination August 1993 INTERNET DRAFT Expires: Februrary 16, 1994 Determination of Encapsulation of Multi-protocol Datagrams in Circuit-switched Environments Keith Sklower Computer Science Department University of California, Berkeley 1. Status of This Memo This document 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 appro- priate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 2. Abstract This document enumerates the existing means for transmitting Internet Protocols across public data networks using cir- cuit-mode ISDN, and other switched services. It recommends limiting the choices to the three most common methods, from which one can determine which method is in use by inspection of the packets. The intention is to capture in a slightly more formal way the level of consensus reached at the 24th - 27th IETF meetings. 3. Acknowledgements The author specifically wishes to thank Clifford Frost and William Jolitz for many extensive discussions on the Sklower [Page 1] Draft Encapsulation Determination August 1993 subject, Gary Kessler for correcting errors in the encoding of LLC IE's, Glen Kime of Network Express for the secotion on inverted HDLC, and more generally the IP over Large Pub- lic Data Networks and PPP extensions working groups, whose deliberations this memo is supposed to reflect. References are made to earlier work by Leifer et al. [1], and Murakami et al. [2]. 4. 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 RECOMMENDED -- the 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. 5. Introduction The advent of Circuit-mode ISDN has provided the possibility of much higher rates of information exchange than previously possible over modems and voice-grade lines. We anticipate the use of this technology to encourage ``tele-commuting'' (making it more possible for people to work effectively at home), and to reduce the cost of data communications in businesses having geographically dispersed sites. Other applications, such as multi-media conferencing, are much more economically feasible than before. The contribution by Murakami also cites the use of ISDN to acquire additional bandwidth for handling excess traffic in parallel with leased lines, and more generally back-up of a failed leased line. Given the newness of the technology, the diversity of its applications, and its wide availability, it is not surpris- ing that a number of incompatible link level protocols are coming into use for the transmission of data over ISDN links. Examples are the use of SLIP [3] and PPP [4,5] over asynchronous terminal adapters using V.120 [6], PPP over synchronous terminal adapters using V.120 or directly over the B channel via native ISDN interfaces [13], and both the Multiprotocol Encapsulation over X.25 [7], or Mutltiprocol Encapsulation over Frame Relay [8] directly on the B chan- nel. There are even other examples cited in Murakami's paper. Sklower [Page 2] Draft Encapsulation Determination August 1993 In this paper we recommend limiting the choice of encapsula- tions to those described in RFC 1331 (PPP), RFC 1490 (Frame Relay), and RFC 1356 (X.25). The contribution by Murakami suggests using out-of-band sig- naling for negotiating the link-layer protocol and other configuration parameters using ISDN Information Elements such as UUI and BC. It is the experience of the members of the IPLPDN that ISDN implementation are as yet so diverse, the deployment of Switching System 7 so limited, and sub- scription policies by the regional providers so different, that user cannot depend on having these information elements passed end-to-end. The likeliest element to be passed end- to-end is LLC; this memo proposes a method for chosing the link-layer protocol based on this element when available. Where it is not available, an algorithm is proposed for ``negotiating'' the protocol by in-band exchange of data. Other configuration parameters can be negotiated in band using PPP, even for the Frame Relay and X.25 cases, as described in PNMI[9]. 6. Principal Recommendations 6.1. PPP 6.1.1. Specific Encoding and defaults The packet formats for PPP are specified in RFC's 1331 and 1332. A separate document specifying default values for negotiable parameters is being prepared separately. [13] It is understood that whatever defaults apply to simple HDLC framing over a leased moderate speed line, must also apply to the ISDN B-channel case since the two may be directly linked by the switched-56 service. 6.1.2. Benefits of Using the PPP encapsulation. PPP is widely implemented, and constructed in such a way to force interoperability. The details of the protocol are completely specified by RFC's 1331 and 1332, and are also applicable to any situation where synchronous transmission of data is possible. Many commercially available routers already have code supporting PPP, and it is flexible enough to adapt to all the situations cited as applications in this memo. 6.2. RFC 1490 6.2.1. Specific Encoding RFC 1490 specifies the transmission of datagrams in a format according to Q.922. As this is an HDLC framing, it is Sklower [Page 3] Draft Encapsulation Determination August 1993 completely suitable for use on an ISDN B channel. The RFC does not describe how the Q.922 header is generated; it was assumed that a genuine frame relay would provide it as a normal consequence of its operation. All other details of the encapsulation were completely specified by this RFC. In fact, it is possible to employ ISDN to gain access to a Frame Relay, and when doing so packets received from it will contain a valid DLCI. Obviously, a system communicating with a frame relay must set the DLCI's appropriately. When transmitting datagrams across an ISDN B-channel using this format between systems which are not Frame Relays, such systems MUST provide a valid DLCI header. As such, the low- est order bit of the first byte transmitted MUST be zero. The DLCI may be configured by prior agreement to any accept- able value. A default DLCI value of 16 is consistent with current ANSI recommendations (T1.617), however at some future time when frame relay service is offered over the D channel, the default DLCI value should be 512 (T1.618). 6.2.2. Benefits of Using The Frame Relay Encapsulation A primary advantage for Frame Relay Encapsulation is that communication providers such as the Regional Bell Operating Companies may be able to offer ISDN accessible frame relay service which is high integrated with the voice switching fabric. Proponents for this method have claimed that RFC 1490 encap- sulation is very simple to implement; in fact it is possible to prepend a fixed header to all datagrams sent, and com- pletely ignore the first few bytes of any datagram received. When systems have been compatibly preconfigured, no further state must be maintained on a per B-channel basis. This is clearly of concern for circumstances like multiple primary rate interfaces coming into a single router, thus poten- tially supporting hundreds of B-Channels. Furthermore, it is possible to start transmitting data as soon as the circuit has been established, thereby reducing latency. PPP and X.25, by contrast require an exchange of packets to declare the link up. However, to be fair, changes have been proposed to PPP suggesting that it too may be manually configured, and in such cases may not require the usual exchange of packets 6.3. RFC 1356/B-Channel X.25 Systems supporting exchanging information according to OSI conventions are required to support X.25 over the B-channel, Sklower [Page 4] Draft Encapsulation Determination August 1993 and RFC 1356 provides means for conveying Internet Protocols in this situation. 7. In-Band Link Protocol Determination The algorithm is that the caller starts transmitting data or negotiation according to his preferred encapsulation, and the callee just figures out what is desired by inspection of the first correctly framed HDLC packet. If either the caller or callee selects PPP or X.25, they will be required to retransmit either PPP LCPs or X.25 SABM until they time out. 7.1. Caller's Algorithm A system wishing to exchange information using RFC-1490 encapsulation MUST transmit some packet with a valid two- byte DLCI. The calling system MAY transmit protocol data immediately, given suitable preconfiguration. The calling system MAY also initiate parameter negotiation according to PNMI, using the RFC-1490 encapsulation. A system wishing to exchange information using PPP will issue an LCP packet in native PPP format, according to the requirements of RFC 1331; i.e. the first byte will be 0xff, and the second byte will be 0x3, etc. A system wishing to use X.25 will issue a SABM with an address of station A, according to the OSI implementors agreement [10]. 7.2. Callee's Algorithm The called system will wait until it has received a cor- rectly framed and checksummed HDLC packet and inspect the very first byte. PPP requires that the station address be all ones (0xff). Conventional X.25 HDLC requires a station address of either 1 or 3. The 2,3 or 4 byte DLCI Q.922 for- mats all require that the low order bit of the first byte to be zero. Thus, it is possible for a called system support- ing all three methods to unambiguously determine which encapsulation is desired and respond in the appropriate man- ner. In the past, many networks required that CPE that sent digi- tal data maintain a minimum one's density. One of the com- mon methods of achieving this was to use inverted HDLC data. Inverted HDLC data was the simple inversion of the output of the transmitter. Because HDLC data cannot have more than 5 ones in a row (Abort avoidance). Consequently, inverting HDLC data guarantees no more than 5 zeroes in a row, meeting one's density. Sklower [Page 5] Draft Encapsulation Determination August 1993 Even though this restriction no longer applies on B8ZS lines, some installed equipment still use data inversion. The following details a method which the receiver of a call may use to discriminate between equipment using normal (non- inverted) data and equipment using inverted data. Note that the recommended method for both Caller and Callee is to use normal data. Upon call establishment, the receiver should program their CPE to accept normal data. If a correctly-framed HDLC packet with a correct CRC (hereafter referred to as a "good" frame) is received, the procedures described above should be followed. If, after 10 seconds, no "good" frame has been received, the hardware should be reprogrammed to accept inverted data. If a "good" packet has been received, handle as above. Otherwise, wait 10 seconds and revert to inverted. Continue this as long as makes sense. One thought on total time is that, at this point, the call has been established. Thus, you will likely be charged for 1 minute anyway, so you might as well try for a minute. 8. Out of Band Signaling {Warning - Meta paragraph. At the last IETF meeting, it was agreed that somebody would approach ANSI for obtaining a code point for the LLC-IE byte 7 "user information layer 3 protocol" that would indicate PPP. I probably have botched this section but I'm going to include it to make it easier for whoever edits this next}. 8.1. Caller's Requirements In cases where the LLC information element is available and can be transmitted to be relied on end to end, and the sys- tem wishes to communicate using the RFC-1490 encapsulation, a system MUST encode the LLC-IE in the following way in his setup message: Sklower [Page 6] Draft Encapsulation Determination August 1993 8 7 6 5 4 3 2 1 ----------------------------------------------------------- 0 1 1 1 1 1 0 0 0 Low Layer Compatibility Octet 1 ----------------------------------------------------------- . . . ----------------------------------------------------------- 1 1 0 0 1 1 1 1 Octet 6 ext layer 2 ident Core Aspects of Q.922 (Frame Relay) -or- 1 1 0 0 1 1 1 0 Octet 6 ext layer 2 ident Full Q.922 (LAPF) ----------------------------------------------------------- 1 1 1 0 1 0 1 1 Octet 7 ext layer 3 ident ISO/IEC TR 9577 (Protocol Identifi- cation in the Network Layer) ----------------------------------------------------------- In cases where the system wishes to exchange information using RFC-1356/X.25 PLP/LAPB a system MUST encode the LLC-IE in the following way in his setup message: 8 7 6 5 4 3 2 1 ----------------------------------------------------------- 0 1 1 1 1 1 0 0 0 Low Layer Compatibility Octet 1 ----------------------------------------------------------- . . . ----------------------------------------------------------- 1 1 0 0 0 1 1 0 Octet 6 ext layer 2 ident CCITT Recommendation X.25 link level ----------------------------------------------------------- 1 1 1 0 0 1 1 0 Octet 7 ext layer 3 ident CCITT Recommendation X.25 packet level ----------------------------------------------------------- 8.2. Callee's Algorithm If the LLC-IE exactly matches that generated by the caller's algorithm, the system SHOULD proceed according to the encap- sulations spelled out here. The callee MAY inspect the first correctly framed HDLC packet to see that it matches the encapsulation scheme described. If the LLC-IE contains other values, the system SHOULD pro- ceed according to the ``wait-and-see'' algorithm described Sklower [Page 7] Draft Encapsulation Determination August 1993 above. However, system MAY refuse the connection, or the system MAY make the following inferences: If the User infor- mation layer 3 protocol is 0 1 0 0 0 (ISO 8348 Connection oriented network service), the system MAY assume that RFC-1356/X.25 operation is requested. If the User informa- tion layer 3 protocol is 0 1 0 0 1 the system MAY assume that only ISO 8473 packets will be routed, (just as if an X.25 call had been placed with a CUD of 81). A system MAY also assume that octet 7 with a value of 0 1 1 1 0 indicates a desire to encapsulate according to RFC-1490. 9. Interoperability Defaults and Recommendations. It is REQUIRED that all systems wishing to exchange multi- protocol datagrams over circuit mode ISDN implement the PPP protocol. Such systems encapsulate packets MAY encapsulate packets according to any of the metchods delineated here: PPP, Frame Relay, or X.25. (Systems cannot expect to inter- operate if they use PPP inside V.120, or transmit IP directly inside HDLC framed packets). If a calling system does not get a response to its initial choice of encapsula- tion, it MUST eventually try using the PPP encapsulation. 10. Addressing Stated Requirements of Earlier Work 10.1. Leifer et al A goal of this proposal was to be able to use bandwidth on demand, and obtain the advantage of using multiple B chan- nels for transmitting traffic between two hosts. There are a number of possible ways of doing this which will be dis- cussed at length in a separate draft.[12] 10.2. Murakami et al A major concern of this paper was the use of out-of-band signaling to negotiate compatible configuration parameters. It is the contention of this author that any parameter need- ing to be negotiated in this scheme should be able to be done so by PNMI, and if it can't then PPP should be extended to negotiate that parameter. 11. References [1] Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork Control Protocol for ISDN Circuit-Switching" IPLPDN Working Group, Internet Draft (Expired), March 1991. [2] Muramaki, K., and Sugawara, T., "A Negotiation Protocol for Mutliple Link-Protocol over ISDN Circuit Switch- ing", IPLPDN Working Group, Committee Document, May Sklower [Page 8] Draft Encapsulation Determination August 1993 1992. [3] Romkey, J.L., "A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP." Network Working Group, RFC-1055, June 1988. [4] Simpson, W., "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to- Point Links", Network Working Group, RFC-1331, May 1992. [5] McGregor, G., "The PPP Internet Protocol Control Proto- col (IPCP)" Network Working Group, RFC-1332, May 1992. [6] CCITT, "Recommendation V.120: Data Communications over the Telephone Network" Blue Book, ITU 1988 [7] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", Net- work Working Group, RFC-1356, August 1992. [8] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", Network Working Group, RFC-1490, January 1992. [9] Sklower, K. and Frost, C. "Parameter Negotiation for the Multiprotocol Interconnect" IPLPDN Working Group, Committee Document, November 1992. [10] Boland, F., editor, "Stable Implementation Agreements for Open Systems Interconnection Protocols: Version 2 Edition 1", NIST Workshop for Implementors of OSI, NIST, February 1989. [11] Internation Organisation for Standardization, "HDLC - Description of the X.25 LAPB-Compatible DTE Data Link Procedures", Internation Standard 7776, 1988 [12] Sklower, K., "A Multilink Proceedure for Synchronizing the transmission of Multi-protocol Datagrams", Internet Draft, CNRI, April 1993 12. Author's Address [13] Simpson, W., "PPP over ISDN", Internet Draft, CNRI, August 1993. Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Sklower [Page 9] Draft Encapsulation Determination August 1993 Phone: (510) 642-9587 Email: sklower@cs.Berkeley.EDU 13. Expiration Date of this Draft February 16, 1994 Sklower [Page 10]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10970; 22 Oct 93 14:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10966; 22 Oct 93 14:55 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19152; 22 Oct 93 14:55 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10945; 22 Oct 93 14:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10941; 22 Oct 93 14:55 EDT Received: from vangogh.CS.Berkeley.EDU by CNRI.Reston.VA.US id aa19026; 22 Oct 93 14:54 EDT Received: from localhost (sklower@localhost) by vangogh.CS.Berkeley.EDU (8.1C/6.32) id LAA09339; Fri, 22 Oct 1993 11:52:10 -0700 Date: Fri, 22 Oct 1993 11:52:10 -0700 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith Sklower Message-Id: <199310221852.LAA09339@vangogh.CS.Berkeley.EDU> To: iplpdn@CNRI.Reston.VA.US Subject: Would be internet draft on parameter negotiation. This never got filed due to the ``on hiatus'' status of iplpdn; Caralyn Brown asked me to post it to the list. Draft Parameter Negotiation August 1993 INTERNET DRAFT Expires: February 25, 1994 Parameter Negotiation for the Multiprotocol Interconnect Keith Sklower Computer Science Department University of California, Berkeley Clifford Frost Information Systems & Technology University of California, Berkeley 1. Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Inter- net Engineering Task Force (IETF), its Areas, and its Work- ing 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 appro- priate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 2. Abstract This document describes mechanisms for negotiating opera- tional parameters wherever the use of an ISO TR9577 NLPID is available.[6] For example, it is suitable for use in con- junction with RFC 1490 (Multiprotocol Over Frame Relay) and RFC 1356 (Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode) [1,2], and potentially others. The mechanisms described here are intended as optional extensions, intended to facilitate interoperation in public networks were precon- figuration may not have been done symmetrically by all par- ties who wish to exchange information. Sklower & Frost [Page 1] Draft Parameter Negotiation August 1993 3. Acknowledgements The authors wish to thank Brian Lloyd of Lloyd & Associates and Bill Simpson of Daydreamer, Inc. for extensive discus- sion of the PPP protocol, and this draft draws heavily on some ideas advanced by Bill in related work. Brad Steinke of Microcom, and Joel Halpern of Network Systems for useful suggestions, and especially Chris Ranch of Novell for details about the protocol itself. 4. 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 RECOMMENDED -- the 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. 5. Introduction When parties wish to exchange information over a public data network, it may be useful to perform sanity checks, such as verifying that buffer sizes are sufficient to receive data being transmitted, or that there is agreement as to which protocols will be routed or bridged. As another example, there may be circumstance in which the identity of a calling party may not be readily available; thus some form of authentication may be desired. The Point-to-Point Protocol (RFC 1331 and 1332) provides a means of achieving these goals [3,4]. It is very general and can be adapted to any situation where there is a virtual point-to-point connection between parties wishing to exchange information. Both RFC's 1490 and 1331 specify details of framing and encapsulation in incompatible ways; however, one can accommodate PPP's encapsulation of control packets by prepending a NLPID without otherwise changing the description of the packets. Negotiations are currently under way with ANSI for the assignment of a NLPID; it is believed that the numeric value CF (hex) will be assigned to this purpose. Members of the IPLPDN group expressed the desire that param- eter negotiation as a whole be made optional, and also wanted to be able to renegotiate parameters at any time dur- ing the course of an association. Sklower & Frost [Page 2] Draft Parameter Negotiation August 1993 6. Frame Format 6.1. Basic Format In this document, we propose prepending an NPLID to that portion of PPP control packets that follow link media head- ers, such as the two byte PPP address and control field. The NLPID value is 0xCF. A system SHOULD recognize incoming PPP data packets. We RECOMMEND that only control or negoti- ation type PPP packets be transmitted in this fashion, since RFCs 1490 and 1356 already specify a means of encapsulating data packets. Since we are proposing using this in conjunction with both RFC1490 and RFC1356, we give an example in each packet for- mat: Sklower & Frost [Page 3] Draft Parameter Negotiation August 1993 Sample Frame Relay PPP LCP packet +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ | Q.922 Address | +-- --+ | | +-----------------------------+ | Control (UI = 0x03) | +-----------------------------+ | Optional Pad(s) (0x00) | +-----------------------------+ | NLPID 0xCF | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ | PPP Protocol (0x21 for LCP)| | (two octets) | +-----------------------------+ | Data | | (e.g LCP Code ) | +-----------------------------+ | (e.g LCP Identifier) | +-----------------------------+ | (e.g. LCP Option Length)| +-- . --+ | (two octets) | +-----------------------------+ | (e.g. LCP Option) | | . | | . | | . | | . | +-----------------------------+ | Frame Check Sequence | +-- . --+ | (two octets) | +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ Sklower & Frost [Page 4] Draft Parameter Negotiation August 1993 Sample X.25 PPP LCP packet +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ | Address A or B 0x1 or 0x3 | +-- --+ | LAPB Control | +-----------------------------+ | D,Q bits | SVC# high order | +-----------------------------+ | SVC low order | +-----------------------------+ | p(r) | m_bit | p(s) | 0 | +-----------------------------+ | NLPID 0xCF | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ | PPP Protocol (0x21 for LCP)| | (two octets) | +-----------------------------+ | Data | | (e.g LCP Code ) | +-----------------------------+ | (e.g LCP Identifier) | +-----------------------------+ | (e.g. LCP Option Length)| +-- . --+ | (two octets) | +-----------------------------+ | (e.g. LCP Option) | | . | | . | | . | | . | +-----------------------------+ | Frame Check Sequence | +-- . --+ | (two octets) | +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ Since one of the packet formats specified in RFC1356 permits logically prepending the call user data supplied when the virtual circuit was established to each packet transmitted over that virtual circuit, one could transmit PPP packet unchanged if the single byte NLPID is supplied as the call user data. RFC1356 allows the use of single SVC connections between systems (termed the null encapsulation) indicated by the use of a single byte CUD with value 0. In the elements of Sklower & Frost [Page 5] Draft Parameter Negotiation August 1993 proceedure described below, if a system initiates traffic over such an SVC and subsequently initiates parameter nego- tiation with a system that may not have implemented this extension, all traffic becomes blocked until the initiating system has exhausted its PPP timers, whereas the system will reject a call request with a single byte CUD with the PPP value immediately. Also, PPP encodings for some protocols are more compact. Thus we RECOMMEND that when there are sufficient SVCS available, traffic requiring parameter nego- tiation be sent over a separate SVC. 6.2. Supported Types The PPP protocol is a rich language and allows many options to be negotiated. An implementation MAY request any option specified by PPP, but MAY decline to support any option. Because PPP and Frame Relay encapsulations evolved indepen- dently, there are duplicate ways to obtain configuration information such as the IP address of the other end of the PVC - by inverse arp, or determine the transmit and receive buffer sizes - by XID negotiation. Where there are such choices, it is RECOMMENDED that an implementation adhere to practice specified in the Frame Relay and X.25 RFCs. Manual configuration also implicitly provides information that may otherwise have been explicitly negotiated. 7. Elements of Proceedure As noted above, people have expressed the desire not to be required to conduct any negotiations before transmitting data packets in a public data network environment. Thus, an implementation MAY silently ignore any SNAP encapsulated PPP packet. If an implementation responds to LCP packets, it MUST traverse the LCP state diagram according to RFC1331. If an implementation responds to NCP packets for any partic- ular protocol, it MUST otherwise obey the rules of the RFC for that corresponding NCP. An implementation MUST NOT accept the address and control field compression option; these are required for correct operation over an X.25 over Frame Relay link. An implemen- tation MUST NOT accept the protocol identifier compression option; in the case where a non-PPP-initiating, but PPP- responding implementation has crashed and revived, it may depend on presence of the PPP NLPID in order to recognize that a negotiation has occurred. Although it would be pos- sible to interpret that opption as meaning removal of only the higher order zero valued byte of the two byte protocol field in this context, that would be at odds with other pro- posed extensions to PPP.[7] Sklower & Frost [Page 6] Draft Parameter Negotiation August 1993 One reason for making negotiations optional is cost; there are environments which charge by the packet and there are applications such as mail hubs which generally exchange only a few data packets with a given remote host and then will not exchange any other packets for relatively long periods of time. Another reason is simplicity of implementation. For use of small computers at home, people may wish to be able to only support the required packet framing. Or, for routers at campus or business hubs, this could reduce memory require- ments from having to maintain state information for hundreds of virtual point-to-point connections. Another reason is reduction of latency. 8. References [1] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", Network Working Group, RFC-1490, January 1992. [2] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", Net- work Working Group, RFC-1356, August 1992. [3] Simpson, W., "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to- Point Links", Network Working Group, RFC-1331, May 1992. [4] McGregor, G., "The PPP Internet Protocol Control Proto- col (IPCP)" Network Working Group, RFC-1332, May 1992. [5] Postel, J. and Reynolds, J., "A Standard for the Trans- mission of IP Datagrams over IEEE 802 Networks", ISI, RFC-1042, February 1988. [6] International Organization for Standardization, "Infor- mation technology - Telecommunications and Informations exchange between systems - Protocol identification in the network layer", Technical Report 9577, October 1990. [7] Simpson, W. A., "PPP in Frame Relay" and "PPP in X.25", Lansing Michigan, 1993, unpublished. 9. Authors' Addresses Keith Sklower Computer Science Department 570 Evans Hall University of California Sklower & Frost [Page 7] Draft Parameter Negotiation August 1993 Berkeley, CA 94720 Phone: (510) 642-9587 E-mail: sklower@cs.Berkeley.EDU Clifford Frost Information Systems & Technology 275 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-5360 E-mail: cliff@cmsa.Berkeley.EDU 10. Expiration Date of this Draft February 25, 1994 Sklower & Frost [Page 8]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01259; 25 Oct 93 11:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01249; 25 Oct 93 11:30 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08222; 25 Oct 93 11:30 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01190; 25 Oct 93 11:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01186; 25 Oct 93 11:27 EDT Received: from LOBSTER.WELLFLEET.COM by CNRI.Reston.VA.US id aa08046; 25 Oct 93 11:27 EDT Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20305; Mon, 25 Oct 93 11:17:39 EDT Received: from godiva.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA21062; Mon, 25 Oct 93 11:24:54 EDT Date: Mon, 25 Oct 93 11:24:54 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9310251524.AA21062@pobox.wellfleet> To: iplpdn@CNRI.Reston.VA.US Subject: meeting in Houston Hello everyone. I'd like to announce a meeting of the IPLPDN group for the Houston IETF meeting. As most of you know, the group was disbanded several meetings ago. Since then, however, several issues have come up that this group should address. The group is scheduled to meet on Monday at 13:30. I would like to discuss the following items: 1. Keith Sklower's parameter negotiation over frame relay. (he forwarded it (to the list recently) 2. Status of frame relay MIB (modifications to RFC 1315). 3. Inverse ARP modifications (addition of NAKs etc.). 4. How to run source routing bridge over frame relay. 5. Possible extensions to Inverse ARP to specify other protocols other than IP (IPX for example) for interoperability). If anyone has other unfinished business, please let me know so that we can add it to the list. Caralyn   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05528; 25 Oct 93 15:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05524; 25 Oct 93 15:03 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19931; 25 Oct 93 15:03 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05519; 25 Oct 93 15:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05515; 25 Oct 93 15:02 EDT Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa19891; 25 Oct 93 15:02 EDT Received: from jap.xyplex.com by xap.xyplex.com id ; Mon, 25 Oct 93 17:02:58 -0500 Message-Id: Date: Mon, 25 Oct 93 14:58:39 PDT Reply-To: japhilippou@xap.xyplex.com X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: japhilippou@xap.xyplex.com To: iplpdn@CNRI.Reston.VA.US Subject: RE: a question on routing protocols over Frame Relay >Folks, > >To those of you who have implemented routing protocols over Frame >Relay: I'm not aware of any definition of how to run DECnet Phase IV or >ISIS over Frame Relay. The same issues arise here that we resolved in >the PPP case - neither protocol defined how to operate over an >unreliable point to point link service. In the PPP case, DECnet phase >IV uses its broadcast link algorithm while ISIS uses its point to point >link algorithm (which turns out to work OK for unreliable links). > >In the interests of interworking, has anybody implemented either of >these over Frame Relay and if you did, how did you do it ? If there's a >specification which I've overlooked then can you point me at it ? > >Thanks, >Chris Gunner >Digital Equipment Corp. Xyplex uses a NLPID of 0x80 with a SNAP header OUI of 00-00-00 (EtherType) and PID 0x6003 for DECnet encapsulated frames. Jim Philippou japhilippou@eng.xyplex.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08405; 25 Oct 93 17:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08401; 25 Oct 93 17:57 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28063; 25 Oct 93 17:57 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08395; 25 Oct 93 17:57 EDT Received: from corp.timeplex.com by IETF.CNRI.Reston.VA.US id aa08391; 25 Oct 93 17:57 EDT Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF #2740 ) id <01H4JEB7YJV48WW3J0@sys30.timeplex.com>; Mon, 25 Oct 1993 18:00:18 EDT Received: from localhost by maelstrom.timeplex.com (4.1/SMI-4.1) id AA06855; Mon, 25 Oct 93 17:57:07 EDT Date: 25 Oct 1993 17:57:06 -0400 X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andy Malis Subject: Re: meeting in Houston In-reply-to: Your message of "Mon, 25 Oct 1993 11:24:00." To: cbrown@wellfleet.com Cc: malis@maelstrom.timeplex.com, iplpdn@IETF.CNRI.Reston.VA.US Message-id: <9310252157.AA06855@maelstrom.timeplex.com> Content-transfer-encoding: 7BIT Caralyn, > The group is scheduled to meet on Monday at 13:30. This, unfortunately, conflicts with the ATM MIB meeting, which should be attended by anyone interested in seeing it support the Service Management Architecture, so that it can be used with I.555-style ATM/FR connections in conjunction with the FR Service MIB. I know how hard it is to schedule around EVERYBODY's conflicts, but may I humbly suggest Wednesday at 13:30 or Friday at 09:00 instead? Thanks, Andy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10485; 26 Oct 93 13:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10481; 26 Oct 93 13:18 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20396; 26 Oct 93 13:18 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10382; 26 Oct 93 13:18 EDT Received: from LOBSTER.WELLFLEET.COM by IETF.CNRI.Reston.VA.US id aa10378; 26 Oct 93 13:15 EDT Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28580; Tue, 26 Oct 93 13:05:03 EDT Received: from godiva.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA06110; Tue, 26 Oct 93 12:23:12 EDT Date: Tue, 26 Oct 93 12:23:12 EDT X-Orig-Sender:iplpdn-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Caralyn Brown Message-Id: <9310261623.AA06110@pobox.wellfleet> To: malis@maelstrom.timeplex.com Subject: Re: meeting in Houston Cc: iplpdn@IETF.CNRI.Reston.VA.US Andy, I understand this is not exactly the most convenient of times, however, it's really this one or no others at this point. ATM MIB was the bottom of the conflict list, so this is the one that it conflicted with. The problem we have is that on Wednesday all of the rooms are filled so we can't have that time slot. On Friday morning as you have suggested, I won't be there. So, you see we have a little problem. If something comes up and we can find an open room for another time, we'll move it. But for now it's going to have to stay as planned. Sorry. Caralyn > From malis@maelstrom.timeplex.com Mon Oct 25 17:54:31 1993 > Date: 25 Oct 1993 17:57:06 -0400 > From: Andy Malis > Subject: Re: meeting in Houston > To: cbrown@wellfleet.com > Cc: malis@maelstrom.timeplex.com, iplpdn@ietf.cnri.reston.va.us > Content-Transfer-Encoding: 7BIT > Content-Length: 475 > > Caralyn, > > > The group is scheduled to meet on Monday at 13:30. > > This, unfortunately, conflicts with the ATM MIB meeting, which should > be attended by anyone interested in seeing it support the Service > Management Architecture, so that it can be used with I.555-style > ATM/FR connections in conjunction with the FR Service MIB. > > I know how hard it is to schedule around EVERYBODY's conflicts, but > may I humbly suggest Wednesday at 13:30 or Friday at 09:00 instead? > > Thanks, > Andy >