< draft-shore-nls-tl-04.txt		draft-shore-nls-tl-05.txt >
	Network Working Group M. Shore		Network Working Group M. Shore
	Internet-Draft D. McGrew		Internet-Draft D. McGrew
	Intended status: Standards Track K. Biswas		Intended status: Standards Track K. Biswas
	Expires: November 10, 2007 Cisco Systems		Expires: December 15, 2007 Cisco Systems
	May 9, 2007		June 13, 2007
	Network-Layer Signaling: Transport Layer		Network-Layer Signaling: Transport Layer
	draft-shore-nls-tl-04.txt		draft-shore-nls-tl-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 10, 2007.		This Internet-Draft will expire on December 15, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The RSVP model for communicating requests to network devices along a		The RSVP model for communicating requests to network devices along a
	datapath has proven useful for a variety of applications beyond what		datapath has proven useful for a variety of applications beyond what
	the protocol designers envisioned, and while the architectural model		the protocol designers envisioned, and while the architectural model
	generalizes well the protocol itself has a number of features that		generalizes well the protocol itself has a number of features that
	limit its applicability to applications other than IntServ. Network		limit its applicability to applications other than IntServ. Network
	Layer Signaling is a modernized version that, among other things, is		Layer Signaling uses the RSVP on-path communication model to carry
	based on a "two-layer" architecture that divides protocol function		requests to middleboxes and other network devices. It is based on a
	into transport and application. This document describes the		"two-layer" architecture that divides protocol function into
	transport protocol.		transport and application. This document describes the transport
			protocol.
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 6		2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 6
	3. NLS-TL Messages . . . . . . . . . . . . . . . . . . . . . . . 7		3. NLS-TL Messages . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Message Processing Overview . . . . . . . . . . . . . . . 7		3.1. Message Processing Overview . . . . . . . . . . . . . . . 7
	3.1.1. Congestion Considerations . . . . . . . . . . . . . . 8		3.1.1. Congestion Considerations . . . . . . . . . . . . . . 8
	3.2. NAT Traversal Support . . . . . . . . . . . . . . . . . . 8		3.2. NAT Traversal Support . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	RSVP is based on a "path-coupled" signaling model, in which signaling		RSVP is based on a "path-coupled" signaling model, in which signaling
	messages between two endpoints follow a path that is tied to the data		messages between two endpoints follow a path that is tied to the data
	path between the same endpoints, and in which the signaling messages		path between the same endpoints, and in which the signaling messages
	are intercepted and interpreted by RSVP-capable routers along the		are intercepted and interpreted by RSVP-capable routers along the
	path. While RSVP was originally designed to support QoS signaling		path. While RSVP was originally designed to support QoS signaling
	for Integrated Services [rfc1633], this model has proven to		for Integrated Services [RFC1633], this model has proven to
	generalize to other problems extremely well. Some of these problems		generalize to other problems extremely well. Some of these problems
	include topology discovery, QoS signaling, communicating with		include topology discover, communicating with firewalls and NATs,
	firewalls and NATs, discovery of IPSec tunnel endpoints, test		discovery of IPSec tunnel endpoints, test applications, diagnostic
	applications, and so on.		triggers, and so on.
	This document describes the core protocol for an updated version of		This document describes the core protocol for a generalized on-path
	RSVP -- one that is not tied directly to IntServ and in which the		request protocol that is being used today to carry topology discovery
	protocol machinery itself is sufficiently generalized to be able to		and other requests -- one that is not tied directly to IntServ and in
	support a variety of applications (this protocol is referred to as		which the protocol machinery itself is sufficiently generalized to be
	"Network Layer Signaling", or "NLS"). What this means in practice is		able to support a variety of applications (this protocol is referred
	that there will be different signaling applications, all of which		to as "Network Layer Signaling", or "NLS"). What this means in
	share a base NLS transport layer. This architecture is based on work		practice is that there will be different signaling applications, all
	done by Bob Braden and Bob Lindell, and described in [braden]. It is		of which share a base NLS transport layer. This architecture is
	also similar to the concepts used in secsh, where authentication and		based on work done by Bob Braden and Bob Lindell, and described in
	connection protocols run on top of a secsh transport protocol (see		[braden]. It is also similar to the concepts used in secsh, where
	[rfc4251] for details).		authentication and connection protocols run on top of a secsh
			transport protocol (see [RFC4251] for details).
	The protocol machinery was originally based somewhat on RSVP		The protocol machinery was originally based somewhat on RSVP
	[RFC2205] without refresh overhead reduction extensions [rfc2961],		[RFC2205] without refresh overhead reduction extensions [RFC2961],
	but in the process of generalization has lost many of the features		but in the process of generalization has lost many of the features
	that define RSVP, such as necessary receiver-oriented reservations		that define RSVP, such as necessary receiver-oriented reservations
	and processing requirements at each node.		and processing requirements at each node.
	NLS differs from RSVP in several important ways. One of the most		NLS differs from RSVP in several important ways. One of the most
	significant of these is that the transport protocol described in this		significant of these is that the transport protocol described in this
	document (NLS-TL) does not itself trigger reservations in network		document (NLS-TL) does not itself trigger reservations in network
	nodes. The NLS application will do that, and, indeed, some NLS		nodes. Reservations will be installed and managed by NLS
	applications may not carry reservation requests at all (discovery		applications, however some NLS applcations may not carry reservation
	protocols, for example). Because of this NLS-TL does not support		requests at all (discovery protocols, for example). Because of this
	reservation styles (those would be also be attributes of an		NLS-TL does not support reservation styles (those would be also be
	application). Another significant difference is that that		attributes of an application). Another significant difference is
	reservations may be installed by a NLS application in either a		that that reservations may be installed by a NLS application in
	forward (from the sender toward the receiver) or backward (from the		either a forward (from the sender toward the receiver) or backward
	receiver toward the sender) direction -- this is application-		(from the receiver toward the sender) direction -- this is
	specific.		application-specific.
	Other possibly significant differences include that NAT traversal		Other possibly significant differences include that NAT traversal
	support is integrated into the message transport, and that NLS allows		support is integrated into the message transport, and that NLS allows
	an application to install reservations for paths that are		an application to install reservations for paths that are
	bidirectional and asymmetric.		bidirectional and asymmetric.
			NLS also shares some basic design features with NSIS [RFC4080], which
			is another path-coupled protocol. However, unlike NLS, the NSIS
			transport provides reliable delivery of request messages (in NLS this
			is left to the application rather than the transport layer), and NLS
			was not designed with QoS signaling support in mind.
			The NLS Transport Layer is being used by PacketCable and the ITU-T to
			carry topology discovery requests, in a protocol called "Control
			Point Discovery" (CPD).
	2.1. Transport layer		2.1. Transport layer
	This document describes the transport layer. The NLS transport layer		This document describes the transport layer. The NLS transport layer
	is as simple as we could make it, supporting two basic functions:		is as simple as we could make it, supporting two basic functions:
	routing and NAT traversal. The sources of complexity in signaling		routing and NAT traversal. The sources of complexity in signaling
	protocols tend to be the signaling applications themselves. Those		protocols tend to be the signaling applications themselves. Those
	applications have varying performance and reliability requirements,		applications have varying performance and reliability requirements,
	and consequently we feel that application-specific functions belong		and consequently we feel that application-specific functions belong
	in the application layer.		in the application layer.
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 20 ¶
	interface that is expected to terminate the path along which		interface that is expected to terminate the path along which
	signaling is expected to be sent. It may be a application peer host		signaling is expected to be sent. It may be a application peer host
	or terminal, or it may be a proxy. If the message is being sent hop-		or terminal, or it may be a proxy. If the message is being sent hop-
	by-hop the destination address in the IP header is the address of the		by-hop the destination address in the IP header is the address of the
	device interface that is the next hop along the path. That address		device interface that is the next hop along the path. That address
	will have been discovered either through a separate routing process		will have been discovered either through a separate routing process
	or through RSVP-style soft-state messaging.		or through RSVP-style soft-state messaging.
	NLS-TL messages are UDP-encapsulated and sent on UDP port 7549. They		NLS-TL messages are UDP-encapsulated and sent on UDP port 7549. They
	MAY be sent with the router alert bit set in IPv4 headers or with the		MAY be sent with the router alert bit set in IPv4 headers or with the
	IPv6 router alert option [rfc2711], but it is not required. If the		IPv6 router alert option [RFC2711], but it is not required. If the
	message is end-to-end and needs route discovery and pinning, the		message is end-to-end and needs route discovery and pinning, the
	BUILD-ROUTE bit in the NLS-TL flags header MUST be set to 1 and the		BUILD-ROUTE bit in the NLS-TL flags header MUST be set to 1 and the
	HOP-BY-HOP bit MUST be set to 0. If the message is being routed hop-		HOP-BY-HOP bit MUST be set to 0. If the message is being routed hop-
	by-hop, the HOP-BY-HOP bit MUST be set to 1 and the BUILT-ROUTE bit		by-hop, the HOP-BY-HOP bit MUST be set to 1 and the BUILT-ROUTE bit
	MUST be set to 0. (Note that there may be applications in which both		MUST be set to 0. (Note that there may be applications in which both
	the HOP-BY-HOP and the BUILD- ROUTE bit will be set to 0.)		the HOP-BY-HOP and the BUILD- ROUTE bit will be set to 0.)
	If the NLS application wishes to support bidirectional reservations,		If the NLS application wishes to support bidirectional reservations,
	the BIDIRECTIONAL flag must be set to 1, the BUILD-ROUTE flag should		the BIDIRECTIONAL flag must be set to 1, the BUILD-ROUTE flag should
	be set to 1, and the HOP-BY-HOP flag should be set to 0, at least in		be set to 1, and the HOP-BY-HOP flag should be set to 0, at least in
	skipping to change at page 44, line 28 ¶		skipping to change at page 44, line 28 ¶
	Extensions", RFC 2961, April 2001.		Extensions", RFC 2961, April 2001.
	[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The		[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
	Group Domain of Interpretation", RFC 3547, July 2003.		Group Domain of Interpretation", RFC 3547, July 2003.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	15.2. Informative References		15.2. Informative References
	[braden] Braden, R. and R. Lindell, "A Two-Level Architecture for		[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
	Internet Signaling", draft-braden-2level-signaling-01.txt
	(work in progress), November 2002.
	[rfc1633] Braden, R., Clark, D., and S. Shenker, "Integrated
	Services in the Internet Architecture: an Overview",		Services in the Internet Architecture: an Overview",
	RFC 1633, June 1994.		RFC 1633, June 1994.
	[rfc2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",		[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
	October 1999.		RFC 2711, October 1999.
	[rfc2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,		[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
	and S. Molendini, "RSVP Refresh Overhead Reduction		Bosch, "Next Steps in Signaling (NSIS): Framework",
	Extensions", RFC 2961, April 2001.		RFC 4080, June 2005.
	[rfc4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Protocol Architecture", RFC 4251, January 2006.		Protocol Architecture", RFC 4251, January 2006.
			[braden] Braden, R. and R. Lindell, "A Two-Level Architecture for
			Internet Signaling", draft-braden-2level-signaling-01.txt
			(work in progress), November 2002.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors would like to express their gratitude to Jan Vilhuber,		The authors would like to express their gratitude to Jan Vilhuber,
	Senthil Sivakumar, Bill Foster, and Dan Wing for their careful review		Senthil Sivakumar, Bill Foster, and Dan Wing for their careful review
	and feedback. Special thanks to Jan for his text on challenge/		and feedback. Special thanks to Jan for his text on challenge/
	response calculations, and to Rajesh Karnik and Lisa Fang for their		response calculations, and to Rajesh Karnik and Lisa Fang for their
	help in clarifying the text describing the authentication exchange.		help in clarifying the text describing the authentication exchange.
	Authors' Addresses		Authors' Addresses
End of changes. 16 change blocks.
	45 lines changed or deleted		57 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/