Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01442; 1 Oct 92 7:47 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa01438; 1 Oct 92 7:47 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa04830; 1 Oct 92 7:52 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01402; 1 Oct 92 7:47 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa01398; 1 Oct 92 7:43 EDT Received: from LOBSTER.WELLFLEET.COM by NRI.Reston.VA.US id aa04711; 1 Oct 92 7:48 EDT Received: from cbrown.wellfleet ([192.32.1.187]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA05980; Thu, 1 Oct 92 07:46:26 EDT Received: by cbrown.wellfleet (4.1/SMI-4.1) id AA26068; Thu, 1 Oct 92 07:48:46 EDT Date: Thu, 1 Oct 92 07:48:46 EDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Caralyn Brown Message-Id: <9210011148.AA26068@cbrown.wellfleet> To: iplpdn@NRI.Reston.VA.US Subject: updates to 1294 It has been suggested that the bridging section (13) of rfc 1294 could be improved. It is written assuming the frame relay interface is the bridge port and the VCs are destinations. Since there are configurations in which one would want each VC to be a bridge port, this section may be misleading. What do the rest of you say? Should I go ahead and try to clearify the two configurations? c   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02217; 1 Oct 92 9:39 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa02210; 1 Oct 92 9:39 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa07885; 1 Oct 92 9:44 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02196; 1 Oct 92 9:39 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa02192; 1 Oct 92 9:39 EDT Received: from uwm.edu by NRI.Reston.VA.US id aa07846; 1 Oct 92 9:43 EDT Received: by uwm.edu; id AA03896; Thu, 1 Oct 92 08:43:48 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Thu, 1 Oct 92 08:12 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.5) id ; Thu, 1 Oct 92 08:03 CDT Message-Id: X-Orig-Sender:iesg-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "George H. Clapp" Subject: submit Directed ARP to IESG To: Internet Engineering Steering Group , IPLPDN WG Date: Thu, 1 Oct 92 8:03:16 CDT The IP over Large Public Data Networks Working Groups agreed at the July IETF meeting in Cambridge that the work on Directed ARP has progressed to the point that the internet draft can be released to the IESG for approval release as a Draft Standard. The internet draft is titled "draft-ietf-iplpdn-directed_arp-00.txt." So, the working group would like to submit this draft to the IESG for their consideration. Thanks, George Clapp Chair, IPLPDN WG email: clapp@ameris.center.il.ameritech.com work: 708-248-6507 fax: 708-248-6038   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05274; 1 Oct 92 12:20 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa05270; 1 Oct 92 12:20 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa12271; 1 Oct 92 12:25 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05254; 1 Oct 92 12:20 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa05250; 1 Oct 92 12:19 EDT Received: from SAFFRON.ACC.COM by NRI.Reston.VA.US id aa12234; 1 Oct 92 12:24 EDT Received: by saffron.acc.com (4.1/SMI-4.1) id AA15027; Thu, 1 Oct 92 09:23:35 PDT Date: Thu, 1 Oct 92 09:23:35 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Fred Baker Message-Id: <9210011623.AA15027@saffron.acc.com> To: cbrown@wellfleet.com Subject: Re: updates to 1294 Cc: iplpdn@NRI.Reston.VA.US The Bridge MIB (RFC 1286) is structured to believe that each circuit on an underlying multiplexed interface (X.25, Frame Relay, etc) is a separate point to point bridge port. My vote would be that we assume bridges will follow that model. Dot1dBasePortEntry ::= SEQUENCE { dot1dBasePort INTEGER, dot1dBasePortIfIndex INTEGER, dot1dBasePortCircuit OBJECT IDENTIFIER, dot1dBasePortDelayExceededDiscards Counter, dot1dBasePortMtuExceededDiscards Counter } dot1dBasePort OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The port number of the port for which this entry contains bridge management information." ::= { dot1dBasePortEntry 1 } dot1dBasePortIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of the instance of the ifIndex object, defined in [4,6], for the interface corresponding to this port." ::= { dot1dBasePortEntry 2 } dot1dBasePortCircuit OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "For a port which (potentially) has the same value of dot1dBasePortIfIndex as another port on the same bridge, this object contains the name of an object instance unique to this port. For example, in the case where multiple ports correspond one- to-one with multiple X.25 virtual circuits, this value might identify an (e.g., the first) object instance associated with the X.25 virtual circuit corresponding to this port. For a port which has a unique value of dot1dBasePortIfIndex, this object can have the value { 0 0 }." ::= { dot1dBasePortEntry 3 }   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05795; 1 Oct 92 13:39 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa05790; 1 Oct 92 13:39 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa13813; 1 Oct 92 13:44 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05766; 1 Oct 92 13:39 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa05762; 1 Oct 92 13:39 EDT Received: from uwm.edu by NRI.Reston.VA.US id aa13772; 1 Oct 92 13:43 EDT Received: by uwm.edu; id AA06178; Thu, 1 Oct 92 12:43:47 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Thu, 1 Oct 92 12:01 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.5) id ; Thu, 1 Oct 92 11:52 CDT Message-Id: X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "George H. Clapp" Subject: Re: submit Directed ARP to IESG To: IPLPDN WG Date: Thu, 1 Oct 92 11:52:17 CDT In-Reply-To: <9210011504.AA01279@gateway.Ameritech.COM>; from "Andy Malis" at Oct 1, 92 11:04 am The previous message about Directed ARP asked that the draft be approved as a Draft Standard. I've been told that "Proposed" comes before "Draft," so the correct term is Proposed Standard. Sorry for the confusion. George Clapp email: clapp@ameris.center.il.ameritech.com work: 708-248-6507 fax: 708-248-6038   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06416; 1 Oct 92 14:04 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa06412; 1 Oct 92 14:04 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa14986; 1 Oct 92 14:08 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06377; 1 Oct 92 14:03 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa06342; 1 Oct 92 14:03 EDT Received: from sonny.proteon.com by NRI.Reston.VA.US id aa14941; 1 Oct 92 14:07 EDT Received: by sonny.proteon.com (5.65/1.7) id AA14689; Thu, 1 Oct 92 14:06:09 -0400 Date: Thu, 1 Oct 92 14:06:09 -0400 X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "John A. Shriver" Message-Id: <9210011806.AA14689@sonny.proteon.com> To: cbrown@wellfleet.com Cc: iplpdn@NRI.Reston.VA.US In-Reply-To: Caralyn Brown's message of Thu, 1 Oct 92 07:48:46 EDT <9210011148.AA26068@cbrown.wellfleet> Subject: updates to 1294 - bridging Oh, we're standing on the fence on the WAN vs. LAN model for bridging over Frame Relay. Hmm. Has anyone out there on the list studied and understood IEEE 802.1G? I'll admit that I've done nothing more than glance on it. All I know is that it's trying to deal with incomplete mesh WAN networks, and treat it as one blob in the spanning tree, and not reducing it internally to a spanning tree. This gives maximum utilization, and no extra hops across the WAN links. From a naive understanding of this, it sure looks like mapping one Frame Relay VC to a bridge port is the model more consonant with 802.1G. However, I may be totally out in left field. This is a loose and wobbly issue for all protocols over Frame Relay. We IP types generally are treating each Frame Relay mesh as one IP (sub)network. (Although directed ARP has another view.) However, it's pretty clear that Novell is leaning towards the model of ONE IPX network per FR VC. Maybe we should note which protocols have a defined model, and which are still up in the air. You don't want people making architectural decisions (one FR interface :== one IP network) that later prove wrong for other network layer protocols. The notorious "local matter" of the CCITT?   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08996; 1 Oct 92 17:28 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa08992; 1 Oct 92 17:28 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa21477; 1 Oct 92 17:32 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08962; 1 Oct 92 17:27 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa08958; 1 Oct 92 17:26 EDT Received: from nisc.jvnc.net by NRI.Reston.VA.US id aa21419; 1 Oct 92 17:31 EDT Received: from secureSUN250.timeplex.com by nisc.jvnc.net (5.65/1.34) id AA19901; Thu, 1 Oct 92 17:31:13 -0400 Received: from doelztc.timeplex.com (doelztc.timeplex.com) by bigguy.timeplex.com (4.1/SMI-4.1) id AA00436; Thu, 1 Oct 92 17:31:51 EDT Received: from gu4.doelz by doelztc.timeplex.com (4.1/SMI-4.1) id AA09699; Thu, 1 Oct 92 14:32:36 PDT Date: Thu, 1 Oct 92 14:32:36 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Shekar Nair Message-Id: <9210012132.AA09699@ doelztc.timeplex.com> To: cbrown@wellfleet.com Subject: re: updates to RFC 1294 Cc: iplpdn@NRI.Reston.VA.US > ......If at any time during this re-assembly process, > a fragment is corrupted or a fragment is missing, > the entire message is dropped. The upper layer protocol is > responsible for any retransmission in this case. How do we determine the reassembly timer value to time out lost packets. IP uses the "time-to-live" value in the datagram. Any suggestion ? Assuming a reassembly timer mechanism is used, why should a message be dropped if a fragment is missing at any time during the re-assembly process. The fragment could be out of order as each fragment is routed independently by the FR network, and topology changes and traffic conditions may cause the fragment to go out of order. nair. s   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01392; 2 Oct 92 7:16 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa01388; 2 Oct 92 7:16 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa04163; 2 Oct 92 7:21 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01331; 2 Oct 92 7:16 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa01326; 2 Oct 92 7:11 EDT Received: from uwm.edu by NRI.Reston.VA.US id aa04099; 2 Oct 92 7:16 EDT Received: by uwm.edu; id AA14877; Fri, 2 Oct 92 06:16:45 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Fri, 2 Oct 92 06:00 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.5) id ; Fri, 2 Oct 92 05:51 CDT Message-Id: X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "George H. Clapp" Subject: draft of Directed ARP document To: IPLPDN WG Date: Fri, 2 Oct 92 5:51:16 CDT For your information, here is a copy of the internet draft on Directed ARP which we are submitting to the IESG. George Clapp email: clapp@ameris.center.il.ameritech.com work: 708-248-6507 fax: 708-248-6038 *********************************************************************** Network Working Group J. W. Garrett INTERNET DRAFT AT&T Bell Laboratories J. D. Hagan University of Pennsylvania J. A. Wong AT&T Bell Laboratories June 18, 1992 Directed ARP 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 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 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. This document will be submitted to the Internet Activities Board as a proposed standard. This document will expire before December 18, 1992. Distribution of this memo is unlimited. Please send comments to the IP over Large Public Data Networks (IPLPDN) working group at iplpdn@NRI.Reston.VA.US Abstract A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (via ICMP Redirects) and routers (via dynamic routing protocols). However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the "foreign" IP network to their corresponding link level addresses. Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. Garrett, Hagan, & Wong [Page 1] INTERNET DRAFT Directed ARP Expires December 18, 1992 Acknowledgment The authors are indebted to Joel Halpern of Network Systems Corporation and David O'Leary who provided valuable comments and insight to the authors, as well as ongoing moral support as the presentation of this material evolved through many drafts. Members of the IPLPDN working group also provided valuable comments during presentations and through the IPLPDN mailing list. Chuck Hedrick of Rutgers University, Paul Tsuchiya of Bell Communications Research, and Doris Tillman of AT&T Bell Laboratories provided early insight as well as comments on early drafts. 1. Terminology A "link level network" is the upper layer of what is sometimes referred to (e.g., OSI parlance) as the "subnetwork", i.e., the layers below IP. The term "link level" is used to avoid potential confusion with the term "IP sub-network", and to identify addresses (i.e., "link level address") associated with the network used to transport IP datagrams. From the perspective of a host or router, an IP network is "foreign" if the host or router does not have an address on the IP network. 2. Introduction Multiple IP networks may be administered on the same link level network (e.g., on a large public data network). A router with a single interface on two IP networks could use existing routing update procedures to advertise that the two IP networks shared the same link level network. Cost/performance benefits could be achieved if hosts and routers that were not on the same IP network could use that advertised information, and exchange packets directly, rather than through the dual addressed router. But a host or router can not send packets directly to an IP address without first resolving the IP address to its link level address. IP address resolution procedures are established independently for each IP network. For example, on an SMDS network [1], address resolution may be achieved using the Address Resolution Protocol (ARP) [2], with a separate SMDS ARP Request Address (e.g., an SMDS Multicast Group Address) associated with each IP network. A host or router that was not configured with the appropriate ARP Request Address would have no way to learn the ARP Request Address associated with an IP network, and would not send an ARP Request to the appropriate ARP Request Address. On an Ethernet network a host or Garrett, Hagan, & Wong [Page 2] INTERNET DRAFT Directed ARP Expires December 18, 1992 router might guess that an IP address could be resolved by sending an ARP Request to the broadcast address. But if the IP network used a different address resolution procedure (e.g., administered address resolution tables), the ARP Request might go unanswered. Directed ARP is a procedure that enables a router advertising that an IP address is on a shared link level network to also aid in resolving the IP address to its associated link level address. By removing address resolution constraints, Directed ARP enables dynamic routing protocols such as BGP [3] and OSPF [4] to advertise and use routing information that leads to next-hop addresses on "foreign" IP networks. In addition, Directed ARP enables routers to advertise (via ICMP Redirects) next-hop addresses that are "foreign" to hosts, since the hosts can use Directed ARP to resolve the "foreign" next- hop addresses. 3. Directed ARP Directed ARP uses the normal ARP packet format, and is consistent with ARP procedures, as defined in [1] and [2], and with routers and hosts that implement those procedures. 3.1 ARP Helper Address Hosts and routers maintain routing information, logically organized as a routing table. Each routing table entry associates one or more destination IP addresses with a next-hop IP address and a physical interface used to forward a packet to the next-hop IP address. If the destination IP address is local (i.e., can be reached without the aid of a router), the next-hop IP address is NULL (or a logical equivalent, such as the IP address of the associated physical interface). Otherwise, the next-hop IP address is the address of a next-hop router. A host or router that implements Directed ARP procedures associates an ARP Helper Address with each routing table entry. If the host or router has been configured to resolve the next-hop IP address to its associated link level address (or to resolve the destination IP address, if the next-hop IP address is NULL), the associated ARP Helper Address is NULL. Otherwise, the ARP Helper Address is the IP address of the router that provided the routing information indicating that the next-hop address was on the same link level network as the associated physical interface. Section 4 provides detailed examples of the determination of ARP Helper Addresses by dynamic routing procedures. Garrett, Hagan, & Wong [Page 3] INTERNET DRAFT Directed ARP Expires December 18, 1992 3.2 Address Resolution Procedures To forward an IP packet, a host or router searches its routing table for an entry that is the best match based on the destination IP address and perhaps other factors (e.g., Type of Service). The selected routing table entry includes the IP address of a next-hop router (which may be NULL), the physical interface through which the IP packet should be forwarded, an ARP Helper Address (which may be NULL), and other information. The routing function passes the next- hop IP address, the physical interface, and the ARP Helper Address to the address resolution function. The address resolution function must then resolve the next-hop IP address (or destination IP address if the next-hop IP address is NULL) to its associated link level address. The IP packet, the link level address to which the packet should be forwarded, and the interface through which the packet should be forwarded are then passed to the link level driver associated with the physical interface. The link level driver encapsulates the IP packet in one or more link level frames (i.e., may do fragmentation) addressed to the associated link level address, and forwards the frame(s) through the appropriate physical interface. The details of the functions performed are described via C pseudo- code below. The procedures are organized as two functions, Route() and Resolve(), corresponding to routing and address resolution. In addition, the following low level functions are also used: Get_Route(IP_Add,Other) returns a pointer to the routing table entry with the destination field that best matches IP_Add. If no matching entry is found, NULL is returned. Other information such as Type of Service may be considered in selecting the best route. Forward(Packet,Link_Level_Add,Phys_Int) fragments Packet (if needed), and encapsulates Packet in one or more Link Level Frames addressed to Link_Level_Add, and forwards the frame(s) through interface, Phys_Int. Look_Up_Add_Res_Table(IP_Add,Phys_Int) returns a pointer to the link level address associated with IP_Add in the address resolution table associated with interface, Phys_Int. If IP_Add is not found in the address resolution table, NULL is returned. Local_Add_Res(IP_Add,Phys_Int) returns a pointer to the Link Level address associated with IP_Add, using address resolution procedures associated with address, IP_Add, and interface, Phys_Int. If address resolution is unsuccessful, NULL is returned. Note that different address resolution procedures may be used for different IP networks. Garrett, Hagan, & Wong [Page 4] INTERNET DRAFT Directed ARP Expires December 18, 1992 Receive_ARP_Response(IP_Add,Phys_Int) returns a pointer to an ARP Response received through interface, Phys_Int, that resolves IP_Add. If no ARP response is received, NULL is returned. Dest_IP_Add(IP_Packet) returns the IP destination address from IP_Packet. Next_Hop(Entry) returns the IP address in the next-hop field of (routing table) Entry. Interface(Entry) returns the physical interface field of (routing table) Entry. ARP_Helper_Add(Entry) returns the IP address in the ARP Helper Address field of (routing table) Entry. ARP_Request(IP_Add) returns an ARP Request packet with IP_Add as the Target IP address. Source_Link_Level(ARP_Response) returns the link level address of the sender of ARP_Response. ROUTE(IP_Packet) { Entry = Get_Route(Dest_IP_Add(IP_Packet),Other(IP_Packet)); If (Entry == NULL) /* No matching entry in routing table */ Return; /* Discard IP_Packet */ else { /* Resolve next-hop IP address to link level address */ If (Next_Hop(Entry) != NULL) /* Route packet via next-hop router */ Next_IP = Next_Hop(Entry); else /* Destination is local */ Next_IP = Dest_IP_Add(IP_Packet); L_L_Add = Resolve(Next_IP,Interface(Entry),ARP_Helper_Add(Entry)); If (L_L_Add != NULL) Forward(IP_Packet,L_L_Add,Interface(Entry)); else /* Couldn't resolve next-hop IP address */ Return; /* Discard IP_Packet */ Return; } } Figure 1: C Pseudo-Code for the Routing function. Garrett, Hagan, & Wong [Page 5] INTERNET DRAFT Directed ARP Expires December 18, 1992 Resolve(IP_Add,Interface,ARP_Help_Add) { If ((L_L_Add = Look_Up_Add_Res_Table(IP_Add,Interface)) != NULL) { /* Found it in Address Resolution Table */ Return L_L_Add; } else { If (ARP_Help_Add == NULL) { /* Do local Address Resolution Procedure */ Return Local_Add_Res(IP_Add,Interface); } else /* ARP_Help_Add != NULL */ { L_L_ARP_Help_Add = Look_Up_Add_Res_Table(ARP_Help_Add,Interface); If (L_L_ARP_Help_Add == NULL) /* Not in Address Resolution Table */ L_L_ARP_Help_Add = Local_Add_Res(ARP_Help_Add,Interface); If (L_L_ARP_Help_Add == NULL) /* Can't Resolve ARP Helper Add */ Return NULL; /* Address Resolution Failed */ else { /* ARP for IP_Add */ Forward(ARP_Request(IP_Add),L_L_ARP_Help_Add,Interface); ARP_Resp = Receive_ARP_Response(IP_Add,Interface); If (ARP_Resp == NULL) /* No ARP Response (after persistence) */ Return NULL; /* Address Resolution Failed */ else Return Source_Link_Level(ARP_Resp); } } } } } Figure 2: C Pseudo-Code for Address Resolution function. Garrett, Hagan, & Wong [Page 6] INTERNET DRAFT Directed ARP Expires December 18, 1992 3.3 Forwarding ARP Requests A host that implements Directed ARP procedures uses normal procedures to process received ARP Requests. That is, if the Target IP address is the host's address, the host uses normal procedures to respond to the ARP Request. If the Target IP address is not the host's address, the host silently discards the ARP Request. If the Target IP address of an ARP Request received by a router is the router's address, the router uses normal procedures to respond to the ARP Request. But if the Target IP address is not the router's address, the router may forward the ARP Request back through the same interface it was received from, addressed to a Link Level Address that corresponds to an ARP Helper Address in the router's routing table. The procedures used to process an ARP Request are described via C pseudo-code below. The function Receive() describes procedures followed by hosts and routers, and the function Direct() describes additional procedures followed by routers. In addition, the following low level functions are also used: Is_Local_IP_Add(IP_Add,Phys_Int) returns TRUE if Phys_Int has been assigned IP address, IP_Add. Otherwise, returns FALSE. Do_ARP_Processing(ARP_Request,Interface) processes ARP_Request using ARP procedures described in [2]. I_Am_Router returns TRUE if device is a router and False if device is a host. Target_IP(ARP_Request) returns the Target IP address from ARP_Request. Filter(ARP_Request,Phys_Int) returns TRUE if ARP_Request passes filtering constraints, and FALSE if filtering constraints are not passed. See section 3.4. Forward(Packet,Link_Level_Add,Phys_Int) fragments Packet (if needed), and encapsulates Packet in one or more Link Level Frames addressed to Link_Level_Add, and forwards the frame(s) through interface, Phys_Int. Look_Up_Next_Hop_Route_Table(IP_Add) returns a pointer to the routing table entry with the next-hop field that matches IP_Add. If no matching entry is found, NULL is returned. Look_Up_Dest_Route_Table(IP_Add) returns a pointer to the routing table entry with the destination field that best matches IP_Add. If no matching entry is found, NULL is returned. Garrett, Hagan, & Wong [Page 7] INTERNET DRAFT Directed ARP Expires December 18, 1992 Link_Level_ARP_Req_Add(IP_Add,Phys_Int) returns the link level address to which an ARP Request to resolve IP_Add should be forwarded. If ARP is not used to perform local address resolution of IP_Add, NULL is returned. Local_Add_Res(IP_Add,Phys_Int) returns a pointer to the Link Level address associated with IP_Add, using address resolution procedures associated with address, IP_Add, and interface, Phys_Int. If address resolution is unsuccessful, NULL is returned. Note that different address resolution procedures may be used for different IP networks. Next_Hop(Entry) returns the IP address in the next-hop field of (routing table) Entry. Interface(Entry) returns the physical interface field of (routing table) Entry. ARP_Helper_Add(Entry) returns the IP address in the ARP Helper Address field of (routing table) Entry. Source_Link_Level(ARP_Request) returns the link level address of the sender of ARP_Request. Receive(ARP_Request,Interface) { If (Is_Local_IP_Add(Target_IP(ARP_Request),Interface)) Do_ARP_Processing(ARP_Request,Interface); else /* Not my IP Address */ If (I_Am_Router) /* Hosts don't Direct ARP Requests */ If (Filter(ARP_Request,Interface)) /* Passes Filter Test */ /* See Section 3.4 */ Direct(ARP_Request,Interface); /* Directed ARP Procedures */ Return; } Figure 3: C Pseudo-Code for Receiving ARP Requests. Garrett, Hagan, & Wong [Page 8] INTERNET DRAFT Directed ARP Expires December 18, 1992 Direct(ARP_Request,Phys_Int) { Entry = Look_Up_Next_Hop_Route_Table(Target_IP(ARP_Request)); If (Entry == NULL) /* Target_IP Address is not a next-hop */ { /* in Routing Table */ Entry = Look_Up_Dest_Route_Table(Target_IP(ARP_Request)); If (Entry == NULL) /* Not a destination either */ Return; /* Discard ARP Request */ else If (Next_Hop(Entry) != NULL) /* Not a next-hop and Not local */ Return; /* Discard ARP Request */ } If (Interface(Entry) != Phys_Int) /* Must be same physical interface */ Return; /* Discard ARP Request */ If (ARP_Helper_Add(Entry) != NULL) { L_L_ARP_Helper_Add = Resolve(ARP_Helper_Add(Entry),Phys_Int,NULL); If (L_L_ARP_Helper_Add != NULL) Forward(ARP_Request,L_L_ARP_Helper_Add,Phys_Int); /* Forward ARP_Request to ARP Helper Address */ Return; } else /* Do local address resolution. */ { L_L_ARP_Req_Add = Link_Level_ARP_Req_Add(Target_IP(ARP_Request),Phys_Int); If (L_L_ARP_Req_Add != NULL) { /* Local address resolution procedure is ARP. */ /* Forward ARP_Request. */ Forward(ARP_Request,L_L_ARP_Req_Add,Phys_Int); Return; } else { /* Local address resolution procedure is not ARP. */ /* Do "published ARP" on behalf of Target IP Address */ Target_Link_Level = Local_Add_Res(Target_IP(ARP_Request),Phys_Int); If (Target_Link_Level != NULL) /* Resolved Address */ { Forward(ARP_Response,Source_Link_Level(ARP_Request),Phys_Int); } Return; } } } Figure 4: C Pseudo_Code for Directing ARP Requests. Garrett, Hagan, & Wong [Page 9] INTERNET DRAFT Directed ARP Expires December 18, 1992 3.4 Filtering Procedures A router performing Directed ARP procedures must filter the propagation of ARP Request packets to constrain the scope of potential "ARP floods" caused by misbehaving routers or hosts, and to terminate potential ARP loops that may occur during periods of routing protocol instability or as a result of inappropriate manual configurations. Specific procedures to filter the propagation of ARP Request packets are beyond the scope of this document. The following procedures are suggested as potential implementations that should be sufficient. Other procedures may be better suited to a particular implementation. To control the propagation of an "ARP flood", a router performing Directed ARP procedures could limit the number of identical ARP Requests (i.e., same Source IP address and same Target IP address) that it would forward per small time interval (e.g., no more than one ARP Request per second). This is consistent with the procedure suggested in [5] to prevent ARP flooding. Forwarding of ARP Request packets introduces the possibility of ARP loops. The procedures used to control the scope of potential ARP floods may terminate some ARP loops, but additional procedures are needed if the time required to traverse a loop is longer than the timer used to control ARP floods. A router could refuse to forward more than N identical ARP Requests per T minutes, where N and T are administered numbers. If T and N are chosen so that T/N minutes is greater than the maximum time required to traverse a loop, such a filter would terminate the loop. In some cases a host may send more than one ARP Request with the same Source IP address,Target IP address pair (i.e., N should be greater than 1). For example, the first ARP Request might be lost. However, once an ARP Response is received, a host would normally save the associated information, and therefore would not generate an identical ARP Request for a period of time on the order of minutes. Therefore, T may be large enough to ensure that T/N is much larger than the time to traverse any loop. In some implementations the link level destination address of a frame used to transport an ARP Request to a router may be available to the router's Directed ARP filtering process. An important class of simple ARP loops will be prevented from starting if a router never forwards an ARP Request to the same link level address to which the received ARP Request was addressed. Of course, other procedures such as the one described in the paragraph above will stop all loops, and are needed, even if filters are implemented that prevent some loops from starting. Garrett, Hagan, & Wong [Page 10] INTERNET DRAFT Directed ARP Expires December 18, 1992 Host requirements [5] specify that "the packet receive interface between the IP layer and the link layer MUST include a flag to indicate whether the incoming packet was addressed to a link-level broadcast address." An important class of simple ARP floods can be eliminated if routers never forward ARP Requests that were addressed to a link-level broadcast address. 4. Use of Directed ARP by Routing The exchange and use of routing information is constrained by available address resolution procedures. A host or router can not use a next-hop IP address learned via dynamic routing procedures if it is unable to resolve the next-hop IP address to the associated link level address. Without compatible dynamic address resolution procedures, a router may not advertise a next-hop address that is not on the same IP network as the host or router receiving the advertisement. Directed ARP is a procedure that enables a router that advertises routing information to make the routing information useful by also providing assistance in resolving the associated next-hop IP addresses. The following subsections describe the use of Directed ARP to expand the scope of ICMP Redirects [6], distance-vector routing protocols (e.g., BGP [3]), and link-state routing protocols (e.g., OSPF [4]). 4.1 ICMP Redirect If a router forwards a packet to a next-hop address that is on the same link level network as the host that originated the packet, the router may send an ICMP Redirect to the host. But a host can not use a next-hop address advertised via an ICMP Redirect unless the host has a procedure to resolve the advertised next-hop address to its associated link level address. Directed ARP is a procedure that a host could use to resolve an advertised next-hop address, even if the host does not have an address on the same IP network as the advertised next-hop address. A host that implements Directed ARP procedures includes an ARP Helper Address with each routing table entry. The ARP Helper Address associated with an entry learned via an ICMP Redirect is NULL if the associated next-hop address matches a routing table entry with a NULL next-hop and a NULL ARP Helper Address (i.e., the host already knows how to resolve the next-hop address). Otherwise, the ARP Helper Address is the IP address of the router that sent the ICMP Redirect. Note that the router that sent the ICMP Redirect is the current next-hop to the advertised destination [5]. Therefore, the host should have an entry in its address resolution table for the new ARP Garrett, Hagan, & Wong [Page 11] INTERNET DRAFT Directed ARP Expires December 18, 1992 Helper Address. If the host is unable to resolve the next-hop IP address advertised in the ICMP Redirect (e.g., because the associated ARP Helper Address is on a foreign IP network; i.e., was learned via an old ICMP Redirect, and the address resolution table entry for that ARP Helper Address timed out), the host must flush the associated routing table entry. Directed ARP procedures do not recursively use Directed ARP to resolve an ARP Helper Address. A router that performs Directed ARP procedures might advertise a foreign next-hop to a host that does not perform Directed ARP. Following existing procedures, the host would silently discard the ICMP Redirect. A router that does not implement Directed ARP should not advertise a next-hop on a foreign IP network, as specified by existing procedures. If it did, and the ICMP Redirect was received by a host that implemented Directed ARP procedures, the host would send an ARP Request for the foreign IP address to the advertising router, which would silently discard the ARP Request. When address resolution fails, the host should flush the associated entry from its routing table. For various reasons a host may ignore an ICMP Redirect and may continue to forward packets to the same router that sent the ICMP Redirect. For example, a host that does not implement Directed ARP procedures would silently discard an ICMP Redirect advertising a next-hop address on a foreign IP network. Routers should implement constraints to control the number of ICMP Redirects sent to hosts. For example, a router might limit the number of repeated ICMP Redirects sent to a host to no more than N ICMP Redirects per T minutes, where N and T are administered values. 4.2 Distance Vector Routing Protocol A distance-vector routing protocol provides procedures for a router to advertise a destination address (e.g., an IP network), an associated next-hop address, and other information (e.g., associated metric). But a router can not use an advertised route unless the router has a procedure to resolve the advertised next-hop address to its associated link level address. Directed ARP is a procedure that a router could use to resolve an advertised next-hop address, even if the router does not have an address on the same IP network as the advertised next-hop address. The following procedures assume a router only accepts routing updates if it knows the IP address of the sender of the update, can resolve the IP address of the sender to its associated link level address, and has an interface on the same link level network as the sender. Garrett, Hagan, & Wong [Page 12] INTERNET DRAFT Directed ARP Expires December 18, 1992 A router that implements Directed ARP procedures includes an ARP Helper Address with each routing table entry. The ARP Helper Address associated with an entry learned via a routing protocol update is NULL if the associated next-hop address matches a routing table entry with a NULL next-hop and NULL ARP Helper Address (i.e., the router already knows how to resolve the next-hop address). Otherwise, the ARP Helper Address is the IP address of the router that sent the routing update. Some distance-vector routing protocols (e.g., BGP [3]) provide syntax that would permit a router to advertise an address on a foreign IP network as a next-hop. If a router that implements Directed ARP procedures advertises a foreign next-hop IP address to a second router that does not implement Directed ARP procedures, the second router can not use the advertised foreign next-hop. Depending on the details of the routing protocol implementation, it might be appropriate for the first router to also advertise a next-hop that is not on a foreign IP network (e.g., itself), perhaps at a higher cost. Or, if the routing relationship is an administered connection (e.g., BGP relationships are administered TCP/IP connections), the administrative procedure could determine whether foreign next-hop IP addresses should be advertised. A distance-vector routing protocol could advertise that a destination is directly reachable by specifying that the router receiving the advertisement is, itself, the next-hop to the destination. In addition, the advertised metric for the route might be zero. If the router did not already have a routing table entry that specified the advertised destination was local (i.e., NULL next-hop address), the router could add the new route with NULL next-hop, and the IP address of the router that sent the update as ARP Helper Address. 4.3 Link State Routing Protocol A link-state routing protocol provides procedures for routers to identify links to other entities (e.g., other routers and networks), determine the state or cost of those links, reliably distribute link-state information to other routers in the routing domain, and calculate routes based on link-state information received from other routers. A router with an interface to two (or more) IP networks via the same link level interface is connected to those IP networks via a single link, as described above. If a router could advertise that it used the same link to connect to two (or more) IP networks, and would perform Directed ARP procedures, routers on either of the IP networks could forward packets directly to hosts and routers on both IP networks, using Directed ARP procedures to resolve addresses on the foreign IP network. With Directed ARP, the cost of the direct path to the foreign IP network would be less than the cost of the path Garrett, Hagan, & Wong [Page 13] INTERNET DRAFT Directed ARP Expires December 18, 1992 through the router with addresses on both IP networks. To benefit from Directed ARP procedures, the link-state routing protocol must include procedures for a router to advertise connectivity to multiple IP networks via the same link, and the routing table calculation process must include procedures to calculate ARP Helper Addresses and procedures to accurately calculate the reduced cost of the path to a foreign IP network reached directly via Directed ARP procedures. The Shortest Path First algorithm for calculating least cost routes is based on work by Dijkstra [7], and was first used in a routing protocol by the ARPANET, as described by McQuillan [8]. A router constructs its routing table by building a shortest path tree, with itself as root. The process is iterative, starting with no entries on the shortest path tree, and the router, itself, as the only entry in a list of candidate vertices. The router then loops on the following two steps. 1. Remove the entry from the candidate list that is closest to root, and add it to the shortest path tree. 2. Examine the link state advertisement from the entry added to the shortest path tree in step 1. For each neighbor (i.e., router or IP network to which a link connects) - If the neighbor is already on the shortest path tree, do nothing. - If the neighbor is on the candidate list, recalculate the distance from root to the neighbor. Also recalculate the next-hop(s) to the neighbor. - If the neighbor is not on the candidate list, calculate the distance from root to the neighbor and the next-hop(s) from root to the neighbor, and add the neighbor to the candidate list. The process terminates when there are no entries on the candidate list. To take advantage of Directed ARP procedures, the link-state protocol must provide procedures to advertise that a router accesses two or more IP networks via the same link. In addition, the Shortest Path First calculation is modified to calculate ARP Helper Addresses and recognize path cost reductions achieved via Directed ARP. 1. If a neighbor under consideration is an IP network, and its parent (i.e., the entry added to the shortest path tree in step Garrett, Hagan, & Wong [Page 14] INTERNET DRAFT Directed ARP Expires December 18, 1992 1, above) has advertised that the neighbor is reached via the same link as a network that is already on the shortest path tree, the distance from root and next-hop(s) from root to the neighbor are the same as the distance and next-hop(s) associated with the network already on the shortest path tree. If the ARP Helper Address associated with the network that is already on the shortest path tree is not NULL, the neighbor also inherits the ARP Helper Address from the network that is already on the shortest path tree. 2. If the calculated next-hop to the neighbor is not NULL, the neighbor inherits the ARP Helper Address from its parent. Otherwise, except as described in item 1, the ARP Helper Address is the IP address of the next-hop to the neighbor's parent. Note that the next-hop to root is NULL. For each router or IP network on the shortest path tree, the Shortest Path First algorithm described above must calculate one or more next-hops that can be used to access the router or IP network. A router that advertises a link to an IP network must include an IP address that can be used by other routers on the IP network when using the router as a next-hop. A router might advertise that it was connected to two IP networks via the same link by advertising the same next-hop IP address for access from both IP networks. To accommodate the address resolution constraints of routers on both IP networks the router might advertise two IP addresses (one from each IP network) as next-hop IP addresses for access from both IP networks. 5. Robustness Hosts and routers can use Directed ARP to resolve third-party next- hop addresses; i.e., next-hop addresses learned from a routing protocol peer or current next-hop router. Undetected failure of a third party next-hop can result in a routing "black hole". To avoid "black holes", host requirements [5] specify that a host "...MUST be able to detect the failure of a 'next-hop' gateway that is listed in its route cache and to choose an alternate gateway." A host may receive feedback from protocol layers above IP (e.g., TCP) that indicates the status of a next-hop router, and may use other procedures (e.g., ICMP echo) to test the status of a next-hop router. But the complexity of routing is borne by routers, whose routing information must be consistent with the information known to their peers. Routing protocols such as BGP [3], OSPF [4], and others, require that routers must stand behind routing information that they advertise. Routers tag routing information with the IP address of the router that advertised the information. If the information Garrett, Hagan, & Wong [Page 15] INTERNET DRAFT Directed ARP Expires December 18, 1992 becomes invalid, the router that advertised the information must advertise that the old information is no longer valid. If a source of routing information becomes unavailable, all information received from that source must be marked as no longer valid. The complexity of dynamic routing protocols stems from procedures to ensure routers either receive routing updates sent by a peer, or are able to determine that they did not receive the updates (e.g., because connectivity to the peer is no longer available). Third-party next-hops can also result in "black holes" if the underlying link layer network connectivity is not transitive. For example, SMDS filters [9] could be administered to permit communication between the SMDS addresses of router R1 and router R2, and between the SMDS addresses of router R2 and router R3, and to block communication between the SMDS addresses of router R1 and router R3. Router R2 could advertise router R3 as a next-hop to router R1, but SMDS filters would prevent direct communication between router R1 and router R3. Non-symmetric filters might permit router R3 to send packets to router R1, but block packets sent by router R1 addressed to router R3. A host or router could verify link level connectivity with a next-hop router by sending an ICMP echo to the link level address of the next-hop router. (Note that the ICMP echo is sent directly to the link level address of the next-hop router, and is not routed to the IP address of the next-hop router. If the ICMP echo is routed, it may follow a path that does not verify link level connectivity.) This test could be performed before adding the associated routing table entry, or before the first use of the routing table entry. Detection of subsequent changes in link level connectivity is a dynamic routing protocol issue and is beyond the scope of this memo. References [1] Piscitello, D., and J. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", RFC 1209, Bell Communications Research, March 1991. [2] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, Symbolics, Inc., November 1982. [3] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco Systems and IBM T. J. Watson Research Center, October 1991. Garrett, Hagan, & Wong [Page 16] INTERNET DRAFT Directed ARP Expires December 18, 1992 [4] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991. [5] Braden, R., editor, "Requirements for Internet Hosts -- Communication Layers", RFC 1122, ISI, October 1989. [6] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", RFC 792, USC/Information Sciences Institute, September 1981. [7] Dijkstra, E. W., "A Note on Two Problems in Connection with Graphs", Numerische Mathematik, Vol. 1, pp. 269-271, 1959. [8] McQuillan, J. M., I. Richer, and E. C. Rosen, "The New Routing Algorithm for the ARPANET", IEEE Transactions on Communications, Vol. COM-28, May 1980. [9] "Generic System Requirements In Support of Switched Multi- megabit Data Service", Technical Reference TR-TSV-000772, Bell Communications Research Technical Reference, Issue 1, May 1991. Authors' Addresses John Garrett AT&T Bell Laboratories 184 Liberty Corner Road Warren, N.J. 07060-0906 Phone: (908) 580-4719 EMail: jwg@edsel.att.com John Dotts Hagan University of Pennsylvania Suite 221A 3401 Walnut Street Philadelphia, PA 19104-6228 Phone: (215) 898-9192 EMail: Hagan@UPENN.EDU Jeff Wong AT&T Bell Laboratories 184 Liberty Corner Road Warren, N.J. 07060-0906 Phone: (908) 580-5361 EMail: jaw@io.att.com Garrett, Hagan, & Wong [Page 17]   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01844; 2 Oct 92 8:23 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa01840; 2 Oct 92 8:22 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa05737; 2 Oct 92 8:27 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01827; 2 Oct 92 8:22 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa01823; 2 Oct 92 8:21 EDT Received: from OAKLAND.BBN.COM by NRI.Reston.VA.US id aa05716; 2 Oct 92 8:26 EDT To: Shekar Nair cc: cbrown@wellfleet.com, iplpdn@NRI.Reston.VA.US, malis@bbn.com Subject: Re: updates to RFC 1294 In-reply-to: Your message of Thu, 01 Oct 92 14:32:36 -0700. <9210012132.AA09699@ doelztc.timeplex.com> Date: Fri, 02 Oct 92 08:25:22 -0400 X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Andy Malis Message-ID: <9210020826.aa05716@NRI.Reston.VA.US> > > ......If at any time during this re-assembly process, > > a fragment is corrupted or a fragment is missing, > > the entire message is dropped. The upper layer protocol is > > responsible for any retransmission in this case. > How do we determine the reassembly timer value to time out lost packets. > IP uses the "time-to-live" value in the datagram. Any suggestion ? > Assuming a reassembly timer mechanism is used, why should a message be > dropped if a fragment is missing at any time during the re-assembly process. > The fragment could be out of order as each fragment is routed > independently by the FR network, and topology changes and > traffic conditions may cause the fragment to go out of order. No timer is needed. Frame Relay networks do not guarantee to deliver every frame, but they do guarantee that what gets delivered will be in order (it's part of the Frame Relay service description). So, you just have to hold on to fragments until the original datagram is complete, or you receive the next datagram (or a fragment thereof). The "sequence number" field distinguishes one fragmented datagram from another. Regards, Andy   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03236; 2 Oct 92 9:43 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03232; 2 Oct 92 9:43 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa08409; 2 Oct 92 9:47 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03210; 2 Oct 92 9:43 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03206; 2 Oct 92 9:42 EDT Received: from uu5.psi.com by NRI.Reston.VA.US id aa08395; 2 Oct 92 9:46 EDT Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA23221; Fri, 2 Oct 92 09:45:05 -0500 Date: Fri, 2 Oct 92 09:24:33 EDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Chip Sharp 6424 Received: by teleoscom.com (4.1/3.2.083191-Teleos Communications Inc.) id AA23689; Fri, 2 Oct 92 09:24:33 EDT Message-Id: <9210021324.AA23689@teleoscom.com> To: shekar@doelztc.timeplex.com Cc: cbrown@wellfleet.com, iplpdn@NRI.Reston.VA.US In-Reply-To: Shekar Nair's message of Thu, 1 Oct 92 14:32:36 PDT <9210012132.AA09699@ doelztc.timeplex.com> Subject: re: updates to RFC 1294 >The fragment could be out of order as each fragment is routed >independently by the FR network, and topology changes and traffic >conditions may cause the fragment to go out of order. >nair. s ANSI T1.606, Section 6.2 lists the service characteristics of a frame relay service. Item two in the list is as follows: (2) Preserves their (ed., frames) order as given at one user network interface if and when they are delivered at the other end. Thus, as long as the fragments are transmitted over the same Virtual Circuit and the frame relay network conforms to ANSI T1.606, frames should not be delivered out of order. Therefore, as soon as an endpoint receives a fragment with an offset indicating a missing frame (i.e., fragment), the endpoint can safely assume the missing fragment has been lost and can initiate recovery procedures. Chip Sharp   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09560; 2 Oct 92 16:10 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa09556; 2 Oct 92 16:10 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa18477; 2 Oct 92 16:15 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09508; 2 Oct 92 16:10 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa09504; 2 Oct 92 16:09 EDT Received: from uwm.edu by NRI.Reston.VA.US id aa18412; 2 Oct 92 16:14 EDT Received: by uwm.edu; id AA19275; Fri, 2 Oct 92 15:14:14 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Fri, 2 Oct 92 15:11 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.5) id ; Fri, 2 Oct 92 15:02 CDT Message-Id: X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "George H. Clapp" Subject: Re: RFC 1294 version 2 To: IPLPDN WG Date: Fri, 2 Oct 92 15:02:40 CDT > The Bridge MIB (RFC 1286) is structured to believe that each circuit on > an underlying multiplexed interface (X.25, Frame Relay, etc) is a > separate point to point bridge port. My vote would be that we assume > bridges will follow that model. There are network services which are not point-to-point. For example, SMDS has the multicast group address, Frame Relay has the multicast DLCI, and B-ISDN has every intention of supporting multipoint virtual circuits. So, remote bridges may not be connected by only point-to-point services. Does this break something in the Bridge MIB? George Clapp email: clapp@ameris.center.il.ameritech.com work: 708-248-6507 fax: 708-248-6038   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10997; 2 Oct 92 18:13 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa10993; 2 Oct 92 18:13 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa21109; 2 Oct 92 18:18 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10976; 2 Oct 92 18:13 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa10972; 2 Oct 92 18:12 EDT Received: from SAFFRON.ACC.COM by NRI.Reston.VA.US id aa21090; 2 Oct 92 18:17 EDT Received: by saffron.acc.com (4.1/SMI-4.1) id AA08239; Fri, 2 Oct 92 15:13:14 PDT Date: Fri, 2 Oct 92 15:13:14 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Fred Baker Message-Id: <9210022213.AA08239@saffron.acc.com> To: clapp@ameris.center.il.ameritech.com Subject: Re: RFC 1294 version 2 Cc: iplpdn@NRI.Reston.VA.US >> So, remote bridges may not be connected by only point-to-point services. >> Does this break something in the Bridge MIB? No, you don't *have* to associate ports with circuits; you *can* (and normally do) associate ports with "interfaces". However, a bridge port carries the underlying assumption that when a system floods a multicast or point to point message, all of its neighbors (be they end systems, routers, or other bridges) will hear it. With SMDS, that's not *quite* true; multicasts are localized. Therefore, SMDS would want to be modelled as having a single physical interface at a very low level, and some number of virtual interfaces layered on top of that, each of which provides full mush multicast support for the systems connected to it. I suspect that many of these would in fact be point to point. But my comment didn't relate particularly to SMDS, it related to Frame Relay, which in the context wants to be able to be treated as a collection of point to point lines. In the case where a full mesh network is configured, you *could* treat the interface as a single bridge port. But if partial mesh networks are in view, I think you are stuck with the point to point model or some variation on the SMDS model above. Fred   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa11435; 2 Oct 92 19:20 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa11431; 2 Oct 92 19:20 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa22119; 2 Oct 92 19:25 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa11404; 2 Oct 92 19:20 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa11400; 2 Oct 92 19:20 EDT Received: from xap.xyplex.com by NRI.Reston.VA.US id aa22076; 2 Oct 92 19:24 EDT Received: by xap.xyplex.com id ; Fri, 2 Oct 92 19:23:29 -0500 Date: Fri, 2 Oct 92 19:23:29 -0500 X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "Jim A. Philippou" Message-Id: <9210030023.AA00429@xap.xyplex.com> To: iplpdn@NRI.Reston.VA.US Subject: Updated RFC 1294 If we are going to submit an update to RFC 1294 that we address the issue of negotating parameters like what protocols each partner can route/support as well as a negotation of MAC bridging. As far as the point-to-point verses multi-access issue for bridging, lets face it, frame relay can behave like either model. Since this is true, we must account for both views! Jim Philippou japhilippou@eng.xyplex.com   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa00909; 3 Oct 92 8:57 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa00905; 3 Oct 92 8:57 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa04786; 3 Oct 92 9:02 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa00890; 3 Oct 92 8:57 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa00886; 3 Oct 92 8:53 EDT Received: from datanet.tele.fi by NRI.Reston.VA.US id aa04712; 3 Oct 92 8:57 EDT Received: from datanet.tele.fi by datanet.tele.fi id <19400-0@datanet.tele.fi>; Sat, 3 Oct 1992 14:57:47 +0200 To: jas@proteon.com CC: cbrown@wellfleet.com, iplpdn@NRI.Reston.VA.US In-reply-to: <9210011806.AA14689@sonny.proteon.com> "jas@proteon.com" Subject: updates to 1294 - bridging Date: Sat, 3 Oct 1992 14:57:47 +0200 X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi Message-ID: <9210030857.aa04712@NRI.Reston.VA.US> we definitely need to support both models, ie., that an FR interface is considered as a set of point-to-point lines or one (sub)network. in case of bridging, no spanning tree is needed in the latter case within the mesh, since each bridge can directly talk to another. the same applies to ATM, SMDS, and X.25 interfaces. -- juha   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa00971; 3 Oct 92 9:08 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa00967; 3 Oct 92 9:08 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa04942; 3 Oct 92 9:13 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa00947; 3 Oct 92 9:08 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa00943; 3 Oct 92 9:08 EDT Received: from uwm.edu by NRI.Reston.VA.US id aa04932; 3 Oct 92 9:13 EDT Received: by uwm.edu; id AA00385; Sat, 3 Oct 92 08:13:11 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Sat, 3 Oct 92 08:06 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.5) id ; Sat, 3 Oct 92 07:57 CDT Message-Id: X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "George H. Clapp" Subject: Re: Updated RFC 1294 To: "Jim A. Philippou" Date: Sat, 3 Oct 92 7:57:37 CDT Cc: IPLPDN WG In-Reply-To: <9210030023.AA00429@xap.xyplex.com>; from "Jim A. Philippou" at Oct 2, 92 7:23 pm > If we are going to submit an update to RFC 1294 that we address the issue > of negotating parameters like what protocols each partner can route/support > as well as a negotation of MAC bridging. There is work underway to specify the means of negotiating parameters across FR PVCs. Keith Sklower has volunteered to be editor of the document. With luck, we will see a version before the November IETF meeting and spend some time going over the document during the meeting. George Clapp email: clapp@ameris.center.il.ameritech.com work: 708-248-6507 fax: 708-248-6038   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03242; 4 Oct 92 8:39 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03238; 4 Oct 92 8:39 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa22605; 4 Oct 92 8:43 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03227; 4 Oct 92 8:38 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03223; 4 Oct 92 8:37 EDT Received: from uwm.edu by NRI.Reston.VA.US id aa22588; 4 Oct 92 8:41 EDT Received: by uwm.edu; id AA08264; Sun, 4 Oct 92 07:42:07 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Sun, 4 Oct 92 06:57 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.5) id ; Sun, 4 Oct 92 06:47 CDT Message-Id: X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: "George H. Clapp" Subject: RFC 1294 version 2 To: IPLPDN WG Date: Sun, 4 Oct 92 6:47:26 CDT The section describing the encapsulation of bridged 802.5 MAC frames doesn't say anything about the optional use of a PAD byte as the Access Control field, while I believe that the Multiprotocol over AAL5 draft does. Would we want to copy the AAL5 text into the new version? George Clapp email: clapp@ameris.center.il.ameritech.com work: 708-248-6507 fax: 708-248-6038   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa11053; 5 Oct 92 14:11 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa11047; 5 Oct 92 14:11 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa20250; 5 Oct 92 14:16 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa10877; 5 Oct 92 14:11 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa10873; 5 Oct 92 14:07 EDT Received: from SPECTRUM.CMC.COM by NRI.Reston.VA.US id aa20070; 5 Oct 92 14:12 EDT Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA28687; Mon, 5 Oct 92 11:10:19 PDT Date: Mon, 5 Oct 92 11:10:19 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Frank Heath Message-Id: <9210051810.AA28687@Spectrum.CMC.COM> To: asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Subject: Setup Message/Framing IEFT IPLPDN/NIST ASI People In our discussions of IP over ISDN we have assumed that we could use the Low Layer Compatibility Information Element(LLC-IE, to avoid confusion with Logical Link Control(LLC)) where available to indicate the framing. I have attempted to code this up and have run into a problem. First the background, the LLC-IE has the following layout: 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 user information layer 2 protocol 6 ext layer 2 indent ----------------------------------------------------------- 1 Optional layer 2 protocol information 6a ext ----------------------------------------------------------- 1 1 1 user information layer 3 protocol 7 ext layer 3 indent ----------------------------------------------------------- 1 Optional layer 3 protocol information 7a ext ----------------------------------------------------------- Note both 6a and 7a are marked as "To be defined" in the CCITT specs and are not even mentioned in AT&T 41449(the Primary Rate spec). The definition of these fields: User information layer 2 protocol (octet 6) Bits 5 4 3 2 1 ------------- 0 0 0 0 1 Basic mode ISO 1745 0 0 0 1 0 CCITT Recommendation Q.921 (I.441) 0 0 1 1 0 CCITT Recommendation X.25 link level . . 0 1 1 0 0 LAN Logical link control(ISO 8802/2) User information layer 3 protocol (octet 7) Bits 5 4 3 2 1 ------------- 0 0 0 1 0 CCITT Recommendation Q.931 (I.451) 0 0 1 1 0 CCITT Recommendation X.25 packet level . . 0 1 0 0 0 ISO 8348 Connection oriented network service.. 0 1 0 0 1 ISO 8473 Connectionless service. Finally from RFC 1294 Known NLPIDs 0x80 SNAP 0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0xCC Internet IP Ok, if I want to run rfc1294 framing over ISDN what do I put in my setup message? I assume octet 6 will be 0xC2 (I.441). What do I put for octet 7? None of the NLPIDs shown above fit in 5 bits. ISO CLNP(NLPID 0x81) is 0xE9 in CCITT encodings. I am basically a UNIX driver hack, not a CCITT Q.931 guru, so does anybody have any suggestions? Frank S. Heath Software Manager, WAN Products Rockwell International CMC Network Products   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa13211; 5 Oct 92 16:28 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa13205; 5 Oct 92 16:28 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa23742; 5 Oct 92 16:33 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa13190; 5 Oct 92 16:28 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa13182; 5 Oct 92 16:27 EDT Received: from relay2.UU.NET by NRI.Reston.VA.US id aa23721; 5 Oct 92 16:32 EDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17217; Mon, 5 Oct 92 16:31:11 -0400 Received: from aria.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 162923.21037; Mon, 5 Oct 1992 16:29:23 EDT Received: from turkey.Ascend.COM by aria.ascend.com (4.0/SMI-4.0) id AA11293; Mon, 5 Oct 92 13:16:07 PDT Received: by turkey.Ascend.COM (4.1/SMI-4.1) id AA25380; Mon, 5 Oct 92 13:16:37 PDT Date: Mon, 5 Oct 92 13:16:37 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Marco S Hyman Message-Id: <9210052016.AA25380@turkey.Ascend.COM> To: heath@cmc.com Cc: asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US In-Reply-To: Frank Heath's message of Mon, 5 Oct 92 11:10:19 PDT <9210051810.AA28687@Spectrum.CMC.COM> Subject: Setup Message/Framing In our discussions of IP over ISDN we have assumed that we could use the Low Layer Compatibility Information Element(LLC-IE, to avoid confusion with Logical Link Control(LLC)) where available to indicate the framing. At this point in time you can not guarantee that LLC-IE will be transported from end-to-end given any two arbitrary end-points. The only way to be sure that you can inter-operate between any two arbitrary end points is to use some kind of in-band protocol, perhaps PPP. This may change in the future... // marc   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15103; 5 Oct 92 18:42 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15097; 5 Oct 92 18:42 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa27257; 5 Oct 92 18:47 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15086; 5 Oct 92 18:42 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15082; 5 Oct 92 18:41 EDT Received: from SPECTRUM.CMC.COM by NRI.Reston.VA.US id aa27239; 5 Oct 92 18:46 EDT Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA10233; Mon, 5 Oct 92 15:45:11 PDT Date: Mon, 5 Oct 92 15:45:11 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Frank Heath Message-Id: <9210052245.AA10233@Spectrum.CMC.COM> To: heath@cmc.com, marc@ascend.com Subject: Re: Setup Message/Framing Cc: asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Marc I am aware of the lack of end to end transport of LLC-IE in most cases. That is one reason I haven't looked at the coding in detail before. When it is available it does make life much easier. My message was it intended to explore the optimal case. Frank Heath CMC.COM   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15137; 5 Oct 92 18:44 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15131; 5 Oct 92 18:44 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa27296; 5 Oct 92 18:49 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15116; 5 Oct 92 18:44 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15112; 5 Oct 92 18:43 EDT Received: from motgate.mot.com by NRI.Reston.VA.US id aa27283; 5 Oct 92 18:48 EDT Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA13064 (5.65a+/IDA-1.4.2 for heath@cmc.com); Mon, 5 Oct 92 18:49:43 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA02999 (5.65a+/IDA-1.4.2 for iplpdn@nri.reston.va.us); Mon, 5 Oct 92 18:49:40 -0400 Message-Id: <9210052249.AA02999@dbg.dev.cdx.mot.com> To: Frank Heath Cc: asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Subject: Re: Setup Message/Framing In-Reply-To: Your message of Mon, 05 Oct 92 11:10:19 -0700. <9210051810.AA28687@Spectrum.CMC.COM> Date: Mon, 05 Oct 92 18:49:38 EDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com You may be working from an older version of Q.931. There is a relatively new codepoint, '01011B' in octet 7 for ISO TR 9577 (NLPID). I would code octet 6 as 'Core aspects of CCITT Recommendation Q.922', and octet 7 as 'ISO TR 9577'. All the codings for SNAP, OSI connectionless protocols and IP would be carried inband, and not in the signalling protocol in the scenario you describe. Incidentally, Marc is right, if you get a CALL PROCEEDING, PROGRESS, ALERTING or CONNECT message with Progress Indicator #8, 'Call is not end to end ISDN', or if you get cause #43 'Access Information Discarded' you know that your're talking to a degenerate ISDN, and that LLC has not gotten to the other end. I believe that LLC will not be discarded without notification. BTW, if you are talking to a basic rate interface, make sure that subscription parameters are set up so that LLC is allowed at both ends - Bellcore, in their wisdom, decided to make LLC delivery a subscription parameter, and the switch vendors have been doing what their customers ask for.   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15282; 5 Oct 92 19:09 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15276; 5 Oct 92 19:09 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa27714; 5 Oct 92 19:14 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15259; 5 Oct 92 19:09 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15255; 5 Oct 92 19:09 EDT Received: from SPECTRUM.CMC.COM by NRI.Reston.VA.US id aa27697; 5 Oct 92 19:14 EDT Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA11226; Mon, 5 Oct 92 16:12:34 PDT Date: Mon, 5 Oct 92 16:12:34 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Frank Heath Message-Id: <9210052312.AA11226@Spectrum.CMC.COM> To: dan@merlin.dev.cdx.mot.com, heath@cmc.com Subject: Re: Setup Message/Framing Cc: asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Dan > From dan@dbg.dev.cdx.mot.com Mon Oct 5 15:48:30 1992 > > You may be working from an older version of Q.931. There is a > relatively new codepoint, '01011B' in octet 7 for ISO TR 9577 (NLPID). > I would code octet 6 as 'Core aspects of CCITT Recommendation Q.922', > and octet 7 as 'ISO TR 9577'. All the codings for SNAP, OSI > connectionless protocols and IP would be carried inband, and not in the > signalling protocol in the scenario you describe. > My list of encoding is evidently out of date, what is the encoding for q.922 vs q.921? > Incidentally, Marc is right, if you get a CALL PROCEEDING, PROGRESS, I ment to say "where available" but got distracted. The negotiation issue has been flamed on several lists. Keith Sklower is working on the in band case, I've already spoken briefly on the phone with him. I'd like to keep this thread on the issue of call setup borne messages. Frank Heath CMC.COM   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15450; 5 Oct 92 19:32 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15444; 5 Oct 92 19:32 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa28119; 5 Oct 92 19:37 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa15406; 5 Oct 92 19:31 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa15402; 5 Oct 92 19:31 EDT Received: from vangogh.CS.Berkeley.EDU by NRI.Reston.VA.US id aa28083; 5 Oct 92 19:36 EDT Received: by vangogh.CS.Berkeley.EDU (5.113/2.7) id AA22249; Mon, 5 Oct 92 16:35:44 -0700 Date: Mon, 5 Oct 92 16:35:44 -0700 X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Keith Sklower Message-Id: <9210052335.AA22249@vangogh.CS.Berkeley.EDU> To: asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Subject: re: SSetup Message/Framing for IP over circuit switched ISDN Here are my recollections of the Discussion of encaspulating IP over ISDN from the last IETF: 1.) It was agreed that for the near term, we could not count on any information elements being reliably received by the called parties. 2.) It was important to make some recommendation of how to transmit IP datagrams over circuit switched ISDN in spite of this to promote interoperability. 3.) Where the LLC-IE could be exchanged reliably, it was assumed that this alone should be enough to decide easily which framing method was being employed (among a limited set of possibilities). 4.) Several people at the meeting expressed in very strong terms the desire not to be required to run a full PPP ``session'' for each each connection. (The argument was generally that there was a lot of ``state'' associated with each PPP connection, and if you had several PRI's coming into your router, this was onerous). 5.) It was generally agreed that you could not prevent consenting adults from running PPP between themselves over circuit ISDN, since that might be a very natural thing to do for existing workstations hooked up to an external terminal adapters via a serial synchronous interface. 6.) In the case where the LLC-IE is not available or trustworthy, I proposed a method where the callee simply waits for a correctly framed HDLC packet to be received an examines it to determine the desired framing. (details to follow). 7.) In the case where the LLC-IE was available, my recollection agrees with what Frank Heath said: If the desire was to run PPP, then there should be a code point assigned by CCITT for that purpose. None exists and we didn't know exactly who to ask, but somewhat volunteered to pursue that. If the desire was to run RFC1294 framing then the LLC was supposed to specify Q.922 for the 6th byte. (At least somebody at the meeting said that there was such a code point.) Frank suggests and I agree that we should probably also accept the code point for Q.921 (I.441). If somebody wanted to run IP over X.25, then they should use the rules for placing a call to an X.25 service provider. There were other code points called out in a contribution from NTT (of japan). 8.) Some of the foxes said they were willing to guard the henhouse, i.e. Cliff Frost and I (who prefer the RFC1294 encapsulation), volunteered to write up a draft recommending this as the preffered encapsulation, but making it clear that the others were not prohibited.   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02696; 6 Oct 92 10:09 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa02690; 6 Oct 92 10:09 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa07921; 6 Oct 92 10:09 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02602; 6 Oct 92 10:08 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa02597; 6 Oct 92 10:03 EDT Received: from motgate.mot.com by NRI.Reston.VA.US id aa07810; 6 Oct 92 10:03 EDT Received: from merlin.dev.cdx.mot.com by pobox.mot.com (4.1/SMI-4.0) id AA14836; Tue, 6 Oct 92 09:03:52 CDT Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA16424 (5.65a+/IDA-1.4.2 for heath@cmc.com); Tue, 6 Oct 92 10:05:18 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA03247 (5.65a+/IDA-1.4.2 for iplpdn@nri.reston.va.us); Tue, 6 Oct 92 10:05:16 -0400 Message-Id: <9210061405.AA03247@dbg.dev.cdx.mot.com> To: Frank Heath Cc: dan@merlin.dev.cdx.mot.com, asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Subject: Re: Setup Message/Framing In-Reply-To: Your message of Mon, 05 Oct 92 16:12:34 -0700. <9210052312.AA11226@Spectrum.CMC.COM> Date: Tue, 06 Oct 92 10:05:15 EDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com > My list of encoding is evidently out of date, what is the encoding for > q.922 vs q.921? Relevant codings are: Bits 5 4 3 2 1 --------- 0 0 0 0 1 CCITT Recommendation Q.921 0 1 1 0 0 LAN logical link control (ISO 8802/2) 0 1 1 1 0 CCITT Recommendation Q.922 0 1 1 1 1 Core Aspects of CCITT Recommendation Q.922 [aka frame relay]   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04854; 6 Oct 92 13:16 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa04848; 6 Oct 92 13:16 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa13043; 6 Oct 92 13:16 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04817; 6 Oct 92 13:16 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa04810; 6 Oct 92 13:14 EDT Received: from SPECTRUM.CMC.COM by NRI.Reston.VA.US id aa12951; 6 Oct 92 13:14 EDT Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA01414; Tue, 6 Oct 92 10:13:02 PDT Date: Tue, 6 Oct 92 10:13:02 PDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: Frank Heath Message-Id: <9210061713.AA01414@Spectrum.CMC.COM> To: dan@dbg.dev.cdx.mot.com Subject: Encoding values? Cc: asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Dan Is the value for Q.921 below correct? In all my specs it is 00010. Frank Heath CMC.COM --------------------------- Begin Included --------------------------------- From dan@dbg.dev.cdx.mot.com Tue Oct 6 07:03:18 1992 To: Frank Heath Cc: dan@merlin.dev.cdx.mot.com, asi_group@cplxsys.ncsl.nist.gov, iplpdn@nri.reston.va.us Subject: Re: Setup Message/Framing > My list of encoding is evidently out of date, what is the encoding for > q.922 vs q.921? Relevant codings are: Bits 5 4 3 2 1 --------- 0 0 0 0 1 CCITT Recommendation Q.921 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0 1 1 0 0 LAN logical link control (ISO 8802/2) 0 1 1 1 0 CCITT Recommendation Q.922 0 1 1 1 1 Core Aspects of CCITT Recommendation Q.922 [aka frame relay] --------------------------------End Included----------------------   Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04982; 6 Oct 92 13:22 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa04976; 6 Oct 92 13:22 EDT Received: from ietf.nri.reston.va.us by NRI.Reston.VA.US id aa13278; 6 Oct 92 13:22 EDT Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04959; 6 Oct 92 13:22 EDT Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa04955; 6 Oct 92 13:20 EDT Received: from motgate.mot.com by NRI.Reston.VA.US id aa13256; 6 Oct 92 13:20 EDT Received: from merlin.dev.cdx.mot.com by pobox.mot.com (4.1/SMI-4.0) id AA21766; Tue, 6 Oct 92 12:20:53 CDT Received: from dbg.dev.cdx.mot.com by merlin.dev.cdx.mot.com with SMTP id AA27445 (5.65a+/IDA-1.4.2 for heath@cmc.com); Tue, 6 Oct 92 13:22:21 -0400 Received: from localhost by dbg.dev.cdx.mot.com with SMTP id AA03329 (5.65a+/IDA-1.4.2 for iplpdn@nri.reston.va.us); Tue, 6 Oct 92 13:22:19 -0400 Message-Id: <9210061722.AA03329@dbg.dev.cdx.mot.com> To: Frank Heath Cc: dan@merlin.dev.cdx.mot.com, asi_group@cplxsys.ncsl.nist.gov, iplpdn@NRI.Reston.VA.US Subject: Re: Encoding values? In-Reply-To: Your message of Tue, 06 Oct 92 10:13:02 -0700. <9210061713.AA01414@Spectrum.CMC.COM> Date: Tue, 06 Oct 92 13:22:18 EDT X-Orig-Sender:iplpdn-request@IETF.NRI.Reston.VA.US Sender:ietf-archive-request@IETF.NRI.Reston.VA.US From: dan@merlin.dev.cdx.mot.com > Is the value for Q.921 below correct? In all my specs it is 00010. Ooops, that was a typo, it should be 00010. All the others are right.