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/