draft-ietf-tsvwg-vpn-signaled-preemption-02.txt | rfc4923.txt | |||
---|---|---|---|---|
Transport Working Group F. Baker | Network Working Group F. Baker | |||
Internet-Draft Cisco Systems | Request for Comments: 4923 Cisco Systems | |||
Intended status: Informational P. Bose | Category: Informational P. Bose | |||
Expires: August 6, 2007 Lockheed Martin | Lockheed Martin | |||
February 2, 2007 | August 2007 | |||
QoS Signaling in a Nested Virtual Private Network | Quality of Service (QoS) Signaling in a Nested Virtual Private Network | |||
draft-ietf-tsvwg-vpn-signaled-preemption-02 | ||||
Status of This Memo | Status of This Memo | |||
By submitting this Internet-Draft, each author represents that any | This memo provides information for the Internet community. It does | |||
applicable patent or other IPR claims of which he or she is aware | not specify an Internet standard of any kind. Distribution of this | |||
have been or will be disclosed, and any of which he or she becomes | memo is unlimited. | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | ||||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on August 6, 2007. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
Some networks require communication between an interior and exterior | Some networks require communication between an interior and exterior | |||
portion of a VPN or through a concatenation of such networks | portion of a Virtual Private Network (VPN) or through a concatenation | |||
resulting in a nested VPN, but have sensitivities about what | of such networks resulting in a nested VPN, but have sensitivities | |||
information is communicated across the boundary, especially while | about what information is communicated across the boundary, | |||
providing quality of service to communications with different | especially while providing quality of service to communications with | |||
precedence. This note seeks to outline the issues and the nature of | different precedence. This note seeks to outline the issues and the | |||
the proposed solutions based on the framework for Integrated Services | nature of the proposed solutions based on the framework for | |||
operation over DiffServ networks as described in RFC 2998 . | Integrated Services operation over Diffserv networks as described in | |||
RFC 2998. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction ....................................................3 | |||
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Problem Statement ..........................................3 | |||
1.2. Background Information and Terminology . . . . . . . . . . 4 | 1.2. Background Information and Terminology .....................4 | |||
1.3. Nested VPNs . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.3. Nested VPNs ................................................5 | |||
1.4. Signaled QoS technology . . . . . . . . . . . . . . . . . 7 | 1.4. Signaled QoS Technology ....................................7 | |||
1.5. The Resource Reservation Protocol (RSVP) . . . . . . . . . 8 | 1.5. The Resource Reservation Protocol (RSVP) ...................9 | |||
1.6. Logical structure of a VPN Router . . . . . . . . . . . . 10 | 1.6. Logical Structure of a VPN Router .........................10 | |||
2. Reservation and Preemption in a Nested VPN .....................13 | ||||
2. Reservation and Preemption in a nested VPN . . . . . . . . . . 13 | 2.1. Reservation in a Nested VPN ...............................14 | |||
2.1. Reservation in a nested VPN . . . . . . . . . . . . . . . 14 | 2.2. Preemption in a Nested VPN ................................16 | |||
2.2. Preemption in a nested VPN . . . . . . . . . . . . . . . . 16 | 2.3. Working through an Example ................................17 | |||
2.3. Working through an example . . . . . . . . . . . . . . . . 17 | 2.3.1. Initial Routine Reservations - Generating | |||
2.3.1. Initial routine reservations - generating network | Network State ......................................18 | |||
state . . . . . . . . . . . . . . . . . . . . . . . . 18 | 2.3.2. Initial Routine Reservations - Request | |||
2.3.2. Initial routine reservations - request reservation . . 19 | Reservation ........................................19 | |||
2.3.3. Installation of a reservation using precedence . . . . 20 | 2.3.3. Installation of a Reservation Using Precedence .....20 | |||
2.3.4. Installation of a reservation using preemption . . . . 21 | 2.3.4. Installation of a Reservation Using Preemption .....21 | |||
3. Data Flows within a VPN Router .................................24 | ||||
3. Data flows within a VPN Router . . . . . . . . . . . . . . . . 24 | 3.1. VPN Routers That Carry Data across the | |||
3.1. VPN Routers that carry data across the cryptographic | Cryptographic Boundary ....................................24 | |||
boundary . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 3.1.1. Plaintext to Ciphertext Data Flows .................24 | |||
3.1.1. Plaintext to Ciphertext Data Flows . . . . . . . . . . 24 | 3.1.2. Ciphertext to Plaintext Data Flows .................27 | |||
3.1.2. Ciphertext to Plaintext Data Flows . . . . . . . . . . 26 | 3.2. VPN Routers That Use the Network Guard for | |||
3.2. VPN Routers that use the Network Guard for signaling | Signaling across the Cryptographic Boundary ...............28 | |||
across the cryptographic boundary . . . . . . . . . . . . 27 | 3.2.1. Signaling Flow .....................................29 | |||
3.2.1. Signaling Flow . . . . . . . . . . . . . . . . . . . . 28 | 3.2.2. Use Case with Network Guard ........................30 | |||
3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 | 4. Security Considerations ........................................33 | |||
5. Acknowledgements ...............................................34 | ||||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 6. References .....................................................34 | |||
6.1. Normative References ......................................34 | ||||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 | 6.2. Informative References ....................................35 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 33 | ||||
7.2. Informative References . . . . . . . . . . . . . . . . . . 34 | ||||
1. Introduction | 1. Introduction | |||
1.1. Problem Statement | 1.1. Problem Statement | |||
More and more networks wish to guarantee secure transmission of IP | More and more networks wish to guarantee secure transmission of IP | |||
traffic across public LANs or WANs and therefore use Virtual Private | traffic across public LANs or WANs and therefore use Virtual Private | |||
Networks. Some networks require communication between an interior | Networks. Some networks require communication between an interior | |||
and exterior portion of a VPN or through a concatenation of such | and exterior portion of a VPN or through a concatenation of such | |||
networks resulting in a nested VPN, but have sensitivities about what | networks resulting in a nested VPN, but have sensitivities about what | |||
information is communicated across the boundary, especially while | information is communicated across the boundary, especially while | |||
providing quality of service to communications with different | providing quality of service to communications with different | |||
precedence. This note seeks to outline the issues and the nature of | precedence. This note seeks to outline the issues and the nature of | |||
the proposed solutions. The outline of the QoS solution for real- | the proposed solutions. The outline of the QoS solution for real- | |||
time traffic has been described at a high level in [RFC4542]. The | time traffic has been described at a high level in [RFC4542]. The | |||
key characteristics of this proposal are that | key characteristics of this 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 | |||
manager, | manager, | |||
o It provides for the preemption of established data flows, | o it provides for the preemption of established data flows, | |||
o In that preemption, it not only permits a policy-admitted data | o in that preemption, it not only permits a policy-admitted data | |||
flow in, but selects a specific data flow to exclude based upon | flow in, but selects a specific data flow to exclude based upon | |||
control input rather than simply accepting a loss of service | control input rather than simply accepting a loss of service | |||
dictated at the discretion of the network control function, and | dictated at the discretion of the network control function, and | |||
o interoperates directly with SIP Proxies, H.323 Gatekeepers, or | o it interoperates directly with SIP Proxies, H.323 Gatekeepers, or | |||
other call management subsystems to present the other services | other call management subsystems to present the other services | |||
required in a preemptive or preferential telephone network. | required in a preemptive or preferential telephone network. | |||
The thrust of the memo surrounds VPNs that use encryption in some | The thrust of the memo surrounds VPNs that use encryption in some | |||
form, such as IPsec and their subsequent nesting across multiple | form, such as IPsec and their subsequent nesting across multiple | |||
network domains. This specific type of VPNs is further clarified in | network domains. This specific type of VPNs is further clarified in | |||
Section 1.3 which describes the nested VPN as an example of an IPsec | Section 1.3, which describes the nested VPN as an example of an IPsec | |||
or IPsec like VPN under the context of a 'customer provisioned' VPN. | or IPsec like VPN under the context of a 'customer provisioned' VPN. | |||
As a result, we will discuss the VPN Router supporting "plaintext" | As a result, we will discuss the VPN router supporting "plaintext" | |||
and "ciphertext" interfaces. However, the concept extends readily to | and "ciphertext" interfaces. However, the concept extends readily to | |||
any form of aggregation, including the concept proposed in [RFC3175] | any form of aggregation, including the concept proposed in [RFC3175] | |||
of the IP traffic entering and leaving a network at identified | of the IP traffic entering and leaving a network at identified | |||
points, and the use of other kinds of tunnels including GRE, IP/IP, | points, and the use of other kinds of tunnels including Generic | |||
MPLS, and so on. | Routing Encapsulation (GRE), IP/IP, MPLS, and so on. | |||
1.2. Background Information and Terminology | 1.2. Background Information and Terminology | |||
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 most of the jitter by passing jitter it would | of traffic from most of the jitter by passing jitter it would | |||
otherwise have experienced to another class. [RFC3181] applies the | otherwise have experienced to another class. [RFC3181] applies the | |||
term to a 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 | |||
thing. | thing. | |||
Along the same lines, it is important for the reader to understand | Along the same lines, it is important for the reader to understand | |||
the difference between QoS policies and policies based on the | the difference between QoS policies and policies based on the | |||
"precedence" or "importance" of data to the person or function using | "precedence" or "importance" of data to the person or function using | |||
skipping to change at page 5, line 15 | skipping to change at page 5, line 16 | |||
than it would be if datagrams had to be retransmitted, and this is | than it would be if datagrams had to be retransmitted, and this is | |||
true regardless of whether the call is routine or of high precedence. | true regardless of whether the call is routine or of high precedence. | |||
As such, QoS markings tell us how to provide good service to an | As such, QoS markings tell us how to provide good service to an | |||
application independent of how "important" it may be at the current | application independent of how "important" it may be at the current | |||
time, while "importance" can be conveyed separately in many cases. | time, while "importance" can be conveyed separately in many cases. | |||
1.3. Nested VPNs | 1.3. Nested VPNs | |||
One could describe a nested VPN network in terms of three network | One could describe a nested VPN network in terms of three network | |||
diagrams. Figure 1 shows a simple network stretched across a VPN | diagrams. Figure 1 shows a simple network stretched across a VPN | |||
connection. The VPN Router (where, following [RFC2460] a "router" is | connection. The VPN router (where, following [RFC2460], a "router" | |||
"a node that forwards packets not explicitly addressed to itself"), | is "a node that forwards packets not explicitly addressed to | |||
performs the following steps: it | itself"), performs the following steps: | |||
o receives an IP datagram from a plain text interface, | o receives an IP datagram from a plain text interface, | |||
o determines what remote enclave and therefore other VPN Router to | o determines what remote enclave and therefore other VPN router to | |||
forward it to, | forward it to, | |||
o ensures that it has a tunnel mode security association (as | o ensures that it has a tunnel mode security association (as | |||
generally defined in [RFC2401] section 4) with that router, | generally defined in [RFC4301], Section 4) with that router, | |||
o encloses the encrypted datagram within another VPN (e.g. IPsec) | o encloses the encrypted datagram within another VPN (e.g., IPsec) | |||
and IP header, and | and IP header, and | |||
o forwards the encapsulated datagram toward the remote VPN Router. | o forwards the encapsulated datagram toward the remote VPN router. | |||
The receiving VPN Router reverses the steps: it | The receiving VPN router reverses the steps: | |||
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 [RFC4303]. | [RFC4301] 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 | |||
| | | | |||
Router -------Router | Router -------Router | |||
/------------------/ /------------------/ | /------------------/ /------------------/ | |||
Host Host Host Host Host Host | Host Host Host Host Host Host | |||
Figure 1: VPN-connected enclave | Figure 1: VPN-Connected Enclave | |||
An important point to understand is that the VPN tunnel, like other | An important point to understand is that the VPN tunnel, like other | |||
features of the routed network, are invisible to the host. The host | features of the routed network, are invisible to the host. The host | |||
can infer that "something out there" is affecting the Path MTU, | can infer that "something out there" is affecting the Path MTU, | |||
introducing delay, or otherwise affecting its data stream, but if | introducing delay, or otherwise affecting its data stream, but if | |||
properly implemented it should be able to adapt to these. The words | properly implemented, it should be able to adapt to these. The words | |||
"if properly implemented" are the bane of every network manager, | "if properly implemented" are the bane of every network manager, | |||
however; substandard implementations do demonstrably exist. | however; substandard implementations do demonstrably exist. | |||
Outside of the enclave, the hosts are essentially invisible. The | Outside of the enclave, the hosts are essentially invisible. The | |||
communicating enclaves look like a simple data exchange between peer | communicating enclaves look like a simple data exchange between peer | |||
hosts across a routed network, as shown in Figure 2. | hosts across a routed network, as shown in Figure 2. | |||
Hosts Not Visible | Hosts Not Visible | |||
/==================/ | /==================/ | |||
Router | Router | |||
skipping to change at page 6, line 47 | skipping to change at page 6, line 47 | |||
VPN-Router | VPN-Router | |||
/---------------------/ | /---------------------/ | |||
Inner Domain | Inner Domain | |||
/---------------------/ | /---------------------/ | |||
VPN-Router | VPN-Router | |||
| | | | |||
Router | Router | |||
/==================/ | /==================/ | |||
Hosts Not Visible | Hosts Not Visible | |||
Figure 2: VPN-connected enclave from exterior perspective | Figure 2: VPN-Connected Enclave from Exterior Perspective | |||
Such networks can be nested and re-used in a complex manner. As | Such networks can be nested and re-used in a complex manner. As | |||
shown in Figure 3 a pair of enclaves might communicate across a | shown in Figure 3, a pair of enclaves might communicate across a | |||
cipher text network which, for various reasons, is itself re- | ciphertext network that, for various reasons, is itself re-encrypted | |||
encrypted and transmitted across a larger cipher text network. The | and transmitted across a larger ciphertext network. The reasons for | |||
reasons for doing this vary, but they relate to information-hiding in | doing this vary, but they relate to information-hiding in the wider | |||
the wider network, different levels of security required for | network, different levels of security required for different enclosed | |||
different enclosed enclaves, and so on. | enclaves, and so on. | |||
Host Host Host Host Host Host | Host Host Host Host Host Host | |||
/------------------/ /------------------/ | /------------------/ /------------------/ | |||
Router -------Router | Router -------Router | |||
| | | | |||
VPN-Router VPN-Router VPN-Router | VPN-Router VPN-Router VPN-Router | |||
/---------------------/ /----------/ | /---------------------/ /----------/ | |||
Router -------------Router | Router -------------Router | |||
| | | | |||
VPN-Router VPN-Router | VPN-Router VPN-Router | |||
skipping to change at page 7, line 38 | skipping to change at page 7, line 38 | |||
| | | | |||
Router -------Router | Router -------Router | |||
/------------------/ /------------------/ | /------------------/ /------------------/ | |||
Host Host Host Host Host Host | Host Host Host Host Host Host | |||
Figure 3: Nested VPN | Figure 3: Nested VPN | |||
The key question this document explores is "how do reservations, and | The key question this document explores is "how do reservations, and | |||
preemption of reservations, work in such an environment?" | preemption of reservations, work in such an environment?" | |||
1.4. Signaled QoS technology | 1.4. Signaled QoS Technology | |||
The Integrated Services model for networking was originally proposed | The Integrated Services model for networking was originally proposed | |||
in [RFC1633]. In short, it divides all applications into two broad | in [RFC1633]. In short, it divides all applications into two broad | |||
classes: those that will adapt themselves to any available bandwidth, | classes: those that will adapt themselves to any available bandwidth, | |||
and those that will not or cannot. In its own words, | and those that will not or cannot. In the words of [RFC1633]: | |||
One class of applications needs the data in each packet by a | One class of applications needs the data in each packet by a | |||
certain time and, if the data has not arrived by then, the data | certain time and, if the data has not arrived by then, the data | |||
is essentially worthless; we call these "real-time" | is essentially worthless; we call these "real-time" | |||
applications. Another class of applications will always wait | applications. Another class of applications will always wait | |||
for data to arrive; we call these "elastic" applications. | for data to arrive; we call these "elastic" applications. | |||
The Integrated Services model defines data flows supporting | The Integrated Services model defines data flows supporting | |||
applications as either "real-time" or "elastic". It should be noted | applications as either "real-time" or "elastic". It should be noted | |||
that "real-time" traffic is also referred to as "inelastic" traffic, | that "real-time" traffic is also referred to as "inelastic" traffic, | |||
and that elastic traffic is occasionally referred to as "non-real- | and that elastic traffic is occasionally referred to as "non-real- | |||
time." | time". | |||
In this view, the key issue is the so-called "playback point": a | In this view, the key issue is the so-called "playback point": a | |||
real-time application is considered to have a certain point in time | real-time application is considered to have a certain point in time | |||
at which data describing the next sound, picture, or whatever to be | at which data describing the next sound, picture, or whatever to be | |||
delivered to a display device or forfeit its utility, while an | delivered to a display device or forfeit its utility, while an | |||
elastic application has no such boundary. Another way to look at the | elastic application has no such boundary. Another way to look at the | |||
difference is that real-time applications have an irreducible lower | difference is that real-time applications have an irreducible lower | |||
bound on their bandwidth requirements. For example, the typical | bound on their bandwidth requirements. For example, the typical | |||
G.711 payload is delivered in 160 byte samples (plus 40 bytes of IP/ | G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/ | |||
UDP/RTP headers) at 20 millisecond intervals. This will yield 80 | UDP/RTP headers) at 20 millisecond intervals. This will yield 80 | |||
KBPS of bandwidth, without silence suppression, and not accounting | kbps of bandwidth, without silence suppression, and not accounting | |||
for the layer 2 overhead. To operate in real-time, a G.711 codec | for the layer 2 overhead. To operate in real-time, a G.711 codec | |||
requires the network over which its data will be delivered to support | requires the network over which its data will be delivered to support | |||
communications at 80 KBPS at the IP layer with roughly constant end | communications at 80 kbps at the IP layer with roughly constant end- | |||
to end delay and nominal or no loss. If this is not possible (if | to-end delay and nominal or no loss. If this is not possible (if | |||
there is significant loss or wide variations in delay), voice quality | there is significant loss or wide variations in delay), voice quality | |||
will suffer. On the other hand, if many megabits of capacity are | will suffer. On the other hand, if many megabits of capacity are | |||
available, the G.711 codec will not increase its bandwidth | available, the G.711 codec will not increase its bandwidth | |||
requirements either. Although adaptive codecs exist, (e.g., G.722.2 | requirements either. Although adaptive codecs exist (e.g., G.722.2 | |||
or G.726), the adaptive mechanism can either require greater or | or G.726), the adaptive mechanism can either require greater or | |||
lesser bandwidth and can adapt only within a certain range of | lesser bandwidth and can adapt only within a certain range of | |||
bandwidth requirements beyond which the quality of the data flow | bandwidth requirements beyond which the quality of the data flow | |||
required is not met. Elastic applications, however, will generally | required is not met. Elastic applications, however, will generally | |||
adapt themselves to any network: if the bottleneck provides 9600 bits | adapt themselves to any network: if the bottleneck provides 9600 bits | |||
per second, a web transfer or electronic mail exchange will happen at | per second, a Web transfer or electronic mail exchange will happen at | |||
9600 bits per second, and if hundreds of megabits are available, the | 9600 bits per second, and if hundreds of megabits are available, the | |||
TCP (or SCTP) transport will increase their transfer rate in an | TCP (or SCTP) transport will increase their transfer rate in an | |||
attempt to reduce the time required to accomplish the transfer. | attempt to reduce the time required to accomplish the transfer. | |||
For real-time applications, those that require data to be delivered | For real-time applications, those that require data to be delivered | |||
end to end with at least a certain rate and with delays varying | end to end with at least a certain rate and with delays varying | |||
between stated bounds, the Integrated Services architecture proposes | between stated bounds, the Integrated Services architecture proposes | |||
the use of a signaling protocol that allows the communicating | the use of a signaling protocol that allows the communicating | |||
applications and the network to communicate about the application | applications and the network to communicate about the application | |||
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 the Resource Reservation Protocol (RSVP) and Next Steps in | |||
Signaling (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.5. The Resource Reservation Protocol (RSVP) | 1.5. 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 specifies | Integrated Services [RFC2210]. Conceptually, this protocol 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.ietf-tsvwg-rsvp-ipsec] and for more | for IPsec [RFC2207] and [RFC4860] and for more generic forms of | |||
generic forms of tunnels [RFC2746]. With the later development of | tunnels [RFC2746]. With the later development of the Differentiated | |||
the Differentiated Services Architecture [RFC2475], definitions were | Services Architecture [RFC2475], definitions were added to specify | |||
added to specify the DSCP [RFC2474] to be used by a standard RSVP | the Differentiated Services Code Point (DSCP) [RFC2474] to be used by | |||
data flow in [RFC2996] and to use a pair of IP addresses and a DSCP | a standard RSVP data flow in [RFC2996] and to use a pair of IP | |||
as the identifying information for a data flow [RFC3175]. | addresses and a DSCP 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 as in [RFC3181] | |||
in [RFC3181] which in essence specifies that a reservation installed | -- a reservation that is installed in the network using an Preemption | |||
in the network using an Preemption Priority and retained using a | Priority and retained using a separate Defending Priority may be | |||
separate Defending Priority may be removed by the network via an RESV | removed by the network via an RESV Error signal that removes the | |||
Error signal that removes the entire reservation. This has issues, | entire reservation. This has issues, however, in that the matter is | |||
however, in that the matter is often not quite so black and white. | often not quite so black and white. If the issue is that an existing | |||
If the issue is that an existing reservation for 80 KBPS can no | reservation for 80 kbps can no longer be sustained but a 60 kbps | |||
longer be sustained but a 60 KBPS reservation could, it is possible | reservation could, it is possible that a VoIP sender could change | |||
that a VoIP sender could change from a G.711 codec to a G.729 codec | from a G.711 codec to a G.729 codec and achieve that. Or, if there | |||
and achieve that. Or, if there are multiple sessions in a tunnel or | are multiple sessions in a tunnel or other aggregate, one of the | |||
other aggregate, one of the calls could be eliminated leaving | calls could be eliminated leaving capacity for the others. [RFC4495] | |||
capacity for the others. [RFC4495] seeks to address this issue. | seeks to 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 | |||
of the packets that are identified, but the IP addresses of the | of the packets that are identified, but the IP addresses of the | |||
ingress and egress devices in the network, and the DSCP that the | ingress and egress devices in the network, and the DSCP that the | |||
traffic will use, | traffic will use. | |||
o The function of a reservation "aggregator", which operates in the | o The function of a reservation "aggregator", which operates in the | |||
ingress router and accepts individual reservations from the | ingress router and accepts individual reservations from the | |||
"customer" network which it aggregates into the ISP core in a | "customer" network. It aggregates the reservations into the ISP | |||
tunnel, an MPLS LSP, or as a traffic stream that it known to leave | core in a tunnel or an MPLS LSP, or as a traffic stream that is | |||
at the deaggregator, | known to leave at the deaggregator. | |||
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.ietf-tsvwg-rsvp-ipsec] or | of [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746]. | |||
[RFC2746]. | ||||
1.6. Logical structure of a VPN Router | 1.6. 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 | |||
interfaces to the protected enclave(s) and one or more interfaces to | more interfaces to the protected enclave(s) and one or more | |||
the outside world. On the latter, it structures some number of | interfaces to the outside world. On the latter, it structures some | |||
tunnels (in the case of an IPsec tunnel, having security | number of tunnels (in the case of an IPsec tunnel, having security | |||
associations) that it can treat as point to point interfaces from a | associations) that it can treat as point-to-point interfaces from a | |||
routing perspective. | routing perspective. | |||
+---------+ +-------+ +----+----+ +---------+ | +---------+ +-------+ +----+----+ +---------+ | |||
| RSVP | |Routing| |Net Guard| |IPsec Mgr| | | RSVP | |Routing| |Net Guard| |IPsec Mgr| | |||
+----+----+ +---+---+ +----+----+ +----+----+ | +----+----+ +---+---+ +----+----+ +----+----+ | |||
| | | | | | | | | | |||
+----+-----------+------------+-----------------+----+ | +----+-----------+------------+-----------------+----+ | |||
| IP | | | IP | | |||
+-----------+--------------------+------------+------+ | +-----------+--------------------+------------+------+ | |||
| | | | | | | | |||
skipping to change at page 11, line 25 | skipping to change at page 11, line 25 | |||
| |Decrypt for| |Decrypt for| | | |Decrypt for| |Decrypt for| | |||
| | Security | | Security | | | | Security | | Security | | |||
| |Association| |Association| | | |Association| |Association| | |||
| +-----+-----+ +----+------+ | | +-----+-----+ +----+------+ | |||
| | | | | | | | |||
+-----------+------------+ +-----+------------+------+ | +-----------+------------+ +-----+------------+------+ | |||
| Plain text | | Cipher text | | | Plain text | | Cipher text | | |||
| Interface | | Interface | | | Interface | | Interface | | |||
+------------------------+ +-------------------------+ | +------------------------+ +-------------------------+ | |||
Figure 4: Logical structure of a VPN Router | Figure 4: Logical Structure of a VPN Router | |||
The encrypt/decrypt unit may be implemented as a function of the | The encrypt/decrypt unit may be implemented as a function of the | |||
plain text router, as a function on its interface card, or as a | plain text router, as a function on its interface card, or as a | |||
function of an external device with a private interface to the IP | function of an external device with a private interface to the IP | |||
routing functionality of the plain text router. These are | routing functionality of the plain text router. These are | |||
conceptually equivalent, although there are practical differences in | conceptually equivalent, although there are practical differences in | |||
implementation. The key issue is that when IP routing presents a | implementation. The key issue is that when IP routing presents a | |||
message to the encrypt/decrypt unit for transmission, it must also be | message to the encrypt/decrypt unit for transmission, it must also be | |||
presented with the IP address of the plain text routing peer, whether | presented with the IP address of the plain text routing peer, whether | |||
host or router, to which the security association must be | host or router, to which the security association must be | |||
established. This IP Address is used to select (and perhaps create) | established. This IP Address is used to select (and perhaps create) | |||
the security association, and in turn select the appropriate set of | the security association, and in turn select the appropriate set of | |||
security parameters. This could also be implemented by presenting | security parameters. This could also be implemented by presenting | |||
the local Security Parameter Index (SPI) for the data, if it has been | the local Security Parameter Index (SPI) for the data, if it has been | |||
created out of band by the Network Management Process. | created out of band by the Network Management Process. | |||
In addition, it is necessary for aggregated signaling to be generated | In addition, it is necessary for aggregated signaling to be generated | |||
for the cipher text domain. This may be accomplished in several | for the ciphertext domain. This may be accomplished in several ways: | |||
ways: | ||||
o by having the RSVP process on the plain text router generate the | o by having the RSVP process on the plain text router generate the | |||
messages and having the encrypt/decrypt unit bypass them into the | messages and having the encrypt/decrypt unit bypass them into the | |||
cipher text network | cipher text network | |||
o by having the plain text RSVP Process advise a process in the | o by having the plaintext RSVP process advise a process in the | |||
encrypt/decrypt implementation of what needs to be generated using | encrypt/decrypt implementation of what needs to be generated using | |||
some local exchange, and having it generate such messages, or | some local exchange, and having it generate such messages, or | |||
o by having a separate parallel network management system | o by having a separate parallel network management system | |||
intermediate between the plain text and cipher text routers, in | intermediate between the plain text and cipher text routers, in | |||
which case the encrypt/decrypt unit and the parallel network | which case, the encrypt/decrypt unit and the parallel network | |||
system must use the same address and the cipher text router must | system must use the same address, and the ciphertext router must | |||
distinguish between traffic for them based on SPI or the presence | distinguish between traffic for them based on SPI or the presence | |||
of encryption. | of encryption. | |||
Control plane signaling using this additional path is described in | Control plane signaling using this additional path is described in | |||
Section 3.2. The information flow between the plain text and cipher | Section 3.2. The information flow between the plaintext and | |||
text domains includes | ciphertext domains includes | |||
o IP datagrams via the encrypt/decrypt unit, | o IP datagrams via the encrypt/decrypt unit, | |||
o RSVP signaling via the bypass path, | o RSVP signaling via the bypass path, | |||
o Control information coordinating security associations, and | o Control information coordinating security associations, and | |||
o precious little else. | o precious little else. | |||
2. Reservation and Preemption in a nested VPN | 2. Reservation and Preemption in a Nested VPN | |||
/ \ | / \ | |||
( +--+ +--+ enclave ) ,---------. | ( +--+ +--+ enclave ) ,---------. | |||
.----------. \ |H2+---+R2| / ,-' ` | .----------. \ |H2+---+R2| / ,-' ` | |||
+--+ +--+`--.\ +--+ ++-+ / / +--+ +--+ | +--+ +--+`--.\ +--+ ++-+ / / +--+ +--+ | |||
|H1+---+R1| \`. | ,' / |R3+---+H3| | |H1+---+R1| \`. | ,' / |R3+---+H3| | |||
+--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+ | +--+ +-++ ) '--. +----++ _.-' ( ++-+ +--+ | |||
| / _.`---|VPN2||''-. \ | | | / _.`---|VPN2||''-. \ | | |||
enclave +----+-i.--'' +----++ `----.\ +----+ enclave | enclave +----+-i.--'' +----++ `----.\ +----+ enclave | |||
--------|VPN1|' | ``|VPN3| , | --------|VPN1|' | ``|VPN3| , | |||
skipping to change at page 13, line 48 | skipping to change at page 13, line 48 | |||
+----+.`----. +----+ _.--'' ,+----+ | +----+.`----. +----+ _.--'' ,+----+ | |||
| \ `--=.-|VPN5|---:' / | | | \ `--=.-|VPN5|---:' / | | |||
+--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+ | +--+ ++-+ : ,-'' +----+ `--. ; ++-+ +--+ | |||
|H6+---+R6| | ,' | `.| |R4+---+H4| | |H6+---+R6| | ,' | `.| |R4+---+H4| | |||
+--+ +--+ ;/ +--+ ++-+ : +--+ +--+ | +--+ +--+ ;/ +--+ ++-+ : +--+ +--+ | |||
// |H5+---+R5| \ | // |H5+---+R5| \ | |||
enclave ,'( +--+ +--+ `. enclave | enclave ,'( +--+ +--+ `. enclave | |||
`. ,' \ enclave / '-. , | `. ,' \ enclave / '-. , | |||
`-------' \ / `-------' | `-------' \ / `-------' | |||
Figure 5: Reservations in a nested VPN | Figure 5: Reservations in a Nested VPN | |||
Let us discuss how a resource reservation protocol, and specifically | Let us discuss how a resource reservation protocol, and specifically | |||
RSVP, might be used in a nested virtual private network. | RSVP, might be used in a nested virtual private network. | |||
2.1. Reservation in a nested VPN | 2.1. Reservation in a Nested VPN | |||
A reservation in a nest VPN is very much like a reservation in any | A reservation in a nested VPN is very much like a reservation in any | |||
other network, with one exception: it is composed of multiple | other network, with one exception: it is composed of multiple | |||
reservations that must be coordinated. These include a reservation | reservations that must be coordinated. These include a reservation | |||
within the originating and receiving enclaves and a reservation at | within the originating and receiving enclaves and a reservation at | |||
each layer of the VPN, as shown in Figure 5. | each layer of the VPN, as shown in Figure 5. | |||
Thus, when a host in one enclave opens a reservation to a host in | Thus, when a host in one enclave opens a reservation to a host in | |||
another enclave, a reservation of the appropriate type and size is | another enclave, a reservation of the appropriate type and size is | |||
created end to end. As it traverses the VPN Router leaving its | created end to end. As it traverses the VPN router leaving its | |||
enclave, the reservation information and the data are placed within | enclave, the reservation information and the data are placed within | |||
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 provision that if routing varies by DSCP then it must be a | the one provision that if routing varies by DSCP, then it must be a | |||
DSCP 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 | |||
service for voice traffic") and asserts a [RFC3182] credential | for voice traffic") and asserts a [RFC3182] credential indicating its | |||
indicating its user (which may be a person or a class of persons). | user (which may be a person or a class of persons). As specified in | |||
As specified in [RFC3181] it also specifies its Preemption Priority | [RFC3181], it also specifies its Preemption Priority and its | |||
and its Defending Priority; these enable the Preemption Priority of a | Defending Priority; these enable the Preemption Priority of a new | |||
new session to be compared with the Defending Priority of previously | 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 ciphertext side of the VPN router, no guarantees result unless | |||
unless the VPN Router likewise sets up a reservation to the peer VPN | the VPN router likewise sets up a reservation to the peer VPN Router | |||
Router across the cipher text domain. Thus, the VPN Router sets up | across the ciphertext domain. Thus, the VPN router sets up an | |||
an [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC3175] reservation to | [RFC2207], [RFC4860], or [RFC3175] reservation to its peer. | |||
its peer. | ||||
The Session Object defined by [RFC2207] or | The Session Object defined by [RFC2207] or [RFC4860] contains a field | |||
[I-D.ietf-tsvwg-rsvp-ipsec] contains a field called a "virtual | called a "virtual destination port", which allows the multiplexing of | |||
destination port", which allows the multiplexing of many reservations | many reservations over a common security association and, in the | |||
over a common security association, and in the latter case, a common | latter case, a common DSCP value. Thus, the voice traffic at every | |||
DSCP value. Thus, the voice traffic at every precedence level might | precedence level might use the Expedited Forwarding (EF) DSCP and | |||
use the EF DSCP and service as described in [RFC3246], but the | service as described in [RFC3246], but the reservations would be for | |||
reservations would be for "the aggregate of voice sessions at | "the aggregate of voice sessions at precedence Pn between these VPN | |||
precedence Pn between these VPN Routers". This would allow the | routers". This would allow the network administration to describe | |||
network administration to describe policies with multiple thresholds, | policies with multiple thresholds, such as "a new session at | |||
such as "a new session at precedence Pn may be accepted if the total | precedence Pn may be accepted if the total reserved bandwidth does | |||
reserved bandwidth does not exceed threshold Qn; if it is necessary | not exceed threshold Qn; if it is necessary and sufficient to accept | |||
and sufficient to accept the reservation, existing reservations at | the reservation, existing reservations at lower precedences may be | |||
lower precedences may be preemptively reduced to make acceptance of | preemptively reduced to make acceptance of the new session possible". | |||
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 | |||
the IP packet is entirely contained within (such as is used to cross | the IP packet is entirely contained within (such as is used to cross | |||
a firewall), then the behavior of [RFC2746] is required of the | a firewall), then the behavior of [RFC2746] is required of the | |||
tunnel. That bearer will have the following characteristics: | tunnel. That bearer will have the following characteristics: | |||
o it will have a DSCP corollary to the DSCP for the data or the same | o it will have a DSCP corollary to the DSCP for the data or the same | |||
DSCP as the data it carries, | DSCP as the data it carries, | |||
o the reservations and data will be carried in security associations | o the reservations and data will be carried in security associations | |||
between the VPN Routers, and | between the VPN routers, and | |||
o the specification for the reservation for the tunnel itself will | o the specification for the reservation for the tunnel itself will | |||
not be less than the sum of the requirements of the aggregated | not be less than the sum of the requirements of the aggregated | |||
reservations. | reservations. | |||
The following requirements relationships apply between the set of | The following requirements relationships apply between the set of | |||
enclosed reservations and the tunnel reservation: | enclosed reservations and the tunnel reservation: | |||
o The sum of the average rates of the contained reservations, having | o The sum of the average rates of the contained reservations, having | |||
been adjusted for the additional IP headers, will be less than or | been adjusted for the additional IP headers, will be less than or | |||
skipping to change at page 16, line 15 | skipping to change at page 16, line 15 | |||
This would differ only in the case that measurement-based admission | This would differ only in the case that measurement-based admission | |||
is in use in the tunnel but not in the end system. In that case, the | is in use in the tunnel but not in the end system. In that case, the | |||
tunnel's average bandwidth specification would be greater than or | tunnel's average bandwidth specification would be greater than or | |||
equal to the actual average offered traffic. Such systems are beyond | equal to the actual average offered traffic. Such systems are beyond | |||
the scope of this specification. | the scope of this specification. | |||
As a policy matter, it may be useful to note a quirk in the way | As a policy matter, it may be useful to note a quirk in the way | |||
Internet QoS works. If the policies for various precedence levels | Internet QoS works. If the policies for various precedence levels | |||
specify different thresholds (e. g., "to accept a new routine call, | specify different thresholds (e. g., "to accept a new routine call, | |||
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 call with a higher precedence level, the total reserved | |||
after admission may not exceed X+Y, and this may be achieved by | bandwidth after admission may not exceed X+Y, and this may be | |||
preempting a lower precedence level call"), the bandwidth Y | achieved by preempting a call with a lower precedence level"), the | |||
effectively comes from the bandwidth in use by elastic traffic rather | bandwidth Y effectively comes from the bandwidth in use by elastic | |||
than forcing a preemption event. | traffic rather than forcing a preemption event. | |||
2.2. Preemption in a nested VPN | 2.2. Preemption in a Nested VPN | |||
As discussed in Section 1.5 preemption is specified in [RFC3181] and | As discussed in Section 1.5, preemption is specified in [RFC3181] and | |||
further addressed in [RFC4495]. The issue is that in many cases the | further addressed in [RFC4495]. The issue is that in many cases the | |||
need is to reduce the bandwidth of a reservation due to a change in | need is to reduce the bandwidth of a reservation due to a change in | |||
the network, not simply to remove the reservation. In the case of an | the network, not simply to remove the reservation. In the case of an | |||
end system originated reservation, the end system might be able to | end-system-originated reservation, the end system might be able to | |||
accommodate the need through a change of codec; in the case of an | accommodate the need through a change of codec; in the case of an | |||
aggregate of some kind, it could reduce the bandwidth it is sending | aggregate of some kind, it could reduce the bandwidth it is sending | |||
by dropping one or more reservations entirely. | by dropping one or more reservations 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 | |||
the job, and | the job, and | |||
o signal them to reduce their bandwidth accordingly. | o signal them to reduce their bandwidth accordingly. | |||
It is possible, of course, that it is signaling them to reduce their | It is possible, of course, that it is signaling them to reduce their | |||
bandwidth to zero, which is functionally equivalent to removing the | bandwidth to zero, which is functionally equivalent to removing the | |||
reservation as described in [RFC3181]. | reservation as described in [RFC3181]. | |||
In the routers in the core, an additional case arises. One could | In the routers in the core, an additional case arises. One could | |||
imagine that some enclave presents the VPN with a single session, and | imagine that some enclave presents the VPN with a single session, and | |||
that session has a higher precedence level. If some interior link is | that session has a higher precedence level. If some interior link is | |||
congested (e. g., the reserved bandwidth will exceed policy if the | congested (e. g., the reserved bandwidth will exceed policy if the | |||
call is admitted), a session between a different pair of VPN Routers | call is admitted), a session between a different pair of VPN routers | |||
must be preempted. More generally, in selecting a reservation to | must be preempted. More generally, in selecting a reservation to | |||
preempt, the core router must always select a reservation at the | preempt, the core router must always select a reservation at the | |||
lowest available Defending Priority. This is the reason that various | lowest available Defending Priority. This is the reason that various | |||
precedence levels must be kept separate in the core. | precedence levels must be kept separate in the core. | |||
2.3. Working through an example | 2.3. Working through an Example | |||
The network in Figure 5 shows three security layers: six plain text | The network in Figure 5 shows three security layers: six plain text | |||
enclaves around the periphery, two cipher text domains connecting | enclaves around the periphery, two ciphertext domains connecting them | |||
them at one layer (referred to in the diagram as an "interface | at one layer (referred to in the diagram as an "interface domain"), | |||
domain"), and a third cipher text domain connecting the first two | and a third ciphertext domain connecting the first two (referred to | |||
(referred to in the diagram as an "inner domain"). The following | in the diagram as an "inner domain"). The following distribution of | |||
distribution of information exists: | information exists: | |||
o Each enclave has access to general routing information concerning | o Each enclave has access to general routing information concerning | |||
other enclaves it is authorized to communicate with: systems in it | other enclaves it is authorized to communicate with: systems in it | |||
can translate a DNS name for a remote host or domain and obtain | can translate a DNS name for a remote host or domain and obtain | |||
the corresponding address or prefix. | the corresponding address or prefix. | |||
o Each enclave router also has specific routing information | o Each enclave router also has specific routing information | |||
regarding its own enclave. | regarding its own enclave. | |||
o A default route is distributed within the enclave, pointing to its | o A default route is distributed within the enclave, pointing to its | |||
VPN Router. | VPN router. | |||
o VPN Routers 1-6 are able to translate remote enclave prefixes to | o VPN Routers 1-6 are able to translate remote enclave prefixes to | |||
the appropriate remote enclave's VPN Router addresses. | the appropriate remote enclave's VPN router addresses. | |||
o Each interface domain has access to general routing information | o Each interface domain has access to general routing information | |||
concerning the other interface domains, but not the enclaves. | concerning the other interface domains, but not the enclaves. | |||
Systems in an interface domain can translate a DNS name for a | Systems in an interface domain can translate a DNS name for a | |||
remote interface domain and obtain the corresponding address or | remote interface domain and obtain the corresponding address or | |||
prefix. | prefix. | |||
o Each interface domain router also has specific routing information | o Each interface domain router also has specific routing information | |||
regarding its own interface domain. | regarding its own interface domain. | |||
o A default route is distributed within the interface domain, | o A default route is distributed within the interface domain, | |||
pointing to the "inner" VPN Router. | pointing to the "inner" VPN router. | |||
o VPN Routers 7 and 8 are able to translate remote interface domain | o VPN Routers 7 and 8 are able to translate remote interface domain | |||
prefixes to remote VPN Router addresses. | prefixes to remote VPN router addresses. | |||
o Routers in the inner domain have routing information for that | o Routers in the inner domain have routing information for that | |||
domain only. | domain only. | |||
While the example shows three levels, there is nothing magic about | While the example shows three levels, there is nothing magic about | |||
the number three. The model can be extended to any number of | the number three. The model can be extended to any number of | |||
concentric layers. | concentric layers. | |||
Note that this example places unidirectional reservations in the | Note that this example places unidirectional reservations in the | |||
forward direction. In voice and video applications, one generally | forward direction. In voice and video applications, one generally | |||
has a reservation in each direction. The reverse direction is not | has a reservation in each direction. The reverse direction is not | |||
discussed, for the sake of clarity, but operates in the same way in | discussed, for the sake of clarity, but operates in the same way in | |||
the reverse direction and uses the same security associations. | the reverse direction and uses the same security associations. | |||
2.3.1. Initial routine reservations - generating network state | 2.3.1. Initial Routine Reservations - Generating Network State | |||
Now let us install a set of reservations from H1 to H4, H2 to H5, and | Now let us install a set of reservations from H1 to H4, H2 to H5, and | |||
H3 to H6, and for the sake of argument let us presume that these are | H3 to H6, and for the sake of argument, let us presume that these are | |||
at the "routine" precedence. H1, H2, and H3 each initiate an PATH | at the "routine" precedence. H1, H2, and H3 each initiate a PATH | |||
signal describing their traffic. For the sake of argument, let us | signal describing their traffic. For the sake of argument, let us | |||
presume that H1's reservation is for an [RFC2205] session, H2's | presume that H1's reservation is for an [RFC2205] session, H2's | |||
reservation is for a session encrypted using IPsec, and therefore | reservation is for a session encrypted using IPsec, and therefore | |||
depends on [RFC2207] and H3 (which is a PSTN Gateway) sends an | depends on [RFC2207], and H3 (which is a Public Switched Telephone | |||
[RFC3175] reservation comprising a number of distinct sessions. | Network (PSTN) gateway) sends an [RFC3175] reservation comprising a | |||
Since these are going to H4, H5, and H6 respectively, the default | number of distinct sessions. Since these are going to H4, H5, and | |||
route leads them to VPN1, VPN2, and VPN3 respectively. | H6, respectively, the default route leads them to VPN1, VPN2, and | |||
VPN3, respectively. | ||||
The VPN Routers each ensure that they have an appropriate security | The VPN routers each ensure that they have an appropriate security | |||
association or tunnel open to the indicated remote VPN Router (VPN4, | association or tunnel open to the indicated remote VPN router (VPN4, | |||
VPN5, or VPN6). This will be a security association or tunnel for | VPN5, or VPN6). This will be a security association or tunnel for | |||
the indicated application at the indicated precedence level. Having | the indicated application at the indicated precedence level. Having | |||
accomplished that, it will place the PATH signal into the security | accomplished that, it will place the PATH signal into the security | |||
association and forward it. If such does not already exist, | association and forward it. If such does not already exist, | |||
following [RFC3175] 's aggregation model, it will now open a | following [RFC3175] 's aggregation model, it will now open a | |||
reservation (send a PATH signal) for the tunnel/SA within the | reservation (send a PATH signal) for the tunnel/SA within the | |||
interface domain; if the reservation does exist, the VPN Router will | interface domain; if the reservation does exist, the VPN router will | |||
increase the bandwidth indicated in the ADSPEC appropriately. In | increase the bandwidth indicated in the ADSPEC appropriately. In | |||
this example, these tunnel/SA reservations will follow the default | this example, these tunnel/SA reservations will follow the default | |||
route to VPN7. | route to VPN7. | |||
VPN7 ensures that it has an appropriate security association or | VPN7 ensures that it has an appropriate security association or | |||
tunnel open to VPN8. This will be a security association or tunnel | tunnel open to VPN8. This will be a security association or tunnel | |||
for the indicated application at the indicated precedence level. | for the indicated application at the indicated precedence level. | |||
Having accomplished that, it will place the PATH signal into the | Having accomplished that, it will place the PATH signal into the | |||
security association and forward it. If such does not already exist, | security association and forward it. If such does not already exist, | |||
following [RFC3175] 's aggregation model, it will now open a | following [RFC3175] 's aggregation model, it will now open a | |||
reservation (send a PATH signal) for the tunnel/SA within the | reservation (send a PATH signal) for the tunnel/SA within the | |||
interface domain; if the reservation does exist, the VPN Router will | interface domain; if the reservation does exist, the VPN router will | |||
increase the bandwidth indicated in the ADSPEC appropriately. In | increase the bandwidth indicated in the ADSPEC appropriately. In | |||
this example, this tunnel/SA reservation is forwarded to VPN8. | this example, this tunnel/SA reservation is forwarded to VPN8. | |||
VPN8 acts as an [RFC3175] deaggregator for the inner domain. This | VPN8 acts as an [RFC3175] deaggregator for the inner domain. This | |||
means that it receives the PATH signal for the inner domain | means that it receives the PATH signal for the inner domain | |||
reservation and stores state, decrypts the data stream from VPN7, | reservation and stores state, decrypts the data stream from VPN7, | |||
operates on the RSVP signals as an RSVP-configured router, and | operates on the RSVP signals as an RSVP-configured router, and | |||
forwards the received IP datagrams (including the updated PATH | forwards the received IP datagrams (including the updated PATH | |||
signals) into its interface domain. The PATH signals originated by | signals) into its interface domain. The PATH signals originated by | |||
VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and | VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and | |||
skipping to change at page 19, line 23 | skipping to change at page 19, line 26 | |||
the interface domain reservation and stores state, decrypts the data | the interface domain reservation and stores state, decrypts the data | |||
stream from its peer, operates on the RSVP signals as an RSVP- | stream from its peer, operates on the RSVP signals as an RSVP- | |||
configured router, and forwards the received IP datagrams (including | configured router, and forwards the received IP datagrams (including | |||
the updated PATH signals) into its enclave. The PATH signals | the updated PATH signals) into its enclave. The PATH signals | |||
originated by H1, H2, and H3 are therefore forwarded towards H4, H5, | originated by H1, H2, and H3 are therefore forwarded towards H4, H5, | |||
and H6 according to the routing of the enclave. | and H6 according to the routing of the enclave. | |||
H4, H5, and H6 now receive the original PATH signals and deliver them | H4, H5, and H6 now receive the original PATH signals and deliver them | |||
to their application. | to their application. | |||
2.3.2. Initial routine reservations - request reservation | 2.3.2. Initial Routine Reservations - Request Reservation | |||
The application in H4, H5, and H6 decides to install the indicated | The application in H4, H5, and H6 decides to install the indicated | |||
reservations, meaning that they now reply with RESV signals. These | reservations, meaning that they now reply with RESV signals. These | |||
signals request the bandwidth reservation. Following the trail left | signals request the bandwidth reservation. Following the trail left | |||
by the PATH signals, the RESV signals traipse back to their | by the PATH signals, the RESV signals traipse back to their | |||
respective sources. The state left by the PATH signals leads them to | respective sources. The state left by the PATH signals leads them to | |||
VPN4, VPN5, and VPN6 respectively. If the routers in the enclaves | VPN4, VPN5, and VPN6, respectively. If the routers in the enclaves | |||
are configured for RSVP, this will be explicitly via R4, R5, or R6; | are configured for RSVP, this will be explicitly via R4, R5, or R6; | |||
if they are not, routing will lead them through those routers. | if they are not, routing will lead them through those routers. | |||
The various RSVP-configured routers en route in the enclave | The various RSVP-configured routers en route in the enclave | |||
(including the VPN Router on the "enclave" side) will verify that | (including the VPN router on the "enclave" side) will verify that | |||
there is sufficient bandwidth on their links and that any other | there is sufficient bandwidth on their links and that any other | |||
stated policy is also met. Having accomplished that, each will | stated policy is also met. Having accomplished that, each will | |||
update its reservation state and forward the RESV signal to the next. | update its reservation state and forward the RESV signal to the next. | |||
The VPN Routers will also each generate an RESV for the reservation | The VPN routers will also each generate an RESV for the reservation | |||
within the interface domain, attempting to set or increase the | within the interface domain, attempting to set or increase the | |||
bandwidth of the reservation appropriately. | bandwidth of the reservation appropriately. | |||
The various RSVP-configured routers en route in the interface domain | The various RSVP-configured routers en route in the interface domain | |||
(including VPN8) will verify that there is sufficient bandwidth on | (including VPN8) will verify that there is sufficient bandwidth on | |||
their links and that any other stated policy is also met. Having | their links and that any other stated policy is also met. Having | |||
accomplished that, each will update its reservation state and forward | accomplished that, each will update its reservation state and forward | |||
the RESV signal to the next. VPN8 will also generate an RESV for the | the RESV signal to the next. VPN8 will also generate an RESV for the | |||
reservation within the inner domain, attempting to set or increase | reservation within the inner domain, attempting to set or increase | |||
the bandwidth of the reservation appropriately. This gets the | the bandwidth of the reservation appropriately. This gets the | |||
skipping to change at page 20, line 32 | skipping to change at page 20, line 35 | |||
the interface domain reservation and stores state, decrypts the data | the interface domain reservation and stores state, decrypts the data | |||
stream from its peer, operates on the RSVP signals as an RSVP- | stream from its peer, operates on the RSVP signals as an RSVP- | |||
configured router, and forwards the received IP datagrams (including | configured router, and forwards the received IP datagrams (including | |||
the updated RESV signals) into its enclave. The RESV signals | the updated RESV signals) into its enclave. The RESV signals | |||
originated by H4, H5, and H6 are therefore forwarded towards H1, H2, | originated by H4, H5, and H6 are therefore forwarded towards H1, H2, | |||
and H3 according to the routing of the enclave. | and H3 according to the routing of the enclave. | |||
H1, H2, and H3 now receive the original RESV signals and deliver them | H1, H2, and H3 now receive the original RESV signals and deliver them | |||
to their application. | to their application. | |||
2.3.3. Installation of a reservation using precedence | 2.3.3. Installation of a Reservation Using Precedence | |||
Without going through the details called out in Section 2.3.1 and | Without going through the details called out in Sections 2.3.1 and | |||
Section 2.3.2 if sufficient bandwidth exists to support them, | 2.3.2, if sufficient bandwidth exists to support them, reservations | |||
reservations of other precedence levels or other applications may | of other precedence levels or other applications may also be | |||
also be installed across this network. If the "routine" reservations | installed across this network. If the "routine" reservations already | |||
already described are for voice, for example, and sufficient | described are for voice, for example, and sufficient bandwidth is | |||
bandwidth is available under the relevant policy, a reservation for | available under the relevant policy, a reservation for voice at the | |||
voice at the "priority" precedence level might be installed. Due to | "priority" precedence level might be installed. Due to the mechanics | |||
the mechanics of preemption, however, this would not expand the | of preemption, however, this would not expand the existing "routine" | |||
existing "routine" reservations in the interface and inner domains, | reservations in the interface and inner domains, as doing this causes | |||
as doing this causes loss of information - how much of the | loss of information - how much of the reservation is now "routine" | |||
reservation is now "routine" and how much is "priority"? Rather, | and how much is "priority"? Rather, this new reservation will open | |||
this new reservation will open up a separate set of tunnels or | up a separate set of tunnels or security associations for traffic of | |||
security associations for traffic of its application class at its | its application class at its precedence between that aggregator and | |||
precedence between that aggregator and deaggregator. | deaggregator. | |||
As a side note, there is an opportunity here that does not exist in | As a side note, there is an opportunity here that does not exist in | |||
the PSTN. In the PSTN, all circuits are potentially usable by any | the PSTN. In the PSTN, all circuits are potentially usable by any | |||
PSTN application under a certain set of rules (H channels, such as | PSTN application under a certain set of rules (H channels, such as | |||
are used by video streams, must be contiguous and ordered). As such, | those used by video streams, must be contiguous and ordered). As | |||
if a channel is not made available to routine traffic but is made | such, if a channel is not made available to routine traffic but is | |||
available to priority traffic, the operator is potentially losing | made available to priority traffic, the operator is potentially | |||
revenue on the reserved bandwidth and deserves remuneration. | losing revenue on the reserved bandwidth and deserves remuneration. | |||
However, in the IP Internet, some bandwidth must be kept for basic | However, in the IP Internet, some bandwidth must be kept for basic | |||
functions such as routing, and in general policies will not permit | functions such as routing, and, in general, policies will not permit | |||
100% of the bandwidth on an interface to be allocated to one | 100% of the bandwidth on an interface to be allocated to one | |||
application at one precedence. As a result, it may be acceptable to | application at one precedence. As a result, it may be acceptable to | |||
permit a certain portion (e. g. 50%) to be used by routine voice and | permit a certain portion (e.g., 50%) to be used by routine voice and | |||
a larger amount (e. g. 60%) to be used by voice at a higher | a larger amount (e.g., 60%) to be used by voice at a higher | |||
precedence level. Under such a policy, a higher precedence | precedence level. Under such a policy, a higher precedence | |||
reservation for voice might not result in the preemption of a routine | reservation for voice might not result in the preemption of a routine | |||
call, but rather impact elastic traffic, and might be accepted at a | call, but rather impact elastic traffic, and might be accepted at a | |||
time that a new reservation of lower precedence might be denied. | time that a new reservation of lower precedence might be denied. | |||
In microwave networks, such as satellite or mobile ad hoc, one could | In microwave networks, such as satellite or mobile ad hoc, one could | |||
also imagine network management intervention that could change the | also imagine network management intervention that could change the | |||
characteristics of the radio signal to increase the bandwidth under | characteristics of the radio signal to increase the bandwidth under | |||
some appropriate policy. | some appropriate policy. | |||
2.3.4. Installation of a reservation using preemption | 2.3.4. Installation of a Reservation Using Preemption | |||
So we now have a number of reservations across the network described | So we now have a number of reservations across the network described | |||
in Figure 5 including several reservations at "routine" precedence | in Figure 5 including several reservations at "routine" precedence | |||
and one at "priority" precedence. For sake of argument, let us | and one at "priority" precedence. For sake of argument, let us | |||
presume that the link from VPN7 to R9 is now fully utilized - all of | presume that the link from VPN7 to R9 is now fully utilized - all of | |||
the bandwidth allocated by policy to voice at the routine or priority | the bandwidth allocated by policy to voice at the routine or priority | |||
level has been reserved. Let us further imagine that a new | level has been reserved. Let us further imagine that a new | |||
"priority" reservation is now placed from H3 to H6. | "priority" reservation is now placed from H3 to H6. | |||
The process described in Section 2.3.1 is followed, resulting in PATH | The process described in Section 2.3.1 is followed, resulting in PATH | |||
state across the network for the new reservation. This is installed | state across the network for the new reservation. This is installed | |||
even though it is not possible to install a new reservation on | even though it is not possible to install a new reservation on VPN7- | |||
VPN7-R9, as it does not install any reservation and the network does | R9, as it does not install any reservation and the network does not | |||
not know whether H6 will ultimately require a reservation. | know whether H6 will ultimately require a reservation. | |||
The process described in Section 2.3.2 is also followed. The | The process described in Section 2.3.2 is also followed. The | |||
application in H6 decides to install the indicated reservation, | application in H6 decides to install the indicated reservation, | |||
meaning that it now replies with an RESV signal. Following the trail | meaning that it now replies with an RESV signal. Following the trail | |||
left by the PATH signal, the RESV signal traipses back towards H3. | left by the PATH signal, the RESV signal traipses back towards H3. | |||
VPN6 and (if RSVP was configured) R6 verify that there is sufficient | VPN6 and (if RSVP was configured) R6 verify that there is sufficient | |||
bandwidth on their links and that any other stated policy is also | bandwidth on their links and that any other stated policy is also | |||
met. Having accomplished that, each will update its reservation | met. Having accomplished that, each will update its reservation | |||
state and forward the RESV signal to the next. VPN6 also generates | state and forward the RESV signal to the next. VPN6 also generates | |||
an RESV for the reservation within the interface domain, attempting | an RESV for the reservation within the interface domain, attempting | |||
to set or increase the bandwidth of the reservation appropriately. | to set or increase the bandwidth of the reservation appropriately. | |||
VPN6, R8, and VPN8's "interface domain" side now verify that there is | VPN6, R8, and VPN8's "interface domain" sides now verify that there | |||
sufficient bandwidth on their links and that any other stated policy | is sufficient bandwidth on their links and that any other stated | |||
is also met. Having accomplished that, each will update its | policy is also met. Having accomplished that, each will update its | |||
reservation state and forward the RESV signal to the next. VPN8 will | reservation state and forward the RESV signal to the next. VPN8 will | |||
also generate an RESV for the reservation within the inner domain, | also generate an RESV for the reservation within the inner domain, | |||
attempting to set or increase the bandwidth of the reservation | attempting to set or increase the bandwidth of the reservation | |||
appropriately. This gets the reservation to the inner deaggregator, | appropriately. This gets the reservation to the inner deaggregator, | |||
VPN8. | VPN8. | |||
VPN8's "inner domain" side and R9 now verify that there is sufficient | VPN8's "inner domain" side and R9 now verify that there is sufficient | |||
bandwidth on their links and that any other stated policy is also | bandwidth on their links and that any other stated policy is also | |||
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 | |||
existing reservation of lower bandwidth already existed, the previous | preexisting reservation of lower bandwidth already existed, the | |||
reservation would remain in place but the new bandwidth would not be | previous reservation would remain in place but the new bandwidth | |||
granted, and the originator (H6) would be informed. Let us clarify | would not be granted, and the originator (H6) would be informed. Let | |||
what it means to be at a stated precedence: it means that the | us clarify what it means to be at a stated precedence: it means that | |||
POLICY_DATA object in the RESV contains a Preemption Priority and a | the POLICY_DATA object in the RESV contains a Preemption Priority and | |||
Defending Priority with values specified in some memo. With | a Defending Priority with values specified in some memo. With | |||
precedence, [RFC4495]'s algorithm would have the Preemption Priority | precedence, [RFC4495]'s algorithm would have the Preemption Priority | |||
of the new reservation compared to the Defending Priority of extant | of the new reservation compared to the Defending Priority of extant | |||
reservations in the router, of which there are two: one VPN7->VPN8 at | reservations in the router, of which there are two: one VPN7->VPN8 at | |||
"routine" precedence and one VPN7->VPN8 at "priority" precedence. | "routine" precedence and one VPN7->VPN8 at "priority" precedence. | |||
Since the Defending Priority of routine reservation is less than the | Since the Defending Priority of routine reservation is less than the | |||
Preemption Priority of a "priority" reservation, the "routine" | Preemption Priority of a "priority" reservation, the "routine" | |||
reservation is selected. R9 determines that it will accept the | reservation is selected. R9 determines that it will accept the | |||
increase in its "priority" reservation VPN7->VPN8 and reduce the | increase in its "priority" reservation VPN7->VPN8 and reduce the | |||
corresponding "routine" reservation. Two processes now occur in | corresponding "routine" 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 | |||
[RFC4495] 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 | |||
aggregator, makes two changes. On the "inner domain" side, it marks | deaggregator, makes two changes. On the "inner domain" side, it | |||
its reservation down to the indicated rate (the most it is now | marks its reservation down to the indicated rate (the most it is now | |||
permitted to reserve), so that if an RESV Refresh event happens it | permitted to reserve), so that if an RESV Refresh event happens, it | |||
will request the specified rate. On the "interface domain" side it | will request the specified rate. On the "interface domain" side, it | |||
selects one or more of the relevant reservations by an algorithm of | selects one or more of the relevant reservations by an algorithm of | |||
its choosing and requests that it likewise reduce its rate. For sake | its choosing and requests that it likewise reduce its rate. For the | |||
of argument, let us imagine that the selected reservation is the one | sake of argument, let us imagine that the selected reservation is the | |||
to VPN5. The RESV Error now makes its way through R8 to VPN5, which | one to VPN5. The RESV Error now makes its way through R8 to VPN5, | |||
similarly reduces its bandwidth request to the stated amount and | which similarly reduces its bandwidth request to the stated amount | |||
passes a RESV Error signal on the "enclave" side requesting that the | and passes a RESV Error signal on the "enclave" side requesting that | |||
reservation be appropriately reduced. | the reservation be appropriately reduced. | |||
H5 is now faced with a decision. If the request is to reduce its | H5 is now faced with a decision. If the request is to reduce its | |||
reservation to zero, that is equivalent to tearing down the | reservation to zero, that is equivalent to tearing down the | |||
reservation. In this simple case, it sends an RESV Tear to tear down | reservation. In this simple case, it sends an RESV Tear to tear down | |||
the reservation entirely and advises its application to adjust its | the reservation entirely and advises its application to adjust its | |||
expectations of the session accordingly, which may mean shutting down | expectations of the session accordingly, which may mean shutting down | |||
the session. If the request is to reduce it below a certain value, | the session. If the request is to reduce it below a certain value, | |||
however, it may be possible for the application to do so and remain | however, it may be possible for the application to do so and remain | |||
viable. For example, if a VoIP application using a G. 711 codec (80 | viable. For example, if a VoIP application using a G. 711 codec (80 | |||
KBPS) is asked to reduce its bandwidth below 70 KBPS, it may be | kbps) is asked to reduce its bandwidth below 70 kbps, it may be | |||
possible to renegotiate the codec in use to G. 729 or some other | possible to renegotiate the codec in use to G. 729 or some other | |||
codec. In such a case, the originating application should re-reserve | codec. In such a case, the originating application should re-reserve | |||
at the stated bandwidth (in this case, 70 KBPS), initiate the | at the stated bandwidth (in this case, 70 kbps), initiate the | |||
application level change, and let the application change the | application level change, and let the application change the | |||
reservation again (perhaps to 60 KBPS) when it has completed that | reservation again (perhaps to 60 kbps) when it has completed that | |||
process. | process. | |||
For the "priority" reservation, at the same time, R9 believes that it | At the time the reservation is being processed at R9, for the | |||
has sufficient bandwidth and that any other stated policy is also | "priority" reservation, R9 believes that it has sufficient bandwidth | |||
met, it forwards the RESV to VPN7. Each will update its reservation | and that any other stated policy is also met, and it forwards the | |||
state and forward the RESV signal to the next. VPN7 now acts as an | RESV to VPN7. Each will update its reservation state and forward the | |||
[RFC3175] aggregator for the inner domain. This means that it | RESV signal to the next. VPN7 now acts as an [RFC3175] aggregator | |||
receives the RESV signal for the inner domain reservation and stores | for the inner domain. This means that it receives the RESV signal | |||
state, decrypts the data stream from VPN8, operates on the RSVP | for the inner domain reservation and stores state, decrypts the data | |||
signals as an RSVP-configured router, and forwards the received IP | stream from VPN8, operates on the RSVP signals as an RSVP-configured | |||
datagrams (including the updated RESV signals) into its interface | router, and forwards the received IP datagrams (including the updated | |||
domain. The RESV signals originated by VPN4, VPN5, and VPN6 are | RESV signals) into its interface domain. The RESV signals originated | |||
therefore forwarded towards VPN1, VPN2, and VPN3 through the | by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, | |||
interface domain. | and VPN3 through the interface domain. | |||
VPN3 now acts as an [RFC3175] aggregator for the interface domain. | VPN3 now acts as an [RFC3175] aggregator for the interface domain. | |||
This means that it receives the RESV signal for the interface domain | This means that it receives the RESV signal for the interface domain | |||
reservation and stores state, decrypts the data stream from its peer, | reservation and stores state, decrypts the data stream from its peer, | |||
operates on the RSVP signals as an RSVP-configured router, and | operates on the RSVP signals as an RSVP-configured router, and | |||
forwards the received IP datagrams (including the updated RESV | forwards the received IP datagrams (including the updated RESV | |||
signals) into its enclave. The RESV signal originated by H6 is | signals) into its enclave. The RESV signal originated by H6 is | |||
therefore forwarded towards H3 according to the routing of the | therefore forwarded towards H3 according to the routing of the | |||
enclave. | enclave. | |||
H3 now receives the original RESV signals and deliver it to the | H3 now receives the original RESV signals and delivers it to the | |||
relevant application. | relevant application. | |||
3. Data flows within a VPN Router | 3. Data Flows within a VPN Router | |||
This section details the data flows within a VPN Router, in the | This section details the data flows within a VPN router, in the | |||
context of sessions as described in Section 2. It specifically | context of sessions as described in Section 2. It specifically | |||
identifies the signaling flow at a given VPN boundary and | identifies the signaling flow at a given VPN boundary and | |||
additionally elaborates the signaling mechanism with the aid of a | additionally elaborates the signaling mechanism with the aid of a | |||
network guard. A use case describing the proposal in the context of | Network Guard. A use case describing the proposal in the context of | |||
an operational scenario is presented herein. | an operational scenario is presented herein. | |||
3.1. VPN Routers that carry data across the cryptographic boundary | 3.1. VPN Routers That Carry Data across the Cryptographic Boundary | |||
3.1.1. Plaintext to Ciphertext Data Flows | 3.1.1. Plaintext to Ciphertext Data Flows | |||
+-----------------------+ +----------------------+ | +-----------------------+ +----------------------+ | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| |RSVP || ||Aggregate RSVP || | | |RSVP || ||Aggregate RSVP || | |||
| | || || || | | | || || || | |||
| |Per session: || ID ||Agg. Session || | | |Per session: || ID ||Agg. Session || | |||
| | Destination ||--->|| Agg. Destination || | | | Destination ||--->|| Agg. Destination || | |||
| | Source || || Agg. Source= self || | | | Source || || Agg. Source= self || | |||
| | potential SPI || || Agg. SPI generated|| | | | potential SPI || || Agg. SPI generated|| | |||
| | DSCP ---------> DSCP || | | | DSCP ---------> DSCP || | |||
| | vPort or protocol---------> vPort || | | | vPort or protocol---------> vPort || | |||
skipping to change at page 24, line 42 | skipping to change at page 25, line 4 | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| | IP || || IP || | | | IP || || IP || | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| | Plain text Interface|| ||Cipher text Interface|| | | | Plain text Interface|| ||Cipher text Interface|| | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
+-----------------------+ +----------------------+ | +-----------------------+ +----------------------+ | |||
Figure 6: Data Flows in a VPN Router Outbound | Figure 6: Data Flows in a VPN Router Outbound | |||
Parameters on a reservation include: | Parameters on a reservation include: | |||
Destination Address: On the plain text side, the VPN Router | Destination Address: On the plaintext side, the VPN router | |||
participates in the end to end reservations being installed for | participates in the end-to-end reservations being installed for | |||
plain text sessions. These may include individual flows as | plain text sessions. These may include individual flows as | |||
described in [RFC2205] IPsec data flows [RFC2207] aggregate | described in [RFC2205], IPsec data flows [RFC2207], aggregate | |||
reservations [RFC3175] or other types. It passes an identifier | reservations [RFC3175], or other types. It passes an identifier | |||
for the cipher text side of the deaggregator to its cipher text | for the cipher text side of the deaggregator to its cipher text | |||
unit. | unit. | |||
DSCP: The DSCP of the plain text data flow is provided to the cipher | DSCP: The DSCP of the plain text data flow is provided to the cipher | |||
text side. | text side. | |||
Virtual Port: The virtual destination port is provided to the cipher | Virtual Port: The virtual destination port is provided to the cipher | |||
text side. This may be derived from an [RFC2207] session object | text side. This may be derived from an [RFC2207] session object | |||
or from policy information. | or from policy information. | |||
Mean Rate: The sum of the plain text mean rates is provided to the | Mean Rate: The sum of the plain text mean rates is provided to the | |||
cipher text unit. | cipher text unit. | |||
Peak Rate: A function of the plain text peak rates is provided to | Peak Rate: A function of the plaintext peak rates is provided to the | |||
the cipher text unit. This function is less than or equal to the | ciphertext unit. This function is less than or equal to the sum | |||
sum of the peak rates. | of the peak rates. | |||
Burst Size: The sum of the burst sizes is provided to the cipher | Burst Size: The sum of the burst sizes is provided to the cipher | |||
text unit. | text unit. | |||
Messages include: | Messages include: | |||
Path: The Plain text PATH message is sent as encrypted data to the | Path: The plaintext PATH 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 PATH message for the cipher text side. | aggregated PATH message for the cipher text side. | |||
Path Error: This indicates that a PATH message sent to the remote | Path Error: This indicates that a PATH message sent to the remote | |||
enclave was in error. In the error case, the message itself is | enclave was in error. In the error case, the message itself is | |||
sent on as encrypted data, but a signal is sent to the cipher text | sent on as encrypted data, but a signal is sent to the cipher text | |||
side in case the error affects the cipher text reservation (such | side in case the error affects the ciphertext reservation (such as | |||
as removing or changing state). | removing or changing state). | |||
Path Tear: The PATH Tear message is sent as encrypted data to the | Path Tear: The PATH Tear message is sent as encrypted data to the | |||
cipher text unit. In parallel, a signal is sent to the cipher | ciphertext unit. In parallel, a signal is sent to the cipher text | |||
text side which will trigger a Path Tear on its reservation in the | side; it will trigger a Path Tear on its reservation in the event | |||
event that this is the last aggregated session, or change the | 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 plaintext 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 that was received as | |||
forwarded into the enclave was in error or needed to be preempted | data and forwarded into the enclave was in error or needed to be | |||
as described in [RFC3181] or [RFC4495]. In the error case, the | preempted as described in [RFC3181] or [RFC4495]. In the error | |||
message itself is sent on as encrypted data, but a signal is sent | case, the message itself is sent on as encrypted data, but a | |||
to the cipher text side in case the error affects the cipher text | signal is sent to the ciphertext side in case the error affects | |||
reservation (such as removing or changing state). | the ciphertext reservation (such as removing or 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 | ciphertext unit. In parallel, a signal is sent to the cipher text | |||
text side which will trigger a RESV Tear on its reservation in the | side; it will trigger a RESV Tear on its reservation in the event | |||
event that this is the last aggregated session, or reduce the | that this is the last aggregated session, or reduce the bandwidth | |||
bandwidth of an existing reservation. | 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 ciphertext side, and, in | |||
parallel a signal is sent to potentially trigger an RESV Confirm | parallel, a signal is sent to potentially trigger an RESV Confirm | |||
on the aggregate reservation. | on the aggregate reservation. | |||
3.1.2. Ciphertext to Plaintext Data Flows | 3.1.2. Ciphertext to Plaintext Data Flows | |||
+-----------------------+ +----------------------+ | +-----------------------+ +----------------------+ | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| |RSVP || ||Aggregate RSVP || | | |RSVP || ||Aggregate RSVP || | |||
| | || || terminated || | | | || || terminated || | |||
| |Per session: |+ || || | | |Per session: |+ || || | |||
| | Destination || || || | | | Destination || || || | |||
| | Source <---------Decrypted RSVP || | | | Source <---------Decrypted RSVP || | |||
| | potential SPI || || message sent to || | | | potential SPI || || message sent to || | |||
| | DSCP || || Plain text unit || | | | DSCP || || Plain text unit || | |||
| | vPort or protocol || || *as data* for || | | | vPort or protocol || || *as data* for || | |||
skipping to change at page 26, line 44 | skipping to change at page 27, line 33 | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| | IP || || IP || | | | IP || || IP || | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
| |Plain text Interface|| ||Cipher text Interface|| | | |Plain text Interface|| ||Cipher text Interface|| | |||
| +--------------------+| |+--------------------+| | | +--------------------+| |+--------------------+| | |||
+-----------------------+ +----------------------+ | +-----------------------+ +----------------------+ | |||
Figure 7: Data Flows in a VPN Router Inbound | Figure 7: Data Flows in a VPN Router Inbound | |||
The aggregate reservation is terminated by the cipher text side of | The aggregate reservation is terminated by the ciphertext side of the | |||
the VPN Router. The RSVP messages related to the subsidiary sessions | VPN router. The RSVP messages related to the subsidiary sessions are | |||
are carried in the encrypted tunnel as data, and therefore arrive at | carried in the encrypted tunnel as data, and therefore arrive at the | |||
the plain text side with other data. As the plain text side | plaintext side with other data. As the plaintext side participates | |||
participates in these reservations, some information is returned to | in these reservations, some information is returned to the ciphertext | |||
the cipher text size to parameterize the aggregate reservation as | size to parameterize the aggregate reservation as described in | |||
described in Section 3.1.1 in the processing of the outbound | Section 3.1.1 in the processing of the outbound messages. | |||
messages. | ||||
3.2. VPN Routers that use the Network Guard for signaling across the | 3.2. VPN Routers That Use the Network Guard for Signaling across the | |||
cryptographic boundary | Cryptographic Boundary | |||
As described in Section 1.6 the Network Guard provides an additional | As described in Section 1.6 the Network Guard provides an additional | |||
path for the reservation signaling between the plain text and cipher | path for the reservation signaling between the plain text and cipher | |||
text domains. | text domains. | |||
_.------------. | _.------------. | |||
,--'' Plain text Domain--. | ,--'' Plain text Domain--. | |||
,-' +--------+ +--------+ `-. | ,-' +--------+ +--------+ `-. | |||
,' | Host | | Host | `. | ,' | Host | | Host | `. | |||
,' +--------+ +--------+ `. | ,' +--------+ +--------+ `. | |||
skipping to change at page 27, line 34 | skipping to change at page 28, line 34 | |||
|----|E/D |--|Net Grd| | VPN Router | |----|E/D |--|Net Grd| | VPN Router | |||
,-'| +-+--+ +-+--+--+ |\ | ,-'| +-+--+ +-+--+--+ |\ | |||
, | +----------+ | \ | , | +----------+ | \ | |||
,' | +---+----+ | `. | ,' | +---+----+ | `. | |||
,' | | Router | | | | ,' | | Router | | | | |||
/ | +--------+ | \ | / | +--------+ | \ | |||
; +----------------------+ : | ; +----------------------+ : | |||
| | | | | | |||
: Cipher text Domain ; | : Cipher text Domain ; | |||
Figure 8: RSVP passage via Network Guard | Figure 8: RSVP Passage via Network Guard | |||
In this context, the VPN Router is composed of a plaintext router, a | In this context, the VPN router is composed of a plaintext router, a | |||
ciphertext router, an encrypt/decrypt implementation (such as a line | ciphertext router, an encrypt/decrypt implementation (such as a line | |||
card or interface device) and a network management process that | card or interface device), and a network management process that | |||
manages the encrypt/decrypt implementation and potentially passes | manages the encrypt/decrypt implementation and potentially passes | |||
defined information flows between the plaintext and ciphertext | defined information flows between the plaintext and ciphertext | |||
domains. If the Network Guard is implemented as software process | domains. If the Network Guard is implemented as a software process | |||
that exchanges configuration instructions between the routers, this | that exchanges configuration instructions between the routers, this | |||
is simple to understand. If it is built as separate systems | is simple to understand. If it is built as a separate systems | |||
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 the 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 plaintext and ciphertext routers may use | |||
use the Network Guard as the path for the signaling flows. The | the Network Guard as the path for the signaling flows. The Network | |||
Network Guard performs the following functions to enable the flow of | 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 transforms plaintext session identifiers into ciphertext 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 performs resource management of aggregated reservations (e.g., | |||
cipher text encapsulation overhead to resources requested) | including ciphertext encapsulation overhead to resources | |||
requested) | ||||
o Read and write configuration on the Encrypt/Decrypt units as | o reads and writes configuration on the encrypt/decrypt units as | |||
necessary (e.g. read plain text to cipher text IP address mapping) | necessary (e.g., reads plaintext to ciphertext IP address mapping) | |||
In addition the plain text and cipher text routers must support a | In addition, the plaintext and ciphertext routers must support a | |||
routing function or local interface which ensures that aggregated | routing function or local interface that ensures that aggregated RSVP | |||
RSVP messages flow via the Network Guard. The signaling flow across | messages flow via the Network Guard. However, the signaling flow | |||
the entire VPN Router at cryptographic boundary however remains | across the entire VPN router at a cryptographic boundary remains | |||
identical to the description in Section 3.1. | identical to the description in Section 3.1. | |||
A reader may note that the VPN Router described in Figure 8 can be | A reader may note that the VPN router described in Figure 8 can be | |||
collapsed into a single router with two halves or the Network Guard | collapsed into a single router with two halves, or the Network Guard | |||
and the Encrypt/Decrypt units can be part of the plain text router. | and the encrypt/decrypt units can be part of the plaintext router. | |||
The details of alternate logical and physical architectures for the | The details of alternate logical and physical architectures for the | |||
VPN router are beyond the scope of this document. | VPN router are beyond the scope of this document. | |||
3.2.2. Use case with Network Guard | 3.2.2. Use Case with Network Guard | |||
........................................ | ........................................ | |||
: VPN Router A : | : VPN Router A : | |||
: : | : : | |||
:+-----------++----------++-----------+: | :+-----------++----------++-----------+: | |||
+------+ RSVP :| || NetGrd-A || |: | +------+ RSVP :| || NetGrd-A || |: | |||
|Host-A|<---->:|PT-Router-A|+----------+|CT-Router-A|:::::::: | |Host A|<---->:|PT-Router-A|+----------+|CT-Router-A|:::::::: | |||
+------+ :| || E/D-A || |: :: | +------+ :| || E/D-A || |: :: | |||
:+-----------++----------++-----------+: :: | :+-----------++----------++-----------+: :: | |||
: A-RSVP : :: | : A-RSVP : :: | |||
: <:::::::::::::> : :: | : <:::::::::::::> : :: | |||
:......................................: :: | :......................................: :: | |||
A-RSVP :: | A-RSVP :: | |||
,---. | ,---. | |||
,' `. | ,' `. | |||
/ \ | / \ | |||
; Interface : | ; Interface : | |||
skipping to change at page 29, line 34 | skipping to change at page 30, line 34 | |||
: ; | : ; | |||
\ / | \ / | |||
`. ,' | `. ,' | |||
'---' | '---' | |||
A-RSVP :: | A-RSVP :: | |||
........................................ :: | ........................................ :: | |||
: VPN Router B : :: | : VPN Router B : :: | |||
: : :: | : : :: | |||
:+-----------++----------++-----------+: :: | :+-----------++----------++-----------+: :: | |||
+------+ RSVP :| || NetGrd-B || |: :: | +------+ RSVP :| || NetGrd-B || |: :: | |||
|Host-B|<---->:|PT-Router-B|+----------+|CT-Router-B|:::::::: | |Host B|<---->:|PT-Router-B|+----------+|CT-Router-B|:::::::: | |||
+------+ :| || E/D-B || |: | +------+ :| || E/D-B || |: | |||
:+-----------++----------++-----------+: | :+-----------++----------++-----------+: | |||
: A-RSVP : | : A-RSVP : | |||
: <:::::::::::::> : | : <:::::::::::::> : | |||
:......................................: | :......................................: | |||
Figure 9: Aggregated RSVP via Network Guard | Figure 9: Aggregated RSVP via Network Guard | |||
The above figure depicts a simple use case for aggregated signaling | The above figure depicts a simple use case for aggregated signaling | |||
with the Network Guard. In this scenario, Host A initiates RSVP | with the Network Guard. In this scenario, Host A initiates RSVP | |||
signaling to Host B for a reservation. The RSVP signaling between | signaling to Host B for a reservation. The RSVP signaling between | |||
the hosts is encapsulated by the VPN Router Instances into encrypted | the hosts is encapsulated by the VPN routers into encrypted tunnels. | |||
tunnels. Aggregated RSVP signaling is triggered by VPN Router | Aggregated RSVP signaling is triggered by VPN routers, and flows into | |||
Instances, and flows into the CT-Routers as well as the interface | the CT-Routers, as well as the interface domains, to reserve | |||
domains to reserve resources at RSVP capable routers on the path. | resources at RSVP-capable routers on the path. The aggregation/ | |||
The aggregation/deaggregation point for RSVP reservations in this use | deaggregation point for RSVP reservations in this use case are the | |||
case are the PT-Routers. The signaling aggregation of RSVP into | PT-Routers. The signaling aggregation of RSVP into A-RSVP at the | |||
A-RSVP at the PT-Router is similar to the data flow described in | PT-Router is similar to the data flow described in Section 3.1. The | |||
Section 3.1. The Network Guard performs the additional functions | Network Guard performs the additional functions described in Section | |||
described in Section 3.2.1 to transform plaintext A-RSVP messages | 3.2.1 to transform plaintext A-RSVP messages into suitable ciphertext | |||
into suitable ciphertext A-RSVP messages. A typical reservation set | A-RSVP messages. A typical reservation set up in this case would | |||
up in this case would follow these steps | follow these steps. | |||
o Host-A sends RSVP PATH message to Host B | o Host A sends RSVP PATH message to Host B. | |||
o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to | o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to | |||
VPN Router Instance B | VPN Router B. | |||
o CT Routers and Interface domain carry encrypted RSVP PATH message | o CT Routers and Interface domain carry encrypted RSVP PATH message | |||
(like any other encrypted data message) | (like any other encrypted data message). | |||
o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr | o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr | |||
message to PT-Router-A in the encrypted tunnel. | message to PT-Router-A in the encrypted tunnel. | |||
o PT-Router-B forwards decrypted plaintext RSVP PATH message to | o PT-Router-B forwards decrypted plaintext RSVP PATH message to Host | |||
Host-B. | B. | |||
o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH | o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH | |||
message towards PT-Router-B via the Network Guard. | message towards PT-Router-B via the Network Guard. | |||
o The NetGrd-A transforms the plaintext aggregate RSVP into the | o The NetGrd-A transforms the plaintext aggregate RSVP into the | |||
ciphertext aggregate RSVP message as described in Section 3.2.1 | ciphertext aggregate RSVP message as described in Section 3.2.1 | |||
and sends it to the CT-Router-A. | and sends it to the CT-Router-A. | |||
o The ciphertext aggregated RSVP message travels through ciphertext | o The ciphertext aggregated RSVP message travels through ciphertext | |||
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 | flow, as described in detail in [RFC3175] and [RFC4860]to aggregate | |||
[I-D.ietf-tsvwg-rsvp-ipsec]to aggregate each plaintext reservation | each plaintext reservation into a corresponding ciphertext | |||
into a corresponding ciphertext reservation. This ensures that RSVP | reservation. This ensures that RSVP-capable ciphertext routers | |||
capable ciphertext routers reserve the required resources for a | reserve the required resources for a plaintext end-to-end | |||
plaintext end to end reservation. Subsequent mechanisms such as | reservation. Subsequent mechanisms, such as preemption or the | |||
preemption or the increase and decrease of resources reserved may be | increase and decrease of resources reserved, may be applied to these | |||
applied to these reservations as described before in this document. | reservations as described before in this document. The RSVP data | |||
The RSVP data flow as described in Section 3.1 within the VPN router | flow as described in Section 3.1 within the VPN router (from the | |||
(from the plaintext router to the ciphertext router via the Guard) | plaintext router to the ciphertext router via the Guard) provides | |||
provides necessary and sufficient information to routers in the | necessary and sufficient information to routers in the ciphertext | |||
ciphertext domain to implement the QoS solution presented in the | domain to implement the QoS solution presented in the document. | |||
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 Protocol Independent | |||
traffic is destined to the remote VPN Router. This means that the | Multicast (PIM) routing, the traffic is destined to the remote VPN | |||
Guard must somehow receive and respond to, on behalf of the VPN | router. This means that the Guard must somehow receive and respond | |||
Router, messages that are not directed to it. There are several | to, on behalf of the VPN Router, messages that are not directed to | |||
possible solutions, which need to be carefully selected based on the | it. Several possible solutions exist; they should be selected | |||
security and implementation needs of the environment: | carefully based on the security and implementation needs of the | |||
environment. They are as follows: | ||||
o In the simplest case, the network guard and encrypt/decrypt unit | o In the simplest case, the Network Guard and encrypt/decrypt unit | |||
can be two independent functions which utilize a common network | can be two independent functions that utilize a common network and | |||
and MAC layer. This can allow the two functions to share a common | MAC layer. This can allow the two functions to share a common MAC | |||
MAC and IP address, so that traffic destined for one function is | and IP address, so that traffic destined for one function is also | |||
also received by the other. In the case that these two functions | received by the other. In the case that these two functions are | |||
are physically separated on two devices, they can still share a | physically separated on two devices, they can still share a common | |||
common MAC and IP address, however additional modifications may be | MAC and IP address; however, additional modifications may be | |||
required on the Guard to to filter and not process IP traffic not | required on the Guard to filter and not process IP traffic not | |||
destined for itself. | destined for itself. | |||
o The ciphertext interface of the Guard could be placed into | o The ciphertext interface of the Guard could be placed into | |||
promiscuous mode, allowing it to receive all messages and discard | promiscuous mode, allowing it to receive all messages and discard | |||
all but the few it is interested in. The security considerations | all but the few it is interested in. The security considerations | |||
on putting a device in promiscuous mode at the VPN boundary needs | on putting a device in promiscuous mode at the VPN boundary needs | |||
to be taken into account in this method. | to be taken into account in this method. | |||
o The Guard could be engineered to receive all from the ciphertext | o The Guard could be engineered to receive all from the ciphertext | |||
router and pass the bulk of it on to the VPN Router through | router and pass the bulk of it on to the VPN router through | |||
another interface. In this case, the Guard and the VPN Router | another interface. In this case, the Guard and the VPN router | |||
would use the same IP address. This mechanism puts the load of | would use the same IP address. This mechanism puts the load of | |||
all data and management traffic destined for the VPN router upon | all data and management traffic destined for the VPN router upon | |||
the Guard. | the Guard. | |||
o The VPN Router could be engineered to receive all traffic from the | o The VPN router could be engineered to receive all traffic from the | |||
ciphertext router and pass any unencrypted traffic it receives to | ciphertext router and pass any unencrypted traffic it receives to | |||
the Guard through another interface. In this case, the Guard and | the Guard through another interface. In this case, the Guard and | |||
the VPN Router would use the same IP address. | the VPN router would use the same IP address. | |||
o All the VPN router functions as shown in Figure 9 could be | o All the VPN router functions, as shown in Figure 9, could be | |||
incorporated into a single chassis, with appropriate internal | incorporated into a single chassis, with appropriate internal | |||
traffic management to send some traffic into the plaintext enclave | traffic management to send some traffic into the plaintext enclave | |||
and some to the Guard. In this case, the Guard and the VPN Router | and some to the Guard. In this case, the Guard and the VPN router | |||
would at least functionally be the same system. | would be -- at least, functionally -- the same system. | |||
Of these, clearly the last is the simplest architecturally and the | Of these, clearly the last is the simplest architecturally and the | |||
one which most minimizes the attendant risk. | one that most minimizes the attendant risk. | |||
4. IANA Considerations | ||||
This document makes no request of the IANA. | ||||
Note to RFC Editor: in the process assigning numbers and building | ||||
IANA registries prior to publication, this section will have served | ||||
its purpose. It may therefore be removed upon publication as an RFC. | ||||
5. Security Considerations | 4. Security Considerations | |||
The typical security concerns of datagram integrity, node and user | The typical security concerns of datagram integrity, node and user | |||
authentication are implicitly met by the security association that | authentication are implicitly met by the security association that | |||
exists between the VPN Routers. The secure data stream which flows | exists between the VPN routers. The secure data stream that flows | |||
between the VPN Routers is also used for the reservation signaling | between the VPN routers is also used for the reservation signaling | |||
datagrams flowing between VPN Routers. Information that is contained | datagrams flowing between VPN routers. Information that is contained | |||
in these signaling datagrams receives the same level of encryption | in these signaling datagrams receives the same level of encryption | |||
that is received by the data streams. | that is received by the data streams. | |||
One of the reasons cited for the nesting of VPN routes in Section 1.3 | One of the reasons cited for the nesting of VPN routes in Section 1.3 | |||
are the different levels of security across the nested VPN Routers. | is the different levels of security across the nested VPN routers. | |||
If the security level decreases from one VPN Router to the next VPN | If the security level decreases from one VPN router to the next VPN | |||
Router in the nested path, the reservation signaling datagrams will | Router in the nested path, the reservation signaling datagrams will, | |||
by default receive the lower security level treatment. For most | by default, receive the lower security-level treatment. For most | |||
cases, the lower security treatment is acceptable. In certain | cases, the lower security treatment is acceptable. In certain | |||
networks, however, the reservation signaling across the entire nested | networks, however, the reservation signaling across the entire nested | |||
path must receive the highest security level treatment (e. g. | path must receive the highest security-level treatment (e.g., | |||
encryption, authentication of signaling nodes). For example the | encryption, authentication of signaling nodes). For example, the | |||
highest precedence level may only be signaled to VPN Routers which | highest precedence level may only be signaled to VPN routers that can | |||
can provide the highest security levels. If any VPN Router in the | provide the highest security levels. If any VPN router in the nested | |||
nested path is incapable of providing the highest security level, it | path is incapable of providing the highest security level, it cannot | |||
cannot participate in the reservation mechanism. | participate in the reservation mechanism. | |||
In the general case, the nested path may contain routers which are | In the general case, the nested path may contain routers that are | |||
either incapable of participating in VPNs or providing required | either incapable of participating in VPNs or providing required | |||
security levels. These routers can participate in the reservation | security levels. These routers can participate in the reservation | |||
only if the lower security level is acceptable (as configured by | only if the lower security level is acceptable (as configured by | |||
policy) for the signaling of reservation datagrams. | policy) for the signaling of reservation datagrams. | |||
VPN Routers encapsulate encrypted IP packets and prepend an extra | VPN routers encapsulate encrypted IP packets and prepend an extra | |||
header on each packet. These packets, whether used for signaling or | header on each packet. These packets, whether used for signaling or | |||
data, should be identifiable, at a minimum by the IP addresses and | data, should be identifiable, at a minimum by the IP addresses and | |||
DSCP value. The prepended header, therefore, should contain at a | DSCP value. Therefore, the prepended header should contain, at a | |||
minimum the DSCP value corresponding to the signaled reservation in | minimum, the DSCP value corresponding to the signaled reservation in | |||
each packet. This may literally be the same DSCP as is used for the | each packet. This may literally be the same DSCP as is used for the | |||
data (forcing control plane traffic to receive the same QoS treatment | data (forcing control plane traffic to receive the same QoS treatment | |||
as its data), or a different DSCP that is routed identically | as its data), or a different DSCP that is routed identically | |||
(separating control and data plane traffic QoS but not routing). | (separating control and data-plane traffic QoS but not routing). | |||
Additionally security considerations as described in | Additionally security considerations as described in [RFC4860] and | |||
[I-D.ietf-tsvwg-rsvp-ipsec] and [RFC3175]are also applicable in this | [RFC3175] are also applicable in this environment; they include the | |||
environment which include the integrity of RSVP messages can be | integrity of RSVP messages can be ensured via mechanisms described in | |||
ensured via mechanisms described in [RFC2747] and [RFC3097] and | [RFC2747] and [RFC3097] and related key management (through manual | |||
related key management (through manual configuration or a key | configuration or a key management protocol) at nodes between any | |||
management protocol) at nodes between any aggregator and deaggregator | aggregator and deaggregator pair that processes the messages. In | |||
pair that process the messages. In addition confidentiality can be | addition, confidentiality can be provided between hops by employing | |||
provided between hops by employing IPsec. Further work in the IETF | IPsec. Further work in the IETF MSEC Working Group may be applicable | |||
MSEC Working Group may be applicable in these environments for key | in these environments for key management and confidentiality. | |||
management and confidentiality. | ||||
6. Acknowledgements | 5. 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.ietf-tsvwg-rsvp-ipsec], which clarified the | Bose) added [RFC4860], which clarified the interaction of this | |||
interaction of this approach with the DSCP. | approach with the DSCP. | |||
7. References | ||||
7.1. Normative References | 6. References | |||
[I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate | 6.1. Normative References | |||
Resource ReSerVation Protocol (RSVP) | ||||
Reservations", | ||||
draft-ietf-tsvwg-rsvp-ipsec-04 (work in | ||||
progress), January 2007. | ||||
[RFC2205] Braden, B., Zhang, L., Berson, S., | [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. | |||
Herzog, S., and S. Jamin, "Resource | Jamin, "Resource ReSerVation Protocol (RSVP) -- | |||
ReSerVation Protocol (RSVP) -- Version 1 | Version 1 Functional Specification", RFC 2205, | |||
Functional Specification", RFC 2205, | ||||
September 1997. | September 1997. | |||
[RFC2207] Berger, L. and T. O'Malley, "RSVP | [RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for | |||
Extensions for IPSEC Data Flows", | IPSEC Data Flows", RFC 2207, September 1997. | |||
RFC 2207, September 1997. | ||||
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, | [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. | |||
J., and L. Zhang, "RSVP Operation Over | Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, | |||
IP Tunnels", RFC 2746, January 2000. | January 2000. | |||
[RFC2750] Herzog, S., "RSVP Extensions for Policy | [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC | |||
Control", RFC 2750, January 2000. | 2750, January 2000. | |||
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS | [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC | |||
Object", RFC 2996, November 2000. | 2996, November 2000. | |||
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, | [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. | |||
F., and B. Davie, "Aggregation of RSVP | Davie, "Aggregation of RSVP for IPv4 and IPv6 | |||
for IPv4 and IPv6 Reservations", | Reservations", RFC 3175, September 2001. | |||
RFC 3175, September 2001. | ||||
[RFC4495] Polk, J. and S. Dhesikan, "A Resource | [RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation | |||
Reservation Protocol (RSVP) Extension | Protocol (RSVP) Extension for the Reduction of | |||
for the Reduction of Bandwidth of a | Bandwidth of a Reservation Flow", RFC 4495, May 2006. | |||
Reservation Flow", RFC 4495, May 2006. | ||||
[RFC4542] Baker, F. and J. Polk, "Implementing an | [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency | |||
Emergency Telecommunications Service | Telecommunications Service (ETS) for Real-Time | |||
(ETS) for Real-Time Services in the | Services in the Internet Protocol Suite", RFC 4542, | |||
Internet Protocol Suite", RFC 4542, | ||||
May 2006. | May 2006. | |||
7.2. Informative References | [RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., | |||
and M. Davenport, "Generic Aggregate Resource | ||||
ReSerVation Protocol (RSVP) Reservations", RFC 4860, | ||||
May 2007. | ||||
[ITU.MLPP.1990] International Telecommunications Union, | 6.2. Informative References | |||
"Multilevel Precedence and Preemption | ||||
Service", ITU-T Recommendation I.255.3, | ||||
1990. | ||||
[RFC0791] Postel, J., "Internet Protocol", STD 5, | [ITU.MLPP.1990] International Telecommunications Union, "Multilevel | |||
RFC 791, September 1981. | Precedence and Preemption Service", ITU-T | |||
Recommendation I.255.3, 1990. | ||||
[RFC1633] Braden, B., Clark, D., and S. Shenker, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
"Integrated Services in the Internet | September 1981. | |||
Architecture: an Overview", RFC 1633, | ||||
June 1994. | ||||
[RFC2209] Braden, B. and L. Zhang, "Resource | [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated | |||
ReSerVation Protocol (RSVP) -- Version 1 | Services in the Internet Architecture: an Overview", | |||
Message Processing Rules", RFC 2209, | RFC 1633, June 1994. | |||
September 1997. | ||||
[RFC2210] Wroclawski, J., "The Use of RSVP with | [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation | |||
IETF Integrated Services", RFC 2210, | Protocol (RSVP) -- Version 1 Message Processing | |||
September 1997. | Rules", RFC 2209, September 1997. | |||
[RFC2401] Kent, S. and R. Atkinson, "Security | [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated | |||
Architecture for the Internet Protocol", | Services", RFC 2210, September 1997. | |||
RFC 2401, November 1998. | ||||
[RFC2460] Deering, S. and R. Hinden, "Internet | [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, | |||
Protocol, Version 6 (IPv6) | Version 6 (IPv6) Specification", RFC 2460, December | |||
Specification", RFC 2460, December 1998. | 1998. | |||
[RFC2474] Nichols, K., Blake, S., Baker, F., and | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
D. Black, "Definition of the | "Definition of the Differentiated Services Field (DS | |||
Differentiated Services Field (DS Field) | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
in the IPv4 and IPv6 Headers", RFC 2474, | ||||
December 1998. | December 1998. | |||
[RFC2475] Blake, S., Black, D., Carlson, M., | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, | |||
Davies, E., Wang, Z., and W. Weiss, "An | Z., and W. Weiss, "An Architecture for Differentiated | |||
Architecture for Differentiated | ||||
Services", RFC 2475, December 1998. | Services", RFC 2475, December 1998. | |||
[RFC2747] Baker, F., Lindell, B., and M. Talwar, | [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP | |||
"RSVP Cryptographic Authentication", | Cryptographic Authentication", RFC 2747, January | |||
RFC 2747, January 2000. | 2000. | |||
[RFC2872] Bernet, Y. and R. Pabbati, "Application | [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub | |||
and Sub Application Identity Policy | Application Identity Policy Element for Use with | |||
Element for Use with RSVP", RFC 2872, | RSVP", RFC 2872, June 2000. | |||
June 2000. | ||||
[RFC3097] Braden, R. and L. Zhang, "RSVP | [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic | |||
Cryptographic Authentication -- Updated | Authentication -- Updated Message Type Value", RFC | |||
Message Type Value", RFC 3097, | 3097, April 2001. | |||
April 2001. | ||||
[RFC3181] Herzog, S., "Signaled Preemption | [RFC3181] Herzog, S., "Signaled Preemption Priority Policy | |||
Priority Policy Element", RFC 3181, | Element", RFC 3181, October 2001. | |||
October 2001. | ||||
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., | [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., | |||
Ford, P., Moore, T., Herzog, S., and R. | Moore, T., Herzog, S., and R. Hess, "Identity | |||
Hess, "Identity Representation for | Representation for RSVP", RFC 3182, October 2001. | |||
RSVP", RFC 3182, October 2001. | ||||
[RFC3246] Davie, B., Charny, A., Bennet, J., | [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le | |||
Benson, K., Le Boudec, J., Courtney, W., | Boudec, J., Courtney, W., Davari, S., Firoiu, V., and | |||
Davari, S., Firoiu, V., and D. | D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop | |||
Stiliadis, "An Expedited Forwarding PHB | Behavior)", RFC 3246, March 2002. | |||
(Per-Hop Behavior)", RFC 3246, | ||||
March 2002. | ||||
[RFC3261] Rosenberg, J., Schulzrinne, H., | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., | |||
Camarillo, G., Johnston, A., Peterson, | Johnston, A., Peterson, J., Sparks, R., Handley, M., | |||
J., Sparks, R., Handley, M., and E. | and E. Schooler, "SIP: Session Initiation Protocol", | |||
Schooler, "SIP: Session Initiation | RFC 3261, June 2002. | |||
Protocol", RFC 3261, June 2002. | ||||
[RFC3312] Camarillo, G., Marshall, W., and J. | [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, | |||
Rosenberg, "Integration of Resource | "Integration of Resource Management and Session | |||
Management and Session Initiation | Initiation Protocol (SIP)", RFC 3312, October 2002. | |||
Protocol (SIP)", RFC 3312, October 2002. | ||||
[RFC3473] Berger, L., "Generalized Multi-Protocol | [RFC3473] Berger, L., "Generalized Multi-Protocol Label | |||
Label Switching (GMPLS) Signaling | Switching (GMPLS) Signaling Resource ReserVation | |||
Resource ReserVation Protocol-Traffic | Protocol-Traffic Engineering (RSVP-TE) Extensions", | |||
Engineering (RSVP-TE) Extensions", | ||||
RFC 3473, January 2003. | RFC 3473, January 2003. | |||
[RFC3474] Lin, Z. and D. Pendarakis, | [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA | |||
"Documentation of IANA assignments for | assignments for Generalized MultiProtocol Label | |||
Generalized MultiProtocol Label | Switching (GMPLS) Resource Reservation Protocol - | |||
Switching (GMPLS) Resource Reservation | Traffic Engineering (RSVP-TE) Usage and Extensions | |||
Protocol - Traffic Engineering (RSVP-TE) | for Automatically Switched Optical Network (ASON)", | |||
Usage and Extensions for Automatically | ||||
Switched Optical Network (ASON)", | ||||
RFC 3474, March 2003. | RFC 3474, March 2003. | |||
[RFC4303] Kent, S., "IP Encapsulating Security | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
Payload (ESP)", RFC 4303, December 2005. | Internet Protocol", RFC 4301, December 2005. | |||
[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 | |||
skipping to change at page 38, line 45 | skipping to change at page 38, 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. | |||
Acknowledgements | Acknowledgement | |||
Funding for the RFC Editor function is provided by the IETF | Funding for the RFC Editor function is currently provided by the | |||
Administrative Support Activity (IASA). This document was produced | Internet Society. | |||
using xml2rfc v1.32 (of http://xml.resource.org/) from a source in | ||||
RFC-2629 XML format. | ||||
End of changes. 192 change blocks. | ||||
554 lines changed or deleted | 496 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |