draft-ietf-tsvwg-vpn-signaled-preemption-00.txt		draft-ietf-tsvwg-vpn-signaled-preemption-01.txt
	Transport Working Group F. Baker		Transport Working Group F. Baker
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: August 30, 2006 P. Bose		Intended status: Informational P. Bose
	Lockheed Martin		Expires: March 30, 2007 Lockheed Martin
	February 26, 2006		September 26, 2006
	QoS Signaling in a Nested Virtual Private Network		QoS Signaling in a Nested Virtual Private Network
	draft-ietf-tsvwg-vpn-signaled-preemption-00		draft-ietf-tsvwg-vpn-signaled-preemption-01
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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 August 30, 2006.		This Internet-Draft will expire on March 30, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	Some networks require communication between an interior and exterior		Some networks require communication between an interior and exterior
	portion of a VPN, but have sensitivities about what information is		portion of a VPN, but have sensitivities about what information is
	communicated across the boundary. This note seeks to outline the		communicated across the boundary. This note seeks to outline the
	skipping to change at page 2, line 41		skipping to change at page 2, line 48
	3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29		3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 33		5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 35		7.1. Normative References . . . . . . . . . . . . . . . . . . . 35
	7.2. Informative References . . . . . . . . . . . . . . . . . . 35		7.2. Informative References . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
	Intellectual Property and Copyright Statements . . . . . . . . . . 39
	1. QoS in a nested VPN		1. QoS in a nested VPN
	More and more networks wish to guarantee secure transmission of IP		More and more networks wish to guarantee secure transmission of IP
	traffic for across public LANs or WANs and therefore use Virtual		traffic across public LANs or WANs and therefore use Virtual Private
	Private Networks. Some networks require communication between an		Networks. Some networks require communication between an interior
	interior and exterior portion of a VPN, but have sensitivities about		and exterior portion of a VPN, but have sensitivities about what
	what information is communicated across the boundary. This note		information is communicated across the boundary. This note seeks to
	seeks to outline the issues and the nature of the proposed solutions.		outline the issues and the nature of the proposed solutions. The
	The outline of the QoS solution for real-time traffic has been		outline of the QoS solution for real-time traffic has been described
	described at a high level in [I-D.ietf-tsvwg-mlpp-that-works] . The		at a high level in [RFC4542]. The key characteristics of this
	key characteristics of this proposal are that		proposal are that
	o it uses standardized protocols,		o it uses standardized protocols,
	o It includes reservation setup and teardown for guaranteed and		o It includes reservation setup and teardown for guaranteed and
	controlled load services using the standardized protocols,		controlled load services using the standardized protocols,
	o it is independent of link delay, and therefore consistent with		o it is independent of link delay, and therefore consistent with
	high delay*bandwidth networks as well as the more common variety,		high delay*bandwidth networks as well as the more common variety,
	o it has no single point of failure, such as a central reservation		o it has no single point of failure, such as a central reservation
	skipping to change at page 4, line 6		skipping to change at page 4, line 6
	including GRE, IP/IP, MPLS, and so on.		including GRE, IP/IP, MPLS, and so on.
	A note on the use of the words "priority" and "precedence" in this		A note on the use of the words "priority" and "precedence" in this
	document is in order. The term "priority" has been used in this		document is in order. The term "priority" has been used in this
	context with a variety of meanings, resulting in a great deal of		context with a variety of meanings, resulting in a great deal of
	confusion. The term "priority" is used in this document to identify		confusion. The term "priority" is used in this document to identify
	one of several possible datagram scheduling algorithms. A scheduler		one of several possible datagram scheduling algorithms. A scheduler
	is used when deciding which datagram will be sent next on a computer		is used when deciding which datagram will be sent next on a computer
	interface; a priority scheduler always chooses a datagram from the		interface; a priority scheduler always chooses a datagram from the
	highest priority class (queue) that is occupied, shielding one class		highest priority class (queue) that is occupied, shielding one class
	of traffic from jitter by passing jitter it would otherwise have		of traffic from most of the jitter by passing jitter it would
	experienced to another class. [RFC3181] applies the term to a		otherwise have experienced to another class. [RFC3181] applies the
	reservation, in a sense that this document will refer to as		term to a reservation, in a sense that this document will refer to as
	"precedence". The term "precedence" is used in the sense implied in		"precedence". The term "precedence" is used in the sense implied in
	the phrase "Multi-Level Precedence and Preemption"[ITU.MLPP.1990] ;		the phrase "Multi-Level Precedence and Preemption"[ITU.MLPP.1990] ;
	some classes of sessions take precedence over others, which may		some classes of sessions take precedence over others, which may
	result in bandwidth being admitted that might not otherwise have been		result in bandwidth being admitted that might not otherwise have been
	or may result in the prejudicial termination of a lower precedence		or may result in the prejudicial termination of a lower precedence
	session under a stated set of circumstances. For the purposes of the		session under a stated set of circumstances. For the purposes of the
	present discussion, "priority" is a set of algorithms applied to		present discussion, "priority" is a set of algorithms applied to
	datagrams, where "precedence" is a policy attribute of sessions. The		datagrams, where "precedence" is a policy attribute of sessions. The
	techniques of priority comparisons are used in a router or a policy		techniques of priority comparisons are used in a router or a policy
	decision point to implement precedence, but they are not the same		decision point to implement precedence, but they are not the same
	skipping to change at page 5, line 36		skipping to change at page 5, line 36
	The receiving VPN Router reverses the steps: it		The receiving VPN Router reverses the steps: it
	o determines what security association the datagram was received		o determines what security association the datagram was received
	from,		from,
	o decrypts the interior datagram,		o decrypts the interior datagram,
	o forwards the now-decapsulated datagram on a plain text interface.		o forwards the now-decapsulated datagram on a plain text interface.
	The use of IPsec in this manner is described as the tunnel mode of		The use of IPsec in this manner is described as the tunnel mode of
	[RFC2401] and [RFC2406] .		[RFC2401] and [RFC4303].
	Host Host Host Host Host Host		Host Host Host Host Host Host
	/------------------/ /------------------/		/------------------/ /------------------/
	Router -------Router		Router -------Router
	|		|
	VPN-Router		VPN-Router
	||		||
	|| IPsec Tunnel through routed network		|| IPsec Tunnel through routed network
	||		||
	VPN-Router		VPN-Router
	|		|
	skipping to change at page 8, line 47		skipping to change at page 8, line 47
	requirements and the network's capability to deliver them. Several		requirements and the network's capability to deliver them. Several
	such protocols have been developed or are under development, notably		such protocols have been developed or are under development, notably
	including RSVP and NSIS. The present discussion is limited to RSVP,		including RSVP and NSIS. The present discussion is limited to RSVP,
	although any protocol that delivers a similar set of capabilities		although any protocol that delivers a similar set of capabilities
	could be considered.		could be considered.
	1.3. The Resource Reservation Protocol (RSVP)		1.3. The Resource Reservation Protocol (RSVP)
	RSVP is initially defined in [RFC2205] with a set of datagram		RSVP is initially defined in [RFC2205] with a set of datagram
	processing rules defined in [RFC2209] and datagram details for		processing rules defined in [RFC2209] and datagram details for
	Integrated Services [RFC2210] . Conceptually, this protocol		Integrated Services [RFC2210]. Conceptually, this protocol specifies
	specifies a way to identify data flows from a source application to a		a way to identify data flows from a source application to a
	destination application and request specific resources for them. The		destination application and request specific resources for them. The
	source may be a single machine or a set of machines listed explicitly		source may be a single machine or a set of machines listed explicitly
	or implied, whereas the destination may be a single machine or a		or implied, whereas the destination may be a single machine or a
	multicast group (and therefore all of the machines in it). Each		multicast group (and therefore all of the machines in it). Each
	application is specified by a transport protocol number in the IP		application is specified by a transport protocol number in the IP
	protocol field, or may additionally include destination and perhaps		protocol field, or may additionally include destination and perhaps
	source port numbers. The protocol is defined for both IPv4 [RFC0791]		source port numbers. The protocol is defined for both IPv4 [RFC0791]
	and IPv6 [RFC2460]. It was recognized immediately that it was also		and IPv6 [RFC2460]. It was recognized immediately that it was also
	necessary to provide a means to perform the same function for various		necessary to provide a means to perform the same function for various
	kinds of tunnels, which implies a relationship between what is inside		kinds of tunnels, which implies a relationship between what is inside
	and what is outside the tunnel. Definitions were therefore developed		and what is outside the tunnel. Definitions were therefore developed
	for IPsec [RFC2207] and [I-D.lefaucheur-rsvp-ipsec] and for more		for IPsec [RFC2207] and [I-D.ietf-tsvwg-rsvp-ipsec] and for more
	generic forms of tunnels [RFC2746]. With the later development of		generic forms of tunnels [RFC2746]. With the later development of
	the Differentiated Services Architecture [RFC2475], definitions were		the Differentiated Services Architecture [RFC2475], definitions were
	added to specify the DSCP [RFC2474]to be used by a standard RSVP data		added to specify the DSCP [RFC2474] to be used by a standard RSVP
	flow in [RFC2996] and to use a pair of IP addresses and a DSCP as the		data flow in [RFC2996] and to use a pair of IP addresses and a DSCP
	identifying information for a data flow [RFC3175].		as the identifying information for a data flow [RFC3175].
	In addition, the initial definition of the protocol included a		In addition, the initial definition of the protocol included a
	placeholder for policy information, and for preemption of		placeholder for policy information, and for preemption of
	reservations. This placeholder was later specified in detail in		reservations. This placeholder was later specified in detail in
	[RFC2750] with a view to associating a policy [RFC2872] with an		[RFC2750] with a view to associating a policy [RFC2872] with an
	identity [RFC3182] and thereby enabling the network to provide a		identity [RFC3182] and thereby enabling the network to provide a
	contracted service to an authenticated and authorized user. This was		contracted service to an authenticated and authorized user. This was
	integrated with the Session Initiation Protocol [RFC3261] in		integrated with the Session Initiation Protocol [RFC3261] in
	[RFC3312] . Preemption of a reservation is specified in the context,		[RFC3312] . Preemption of a reservation is specified in the context,
	in [RFC3181] which in essence specifies that a reservation installed		in [RFC3181] which in essence specifies that a reservation installed
	in the network using an Preemption Priority and retained using a		in the network using an Preemption Priority and retained using a
	separate Defending Priority may be removed by the network via an RESV		separate Defending Priority may be removed by the network via an RESV
	Error signal that removes the entire reservation. This has issues,		Error signal that removes the entire reservation. This has issues,
	however, in that the matter is often not quite so black and white.		however, in that the matter is often not quite so black and white.
	If the issue is that an existing reservation for 80 KBPS can no		If the issue is that an existing reservation for 80 KBPS can no
	longer be sustained but a 60 KBPS reservation could, it is possible		longer be sustained but a 60 KBPS reservation could, it is possible
	that a VoIP sender could change from a G.711 codec to a G.729 codec		that a VoIP sender could change from a G.711 codec to a G.729 codec
	and achieve that. Or, if there are multiple sessions in a tunnel or		and achieve that. Or, if there are multiple sessions in a tunnel or
	other aggregate, one of the calls could be eliminated leaving		other aggregate, one of the calls could be eliminated leaving
	capacity for the others. [I-D.polk-tsvwg-rsvp-bw-reduction] seeks to		capacity for the others. [RFC4495] seeks to address this issue.
	address this issue.
	In a similar way, a capability was added to limit the possibility of		In a similar way, a capability was added to limit the possibility of
	control signals being spoofed or otherwise attacked [RFC2747]		control signals being spoofed or otherwise attacked [RFC2747]
	[RFC3097] .		[RFC3097] .
	[RFC3175] describes several features that are unusual in RSVP, being		[RFC3175] describes several features that are unusual in RSVP, being
	specifically set up to handle aggregates in a service provider		specifically set up to handle aggregates in a service provider
	network. It describes three key components:		network. It describes three key components:
	o The RFC 3175 session object, which identifies not the IP addresses		o The RFC 3175 session object, which identifies not the IP addresses
	skipping to change at page 10, line 20		skipping to change at page 10, line 20
	o The function of a reservation "deaggregator", which operates in		o The function of a reservation "deaggregator", which operates in
	the egress router and breaks the aggregate reservation and data		the egress router and breaks the aggregate reservation and data
	streams back out into individual data streams that may be passed		streams back out into individual data streams that may be passed
	to other networks.		to other networks.
	In retrospect, the Session Object specified by RFC 3175 is useful but		In retrospect, the Session Object specified by RFC 3175 is useful but
	not intrinsically necessary. If the ISP network uses tunnels, such		not intrinsically necessary. If the ISP network uses tunnels, such
	as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security		as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security
	Associations, the concepts of an aggregator and a deaggregator work		Associations, the concepts of an aggregator and a deaggregator work
	in the same manner, although the reservation mechanism would be that		in the same manner, although the reservation mechanism would be that
	of [RFC3473] and [RFC3474] [RFC2207] [I-D.lefaucheur-rsvp-ipsec] or		of [RFC3473] and [RFC3474] [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or
	[RFC2746] .		[RFC2746] .
	1.4. Logical structure of a VPN Router		1.4. Logical structure of a VPN Router
	The conceptual structure of a VPN Router is similar to that of any		The conceptual structure of a VPN Router is similar to that of any
	other router. In its simplest form, it is physically a two or more		other router. In its simplest form, it is physically a two or more
	port device, similar to that shown in Figure 4 which has one or more		port device, similar to that shown in Figure 4 which has one or more
	interfaces to the protected enclave(s) and one or more interfaces to		interfaces to the protected enclave(s) and one or more interfaces to
	the outside world. On the latter, it structures some number of		the outside world. On the latter, it structures some number of
	tunnels (in the case of an IPsec tunnel, having security		tunnels (in the case of an IPsec tunnel, having security
	skipping to change at page 14, line 27		skipping to change at page 14, line 27
	the appropriate tunnel (e. g., the IPsec Security Association for its		the appropriate tunnel (e. g., the IPsec Security Association for its
	precedence level to the appropriate remote VPN Router). At the		precedence level to the appropriate remote VPN Router). At the
	remote VPN Router, it is extracted from the tunnel and passed on its		remote VPN Router, it is extracted from the tunnel and passed on its
	way to the target system. The data in the enclave will be marked		way to the target system. The data in the enclave will be marked
	with a DSCP appropriate to its application and (if there is a		with a DSCP appropriate to its application and (if there is a
	difference) precedence level, and the signaling datagrams (PATH and		difference) precedence level, and the signaling datagrams (PATH and
	RESV) are marked with a DCLASS object indicating that value. RSVP		RESV) are marked with a DCLASS object indicating that value. RSVP
	signaling datagrams (PATH and RESV) are marked with a DCLASS object		signaling datagrams (PATH and RESV) are marked with a DCLASS object
	indicating the value used for the corresponding data. The DSCP on		indicating the value used for the corresponding data. The DSCP on
	the signaling datagrams, however, is a DSCP for signaling, and has		the signaling datagrams, however, is a DSCP for signaling, and has
	the one proviso that if routing varies by DSCP then it must be a DSCP		the one provision that if routing varies by DSCP then it must be a
	that is routed the same way as the relevant data. The [RFC2872]		DSCP that is routed the same way as the relevant data. The [RFC2872]
	policy object specifies the applicable policy (e. g., "routine		policy object specifies the applicable policy (e. g., "routine
	service for voice traffic") and asserts a [RFC3182] credential		service for voice traffic") and asserts a [RFC3182] credential
	indicating its user (which may be a person or a class of persons).		indicating its user (which may be a person or a class of persons).
	As specified in [RFC3181] it also specifies its Preemption Priority		As specified in [RFC3181] it also specifies its Preemption Priority
	and its Defending Priority; these enable the Preemption Priority of a		and its Defending Priority; these enable the Preemption Priority of a
	new session to be compared with the Defending Priority of previously		new session to be compared with the Defending Priority of previously
	admitted sessions.		admitted sessions.
	On the cipher text side of the VPN Router, no guarantees result		On the cipher text side of the VPN Router, no guarantees result
	unless the VPN Router likewise sets up a reservation to the peer VPN		unless the VPN Router likewise sets up a reservation to the peer VPN
	Router across the cipher text domain. Thus, the VPN Router sets up		Router across the cipher text domain. Thus, the VPN Router sets up
	an [RFC2207] [I-D.lefaucheur-rsvp-ipsec] or [RFC3175] reservation to		an [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC3175] reservation to
	its peer.		its peer.
	The Session Object defined by [RFC2207] or [I-D.lefaucheur-rsvp-		The Session Object defined by [RFC2207] or
	ipsec] contains a field called a "virtual destination port", which		[I-D.ietf-tsvwg-rsvp-ipsec] contains a field called a "virtual
	allows the multiplexing of many reservations over a common security		destination port", which allows the multiplexing of many reservations
	association, and in the latter case, a common DSCP value. Thus, the		over a common security association, and in the latter case, a common
	voice traffic at every precedence level might use the EF DSCP and		DSCP value. Thus, the voice traffic at every precedence level might
	service as described in [RFC3246], but the reservations would be for		use the EF DSCP and service as described in [RFC3246], but the
	"the aggregate of voice sessions at precedence Pn between these VPN		reservations would be for "the aggregate of voice sessions at
	Routers". This would allow the network administration to describe		precedence Pn between these VPN Routers". This would allow the
	policies with multiple thresholds, such as "a new session at		network administration to describe policies with multiple thresholds,
	precedence Pn may be accepted if the total reserved bandwidth does		such as "a new session at precedence Pn may be accepted if the total
	not exceed threshold Qn; if it is necessary and sufficient to accept		reserved bandwidth does not exceed threshold Qn; if it is necessary
	the reservation, existing reservations at lower precedences may be		and sufficient to accept the reservation, existing reservations at
	preemptively reduced to make acceptance of the new session possible."		lower precedences may be preemptively reduced to make acceptance of
			the new session possible."
	In the [RFC3175] case, since the DSCP must be used to identify both		In the [RFC3175] case, since the DSCP must be used to identify both
	the reservation and the corresponding data stream, the aggregate		the reservation and the corresponding data stream, the aggregate
	reservations for different precedence levels require different DSCP		reservations for different precedence levels require different DSCP
	values.		values.
	In either case, the fundamental necessity is for one VPN Router to		In either case, the fundamental necessity is for one VPN Router to
	act as what [RFC3175] calls the "aggregator" and another to act as		act as what [RFC3175] calls the "aggregator" and another to act as
	the "deaggregator", and extend a VPN tunnel between them. If the VPN		the "deaggregator", and extend a VPN tunnel between them. If the VPN
	Tunnel is an IPsec Security Association between the VPN Routers and		Tunnel is an IPsec Security Association between the VPN Routers and
	skipping to change at page 16, line 24		skipping to change at page 16, line 24
	the total reserved bandwidth after admission may not exceed X; to		the total reserved bandwidth after admission may not exceed X; to
	accept a higher precedence level call, the total reserved bandwidth		accept a higher precedence level call, the total reserved bandwidth
	after admission may not exceed X+Y, and this may be achieved by		after admission may not exceed X+Y, and this may be achieved by
	preempting a lower precedence level call"), the bandwidth Y		preempting a lower precedence level call"), the bandwidth Y
	effectively comes from the bandwidth in use by elastic traffic rather		effectively comes from the bandwidth in use by elastic traffic rather
	than forcing a preemption event.		than forcing a preemption event.
	2.2. Preemption in a nested VPN		2.2. Preemption in a nested VPN
	As discussed in Section 1.3 preemption is specified in [RFC3181] and		As discussed in Section 1.3 preemption is specified in [RFC3181] and
	further addressed in [I-D.polk-tsvwg-rsvp-bw-reduction] . The issue		further addressed in [RFC4495]. The issue is that in many cases the
	is that in many cases the need is to reduce the bandwidth of a		need is to reduce the bandwidth of a reservation due to a change in
	reservation due to a change in the network, not simply to remove the		the network, not simply to remove the reservation. In the case of an
	reservation. In the case of an end system originated reservation,		end system originated reservation, the end system might be able to
	the end system might be able to accommodate the need through a change		accommodate the need through a change of codec; in the case of an
	of codec; in the case of an aggregate of some kind, it could reduce		aggregate of some kind, it could reduce the bandwidth it is sending
	the bandwidth it is sending by dropping one or more reservations		by dropping one or more reservations entirely.
	entirely.
	In a nested VPN or other kind of aggregated reservation, this means		In a nested VPN or other kind of aggregated reservation, this means
	that the deaggregator (the VPN Router initiating the RESV signal for		that the deaggregator (the VPN Router initiating the RESV signal for
	the tunnel) must		the tunnel) must
	o receive the RESV Error signaling it to reduce its bandwidth,		o receive the RESV Error signaling it to reduce its bandwidth,
	o re-issue its RESV accordingly,		o re-issue its RESV accordingly,
	o identify one or more of its aggregated reservations, enough to do		o identify one or more of its aggregated reservations, enough to do
	skipping to change at page 22, line 23		skipping to change at page 22, line 23
	met. At R9, a problem is detected - there is not sufficient		met. At R9, a problem is detected - there is not sufficient
	bandwidth under the relevant policy. In the absence of precedence,		bandwidth under the relevant policy. In the absence of precedence,
	R9 would now return an RESV Error indicating that the reservation		R9 would now return an RESV Error indicating that the reservation
	could not be increased or installed. In such a case, if a pre-		could not be increased or installed. In such a case, if a pre-
	existing reservation of lower bandwidth already existed, the previous		existing reservation of lower bandwidth already existed, the previous
	reservation would remain in place but the new bandwidth would not be		reservation would remain in place but the new bandwidth would not be
	granted, and the originator (H6) would be informed. Let us clarify		granted, and the originator (H6) would be informed. Let us clarify
	what it means to be at a stated precedence: it means that the		what it means to be at a stated precedence: it means that the
	POLICY_DATA object in the RESV contains a Preemption Priority and a		POLICY_DATA object in the RESV contains a Preemption Priority and a
	Defending Priority with values specified in some memo. With		Defending Priority with values specified in some memo. With
	precedence, [I-D.polk-tsvwg-rsvp-bw-reduction] 's algorithm would		precedence, [RFC4495]'s algorithm would have the Preemption Priority
	have the Preemption Priority of the new reservation compared to the		of the new reservation compared to the Defending Priority of extant
	Defending Priority of extant reservations in the router, of which		reservations in the router, of which there are two: one VPN7->VPN8 at
	there are two: one VPN7->VPN8 at "routine" precedence and one		"routine" precedence and one VPN7->VPN8 at "priority" precedence.
	VPN7->VPN8 at "priority" precedence. Since the Defending Priority of		Since the Defending Priority of routine reservation is less than the
	routine reservation is less than the Preemption Priority of a		Preemption Priority of a "priority" reservation, the "routine"
	"priority" reservation, the "routine" reservation is selected. R9		reservation is selected. R9 determines that it will accept the
	determines that it will accept the increase in its "priority"		increase in its "priority" reservation VPN7->VPN8 and reduce the
	reservation VPN7->VPN8 and reduce the corresponding "routine"		corresponding "routine" reservation. Two processes now occur in
	reservation. Two processes now occur in parallel:		parallel:
	o The routine reservation is reduced following the algorithms in		o The routine reservation is reduced following the algorithms in
	[I-D.polk-tsvwg-rsvp-bw-reduction] and		[RFC4495] and
	o The priority reservation continues according to the usual rules.		o The priority reservation continues according to the usual rules.
	R9 reduces its "routine" reservation by sending an RESV Error		R9 reduces its "routine" reservation by sending an RESV Error
	updating its internal state to reflect the reduced reservation and		updating its internal state to reflect the reduced reservation and
	sending an RESV Error to VPN8 requesting that it reduce its		sending an RESV Error to VPN8 requesting that it reduce its
	reservation to a number less than or equal to the relevant threshold		reservation to a number less than or equal to the relevant threshold
	less the sum of the competing reservations. VPN8, acting as a de-		less the sum of the competing reservations. VPN8, acting as a de-
	aggregator, makes two changes. On the "inner domain" side, it marks		aggregator, makes two changes. On the "inner domain" side, it marks
	its reservation down to the indicated rate (the most it is now		its reservation down to the indicated rate (the most it is now
	skipping to change at page 25, line 45		skipping to change at page 25, line 45
	event that this is the last aggregated session, or change the		event that this is the last aggregated session, or change the
	SENDER_TSPEC of the aggregated session.		SENDER_TSPEC of the aggregated session.
	RESV: The Plain text RESV message is sent as encrypted data to the		RESV: The Plain text RESV message is sent as encrypted data to the
	cipher text unit. In parallel, a trigger needs to be sent to the		cipher text unit. In parallel, a trigger needs to be sent to the
	cipher text unit that results in it generating the corresponding		cipher text unit that results in it generating the corresponding
	aggregated RESV message for the cipher text side.		aggregated RESV message for the cipher text side.
	RESV Error: This indicates that a RESV message received as data and		RESV Error: This indicates that a RESV message received as data and
	forwarded into the enclave was in error or needed to be preempted		forwarded into the enclave was in error or needed to be preempted
	as described in [RFC3181] or [I-D.polk-tsvwg-rsvp-bw-reduction] .		as described in [RFC3181] or [RFC4495]. In the error case, the
	In the error case, the message itself is sent on as encrypted		message itself is sent on as encrypted data, but a signal is sent
	data, but a signal is sent to the cipher text side in case the		to the cipher text side in case the error affects the cipher text
	error affects the cipher text reservation (such as removing or		reservation (such as removing or changing state).
	changing state).
	RESV Tear: The RESV Tear message is sent as encrypted data to the		RESV Tear: The RESV Tear message is sent as encrypted data to the
	cipher text unit. In parallel, a signal is sent to the cipher		cipher text unit. In parallel, a signal is sent to the cipher
	text side which will trigger a RESV Tear on its reservation in the		text side which will trigger a RESV Tear on its reservation in the
	event that this is the last aggregated session, or reduce the		event that this is the last aggregated session, or reduce the
	bandwidth of an existing reservation.		bandwidth of an existing reservation.
	RESV Confirm: This indicates that a RESV message received as data		RESV Confirm: This indicates that a RESV message received as data
	and forwarded into the enclave, and is now being confirmed. This		and forwarded into the enclave, and is now being confirmed. This
	message is sent as encrypted data to the cipher text side, and in		message is sent as encrypted data to the cipher text side, and in
	skipping to change at page 28, line 9		skipping to change at page 28, line 9
	exchanging datagrams, it is somewhat more complex, but conceptually		exchanging datagrams, it is somewhat more complex, but conceptually
	equivalent. For example, the ciphertext router would consider an IP		equivalent. For example, the ciphertext router would consider an IP
	datagram received via the Network Guard (control plane) as having		datagram received via the Network Guard (control plane) as having
	been received from and concerning the interface used in the data		been received from and concerning the interface used in the data
	plane to the encrypt/decrypt unit.		plane to the encrypt/decrypt unit.
	3.2.1. Signaling Flow		3.2.1. Signaling Flow
	Encrypt/Decrypt units may not be capable of terminating and		Encrypt/Decrypt units may not be capable of terminating and
	originating flows as described in Section 3.1, and policy may prevent		originating flows as described in Section 3.1, and policy may prevent
	knowledge of th cipher text network addresses in the plain text		knowledge of the cipher text network addresses in the plain text
	router. In such a case the plain text and cipher text routers may		router. In such a case the plain text and cipher text routers may
	use the Network Guard as the path for the signaling flows. The		use the Network Guard as the path for the signaling flows. The
	Network Guard performs the following functions to enable the flow of		Network Guard performs the following functions to enable the flow of
	reservation signaling across the cryptographic domain		reservation signaling across the cryptographic domain
	o Transform plain text session identifiers into cipher text session		o Transform plain text session identifiers into cipher text session
	identifiers and vice-versa in IP datagrams and RSVP objects (e.g.		identifiers and vice-versa in IP datagrams and RSVP objects (e.g.
	IP addresses)		IP addresses)
	o Resource management of aggregated reservations (e.g. including		o Resource management of aggregated reservations (e.g. including
	skipping to change at page 30, line 41		skipping to change at page 30, line 41
	routers in the interface domain.		routers in the interface domain.
	o CT-Router-B receives the ciphertext aggregate RSVP message and		o CT-Router-B receives the ciphertext aggregate RSVP message and
	sends it to the NetGrd-B.		sends it to the NetGrd-B.
	o The NetGrd-B transforms the ciphertext aggregate RSVP into the		o The NetGrd-B transforms the ciphertext aggregate RSVP into the
	plaintext aggregate RSVP message as described in Section 3.2.1 and		plaintext aggregate RSVP message as described in Section 3.2.1 and
	sends it to the PT-Router-B.		sends it to the PT-Router-B.
	The subsequent RSVP and Aggregate RSVP signaling follows a similar		The subsequent RSVP and Aggregate RSVP signaling follows a similar
	flow, as described in detail in [RFC3175] and [I-D.lefaucheur-rsvp-		flow, as described in detail in [RFC3175] and
	ipsec]to aggregate each plaintext reservation into a corresponding		[I-D.ietf-tsvwg-rsvp-ipsec]to aggregate each plaintext reservation
	ciphertext reservation. This ensures that RSVP capable ciphertext		into a corresponding ciphertext reservation. This ensures that RSVP
	routers reserve the required resources for a plaintext end to end		capable ciphertext routers reserve the required resources for a
	reservation. Subsequent mechanisms such as preemption or the		plaintext end to end reservation. Subsequent mechanisms such as
	increase and decrease of resources reserved may be applied to these		preemption or the increase and decrease of resources reserved may be
	reservations as described before in this document. The RSVP data		applied to these reservations as described before in this document.
	flow as described in Section 3.1 within the VPN router (from the		The RSVP data flow as described in Section 3.1 within the VPN router
	plaintext router to the ciphertext router via the Guard) provides		(from the plaintext router to the ciphertext router via the Guard)
	neccessary and sufficient information to routers in the ciphertext		provides necessary and sufficient information to routers in the
	domain to implement the QoS solution presented in the document.		ciphertext domain to implement the QoS solution presented in the
			document.
	In this description, we have described the Network Guard as being		In this description, we have described the Network Guard as being
	separate from the Encrypt/Decrypt unit. This separation exists		separate from the Encrypt/Decrypt unit. This separation exists
	because in certain implementations it is mandated by those who		because in certain implementations it is mandated by those who
	specify the devices. The separation does not come for free, however;		specify the devices. The separation does not come for free, however;
	the separation of the devices for system engineering purposes is		the separation of the devices for system engineering purposes is
	expensive, and it imposes architectural problems. For example, when		expensive, and it imposes architectural problems. For example, when
	the Guard is used to aggregate RSVP messages or PIM routing, the		the Guard is used to aggregate RSVP messages or PIM routing, the
	traffic is destined to the remote VPN Router. This means that the		traffic is destined to the remote VPN Router. This means that the
	Guard must somehow receive and respond to, on behalf of the VPN		Guard must somehow receive and respond to, on behalf of the VPN
	skipping to change at page 34, line 14		skipping to change at page 34, line 14
	6. Acknowledgements		6. Acknowledgements
	Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger		Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger
	Levesque, and Subha Dhesikan gave early review comments.		Levesque, and Subha Dhesikan gave early review comments.
	Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou		Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou
	and their associates resulted in Section 3.2.		and their associates resulted in Section 3.2.
	Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik		Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik
	Bose) added [I-D.lefaucheur-rsvp-ipsec], which clarified the		Bose) added [I-D.ietf-tsvwg-rsvp-ipsec], which clarified the
	interaction of this approach with the DSCP.		interaction of this approach with the DSCP.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-tsvwg-mlpp-that-works]		[I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate RSVP
	Baker, F. and J. Polk, "Implementing an Emergency		Reservations",
	Telecommunications Service for Real Time Services in the		draft-ietf-tsvwg-rsvp-ipsec-01 (work in
	Internet Protocol Suite",		progress), June 2006.
	draft-ietf-tsvwg-mlpp-that-works-02 (work in progress),
	August 2005.
	[I-D.lefaucheur-rsvp-ipsec]
	Faucheur, F., "Generic Aggregate RSVP Reservations",
	draft-lefaucheur-rsvp-ipsec-01 (work in progress),
	July 2005.
	[I-D.polk-tsvwg-rsvp-bw-reduction]
	Polk, J., "A Resource Reservation Extension for the
	Reduction of Bandwidth of a Reservation Flow",
	draft-polk-tsvwg-rsvp-bw-reduction-00 (work in progress),
	October 2004.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, B., Zhang, L., Berson, S.,
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Herzog, S., and S. Jamin, "Resource
	Functional Specification", RFC 2205, September 1997.		ReSerVation Protocol (RSVP) -- Version 1
			Functional Specification", RFC 2205,
			September 1997.
	[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC		[RFC2207] Berger, L. and T. O'Malley, "RSVP
	Data Flows", RFC 2207, September 1997.		Extensions for IPSEC Data Flows",
			RFC 2207, September 1997.
	[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang,		[RFC2746] Terzis, A., Krawczyk, J., Wroclawski,
	"RSVP Operation Over IP Tunnels", RFC 2746, January 2000.		J., and L. Zhang, "RSVP Operation Over
			IP Tunnels", RFC 2746, January 2000.
	[RFC2750] Herzog, S., "RSVP Extensions for Policy Control",		[RFC2750] Herzog, S., "RSVP Extensions for Policy
	RFC 2750, January 2000.		Control", RFC 2750, January 2000.
	[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,		[RFC2996] Bernet, Y., "Format of the RSVP DCLASS
	November 2000.		Object", RFC 2996, November 2000.
	[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,		[RFC3175] Baker, F., Iturralde, C., Le Faucheur,
	"Aggregation of RSVP for IPv4 and IPv6 Reservations",		F., and B. Davie, "Aggregation of RSVP
			for IPv4 and IPv6 Reservations",
	RFC 3175, September 2001.		RFC 3175, September 2001.
	7.2. Informative References		[RFC4495] Polk, J. and S. Dhesikan, "A Resource
			Reservation Protocol (RSVP) Extension
			for the Reduction of Bandwidth of a
			Reservation Flow", RFC 4495, May 2006.
	[ANSI.MLPP.Spec]		[RFC4542] Baker, F. and J. Polk, "Implementing an
	American National Standards Institute, "Telecommunications		Emergency Telecommunications Service
	- Integrated Services Digital Network (ISDN) - Multi-Level		(ETS) for Real-Time Services in the
	Precedence and Preemption (MLPP) Service Capability",		Internet Protocol Suite", RFC 4542,
	ANSI T1.619-1992 (R1999), 1992.		May 2006.
	[ANSI.MLPP.Supplement]		7.2. Informative References
	American National Standards Institute, "MLPP Service
	Domain Cause Value Changes", ANSI ANSI T1.619a-1994
	(R1999), 1990.
	[ITU.MLPP.1990]		[ITU.MLPP.1990] International Telecommunications Union, "Multilevel
	International Telecommunications Union, "Multilevel		Precedence and Preemption Service", ITU-
	Precedence and Preemption Service", ITU-T Recommendation		T Recommendation I.255.3, 1990.
	I.255.3, 1990.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	September 1981.		September 1981.
	[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated		[RFC1633] Braden, B., 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.
	[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol		[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation
	(RSVP) -- Version 1 Message Processing Rules", RFC 2209,		Protocol (RSVP) -- Version 1 Message Processing
	September 1997.		Rules", RFC 2209, September 1997.
	[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
	Services", RFC 2210, September 1997.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the		[RFC2210] Wroclawski, J., "The Use of RSVP with IETF
	Internet Protocol", RFC 2401, November 1998.		Integrated Services", RFC 2210, September 1997.
	[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security		[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
	Payload (ESP)", RFC 2406, November 1998.		the Internet Protocol", RFC 2401, November 1998.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
	(IPv6) Specification", RFC 2460, December 1998.		Version 6 (IPv6) Specification", RFC 2460,
			December 1998.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.		December 1998.
	[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,		[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
	and W. Weiss, "An Architecture for Differentiated		Z., and W. Weiss, "An Architecture for
	Services", RFC 2475, December 1998.		Differentiated Services", RFC 2475, December 1998.
	[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic		[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
	Authentication", RFC 2747, January 2000.		Cryptographic Authentication", RFC 2747,
			January 2000.
	[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub		[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub
	Application Identity Policy Element for Use with RSVP",		Application Identity Policy Element for Use with
	RFC 2872, June 2000.		RSVP", RFC 2872, June 2000.
	[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic		[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
	Authentication -- Updated Message Type Value", RFC 3097,		Authentication -- Updated Message Type Value",
	April 2001.		RFC 3097, April 2001.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, September 2001.
	[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",		[RFC3181] Herzog, S., "Signaled Preemption Priority Policy
	RFC 3181, October 2001.		Element", RFC 3181, October 2001.
	[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,		[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
	Herzog, S., and R. Hess, "Identity Representation for		Moore, T., Herzog, S., and R. Hess, "Identity
	RSVP", RFC 3182, October 2001.		Representation for RSVP", RFC 3182, October 2001.
	[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,		[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le
	J., Courtney, W., Davari, S., Firoiu, V., and D.		Boudec, J., Courtney, W., Davari, S., Firoiu, V.,
	Stiliadis, "An Expedited Forwarding PHB (Per-Hop		and D. Stiliadis, "An Expedited Forwarding PHB (Per-
	Behavior)", RFC 3246, March 2002.		Hop Behavior)", RFC 3246, March 2002.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
	A., Peterson, J., Sparks, R., Handley, M., and E.		Johnston, A., Peterson, J., Sparks, R., Handley, M.,
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		and E. Schooler, "SIP: Session Initiation Protocol",
	June 2002.		RFC 3261, June 2002.
	[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,		[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
	"Integration of Resource Management and Session Initiation		"Integration of Resource Management and Session
	Protocol (SIP)", RFC 3312, October 2002.		Initiation Protocol (SIP)", RFC 3312, October 2002.
	[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching		[RFC3473] Berger, L., "Generalized Multi-Protocol Label
	(GMPLS) Signaling Resource ReserVation Protocol-Traffic		Switching (GMPLS) Signaling Resource ReserVation
	Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.		Protocol-Traffic Engineering (RSVP-TE) Extensions",
			RFC 3473, January 2003.
	[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA		[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
	assignments for Generalized MultiProtocol Label Switching		assignments for Generalized MultiProtocol Label
	(GMPLS) Resource Reservation Protocol - Traffic		Switching (GMPLS) Resource Reservation Protocol -
	Engineering (RSVP-TE) Usage and Extensions for		Traffic Engineering (RSVP-TE) Usage and Extensions
	Automatically Switched Optical Network (ASON)", RFC 3474,		for Automatically Switched Optical Network (ASON)",
	March 2003.		RFC 3474, March 2003.
			[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
			RFC 4303, December 2005.
	Authors' Addresses		Authors' Addresses
	Fred Baker		Fred Baker
	Cisco Systems		Cisco Systems
	1121 Via Del Rey		1121 Via Del Rey
	Santa Barbara, California 93117		Santa Barbara, California 93117
	USA		USA
	Phone: +1-408-526-4257		Phone: +1-408-526-4257
	Fax: +1-413-473-2403		Fax: +1-413-473-2403
	Email: fred@cisco.com		EMail: fred@cisco.com
	Pratik Bose		Pratik Bose
	Lockheed Martin		Lockheed Martin
	700 North Frederick Ave		700 North Frederick Ave
	Gaithersburg, Maryland 20871		Gaithersburg, Maryland 20871
	USA		USA
	Phone: +1-301-240-7041		Phone: +1-301-240-7041
	Fax: +1-301-240-5748		Fax: +1-301-240-5748
	Email: pratik.bose@lmco.com		EMail: pratik.bose@lmco.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	skipping to change at page 39, line 45		skipping to change at page 39, line 45
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment		Acknowledgements
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA). This document was produced
			using xml2rfc v1.31 (of http://xml.resource.org/) from a source in
			RFC-2629 XML format.
End of changes. 53 change blocks.
	179 lines changed or deleted		165 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/