< draft-ietf-ion-fr-update-04.txt		draft-ietf-ion-fr-update-05.txt >
	Network Working Group C. Brown		Network Working Group C. Brown
	INTERNET DRAFT Fore Systems, Inc.		INTERNET DRAFT Consultant
	Obsoletes: 1294, 1490 A. Malis		Obsoletes: 1294, 1490 A. Malis
	<draft-ietf-ion-fr-update-04.txt> Ascend Communications, Inc.		<draft-ietf-ion-fr-update-05.txt> Ascend Communications, Inc.
	March 11, 1998		July 23, 1998
	Expires September 10, 1998		Expires January 22, 1998
	Multiprotocol Interconnect over Frame Relay		Multiprotocol Interconnect over Frame Relay
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as ``work in progress.''		material or to cite them other than as ``work in progress.''
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, please check the
	``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow		``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
	Directories on ds.internic.net (US East Coast), nic.nordu.net		Directories on ftp.ietf.org (US East Coast), nic.nordu.net
	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific		(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
	Rim).		Rim).
	This draft specifies an IAB standards track protocol for the Internet		This draft specifies an IAB standards track protocol for the Internet
	community, and requests discussion and suggestions for improvements.		community, and requests discussion and suggestions for improvements.
	Please refer to the current edition of the "IAB Official Protocol		Please refer to the current edition of the "IAB Official Protocol
	Standards" for the standardization state and status of this protocol.		Standards" for the standardization state and status of this protocol.
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	Abstract		Abstract
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	d) The encapsulation for Source Routing BPDUs was added, and the		d) The encapsulation for Source Routing BPDUs was added, and the
	lists in Appendix A were augmented.		lists in Appendix A were augmented.
	e) The use of canonical and non-canonical MAC destination addresses		e) The use of canonical and non-canonical MAC destination addresses
	in the bridging encapsulations was clarified.		in the bridging encapsulations was clarified.
	f) Explicit support for multiple IP addresses mapped to a single		f) Explicit support for multiple IP addresses mapped to a single
	Frame Relay DLCI.		Frame Relay DLCI.
	g) A new security section was added.		g) The Inverse ARP description was moved to the Inverse ARP
			specification [11].
			h) A new security section was added.
	1. Conventions and Acronyms		1. Conventions and Acronyms
	The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this		SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
	document, are to be interpreted as described in [16].		document, are to be interpreted as described in [16].
	All drawings in this document are drawn with the left-most bit as the		All drawings in this document are drawn with the left-most bit as the
	high order bit for transmission. For example, the drawings might be		high order bit for transmission. For example, the drawings might be
	labeled as:		labeled as:
	skipping to change at page 8, line 39 ¶		skipping to change at page 8, line 39 ¶
	+---------------+---------------+		+---------------+---------------+
	| Control 0x03 | NLPID 0xCC |		| Control 0x03 | NLPID 0xCC |
	+---------------+---------------+		+---------------+---------------+
	| IP Datagram |		| IP Datagram |
	+-------------------------------+		+-------------------------------+
	| FCS |		| FCS |
	+-------------------------------+		+-------------------------------+
	4.2. Bridged Frames		4.2. Bridged Frames
	The second type of Frame Relay traffic is bridged packets. These		The second type of Frame Relay traffic is bridged packets. These
	packets are encapsulated using the NLPID value of 0x80 indicating		packets are encapsulated using the NLPID value of 0x80 indicating
	SNAP. As with other SNAP encapsulated protocols, there will be one		SNAP. As with other SNAP encapsulated protocols, there will be one
	pad octet to align the data portion of the encapsulated frame. The		pad octet to align the data portion of the encapsulated frame. The
	SNAP header which follows the NLPID identifies the format of the		SNAP header which follows the NLPID identifies the format of the
	bridged packet. The OUI value used for this encapsulation is the		bridged packet. The OUI value used for this encapsulation is the
	802.1 organization code 0x00-80-C2. The PID portion of the SNAP		802.1 organization code 0x00-80-C2. The PID portion of the SNAP
	header (the two bytes immediately following the OUI) specifies the		header (the two bytes immediately following the OUI) specifies the
	form of the MAC header, which immediately follows the SNAP header.		form of the MAC header, which immediately follows the SNAP header.
	Additionally, the PID indicates whether the original FCS is preserved		Additionally, the PID indicates whether the original FCS is preserved
	within the bridged frame.		within the bridged frame.
	Following the precedent in RFC 1638 [4], non-canonical MAC destination		Following the precedent in RFC 1638 [4], non-canonical MAC destination
	addresses are used for encapsulated IEEE 802.5 and FDDI frames, and		addresses are used for encapsulated IEEE 802.5 and FDDI frames, and
	canonical MAC destination addresses are used for the remaining		canonical MAC destination addresses are used for the remaining
	encapsulations defined in this section.		encapsulations defined in this section.
	The 802.1 organization has reserved the following values to be used		The 802.1 organization has reserved the following values to be used
	with Frame Relay:		with Frame Relay:
	PID Values for OUI 0x00-80-C2		PID Values for OUI 0x00-80-C2
	with preserved FCS w/o preserved FCS Media		with preserved FCS w/o preserved FCS Media
	------------------ ----------------- ----------------		------------------ ----------------- ----------------
	0x00-01 0x00-07 802.3/Ethernet		0x00-01 0x00-07 802.3/Ethernet
	0x00-02 0x00-08 802.4		0x00-02 0x00-08 802.4
	0x00-03 0x00-09 802.5		0x00-03 0x00-09 802.5
	0x00-04 0x00-0A FDDI		0x00-04 0x00-0A FDDI
	0x00-0B 802.6		0x00-0B 802.6
	skipping to change at page 16, line 51 ¶		skipping to change at page 16, line 51 ¶
	| 0x01 | PL = 1		| 0x01 | PL = 1
	+---------------+		+---------------+
	| 0x00 |		| 0x00 |
	+---------------+		+---------------+
	| FCS | (2 octets)		| FCS | (2 octets)
	| |		| |
	+---------------+		+---------------+
	6. Address Resolution for PVCs		6. Address Resolution for PVCs
	This document only describes address resolution as it applies to PVCs.		This document only describes address resolution as it applies to PVCs.
	SVC operation will be discussed in future documents.		SVC operation will be discussed in future documents.
	There are situations in which a Frame Relay station may wish to		There are situations in which a Frame Relay station may wish to
	dynamically resolve a protocol address over PVCs. This may be		dynamically resolve a protocol address over PVCs. This may be
	accomplished using the standard Address Resolution Protocol (ARP) [6]		accomplished using the standard Address Resolution Protocol (ARP) [6]
	encapsulated within a SNAP encoded Frame Relay packet as follows:		encapsulated within a SNAP encoded Frame Relay packet as follows:
	+-----------------------+-----------------------+		+-----------------------+-----------------------+
	| Q.922 Address |		| Q.922 Address |
	+-----------------------+-----------------------+		+-----------------------+-----------------------+
	| Control (UI) 0x03 | pad 0x00 |		| Control (UI) 0x03 | pad 0x00 |
	+-----------------------+-----------------------+		+-----------------------+-----------------------+
	| NLPID 0x80 | | SNAP Header		| NLPID 0x80 | | SNAP Header
	+-----------------------+ OUI 0x00-00-00 + Indicating		+-----------------------+ OUI 0x00-00-00 + Indicating
	| | ARP		| | ARP
	+-----------------------+-----------------------+		+-----------------------+-----------------------+
	skipping to change at page 19, line 22 ¶		skipping to change at page 18, line 47 ¶
	( | )		( | )
	( | ) <---Frame Relay		( | ) <---Frame Relay
	~~~~~~~~~~~~~~~~ network		~~~~~~~~~~~~~~~~ network
	80		80
	|		|
	+-----+		+-----+
	| |		| |
	| C |		| C |
	| |		| |
	+-----+		+-----+
	Figure 1		Figure 1
	Lines between stations represent data link connections (DLCs).		Lines between stations represent data link connections (DLCs).
	The numbers indicate the local DLCI associated with each		The numbers indicate the local DLCI associated with each
	connection.		connection.
	DLCI to Q.922 Address Table for Figure 1		DLCI to Q.922 Address Table for Figure 1
	DLCI (decimal) Q.922 address (hex)		DLCI (decimal) Q.922 address (hex)
	50 0x0C21		50 0x0C21
	60 0x0CC1		60 0x0CC1
	70 0x1061		70 0x1061
	80 0x1401		80 0x1401
	For authoritative description of the correlation between DLCI and		For authoritative description of the correlation between DLCI and
	Q.922 [1] addresses, the reader should consult Q.922. A summary		Q.922 [1] addresses, the reader should consult that specification.
	of the correlation is included here for convenience. The		A summary of the correlation is included here for convenience. The
	translation between DLCI and Q.922 address is based on a two byte		translation between DLCI and Q.922 address is based on a two byte
	address length using the Q.922 encoding format. The format is:		address length using the Q.922 encoding format. The format is:
	8 7 6 5 4 3 2 1		8 7 6 5 4 3 2 1
	+------------------------+---+--+		+------------------------+---+--+
	| DLCI (high order) |c/r|ea|		| DLCI (high order) |C/R|EA|
	+--------------+----+----+---+--+		+--------------+----+----+---+--+
	| DLCI (lower) |FECN|BECN|DE |EA|		| DLCI (lower) |FECN|BECN|DE |EA|
	+--------------+----+----+---+--+		+--------------+----+----+---+--+
	For ARP and its variants, the FECN, BECN, C/R and DE bits are		For ARP and its variants, the FECN, BECN, C/R and DE bits are
	assumed to be 0.		assumed to be 0.
	When an ARP message reaches a destination, all hardware addresses		When an ARP message reaches a destination, all hardware addresses
	will be invalid. The address found in the frame header will,		will be invalid. The address found in the frame header will,
	however, be correct. Though it does violate the purity of layering,		however, be correct. Though it does violate the purity of layering,
	skipping to change at page 21, line 5 ¶		skipping to change at page 20, line 29 ¶
	then fills in the source addresses with its addresses. In this case,		then fills in the source addresses with its addresses. In this case,
	the ARP response would be:		the ARP response would be:
	ARP response from B		ARP response from B
	ar$op 2 (response)		ar$op 2 (response)
	ar$sha unknown		ar$sha unknown
	ar$spa pB		ar$spa pB
	ar$tha 0x1061 (DLCI 70)		ar$tha 0x1061 (DLCI 70)
	ar$tpa pA		ar$tpa pA
	Again, the source hardware address is unknown and when the request is		Again, the source hardware address is unknown and when the response
	received, station A will extract the address from the Frame Relay		is received, station A will extract the address from the Frame Relay
	header and place it in the source hardware address field. Therefore,		header and place it in the source hardware address field. Therefore,
	the response will become:		the response will become:
	ARP response from B as modified by A		ARP response from B as modified by A
	ar$op 2 (response)		ar$op 2 (response)
	ar$sha 0x0C21 (DLCI 50)		ar$sha 0x0C21 (DLCI 50)
	ar$spa pB		ar$spa pB
	ar$tha 0x1061 (DLCI 70)		ar$tha 0x1061 (DLCI 70)
	ar$tpa pA		ar$tpa pA
	Station A will now correctly recognize station B having protocol		Station A will now correctly recognize station B having protocol
	address pB associated with Q.922 address 0x0C21 (DLCI 50).		address pB associated with Q.922 address 0x0C21 (DLCI 50).
	Reverse ARP (RARP) [8] will work in exactly the same way. Still		Reverse ARP (RARP) [8] works in exactly the same way. Still using
	using figure 1, if we assume station C is an address server, the		figure 1, if we assume station C is an address server, the following
	following RARP exchanges will occur:		RARP exchanges will occur:
	RARP request from A RARP request as modified by C		RARP request from A RARP request as modified by C
	ar$op 3 (RARP request) ar$op 3 (RARP request)		ar$op 3 (RARP request) ar$op 3 (RARP request)
	ar$sha unknown ar$sha 0x1401 (DLCI 80)		ar$sha unknown ar$sha 0x1401 (DLCI 80)
	ar$spa undefined ar$spa undefined		ar$spa undefined ar$spa undefined
	ar$tha 0x0CC1 (DLCI 60) ar$tha 0x0CC1 (DLCI 60)		ar$tha 0x0CC1 (DLCI 60) ar$tha 0x0CC1 (DLCI 60)
	ar$tpa pC ar$tpa pC		ar$tpa pC ar$tpa pC
	Station C will then look up the protocol address corresponding to		Station C will then look up the protocol address corresponding to
	Q.922 address 0x1401 (DLCI 80) and send the RARP response.		Q.922 address 0x1401 (DLCI 80) and send the RARP response.
	skipping to change at page 21, line 48 ¶		skipping to change at page 21, line 24 ¶
	ar$tha 0x1401 (DLCI 80) ar$tha 0x1401 (DLCI 80)		ar$tha 0x1401 (DLCI 80) ar$tha 0x1401 (DLCI 80)
	ar$tpa pA ar$tpa pA		ar$tpa pA ar$tpa pA
	This means that the Frame Relay interface must only intervene in the		This means that the Frame Relay interface must only intervene in the
	processing of incoming packets.		processing of incoming packets.
	In the absence of suitable multicast, ARP may still be implemented.		In the absence of suitable multicast, ARP may still be implemented.
	To do this, the end station simply sends a copy of the ARP request		To do this, the end station simply sends a copy of the ARP request
	through each relevant DLC, thereby simulating a broadcast.		through each relevant DLC, thereby simulating a broadcast.
	The use of multicast addresses in a Frame Relay environment is		The use of multicast addresses in a Frame Relay environment, as
	presently under study by Frame Relay providers. At such time that		specified by [19], is presently being considered by Frame Relay
	the issues surrounding multicasting are resolved, multicast		providers. In time, multicast addressing may become useful in
	addressing may become useful in sending ARP requests and other		sending ARP requests and other "broadcast" messages.
	"broadcast" messages.
	Because of the inefficiencies of broadcasting in a Frame Relay		Because of the inefficiencies of emulating broadcasting in a Frame
	environment, a new address resolution variation was developed. It is		Relay environment, a new address resolution variation was developed.
	called Inverse ARP [11] and describes a method for resolving a		It is called Inverse ARP [11] and describes a method for resolving a
	protocol address when the hardware address is already known. In		protocol address when the hardware address is already known. In
	Frame Relay's case, the known hardware address is the DLCI. Using		Frame Relay's case, the known hardware address is the DLCI. Support
	Inverse ARP for Frame Relay follows the same pattern as ARP and RARP		for Inverse ARP is not required to implement this specification, but
	use. That is the source hardware address is inserted at the		it has proven useful for Frame Relay interface autoconfiguration.
	receiving station.		See [11] for its description and an example of its use with Frame
			Relay.
	In our example, station A may use Inverse ARP to discover the
	protocol address of the station associated with its DLCI 50. The
	Inverse ARP request would be as follows:
	InARP Request from A (DLCI 50)
	ar$op 8 (InARP request)
	ar$sha unknown
	ar$spa pA
	ar$tha 0x0C21 (DLCI 50)
	ar$tpa unknown
	When Station B receives this packet, it will modify the source
	hardware address with the Q.922 address from the Frame Relay header.
	This way, the InARP request from A will become:
	ar$op 8 (InARP request)
	ar$sha 0x1061
	ar$spa pA
	ar$tha 0x0C21
	ar$tpa unknown.
	Station B will format an Inverse ARP response and send it to station
	A as it would for any ARP message.
	Stations must be able to map more than one IP address in the same IP		Stations must be able to map more than one IP address in the same IP
	subnet (CIDR address prefix) to a particular DLCI on a Frame Relay		subnet (CIDR address prefix) to a particular DLCI on a Frame Relay
	interface. This need arises from applications such as remote access,		interface. This need arises from applications such as remote access,
	where servers must act as ARP proxies for many dial-in clients, each		where servers must act as ARP proxies for many dial-in clients, each
	assigned a unique IP address while sharing bandwidth on the same DLC.		assigned a unique IP address while sharing bandwidth on the same DLC.
	The dynamic nature of such applications result in frequent address		The dynamic nature of such applications result in frequent address
	association changes with no affect on the DLC's status as reported by		association changes with no affect on the DLC's status as reported by
	Frame Relay PVC Status Signaling.		Frame Relay PVC Status Signaling.
	skipping to change at page 32, line 42 ¶		skipping to change at page 31, line 42 ¶
	| Note 4 |		| Note 4 |
	+-------------------------------+		+-------------------------------+
	| FCS |		| FCS |
	+-------------------------------+		+-------------------------------+
	Note 4: First octet of 8208 packet also identifies the		Note 4: First octet of 8208 packet also identifies the
	NLPID which is "..10....".		NLPID which is "..10....".
	12. Security Considerations		12. Security Considerations
	This document contains two major functional specifications:		This document defines mechanisms for identifying the multiprotocol
	mechanisms for identifying the multiprotocol encapsulation of		encapsulation of datagrams over Frame Relay. There is obviously an
	datagrams, and the specification of how ARP and InARP are used over		element in trust in any encapsulation protocol - a receiver must
	Frame Relay.		trust that the sender has correctly identified the protocol being
			encapsulated. In general, there is no way for a receiver to try to
	For the former functionality, there is obviously an element in trust		ascertain that the sender did indeed use the proper protocol
	in any encapsulation protocol - a receiver must trust that the sender		identification, nor would this be desired functionality.
	has correctly identified the protocol being encapsulated. In
	general, there is no way for a receiver to try to ascertain that the
	sender did indeed use the proper protocol identification, nor would
	this be desired functionality.
	For the latter functionality, this document specifies the use of the		It also specifies the use of ARP and RARP with Frame Relay, and is
	ARP family of protocols with Frame Relay, and is subject to the same		subject to the same security constraints that affect ARP and similar
	security constraints that affect ARP and similar address resolution		address resolution protocols. Because authentication is not a part
	protocols. Because authentication is not a part of ARP, there are		of ARP, there are known security issues relating to its use (e.g.,
	known security issues relating to its use (e.g., host impersonation).		host impersonation). No additional security mechanisms have been
	No additional security mechanisms have been added to the ARP family		added to ARP or RARP for use with Frame Relay networks.
	of protocols for use with Frame Relay networks.
	13. References		13. References
	[1] International Telecommunication Union, "ISDN Data Link Layer		[1] International Telecommunication Union, "ISDN Data Link Layer
	Specification for Frame Mode Bearer Services", ITU-T		Specification for Frame Mode Bearer Services", ITU-T
	Recommendation Q.922, 1992.		Recommendation Q.922, 1992.
	[2] International Telecommunication Union, "Signalling Specifications		[2] International Telecommunication Union, "Signalling Specifications
	for Frame Mode Switched and Permanent Virtual Connection Control		for Frame Mode Switched and Permanent Virtual Connection Control
	and Status Monitoring", ITU-T Recommendation Q.933, 1995.		and Status Monitoring", ITU-T Recommendation Q.933, 1995.
	skipping to change at page 33, line 36 ¶		skipping to change at page 32, line 31 ¶
	Exchange between systems - Protocol Identification in the Network		Exchange between systems - Protocol Identification in the Network
	Layer, ISO/IEC TR 9577: 1992.		Layer, ISO/IEC TR 9577: 1992.
	[4] F. Baker, R. Bowen, "PPP Bridging Control Protocol (BCP)", RFC		[4] F. Baker, R. Bowen, "PPP Bridging Control Protocol (BCP)", RFC
	1638, ACC, June 1994.		1638, ACC, June 1994.
	[5] International Standard, Information Processing Systems - Local		[5] International Standard, Information Processing Systems - Local
	Area Networks - Logical Link Control, ISO 8802-2, ANSI/IEEE,		Area Networks - Logical Link Control, ISO 8802-2, ANSI/IEEE,
	Second Edition, 1994-12-30.		Second Edition, 1994-12-30.
	[6] Plummer, D., "An Ethernet Address Resolution Protocol - or -		[6] D. Plummer, "An Ethernet Address Resolution Protocol - or -
	Converting Network Protocol Addresses to 48.bit Ethernet Address		Converting Network Protocol Addresses to 48.bit Ethernet Address
	for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,		for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT,
	November 1982.		November 1982.
	[7] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,		[7] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, RFC 1700,
	USC/Information Sciences Institute, October 1994		USC/Information Sciences Institute, October 1994
	[8] Finlayson, R., Mann, R., Mogul, J., and M. Theimer, "A Reverse		[8] R. Finlayson, R. Mann, J. Mogul, M. Theimer, "A Reverse Address
	Address Resolution Protocol", STD 38, RFC 903, Stanford		Resolution Protocol", STD 38, RFC 903, Stanford University, June
	University, June 1984.		1984.
	[9] Postel, J. and Reynolds, J., "A Standard for the Transmission of		[9] J. Postel, J. Reynolds, "A Standard for the Transmission of IP
	IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information		Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
	Sciences Institute, February 1988.		Sciences Institute, February 1988.
	[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:		[10] IEEE, "IEEE Standard for Local and Metropolitan Area Networks:
	Overview and architecture", IEEE Standard 802-1990.		Overview and architecture", IEEE Standard 802-1990.
	[11] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol",		[11] T. Bradley, C. Brown, A. Malis, "Inverse Address Resolution
	RFC 1293, Wellfleet Communications, Inc., January 1992.		Protocol", RFC TBD, August 1998.
	[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media		[12] IEEE, "IEEE Standard for Local and Metropolitan Networks: Media
	Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.		Access Control (MAC) Bridges", IEEE Standard 802.1D-1990.
	[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media		[13] ISO/IEC 15802-5 : 1998 (IEEE Standard 802.1G), Remote Media
	Access Control (MAC) Bridging, March 12, 1997.		Access Control (MAC) Bridging, March 12, 1997.
	[14] Frame Relay Forum, "Data Compression Over Frame Relay		[14] Frame Relay Forum, "Data Compression Over Frame Relay
	Implementation Agreement", FRF.9, January 22, 1996.		Implementation Agreement", FRF.9, January 22, 1996.
	[15] Frame Relay Forum, "Multiprotocol Encapsulation Implementation		[15] Frame Relay Forum, "Multiprotocol Encapsulation Implementation
	Agreement", FRF.3.1, June 22, 1995.		Agreement", FRF.3.1, June 22, 1995.
	[16] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[16] S. Bradner, "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, Harvard University, March 1997.		Levels", BCP 14, RFC 2119, Harvard University, March 1997.
	[17] Simpson, W., "PPP in Frame Relay", RFC 1973, Daydreamer, June		[17] W. Simpson, "PPP in Frame Relay", RFC 1973, Daydreamer, June
	1996.		1996.
	[18] Frame Relay Forum, "Frame Relay Fragmentation Implementation		[18] Frame Relay Forum, "Frame Relay Fragmentation Implementation
	Agreement", FRF.12, December 1997.		Agreement", FRF.12, December 1997.
			[19] Frame Relay Forum, "Frame Relay PVC Multicast Service and
			Protocol Implementation Agreement", FRF.7, October 21, 1994.
	14. Authors' Addresses		14. Authors' Addresses
	Caralyn Brown		Caralyn Brown
	FORE Systems, Inc.		Consultant
	1 Corporate Drive		Email: cbrown@juno.com
	Andover, MA 01810
	Phone: (978) 689-2400 x133
	Email: cbrown@fore.com
	Andrew Malis		Andrew Malis
	Ascend Communications, Inc.		Ascend Communications, Inc.
	1 Robbins Road		1 Robbins Road
	Westford, MA 01886		Westford, MA 01886
	Phone: (978) 952-7414		Phone: (978) 952-7414
	Email: malis@ascend.com		Email: malis@ascend.com
End of changes. 28 change blocks.
	107 lines changed or deleted		82 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/