doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc4923.txt b/doc/rfc/rfc4923.txt
new file mode 100644
index 0000000..f98ed95
--- /dev/null
+++ b/doc/rfc/rfc4923.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Network Working Group                                           F. Baker
+Request for Comments: 4923                                 Cisco Systems
+Category: Informational                                          P. Bose
+                                                         Lockheed Martin
+                                                             August 2007
+
+
+ Quality of Service (QoS) Signaling in a Nested Virtual Private Network
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   Some networks require communication between an interior and exterior
+   portion of a Virtual Private Network (VPN) or through a concatenation
+   of such networks resulting in a nested VPN, but have sensitivities
+   about what information is communicated across the boundary,
+   especially while providing quality of service to communications with
+   different precedence.  This note seeks to outline the issues and the
+   nature of the proposed solutions based on the framework for
+   Integrated Services operation over Diffserv networks as described in
+   RFC 2998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                      [Page 1]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Problem Statement ..........................................3
+      1.2. Background Information and Terminology .....................4
+      1.3. Nested VPNs ................................................5
+      1.4. Signaled QoS Technology ....................................7
+      1.5. The Resource Reservation Protocol (RSVP) ...................9
+      1.6. Logical Structure of a VPN Router .........................10
+   2. Reservation and Preemption in a Nested VPN .....................13
+      2.1. Reservation in a Nested VPN ...............................14
+      2.2. Preemption in a Nested VPN ................................16
+      2.3. Working through an Example ................................17
+           2.3.1. Initial Routine Reservations - Generating
+                  Network State ......................................18
+           2.3.2. Initial Routine Reservations - Request
+                  Reservation ........................................19
+           2.3.3. Installation of a Reservation Using Precedence .....20
+           2.3.4. Installation of a Reservation Using Preemption .....21
+   3. Data Flows within a VPN Router .................................24
+      3.1. VPN Routers That Carry Data across the
+           Cryptographic Boundary ....................................24
+           3.1.1. Plaintext to Ciphertext Data Flows .................24
+           3.1.2. Ciphertext to Plaintext Data Flows .................27
+      3.2. VPN Routers That Use the Network Guard for
+           Signaling across the Cryptographic Boundary ...............28
+           3.2.1. Signaling Flow .....................................29
+           3.2.2. Use Case with Network Guard ........................30
+   4. Security Considerations ........................................33
+   5. Acknowledgements ...............................................34
+   6. References .....................................................34
+      6.1. Normative References ......................................34
+      6.2. Informative References ....................................35
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                      [Page 2]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+1.  Introduction
+
+1.1.  Problem Statement
+
+   More and more networks wish to guarantee secure transmission of IP
+   traffic across public LANs or WANs and therefore use Virtual Private
+   Networks.  Some networks require communication between an interior
+   and exterior portion of a VPN or through a concatenation of such
+   networks resulting in a nested VPN, but have sensitivities about what
+   information is communicated across the boundary, especially while
+   providing quality of service to communications with different
+   precedence.  This note seeks to outline the issues and the nature of
+   the proposed solutions.  The outline of the QoS solution for real-
+   time traffic has been described at a high level in [RFC4542].  The
+   key characteristics of this proposal are that
+
+   o  it uses standardized protocols,
+
+   o  it includes reservation setup and teardown for guaranteed and
+      controlled load services using the standardized protocols,
+
+   o  it is independent of link delay, and therefore consistent with
+      high delay*bandwidth networks as well as the more common variety,
+
+   o  it has no single point of failure, such as a central reservation
+      manager,
+
+   o  it provides for the preemption of established data flows,
+
+   o  in that preemption, it not only permits a policy-admitted data
+      flow in, but selects a specific data flow to exclude based upon
+      control input rather than simply accepting a loss of service
+      dictated at the discretion of the network control function, and
+
+   o  it interoperates directly with SIP Proxies, H.323 Gatekeepers, or
+      other call management subsystems to present the other services
+      required in a preemptive or preferential telephone network.
+
+   The thrust of the memo surrounds VPNs that use encryption in some
+   form, such as IPsec and their subsequent nesting across multiple
+   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
+   or IPsec like VPN under the context of a 'customer provisioned' VPN.
+   As a result, we will discuss the VPN router supporting "plaintext"
+   and "ciphertext" interfaces.  However, the concept extends readily to
+   any form of aggregation, including the concept proposed in [RFC3175]
+   of the IP traffic entering and leaving a network at identified
+
+
+
+
+Baker & Bose                 Informational                      [Page 3]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   points, and the use of other kinds of tunnels including Generic
+   Routing Encapsulation (GRE), IP/IP, MPLS, and so on.
+
+1.2.  Background Information and Terminology
+
+   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
+   context with a variety of meanings, resulting in a great deal of
+   confusion.  The term "priority" is used in this document to identify
+   one of several possible datagram scheduling algorithms.  A scheduler
+   is used when deciding which datagram will be sent next on a computer
+   interface; a priority scheduler always chooses a datagram from the
+   highest priority class (queue) that is occupied, shielding one class
+   of traffic from most of the jitter by passing jitter it would
+   otherwise have experienced to another class.  [RFC3181] applies the
+   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
+   the phrase "Multi-Level Precedence and Preemption" [ITU.MLPP.1990];
+   some classes of sessions take precedence over others, which may
+   result in bandwidth being admitted that might not otherwise have been
+   or may result in the prejudicial termination of a lower-precedence
+   session under a stated set of circumstances.  For the purposes of the
+   present discussion, "priority" is a set of algorithms applied to
+   datagrams, where "precedence" is a policy attribute of sessions.  The
+   techniques of priority comparisons are used in a router or a policy
+   decision point to implement precedence, but they are not the same
+   thing.
+
+   Along the same lines, it is important for the reader to understand
+   the difference between QoS policies and policies based on the
+   "precedence" or "importance" of data to the person or function using
+   it.  Voice, regardless of the precedence level of the call, is
+   impeded by high levels of variation in network-induced delay.  As a
+   result, voice is often serviced using a priority queue, transferring
+   jitter from that application's traffic to other applications.  This
+   is as true of voice for routine calls as it is for flash traffic.
+   There are classes of application traffic that require bounded delay.
+   That is a different concept than "no jitter"; they can accept jitter
+   within stated bounds.  Routing protocols such as OSPF or BGP are
+   critical to the correct functioning of network infrastructure.  While
+   they are designed to work well with moderate loss levels, they are
+   not helped by them, and even a short period of high loss can result
+   in dramatic network events.  Variation in delay, however, is not at
+   all an issue if it is within reasonable bounds.  As a result, it is
+   common for routers to treat routing protocol datagrams in a way that
+   limits the probability of loss, accepting relatively high delay in
+   some cases, even though the traffic is absolutely critical to the
+   network.  Telephone call setup exchanges have this characteristic as
+
+
+
+Baker & Bose                 Informational                      [Page 4]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   well: faced with a choice between loss and delay, protocols like SIP
+   and H.323 far prefer the latter, as the call setup time is far less
+   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.
+   As such, QoS markings tell us how to provide good service to an
+   application independent of how "important" it may be at the current
+   time, while "importance" can be conveyed separately in many cases.
+
+1.3.  Nested VPNs
+
+   One could describe a nested VPN network in terms of three network
+   diagrams.  Figure 1 shows a simple network stretched across a VPN
+   connection.  The VPN router (where, following [RFC2460], a "router"
+   is "a node that forwards packets not explicitly addressed to
+   itself"), performs the following steps:
+
+   o  receives an IP datagram from a plaintext interface,
+
+   o  determines what remote enclave and therefore other VPN router to
+      forward it to,
+
+   o  ensures that it has a tunnel mode security association (as
+      generally defined in [RFC4301], Section 4) with that router,
+
+   o  encloses the encrypted datagram within another VPN (e.g., IPsec)
+      and IP header, and
+
+   o  forwards the encapsulated datagram toward the remote VPN router.
+
+      The receiving VPN router reverses the steps:
+
+   o  determines what security association the datagram was received
+      from,
+
+   o  decrypts the interior datagram,
+
+   o  forwards the now-decapsulated datagram on a plaintext interface.
+
+   The use of IPsec in this manner is described as the tunnel mode of
+   [RFC4301] and [RFC4303].
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                      [Page 5]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+           Host  Host  Host       Host  Host  Host
+       /------------------/   /------------------/
+                 Router -------Router
+                            |
+                        VPN-Router
+                            ||
+                            ||   IPsec Tunnel through routed network
+                            ||
+                        VPN-Router
+                            |
+                  Router -------Router
+       /------------------/   /------------------/
+         Host  Host  Host       Host  Host  Host
+
+                      Figure 1: VPN-Connected Enclave
+
+   An important point to understand is that the VPN tunnel, like other
+   features of the routed network, are invisible to the host.  The host
+   can infer that "something out there" is affecting the Path MTU,
+   introducing delay, or otherwise affecting its data stream, but if
+   properly implemented, it should be able to adapt to these.  The words
+   "if properly implemented" are the bane of every network manager,
+   however; substandard implementations do demonstrably exist.
+
+   Outside of the enclave, the hosts are essentially invisible.  The
+   communicating enclaves look like a simple data exchange between peer
+   hosts across a routed network, as shown in Figure 2.
+
+                                   Hosts Not Visible
+                                 /==================/
+                                       Router
+                                          |
+                                     VPN-Router
+                               /---------------------/
+                                     Inner Domain
+                              /---------------------/
+                                      VPN-Router
+                                          |
+                                       Router
+                                /==================/
+                                 Hosts Not Visible
+
+         Figure 2: VPN-Connected Enclave from Exterior Perspective
+
+   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
+   ciphertext network that, for various reasons, is itself re-encrypted
+   and transmitted across a larger ciphertext network.  The reasons for
+
+
+
+Baker & Bose                 Informational                      [Page 6]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   doing this vary, but they relate to information-hiding in the wider
+   network, different levels of security required for different enclosed
+   enclaves, and so on.
+
+             Host  Host  Host       Host  Host  Host
+          /------------------/   /------------------/
+                     Router -------Router
+                               |
+                       VPN-Router VPN-Router      VPN-Router
+                    /---------------------/    /----------/
+                             Router -------------Router
+                                        |
+                                      VPN-Router      VPN-Router
+                                     /-----------/   /----------/
+                                          Router -------Router
+                                            |
+                                            |
+                                          Router -------Router
+                                     /-----------/   /----------/
+                                      VPN-Router      VPN-Router
+                                        |
+                              Router ------------Router
+                    /---------------------/   /----------/
+                     VPN-Router VPN-Router     VPN-Router
+                               |
+                     Router -------Router
+          /------------------/   /------------------/
+            Host  Host  Host       Host  Host  Host
+
+                           Figure 3: Nested VPN
+
+   The key question this document explores is "how do reservations, and
+   preemption of reservations, work in such an environment?"
+
+1.4.  Signaled QoS Technology
+
+   The Integrated Services model for networking was originally proposed
+   in [RFC1633].  In short, it divides all applications into two broad
+   classes: those that will adapt themselves to any available bandwidth,
+   and those that will not or cannot.  In the words of [RFC1633]:
+
+        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
+        is essentially worthless; we call these "real-time"
+        applications.  Another class of applications will always wait
+        for data to arrive; we call these "elastic" applications.
+
+
+
+
+
+Baker & Bose                 Informational                      [Page 7]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   The Integrated Services model defines data flows supporting
+   applications as either "real-time" or "elastic".  It should be noted
+   that "real-time" traffic is also referred to as "inelastic" traffic,
+   and that elastic traffic is occasionally referred to as "non-real-
+   time".
+
+   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
+   at which data describing the next sound, picture, or whatever to be
+   delivered to a display device or forfeit its utility, while an
+   elastic application has no such boundary.  Another way to look at the
+   difference is that real-time applications have an irreducible lower
+   bound on their bandwidth requirements.  For example, the typical
+   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
+   kbps of bandwidth, without silence suppression, and not accounting
+   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
+   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
+   there is significant loss or wide variations in delay), voice quality
+   will suffer.  On the other hand, if many megabits of capacity are
+   available, the G.711 codec will not increase its bandwidth
+   requirements either.  Although adaptive codecs exist (e.g., G.722.2
+   or G.726), the adaptive mechanism can either require greater or
+   lesser bandwidth and can adapt only within a certain range of
+   bandwidth requirements beyond which the quality of the data flow
+   required is not met.  Elastic applications, however, will generally
+   adapt themselves to any network: if the bottleneck provides 9600 bits
+   per second, a Web transfer or electronic mail exchange will happen at
+   9600 bits per second, and if hundreds of megabits are available, the
+   TCP (or SCTP) transport will increase their transfer rate in an
+   attempt to reduce the time required to accomplish the transfer.
+
+   For real-time applications, those that require data to be delivered
+   end to end with at least a certain rate and with delays varying
+   between stated bounds, the Integrated Services architecture proposes
+   the use of a signaling protocol that allows the communicating
+   applications and the network to communicate about the application
+   requirements and the network's capability to deliver them.  Several
+   such protocols have been developed or are under development, notably
+   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
+   could be considered.
+
+
+
+
+
+
+Baker & Bose                 Informational                      [Page 8]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+1.5.  The Resource Reservation Protocol (RSVP)
+
+   RSVP is initially defined in [RFC2205] with a set of datagram
+   processing rules defined in [RFC2209] and datagram details for
+   Integrated Services [RFC2210].  Conceptually, this protocol specifies
+   a way to identify data flows from a source application to a
+   destination application and request specific resources for them.  The
+   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
+   multicast group (and therefore all of the machines in it).  Each
+   application is specified by a transport protocol number in the IP
+   protocol field, or may additionally include destination and perhaps
+   source port numbers.  The protocol is defined for both IPv4 [RFC0791]
+   and IPv6 [RFC2460].  It was recognized immediately that it was also
+   necessary to provide a means to perform the same function for various
+   kinds of tunnels, which implies a relationship between what is inside
+   and what is outside the tunnel.  Definitions were therefore developed
+   for IPsec [RFC2207] and [RFC4860] and for more generic forms of
+   tunnels [RFC2746].  With the later development of the Differentiated
+   Services Architecture [RFC2475], definitions were added to specify
+   the Differentiated Services Code Point (DSCP) [RFC2474] to be used by
+   a standard RSVP data flow in [RFC2996] and to use a pair of IP
+   addresses and a DSCP as the identifying information for a data flow
+   [RFC3175].
+
+   In addition, the initial definition of the protocol included a
+   placeholder for policy information, and for preemption of
+   reservations.  This placeholder was later specified in detail in
+   [RFC2750] with a view to associating a policy [RFC2872] with an
+   identity [RFC3182] and thereby enabling the network to provide a
+   contracted service to an authenticated and authorized user.  This was
+   integrated with the Session Initiation Protocol [RFC3261] in
+   [RFC3312].  Preemption of a reservation is specified as in [RFC3181]
+   -- a reservation that is installed in the network using an Preemption
+   Priority and retained using a separate Defending Priority may be
+   removed by the network via an RESV Error signal that removes the
+   entire reservation.  This has issues, however, in that the matter is
+   often not quite so black and white.  If the issue is that an existing
+   reservation for 80 kbps can no longer be sustained but a 60 kbps
+   reservation could, it is possible that a VoIP sender could change
+   from a G.711 codec to a G.729 codec and achieve that.  Or, if there
+   are multiple sessions in a tunnel or other aggregate, one of the
+   calls could be eliminated leaving capacity for the others.  [RFC4495]
+   seeks to address this issue.
+
+   In a similar way, a capability was added to limit the possibility of
+   control signals being spoofed or otherwise attacked [RFC2747]
+   [RFC3097].
+
+
+
+Baker & Bose                 Informational                      [Page 9]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   [RFC3175] describes several features that are unusual in RSVP, being
+   specifically set up to handle aggregates in a service provider
+   network.  It describes three key components:
+
+   o  The RFC 3175 session object, which identifies not the IP addresses
+      of the packets that are identified, but the IP addresses of the
+      ingress and egress devices in the network, and the DSCP that the
+      traffic will use.
+
+   o  The function of a reservation "aggregator", which operates in the
+      ingress router and accepts individual reservations from the
+      "customer" network.  It aggregates the reservations into the ISP
+      core in a tunnel or an MPLS LSP, or as a traffic stream that is
+      known to leave at the deaggregator.
+
+   o  The function of a reservation "deaggregator", which operates in
+      the egress router and breaks the aggregate reservation and data
+      streams back out into individual data streams that may be passed
+      to other networks.
+
+   In retrospect, the Session Object specified by RFC 3175 is useful but
+   not intrinsically necessary.  If the ISP network uses tunnels, such
+   as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security
+   Associations, the concepts of an aggregator and a deaggregator work
+   in the same manner, although the reservation mechanism would be that
+   of [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746].
+
+1.6.  Logical Structure of a VPN Router
+
+   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
+   port device (similar to that shown in Figure 4), which has one or
+   more interfaces to the protected enclave(s) and one or more
+   interfaces to the outside world.  On the latter, it structures some
+   number of tunnels (in the case of an IPsec tunnel, having security
+   associations) that it can treat as point-to-point interfaces from a
+   routing perspective.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 10]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+          +---------+  +-------+   +----+----+       +---------+
+          |   RSVP  |  |Routing|   |Net Guard|        |IPsec Mgr|
+          +----+----+  +---+---+   +----+----+       +----+----+
+               |           |            |                 |
+          +----+-----------+------------+-----------------+----+
+          |                         IP                         |
+          +-----------+--------------------+------------+------+
+                      |                    |            |
+                      |              +-----+-----+ +----+------+
+                      |              | Encrypt/  | | Encrypt/  |
+                      |              |Decrypt for| |Decrypt for|
+                      |              | Security  | | Security  |
+                      |              |Association| |Association|
+                      |              +-----+-----+ +----+------+
+                      |                    |            |
+          +-----------+------------+ +-----+------------+------+
+          |       Plaintext        | |       Ciphertext        |
+          |       Interface        | |       Interface         |
+          +------------------------+ +-------------------------+
+
+                Figure 4: Logical Structure of a VPN Router
+
+   The encrypt/decrypt unit may be implemented as a function of the
+   plaintext router, as a function on its interface card, or as a
+   function of an external device with a private interface to the IP
+   routing functionality of the plaintext router.  These are
+   conceptually equivalent, although there are practical differences in
+   implementation.  The key issue is that when IP routing presents a
+   message to the encrypt/decrypt unit for transmission, it must also be
+   presented with the IP address of the plaintext routing peer, whether
+   host or router, to which the security association must be
+   established.  This IP Address is used to select (and perhaps create)
+   the security association, and in turn select the appropriate set of
+   security parameters.  This could also be implemented by presenting
+   the local Security Parameter Index (SPI) for the data, if it has been
+   created out of band by the Network Management Process.
+
+   In addition, it is necessary for aggregated signaling to be generated
+   for the ciphertext domain.  This may be accomplished in several ways:
+
+   o  by having the RSVP process on the plaintext router generate the
+      messages and having the encrypt/decrypt unit bypass them into the
+      ciphertext network
+
+   o  by having the plaintext RSVP process advise a process in the
+      encrypt/decrypt implementation of what needs to be generated using
+      some local exchange, and having it generate such messages, or
+
+
+
+
+Baker & Bose                 Informational                     [Page 11]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   o  by having a separate parallel network management system
+      intermediate between the plaintext and ciphertext routers, in
+      which case, the encrypt/decrypt unit and the parallel network
+      system must use the same address, and the ciphertext router must
+      distinguish between traffic for them based on SPI or the presence
+      of encryption.
+
+   Control plane signaling using this additional path is described in
+   Section 3.2.  The information flow between the plaintext and
+   ciphertext domains includes
+
+   o  IP datagrams via the encrypt/decrypt unit,
+
+   o  RSVP signaling via the bypass path,
+
+   o  Control information coordinating security associations, and
+
+   o  precious little else.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 12]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+2.  Reservation and Preemption in a Nested VPN
+
+                        /                           \
+                       (       +--+   +--+   enclave )   ,---------.
+         .----------.   \      |H2+---+R2|          / ,-'           `
+          +--+   +--+`--.\     +--+   ++-+         / /   +--+   +--+
+          |H1+---+R1|    \`.           |         ,' /    |R3+---+H3|
+          +--+   +-++     ) '--.    +----++  _.-'  (     ++-+   +--+
+                   |     /    _.`---|VPN2||''-.     \     |
+         enclave +----+-i.--''      +----++    `----.\ +----+ enclave
+         --------|VPN1|'              |              ``|VPN3|       ,
+                ,+----+               |                +----+------'
+              ,' --+-------+----------+------------------+---`.
+            ,'            ++-+                                 `.
+          ,'              |R7+--------+                          `.
+         / interface      +--+        |                            \
+           domain 1                 +-+--+                          \
+                          _.--------|VPN7|--------.
+                  ,-----''          +--+-+         `------.         .
+         `-.   ,-'                     |                   `-.   .-'
+            `-:  inner domain        +-++                     `.'
+            (                        |R9|                       )
+            .'.                      ++-+                     ;-.
+          .'   `-.                    |                    ,-'   `-.
+         '        `------.          +-+--+         _.-----'         `
+           interface      `---------|VPN8|-------''
+           domain 2                 +-+--+                          /
+         \                            |          +--+              /
+          `.                          +----------+R8|            ,'
+            `.                                   ++-+          ,'
+              `. --+------------------+-----------+------+-- ,'
+           ,-----+----+               |                +----+------.
+         ,'      |VPN6|.              |              _.|VPN4|       `
+                 +----+.`----.      +----+     _.--'' ,+----+
+                  |     \     `--=.-|VPN5|---:'      /    |
+          +--+   ++-+    :   ,-''   +----+    `--.  ;    ++-+   +--+
+          |H6+---+R6|    | ,'          |          `.|    |R4+---+H4|
+          +--+   +--+    ;/    +--+   ++-+          :    +--+   +--+
+                        //     |H5+---+R5|           \
+          enclave     ,'(      +--+   +--+            `.     enclave
+         `.         ,'   \                 enclave   /  '-.         ,
+           `-------'      \                         /      `-------'
+
+                  Figure 5: Reservations in a Nested VPN
+
+   Let us discuss how a resource reservation protocol, and specifically
+   RSVP, might be used in a nested virtual private network.
+
+
+
+
+Baker & Bose                 Informational                     [Page 13]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+2.1.  Reservation in a Nested VPN
+
+   A reservation in a nested VPN is very much like a reservation in any
+   other network, with one exception: it is composed of multiple
+   reservations that must be coordinated.  These include a reservation
+   within the originating and receiving enclaves and a reservation at
+   each layer of the VPN, as shown in Figure 5.
+
+   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
+   created end to end.  As it traverses the VPN router leaving its
+   enclave, the reservation information and the data are placed within
+   the appropriate tunnel (e.g., the IPsec Security Association for its
+   precedence level to the appropriate remote VPN router).  At the
+   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
+   with a DSCP appropriate to its application and (if there is a
+   difference) precedence level, and the signaling datagrams (PATH and
+   RESV) are marked with a DCLASS object indicating that value.  RSVP
+   signaling datagrams (PATH and RESV) are marked with a DCLASS object
+   indicating the value used for the corresponding data.  The DSCP on
+   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
+   DSCP that is routed the same way as the relevant data.  The [RFC2872]
+   policy object specifies the applicable policy (e.g., "routine service
+   for voice traffic") and asserts a [RFC3182] credential indicating its
+   user (which may be a person or a class of persons).  As specified in
+   [RFC3181], it also specifies its Preemption Priority and its
+   Defending Priority; these enable the Preemption Priority of a new
+   session to be compared with the Defending Priority of previously
+   admitted sessions.
+
+   On the ciphertext side of the VPN router, no guarantees result unless
+   the VPN router likewise sets up a reservation to the peer VPN Router
+   across the ciphertext domain.  Thus, the VPN router sets up an
+   [RFC2207], [RFC4860], or [RFC3175] reservation to its peer.
+
+   The Session Object defined by [RFC2207] or [RFC4860] contains a field
+   called a "virtual destination port", which allows the multiplexing of
+   many reservations over a common security association and, in the
+   latter case, a common DSCP value.  Thus, the voice traffic at every
+   precedence level might use the Expedited Forwarding (EF) DSCP and
+   service as described in [RFC3246], but the reservations would be for
+   "the aggregate of voice sessions at precedence Pn between these VPN
+   routers".  This would allow the network administration to describe
+   policies with multiple thresholds, such as "a new session at
+   precedence Pn may be accepted if the total reserved bandwidth does
+   not exceed threshold Qn; if it is necessary and sufficient to accept
+
+
+
+Baker & Bose                 Informational                     [Page 14]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   the reservation, existing reservations at lower precedences may be
+   preemptively reduced to make acceptance of the new session possible".
+
+   In the [RFC3175] case, since the DSCP must be used to identify both
+   the reservation and the corresponding data stream, the aggregate
+   reservations for different precedence levels require different DSCP
+   values.
+
+   In either case, the fundamental necessity is for one VPN router to
+   act as what [RFC3175] calls the "aggregator" and another to act as
+   the "deaggregator", and extend a VPN tunnel between them.  If the VPN
+   Tunnel is an IPsec Security Association between the VPN routers and
+   the IP packet is entirely contained within (such as is used to cross
+   a firewall), then the behavior of [RFC2746] is required of the
+   tunnel.  That bearer will have the following characteristics:
+
+   o  it will have a DSCP corollary to the DSCP for the data or the same
+      DSCP as the data it carries,
+
+   o  the reservations and data will be carried in security associations
+      between the VPN routers, and
+
+   o  the specification for the reservation for the tunnel itself will
+      not be less than the sum of the requirements of the aggregated
+      reservations.
+
+   The following requirements relationships apply between the set of
+   enclosed reservations and the tunnel reservation:
+
+   o  The sum of the average rates of the contained reservations, having
+      been adjusted for the additional IP headers, will be less than or
+      equal to the average rate of the tunnel reservation.
+
+   o  The sum of the peak rates of the contained reservations, having
+      been adjusted for the additional IP headers, will be less than or
+      equal to the peak rate of the tunnel reservation.
+
+   o  The sum of the burst sizes of the contained reservations, having
+      been adjusted for the additional IP headers, will be less than or
+      equal to the burst size of the tunnel reservation.
+
+   o  The Preemption Priority of a tunnel reservation is identical to
+      that of the individual reservations it aggregates.
+
+   o  The Defending Priority of a tunnel reservation is identical to
+      that of the individual reservations it aggregates.
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 15]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   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
+   tunnel's average bandwidth specification would be greater than or
+   equal to the actual average offered traffic.  Such systems are beyond
+   the scope of this specification.
+
+   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
+   specify different thresholds (e.g., "to accept a new routine call,
+   the total reserved bandwidth after admission may not exceed X; to
+   accept a call with a higher precedence level, the total reserved
+   bandwidth after admission may not exceed X+Y, and this may be
+   achieved by preempting a call with a lower precedence level"), the
+   bandwidth Y effectively comes from the bandwidth in use by elastic
+   traffic rather than forcing a preemption event.
+
+2.2.  Preemption in a Nested VPN
+
+   As discussed in Section 1.5, preemption is specified in [RFC3181] and
+   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
+   the network, not simply to remove the reservation.  In the case of an
+   end-system-originated reservation, the end system might be able to
+   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
+   by dropping one or more reservations entirely.
+
+   In a nested VPN or other kind of aggregated reservation, this means
+   that the deaggregator (the VPN router initiating the RESV signal for
+   the tunnel) must
+
+   o  receive the RESV Error signaling it to reduce its bandwidth,
+
+   o  re-issue its RESV accordingly,
+
+   o  identify one or more of its aggregated reservations, enough to do
+      the job, and
+
+   o  signal them to reduce their bandwidth accordingly.
+
+   It is possible, of course, that it is signaling them to reduce their
+   bandwidth to zero, which is functionally equivalent to removing the
+   reservation as described in [RFC3181].
+
+   In the routers in the core, an additional case arises.  One could
+   imagine that some enclave presents the VPN with a single session, and
+   that session has a higher precedence level.  If some interior link is
+   congested (e.g., the reserved bandwidth will exceed policy if the
+
+
+
+Baker & Bose                 Informational                     [Page 16]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   call is admitted), a session between a different pair of VPN routers
+   must be preempted.  More generally, in selecting a reservation to
+   preempt, the core router must always select a reservation at the
+   lowest available Defending Priority.  This is the reason that various
+   precedence levels must be kept separate in the core.
+
+2.3.  Working through an Example
+
+   The network in Figure 5 shows three security layers: six plaintext
+   enclaves around the periphery, two ciphertext domains connecting them
+   at one layer (referred to in the diagram as an "interface domain"),
+   and a third ciphertext domain connecting the first two (referred to
+   in the diagram as an "inner domain").  The following distribution of
+   information exists:
+
+   o  Each enclave has access to general routing information concerning
+      other enclaves it is authorized to communicate with: systems in it
+      can translate a DNS name for a remote host or domain and obtain
+      the corresponding address or prefix.
+
+   o  Each enclave router also has specific routing information
+      regarding its own enclave.
+
+   o  A default route is distributed within the enclave, pointing to its
+      VPN router.
+
+   o  VPN Routers 1-6 are able to translate remote enclave prefixes to
+      the appropriate remote enclave's VPN router addresses.
+
+   o  Each interface domain has access to general routing information
+      concerning the other interface domains, but not the enclaves.
+      Systems in an interface domain can translate a DNS name for a
+      remote interface domain and obtain the corresponding address or
+      prefix.
+
+   o  Each interface domain router also has specific routing information
+      regarding its own interface domain.
+
+   o  A default route is distributed within the interface domain,
+      pointing to the "inner" VPN router.
+
+   o  VPN Routers 7 and 8 are able to translate remote interface domain
+      prefixes to remote VPN router addresses.
+
+   o  Routers in the inner domain have routing information for that
+      domain only.
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 17]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   While the example shows three levels, there is nothing magic about
+   the number three.  The model can be extended to any number of
+   concentric layers.
+
+   Note that this example places unidirectional reservations in the
+   forward direction.  In voice and video applications, one generally
+   has a reservation in each direction.  The reverse direction is not
+   discussed, for the sake of clarity, but operates in the same way in
+   the reverse direction and uses the same security associations.
+
+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
+   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 a PATH
+   signal describing their traffic.  For the sake of argument, let us
+   presume that H1's reservation is for an [RFC2205] session, H2's
+   reservation is for a session encrypted using IPsec, and therefore
+   depends on [RFC2207], and H3 (which is a Public Switched Telephone
+   Network (PSTN) gateway) sends an [RFC3175] reservation comprising a
+   number of distinct sessions.  Since these are going to H4, H5, and
+   H6, respectively, the default route leads them to VPN1, VPN2, and
+   VPN3, respectively.
+
+   The VPN routers each ensure that they have an appropriate security
+   association or tunnel open to the indicated remote VPN router (VPN4,
+   VPN5, or VPN6).  This will be a security association or tunnel for
+   the indicated application at the indicated precedence level.  Having
+   accomplished that, it will place the PATH signal into the security
+   association and forward it.  If such does not already exist,
+   following [RFC3175]'s aggregation model, it will now open a
+   reservation (send a PATH signal) for the tunnel/SA within the
+   interface domain; if the reservation does exist, the VPN router will
+   increase the bandwidth indicated in the ADSPEC appropriately.  In
+   this example, these tunnel/SA reservations will follow the default
+   route to VPN7.
+
+   VPN7 ensures that it has an appropriate security association or
+   tunnel open to VPN8.  This will be a security association or tunnel
+   for the indicated application at the indicated precedence level.
+   Having accomplished that, it will place the PATH signal into the
+   security association and forward it.  If such does not already exist,
+   following [RFC3175]'s aggregation model, it will now open a
+   reservation (send a PATH signal) for the tunnel/SA within the
+   interface domain; if the reservation does exist, the VPN router will
+   increase the bandwidth indicated in the ADSPEC appropriately.  In
+   this example, this tunnel/SA reservation is forwarded to VPN8.
+
+
+
+
+Baker & Bose                 Informational                     [Page 18]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   VPN8 acts as an [RFC3175] deaggregator for the inner domain.  This
+   means that it receives the PATH signal for the inner domain
+   reservation and stores state, decrypts the data stream from VPN7,
+   operates on the RSVP signals as an RSVP-configured router, and
+   forwards the received IP datagrams (including the updated PATH
+   signals) into its interface domain.  The PATH signals originated by
+   VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and
+   VPN6 according to the routing of the interface domain.
+
+   VPN4, VPN5, and VPN6 each act as an [RFC3175] deaggregator for the
+   interface domain.  This means that it receives the PATH signal for
+   the interface domain reservation and stores state, decrypts the data
+   stream from its peer, operates on the RSVP signals as an RSVP-
+   configured router, and forwards the received IP datagrams (including
+   the updated PATH signals) into its enclave.  The PATH signals
+   originated by H1, H2, and H3 are therefore forwarded towards H4, H5,
+   and H6 according to the routing of the enclave.
+
+   H4, H5, and H6 now receive the original PATH signals and deliver them
+   to their application.
+
+2.3.2.  Initial Routine Reservations - Request Reservation
+
+   The application in H4, H5, and H6 decides to install the indicated
+   reservations, meaning that they now reply with RESV signals.  These
+   signals request the bandwidth reservation.  Following the trail left
+   by the PATH signals, the RESV signals traipse back to their
+   respective sources.  The state left by the PATH signals leads them to
+   VPN4, VPN5, and VPN6, respectively.  If the routers in the enclaves
+   are configured for RSVP, this will be explicitly via R4, R5, or R6;
+   if they are not, routing will lead them through those routers.
+
+   The various RSVP-configured routers en route in the enclave
+   (including the VPN router on the "enclave" side) will verify that
+   there is sufficient bandwidth on their links and that any other
+   stated policy is also met.  Having accomplished that, each will
+   update its reservation state and forward the RESV signal to the next.
+   The VPN routers will also each generate an RESV for the reservation
+   within the interface domain, attempting to set or increase the
+   bandwidth of the reservation appropriately.
+
+   The various RSVP-configured routers en route in the interface domain
+   (including VPN8) will verify that there is sufficient bandwidth on
+   their links and that any other stated policy is also met.  Having
+   accomplished that, each will update its reservation state and forward
+   the RESV signal to the next.  VPN8 will also generate an RESV for the
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 19]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   reservation within the inner domain, attempting to set or increase
+   the bandwidth of the reservation appropriately.  This gets the
+   reservation to the inner deaggregator, VPN8.
+
+   The various RSVP-configured routers en route in the inner domain
+   (including VPN7) will verify that there is sufficient bandwidth on
+   their links and that any other stated policy is also met.  Having
+   accomplished that, each will update its reservation state and forward
+   the RESV signal to the next.  This gets the signal to VPN7.
+
+   VPN7 acts as an [RFC3175] aggregator for the inner domain.  This
+   means that it receives the RESV signal for the inner domain
+   reservation and stores state, decrypts the data stream from VPN8,
+   operates on the RSVP signals as an RSVP-configured router, and
+   forwards the received IP datagrams (including the updated RESV
+   signals) into its interface domain.  The RESV signals originated by
+   VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and
+   VPN3 through the interface domain.
+
+   VPN1, VPN2, and VPN3 each act as an [RFC3175] aggregator 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, operates on the RSVP signals as an RSVP-
+   configured router, and forwards the received IP datagrams (including
+   the updated RESV signals) into its enclave.  The RESV signals
+   originated by H4, H5, and H6 are therefore forwarded towards H1, H2,
+   and H3 according to the routing of the enclave.
+
+   H1, H2, and H3 now receive the original RESV signals and deliver them
+   to their application.
+
+2.3.3.  Installation of a Reservation Using Precedence
+
+   Without going through the details called out in Sections 2.3.1 and
+   2.3.2, if sufficient bandwidth exists to support them, reservations
+   of other precedence levels or other applications may also be
+   installed across this network.  If the "routine" reservations already
+   described are for voice, for example, and sufficient bandwidth is
+   available under the relevant policy, a reservation for voice at the
+   "priority" precedence level might be installed.  Due to the mechanics
+   of preemption, however, this would not expand the existing "routine"
+   reservations in the interface and inner domains, as doing this causes
+   loss of information - how much of the reservation is now "routine"
+   and how much is "priority"?  Rather, this new reservation will open
+   up a separate set of tunnels or security associations for traffic of
+   its application class at its precedence between that aggregator and
+   deaggregator.
+
+
+
+
+Baker & Bose                 Informational                     [Page 20]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   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
+   PSTN application under a certain set of rules (H channels, such as
+   those used by video streams, must be contiguous and ordered).  As
+   such, if a channel is not made available to routine traffic but is
+   made available to priority traffic, the operator is potentially
+   losing revenue on the reserved bandwidth and deserves remuneration.
+   However, in the IP Internet, some bandwidth must be kept for basic
+   functions such as routing, and, in general, policies will not permit
+   100% of the bandwidth on an interface to be allocated to one
+   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
+   a larger amount (e.g., 60%) to be used by voice at a higher
+   precedence level.  Under such a policy, a higher precedence
+   reservation for voice might not result in the preemption of a routine
+   call, but rather impact elastic traffic, and might be accepted at a
+   time that a new reservation of lower precedence might be denied.
+
+   In microwave networks, such as satellite or mobile ad hoc, one could
+   also imagine network management intervention that could change the
+   characteristics of the radio signal to increase the bandwidth under
+   some appropriate policy.
+
+2.3.4.  Installation of a Reservation Using Preemption
+
+   So we now have a number of reservations across the network described
+   in Figure 5 including several reservations at "routine" precedence
+   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
+   the bandwidth allocated by policy to voice at the routine or priority
+   level has been reserved.  Let us further imagine that a new
+   "priority" reservation is now placed from H3 to H6.
+
+   The process described in Section 2.3.1 is followed, resulting in PATH
+   state across the network for the new reservation.  This is installed
+   even though it is not possible to install a new reservation on VPN7-
+   R9, as it does not install any reservation and the network does not
+   know whether H6 will ultimately require a reservation.
+
+   The process described in Section 2.3.2 is also followed.  The
+   application in H6 decides to install the indicated reservation,
+   meaning that it now replies with an RESV signal.  Following the trail
+   left by the PATH signal, the RESV signal traipses back towards H3.
+   VPN6 and (if RSVP was configured) R6 verify that there is sufficient
+   bandwidth on their links and that any other stated policy is also
+   met.  Having accomplished that, each will update its reservation
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 21]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   state and forward the RESV signal to the next.  VPN6 also generates
+   an RESV for the reservation within the interface domain, attempting
+   to set or increase the bandwidth of the reservation appropriately.
+
+   VPN6, R8, and VPN8's "interface domain" sides now verify that there
+   is sufficient bandwidth on their links and that any other stated
+   policy is also met.  Having accomplished that, each will update its
+   reservation state and forward the RESV signal to the next.  VPN8 will
+   also generate an RESV for the reservation within the inner domain,
+   attempting to set or increase the bandwidth of the reservation
+   appropriately.  This gets the reservation to the inner deaggregator,
+   VPN8.
+
+   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
+   met.  At R9, a problem is detected - there is not sufficient
+   bandwidth under the relevant policy.  In the absence of precedence,
+   R9 would now return an RESV Error indicating that the reservation
+   could not be increased or installed.  In such a case, if a
+   preexisting reservation of lower bandwidth already existed, the
+   previous reservation would remain in place but the new bandwidth
+   would not be granted, and the originator (H6) would be informed.  Let
+   us clarify what it means to be at a stated precedence: it means that
+   the POLICY_DATA object in the RESV contains a Preemption Priority and
+   a Defending Priority with values specified in some memo.  With
+   precedence, [RFC4495]'s algorithm would have the Preemption Priority
+   of the new reservation compared to the Defending Priority of extant
+   reservations in the router, of which there are two: one VPN7->VPN8 at
+   "routine" precedence and one VPN7->VPN8 at "priority" precedence.
+   Since the Defending Priority of routine reservation is less than the
+   Preemption Priority of a "priority" reservation, the "routine"
+   reservation is selected.  R9 determines that it will accept the
+   increase in its "priority" reservation VPN7->VPN8 and reduce the
+   corresponding "routine" reservation.  Two processes now occur in
+   parallel:
+
+   o  The routine reservation is reduced following the algorithms in
+      [RFC4495] and
+
+   o  The priority reservation continues according to the usual rules.
+
+   R9 reduces its "routine" reservation by sending an RESV Error
+   updating its internal state to reflect the reduced reservation and
+   sending an RESV Error to VPN8 requesting that it reduce its
+   reservation to a number less than or equal to the relevant threshold
+   less the sum of the competing reservations.  VPN8, acting as a
+   deaggregator, makes two changes.  On the "inner domain" side, it
+   marks its reservation down to the indicated rate (the most it is now
+
+
+
+Baker & Bose                 Informational                     [Page 22]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   permitted to reserve), so that if an RESV Refresh event happens, it
+   will request the specified rate.  On the "interface domain" side, it
+   selects one or more of the relevant reservations by an algorithm of
+   its choosing and requests that it likewise reduce its rate.  For the
+   sake of argument, let us imagine that the selected reservation is the
+   one to VPN5.  The RESV Error now makes its way through R8 to VPN5,
+   which similarly reduces its bandwidth request to the stated amount
+   and passes a RESV Error signal on the "enclave" side requesting that
+   the reservation be appropriately reduced.
+
+   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.  In this simple case, it sends an RESV Tear to tear down
+   the reservation entirely and advises its application to adjust its
+   expectations of the session accordingly, which may mean shutting down
+   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
+   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
+   possible to renegotiate the codec in use to G.729 or some other
+   codec.  In such a case, the originating application should re-reserve
+   at the stated bandwidth (in this case, 70 kbps), initiate the
+   application level change, and let the application change the
+   reservation again (perhaps to 60 kbps) when it has completed that
+   process.
+
+   At the time the reservation is being processed at R9, for the
+   "priority" reservation, R9 believes that it has sufficient bandwidth
+   and that any other stated policy is also met, and it forwards the
+   RESV to VPN7.  Each will update its reservation state and forward the
+   RESV signal to the next.  VPN7 now acts as an [RFC3175] aggregator
+   for the inner domain.  This means that it receives the RESV signal
+   for the inner domain reservation and stores state, decrypts the data
+   stream from VPN8, operates on the RSVP signals as an RSVP-configured
+   router, and forwards the received IP datagrams (including the updated
+   RESV signals) into its interface domain.  The RESV signals originated
+   by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2,
+   and VPN3 through 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
+   reservation and stores state, decrypts the data stream from its peer,
+   operates on the RSVP signals as an RSVP-configured router, and
+   forwards the received IP datagrams (including the updated RESV
+   signals) into its enclave.  The RESV signal originated by H6 is
+   therefore forwarded towards H3 according to the routing of the
+   enclave.
+
+
+
+
+Baker & Bose                 Informational                     [Page 23]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   H3 now receives the original RESV signals and delivers it to the
+   relevant application.
+
+3.  Data Flows within a VPN Router
+
+   This section details the data flows within a VPN router, in the
+   context of sessions as described in Section 2.  It specifically
+   identifies the signaling flow at a given VPN boundary and
+   additionally elaborates the signaling mechanism with the aid of a
+   Network Guard.  A use case describing the proposal in the context of
+   an operational scenario is presented herein.
+
+3.1.  VPN Routers That Carry Data across the Cryptographic Boundary
+
+3.1.1.  Plaintext to Ciphertext Data Flows
+
+          +-----------------------+    +----------------------+
+          | +--------------------+|    |+--------------------+|
+          | |RSVP                ||    ||Aggregate RSVP      ||
+          | |                    ||    ||                    ||
+          | |Per session:        || ID ||Agg. Session        ||
+          | |  Destination       ||--->||  Agg. Destination  ||
+          | |  Source            ||    ||  Agg. Source= self ||
+          | |  potential SPI     ||    ||  Agg. SPI generated||
+          | |  DSCP             ---------> DSCP              ||
+          | |  vPort or protocol---------> vPort             ||
+          | |           and port ||    ||                    ||
+          | |  Mean rate        ---------> Sum of mean rates ||
+          | |  Peak rate        ---------> f(Peak rates)     ||
+          | |  Burst Size       ---------> Sum of Burst sizes||
+          | |                    ||    ||                    ||
+          | +--------------------+|    |+--------------------+|
+          | +--------------------+|    |+--------------------+|
+          | |      IP            ||    ||       IP           ||
+          | +--------------------+|    |+--------------------+|
+          | +--------------------+|    |+--------------------+|
+          | | Plaintext Interface||    ||Ciphertext Interface||
+          | +--------------------+|    |+--------------------+|
+          +-----------------------+    +----------------------+
+
+               Figure 6: Data Flows in a VPN Router Outbound
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 24]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   Parameters on a reservation include:
+
+   Destination Address:  On the plaintext side, the VPN router
+      participates in the end-to-end reservations being installed for
+      plaintext sessions.  These may include individual flows as
+      described in [RFC2205], IPsec data flows [RFC2207], aggregate
+      reservations [RFC3175], or other types.  It passes an identifier
+      for the ciphertext side of the deaggregator to its ciphertext
+      unit.
+
+   DSCP:  The DSCP of the plaintext data flow is provided to the cipher
+      text side.
+
+   Virtual Port:  The virtual destination port is provided to the cipher
+      text side.  This may be derived from an [RFC2207] session object
+      or from policy information.
+
+   Mean Rate:  The sum of the plaintext mean rates is provided to the
+      ciphertext unit.
+
+   Peak Rate:  A function of the plaintext peak rates is provided to the
+      ciphertext unit.  This function is less than or equal to the sum
+      of the peak rates.
+
+   Burst Size:  The sum of the burst sizes is provided to the cipher
+      text unit.
+
+   Messages include:
+
+   Path:  The plaintext PATH message is sent as encrypted data to the
+      ciphertext unit.  In parallel, a trigger needs to be sent to the
+      ciphertext unit that results in it generating the corresponding
+      aggregated PATH message for the ciphertext side.
+
+   Path Error:  This indicates that a PATH message sent to the remote
+      enclave was in error.  In the error case, the message itself is
+      sent on as encrypted data, but a signal is sent to the ciphertext
+      side in case the error affects the ciphertext reservation (such as
+      removing or changing state).
+
+   Path Tear:  The PATH Tear message is sent as encrypted data to the
+      ciphertext unit.  In parallel, a signal is sent to the cipher text
+      side; it will trigger a Path Tear on its reservation in the event
+      that this is the last aggregated session, or change the
+      SENDER_TSPEC of the aggregated session.
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 25]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   RESV:  The plaintext RESV message is sent as encrypted data to the
+      ciphertext unit.  In parallel, a trigger needs to be sent to the
+      ciphertext unit that results in it generating the corresponding
+      aggregated RESV message for the ciphertext side.
+
+   RESV Error:  This indicates that a RESV message that was received as
+      data and forwarded into the enclave was in error or needed to be
+      preempted as described in [RFC3181] or [RFC4495].  In the error
+      case, the message itself is sent on as encrypted data, but a
+      signal is sent to the ciphertext side in case the error affects
+      the ciphertext reservation (such as removing or changing state).
+
+   RESV Tear:  The RESV Tear message is sent as encrypted data to the
+      ciphertext unit.  In parallel, a signal is sent to the cipher text
+      side; it will trigger a RESV Tear on its reservation in the event
+      that this is the last aggregated session, or reduce the bandwidth
+      of an existing reservation.
+
+   RESV Confirm:  This indicates that a RESV message received as data
+      and forwarded into the enclave, and is now being confirmed.  This
+      message is sent as encrypted data to the ciphertext side, and, in
+      parallel, a signal is sent to potentially trigger an RESV Confirm
+      on the aggregate reservation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 26]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+3.1.2.  Ciphertext to Plaintext Data Flows
+
+           +-----------------------+    +----------------------+
+           | +--------------------+|    |+--------------------+|
+           | |RSVP                ||    ||Aggregate RSVP      ||
+           | |                    ||    ||  terminated        ||
+           | |Per session:        |+    ||                    ||
+           | |  Destination       ||    ||                    ||
+           | |  Source          <---------Decrypted RSVP      ||
+           | |  potential SPI     ||    ||  message sent to   ||
+           | |  DSCP              ||    ||  Plaintext unit    ||
+           | |  vPort or protocol ||    ||  *as data* for     ||
+           | |           and port ||    ||  normal processing ||
+           | |  Mean rate         ||    ||                    ||
+           | |  Peak rate         ||    ||                    ||
+           | |  Burst Size        ||    ||                    ||
+           | |                    ||    ||                    ||
+           | +--------------------+|    |+--------------------+|
+           | +--------------------+|    |+--------------------+|
+           | |      IP            ||    ||       IP           ||
+           | +--------------------+|    |+--------------------+|
+           | +--------------------+|    |+--------------------+|
+           | |Plaintext Interface ||    ||Ciphertext Interface||
+           | +--------------------+|    |+--------------------+|
+           +-----------------------+    +----------------------+
+
+               Figure 7: Data Flows in a VPN Router Inbound
+
+   The aggregate reservation is terminated by the ciphertext side of the
+   VPN router.  The RSVP messages related to the subsidiary sessions are
+   carried in the encrypted tunnel as data, and therefore arrive at the
+   plaintext side with other data.  As the plaintext side participates
+   in these reservations, some information is returned to the ciphertext
+   size to parameterize the aggregate reservation as described in
+   Section 3.1.1 in the processing of the outbound messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 27]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+3.2.  VPN Routers That Use the Network Guard for Signaling across the
+      Cryptographic Boundary
+
+   As described in Section 1.6 the Network Guard provides an additional
+   path for the reservation signaling between the plaintext and cipher
+   text domains.
+
+                                 _.------------.
+                            ,--'' Plaintext Domain--.
+                         ,-' +--------+  +--------+  `-.
+                       ,'    |  Host  |  | Host   |     `.
+                     ,'      +--------+  +--------+       `.
+                    ;                                       :
+                    |         +----------------------+      |
+                    :         |  +--------+          |      |
+                     `.       |  | Router |          |    ,'
+                       `.     |  +---+----+          |  ,'
+                         `-   |      +----------+    | ,'
+                           ---|    +-+--+  +-+--+--+ |'
+                              |----|E/D |--|Net Grd| | VPN Router
+                           ,-'|    +-+--+  +-+--+--+ |\
+                          ,   |      +----------+    | \
+                        ,'    |  +---+----+          |  `.
+                      ,'      |  | Router |          |    |
+                     /        |  +--------+          |     \
+                    ;         +----------------------+      :
+                    |                                       |
+                    :            Ciphertext Domain          ;
+
+                 Figure 8: RSVP Passage via Network Guard
+
+   In this context, the VPN router is composed of a plaintext router, a
+   ciphertext router, an encrypt/decrypt implementation (such as a line
+   card or interface device), and a network management process that
+   manages the encrypt/decrypt implementation and potentially passes
+   defined information flows between the plaintext and ciphertext
+   domains.  If the Network Guard is implemented as a software process
+   that exchanges configuration instructions between the routers, this
+   is simple to understand.  If it is built as a separate systems
+   exchanging datagrams, it is somewhat more complex, but conceptually
+   equivalent.  For example, the ciphertext router would consider an IP
+   datagram received via the Network Guard (control plane) as having
+   been received from and concerning the interface used in the data
+   plane to the encrypt/decrypt unit.
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 28]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+3.2.1.  Signaling Flow
+
+   Encrypt/decrypt units may not be capable of terminating and
+   originating flows as described in Section 3.1, and policy may prevent
+   knowledge of the ciphertext network addresses in the plaintext
+   router.  In such a case, the plaintext and ciphertext routers may use
+   the Network Guard as the path for the signaling flows.  The Network
+   Guard performs the following functions to enable the flow of
+   reservation signaling across the cryptographic domain
+
+   o  transforms plaintext session identifiers into ciphertext session
+      identifiers and vice-versa in IP datagrams and RSVP objects (e.g.
+      IP addresses)
+
+   o  performs resource management of aggregated reservations (e.g.,
+      including ciphertext encapsulation overhead to resources
+      requested)
+
+   o  reads and writes configuration on the encrypt/decrypt units as
+      necessary (e.g., reads plaintext to ciphertext IP address mapping)
+
+   In addition, the plaintext and ciphertext routers must support a
+   routing function or local interface that ensures that aggregated RSVP
+   messages flow via the Network Guard.  However, the signaling flow
+   across the entire VPN router at a cryptographic boundary remains
+   identical to the description in Section 3.1.
+
+   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
+   and the encrypt/decrypt units can be part of the plaintext router.
+   The details of alternate logical and physical architectures for the
+   VPN router are beyond the scope of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 29]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+3.2.2.  Use Case with Network Guard
+
+                   ........................................
+                   :              VPN Router A            :
+                   :                                      :
+                   :+-----------++----------++-----------+:
+     +------+ RSVP :|           || NetGrd-A ||           |:
+     |Host A|<---->:|PT-Router-A|+----------+|CT-Router-A|::::::::
+     +------+      :|           ||   E/D-A  ||           |:     ::
+                   :+-----------++----------++-----------+:     ::
+                   :                A-RSVP                :     ::
+                   :            <:::::::::::::>           :     ::
+                   :......................................:     ::
+                                                         A-RSVP ::
+                                                               ,---.
+                                                             ,'     `.
+                                                            /         \
+                                                           ; Interface :
+                                                           |  Domain   |
+                                                           :           ;
+                                                            \         /
+                                                             `.     ,'
+                                                               '---'
+                                                         A-RSVP ::
+                   ........................................     ::
+                   :              VPN Router B            :     ::
+                   :                                      :     ::
+                   :+-----------++----------++-----------+:     ::
+     +------+ RSVP :|           || NetGrd-B ||           |:     ::
+     |Host B|<---->:|PT-Router-B|+----------+|CT-Router-B|::::::::
+     +------+      :|           ||   E/D-B  ||           |:
+                   :+-----------++----------++-----------+:
+                   :                A-RSVP                :
+                   :            <:::::::::::::>           :
+                   :......................................:
+
+                Figure 9: Aggregated RSVP via Network Guard
+
+   The above figure depicts a simple use case for aggregated signaling
+   with the Network Guard.  In this scenario, Host A initiates RSVP
+   signaling to Host B for a reservation.  The RSVP signaling between
+   the hosts is encapsulated by the VPN routers into encrypted tunnels.
+   Aggregated RSVP signaling is triggered by VPN routers, and flows into
+   the CT-Routers, as well as the interface domains, to reserve
+   resources at RSVP-capable routers on the path.  The aggregation/
+   deaggregation point for RSVP reservations in this use case are the
+   PT-Routers.  The signaling aggregation of RSVP into A-RSVP at the
+   PT-Router is similar to the data flow described in Section 3.1.  The
+
+
+
+Baker & Bose                 Informational                     [Page 30]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   Network Guard performs the additional functions described in Section
+   3.2.1 to transform plaintext A-RSVP messages into suitable ciphertext
+   A-RSVP messages.  A typical reservation set up in this case would
+   follow these steps.
+
+   o  Host A sends RSVP PATH message to Host B.
+
+   o  PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to
+      VPN Router B.
+
+   o  CT Routers and Interface domain carry encrypted RSVP PATH message
+      (like any other encrypted data message).
+
+   o  PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr
+      message to PT-Router-A in the encrypted tunnel.
+
+   o  PT-Router-B forwards decrypted plaintext RSVP PATH message to Host
+      B.
+
+   o  PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH
+      message towards PT-Router-B via the Network Guard.
+
+   o  The NetGrd-A transforms the plaintext aggregate RSVP into the
+      ciphertext aggregate RSVP message as described in Section 3.2.1
+      and sends it to the CT-Router-A.
+
+   o  The ciphertext aggregated RSVP message travels through ciphertext
+      routers in the interface domain.
+
+   o  CT-Router-B receives the ciphertext aggregate RSVP message and
+      sends it to the NetGrd-B.
+
+   o  The NetGrd-B transforms the ciphertext aggregate RSVP into the
+      plaintext aggregate RSVP message as described in Section 3.2.1 and
+      sends it to the PT-Router-B.
+
+   The subsequent RSVP and Aggregate RSVP signaling follows a similar
+   flow, as described in detail in [RFC3175] and [RFC4860]to aggregate
+   each plaintext reservation into a corresponding ciphertext
+   reservation.  This ensures that RSVP-capable ciphertext routers
+   reserve the required resources for a plaintext end-to-end
+   reservation.  Subsequent mechanisms, such as preemption or the
+   increase and decrease of resources reserved, may be applied to these
+   reservations as described before in this document.  The RSVP data
+   flow as described in Section 3.1 within the VPN router (from the
+   plaintext router to the ciphertext router via the Guard) provides
+   necessary and sufficient information to routers in the ciphertext
+   domain to implement the QoS solution presented in the document.
+
+
+
+Baker & Bose                 Informational                     [Page 31]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   In this description, we have described the Network Guard as being
+   separate from the encrypt/decrypt unit.  This separation exists
+   because in certain implementations, it is mandated by those who
+   specify the devices.  The separation does not come for free, however;
+   the separation of the devices for system-engineering purposes is
+   expensive, and it imposes architectural problems.  For example, when
+   the Guard is used to aggregate RSVP messages or Protocol Independent
+   Multicast (PIM) routing, the traffic is destined to the remote VPN
+   router.  This means that the Guard must somehow receive and respond
+   to, on behalf of the VPN Router, messages that are not directed to
+   it.  Several possible solutions exist; they should be selected
+   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
+      can be two independent functions that utilize a common network and
+      MAC layer.  This can allow the two functions to share a common MAC
+      and IP address, so that traffic destined for one function is also
+      received by the other.  In the case that these two functions are
+      physically separated on two devices, they can still share a common
+      MAC and IP address; however, additional modifications may be
+      required on the Guard to filter and not process IP traffic not
+      destined for itself.
+
+   o  The ciphertext interface of the Guard could be placed into
+      promiscuous mode, allowing it to receive all messages and discard
+      all but the few it is interested in.  The security considerations
+      on putting a device in promiscuous mode at the VPN boundary needs
+      to be taken into account in this method.
+
+   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
+      another interface.  In this case, the Guard and the VPN router
+      would use the same IP address.  This mechanism puts the load of
+      all data and management traffic destined for the VPN router upon
+      the Guard.
+
+   o  The VPN router could be engineered to receive all traffic from the
+      ciphertext router and pass any unencrypted traffic it receives to
+      the Guard through another interface.  In this case, the Guard and
+      the VPN router would use the same IP address.
+
+   o  All the VPN router functions, as shown in Figure 9, could be
+      incorporated into a single chassis, with appropriate internal
+      traffic management to send some traffic into the plaintext enclave
+      and some to the Guard.  In this case, the Guard and the VPN router
+      would be -- at least, functionally -- the same system.
+
+
+
+
+Baker & Bose                 Informational                     [Page 32]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   Of these, clearly the last is the simplest architecturally and the
+   one that most minimizes the attendant risk.
+
+4.  Security Considerations
+
+   The typical security concerns of datagram integrity, node and user
+   authentication are implicitly met by the security association that
+   exists between the VPN routers.  The secure data stream that flows
+   between the VPN routers is also used for the reservation signaling
+   datagrams flowing between VPN routers.  Information that is contained
+   in these signaling datagrams receives the same level of encryption
+   that is received by the data streams.
+
+   One of the reasons cited for the nesting of VPN routes in Section 1.3
+   is the different levels of security across the nested VPN routers.
+   If the security level decreases from one VPN router to the next VPN
+   Router in the nested path, the reservation signaling datagrams will,
+   by default, receive the lower security-level treatment.  For most
+   cases, the lower security treatment is acceptable.  In certain
+   networks, however, the reservation signaling across the entire nested
+   path must receive the highest security-level treatment (e.g.,
+   encryption, authentication of signaling nodes).  For example, the
+   highest precedence level may only be signaled to VPN routers that can
+   provide the highest security levels.  If any VPN router in the nested
+   path is incapable of providing the highest security level, it cannot
+   participate in the reservation mechanism.
+
+   In the general case, the nested path may contain routers that are
+   either incapable of participating in VPNs or providing required
+   security levels.  These routers can participate in the reservation
+   only if the lower security level is acceptable (as configured by
+   policy) for the signaling of reservation datagrams.
+
+   VPN routers encapsulate encrypted IP packets and prepend an extra
+   header on each packet.  These packets, whether used for signaling or
+   data, should be identifiable, at a minimum by the IP addresses and
+   DSCP value.  Therefore, the prepended header should contain, at a
+   minimum, the DSCP value corresponding to the signaled reservation in
+   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
+   as its data), or a different DSCP that is routed identically
+   (separating control and data-plane traffic QoS but not routing).
+
+   Additionally security considerations as described in [RFC4860] and
+   [RFC3175] are also applicable in this environment; they include the
+   integrity of RSVP messages can be ensured via mechanisms described in
+   [RFC2747] and [RFC3097] and related key management (through manual
+   configuration or a key management protocol) at nodes between any
+
+
+
+Baker & Bose                 Informational                     [Page 33]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   aggregator and deaggregator pair that processes the messages.  In
+   addition, confidentiality can be provided between hops by employing
+   IPsec.  Further work in the IETF MSEC Working Group may be applicable
+   in these environments for key management and confidentiality.
+
+5.  Acknowledgements
+
+   Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger
+   Levesque, and Subha Dhesikan gave early review comments.
+
+   Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou,
+   and their associates resulted in Section 3.2.
+
+   Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik
+   Bose) added [RFC4860], which clarified the interaction of this
+   approach with the DSCP.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2205]       Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
+                   Jamin, "Resource ReSerVation Protocol (RSVP) --
+                   Version 1 Functional Specification", RFC 2205,
+                   September 1997.
+
+   [RFC2207]       Berger, L. and T. O'Malley, "RSVP Extensions for
+                   IPSEC Data Flows", RFC 2207, September 1997.
+
+   [RFC2746]       Terzis, A., Krawczyk, J., Wroclawski, J., and L.
+                   Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
+                   January 2000.
+
+   [RFC2750]       Herzog, S., "RSVP Extensions for Policy Control", RFC
+                   2750, January 2000.
+
+   [RFC2996]       Bernet, Y., "Format of the RSVP DCLASS Object", RFC
+                   2996, November 2000.
+
+   [RFC3175]       Baker, F., Iturralde, C., Le Faucheur, F., and B.
+                   Davie, "Aggregation of RSVP for IPv4 and IPv6
+                   Reservations", RFC 3175, September 2001.
+
+   [RFC4495]       Polk, J. and S. Dhesikan, "A Resource Reservation
+                   Protocol (RSVP) Extension for the Reduction of
+                   Bandwidth of a Reservation Flow", RFC 4495, May 2006.
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 34]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   [RFC4542]       Baker, F. and J. Polk, "Implementing an Emergency
+                   Telecommunications Service (ETS) for Real-Time
+                   Services in the Internet Protocol Suite", RFC 4542,
+                   May 2006.
+
+   [RFC4860]       Le Faucheur, F., Davie, B., Bose, P., Christou, C.,
+                   and M. Davenport, "Generic Aggregate Resource
+                   ReSerVation Protocol (RSVP) Reservations", RFC 4860,
+                   May 2007.
+
+6.2.  Informative References
+
+   [ITU.MLPP.1990] International Telecommunications Union, "Multilevel
+                   Precedence and Preemption Service", ITU-T
+                   Recommendation I.255.3, 1990.
+
+   [RFC0791]       Postel, J., "Internet Protocol", STD 5, RFC 791,
+                   September 1981.
+
+   [RFC1633]       Braden, B., Clark, D., and S. Shenker, "Integrated
+                   Services in the Internet Architecture: an Overview",
+                   RFC 1633, June 1994.
+
+   [RFC2209]       Braden, B. and L. Zhang, "Resource ReSerVation
+                   Protocol (RSVP) -- Version 1 Message Processing
+                   Rules", RFC 2209, September 1997.
+
+   [RFC2210]       Wroclawski, J., "The Use of RSVP with IETF Integrated
+                   Services", RFC 2210, September 1997.
+
+   [RFC2460]       Deering, S. and R. Hinden, "Internet Protocol,
+                   Version 6 (IPv6) Specification", RFC 2460, December
+                   1998.
+
+   [RFC2474]       Nichols, K., Blake, S., Baker, F., and D. Black,
+                   "Definition of the Differentiated Services Field (DS
+                   Field) in the IPv4 and IPv6 Headers", RFC 2474,
+                   December 1998.
+
+   [RFC2475]       Blake, S., Black, D., Carlson, M., Davies, E., Wang,
+                   Z., and W. Weiss, "An Architecture for Differentiated
+                   Services", RFC 2475, December 1998.
+
+   [RFC2747]       Baker, F., Lindell, B., and M. Talwar, "RSVP
+                   Cryptographic Authentication", RFC 2747, January
+                   2000.
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 35]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+   [RFC2872]       Bernet, Y. and R. Pabbati, "Application and Sub
+                   Application Identity Policy Element for Use with
+                   RSVP", RFC 2872, June 2000.
+
+   [RFC3097]       Braden, R. and L. Zhang, "RSVP Cryptographic
+                   Authentication -- Updated Message Type Value", RFC
+                   3097, April 2001.
+
+   [RFC3181]       Herzog, S., "Signaled Preemption Priority Policy
+                   Element", RFC 3181, October 2001.
+
+   [RFC3182]       Yadav, S., Yavatkar, R., Pabbati, R., Ford, P.,
+                   Moore, T., Herzog, S., and R.  Hess, "Identity
+                   Representation for RSVP", RFC 3182, October 2001.
+
+   [RFC3246]       Davie, B., Charny, A., Bennet, J., Benson, K., Le
+                   Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
+                   D.  Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+                   Behavior)", RFC 3246, March 2002.
+
+   [RFC3261]       Rosenberg, J., Schulzrinne, H., Camarillo, G.,
+                   Johnston, A., Peterson, J., Sparks, R., Handley, M.,
+                   and E.  Schooler, "SIP: Session Initiation Protocol",
+                   RFC 3261, June 2002.
+
+   [RFC3312]       Camarillo, G., Marshall, W., and J.  Rosenberg,
+                   "Integration of Resource Management and Session
+                   Initiation Protocol (SIP)", RFC 3312, October 2002.
+
+   [RFC3473]       Berger, L., "Generalized Multi-Protocol Label
+                   Switching (GMPLS) Signaling Resource ReserVation
+                   Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                   RFC 3473, January 2003.
+
+   [RFC3474]       Lin, Z. and D. Pendarakis, "Documentation of IANA
+                   assignments for Generalized MultiProtocol Label
+                   Switching (GMPLS) Resource Reservation Protocol -
+                   Traffic Engineering (RSVP-TE) Usage and Extensions
+                   for Automatically Switched Optical Network (ASON)",
+                   RFC 3474, March 2003.
+
+   [RFC4301]       Kent, S. and K. Seo, "Security Architecture for the
+                   Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4303]       Kent, S., "IP Encapsulating Security Payload (ESP)",
+                   RFC 4303, December 2005.
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 36]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+Authors' Addresses
+
+   Fred Baker
+   Cisco Systems
+   1121 Via Del Rey
+   Santa Barbara, California  93117
+   USA
+
+   Phone: +1-408-526-4257
+   Fax:   +1-413-473-2403
+   EMail: fred@cisco.com
+
+
+   Pratik Bose
+   Lockheed Martin
+   700 North Frederick Ave
+   Gaithersburg, Maryland  20871
+   USA
+
+   Phone: +1-301-240-7041
+   Fax:   +1-301-240-5748
+   EMail: pratik.bose@lmco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 37]
+
+RFC 4923                  QoS in a Nested VPN                August 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Baker & Bose                 Informational                     [Page 38]
+