--- 1/draft-ietf-tsvwg-vpn-signaled-preemption-01.txt 2007-02-06 22:12:15.000000000 +0100 +++ 2/draft-ietf-tsvwg-vpn-signaled-preemption-02.txt 2007-02-06 22:12:15.000000000 +0100 @@ -1,19 +1,19 @@ Transport Working Group F. Baker Internet-Draft Cisco Systems Intended status: Informational P. Bose -Expires: March 30, 2007 Lockheed Martin - September 26, 2006 +Expires: August 6, 2007 Lockheed Martin + February 2, 2007 QoS Signaling in a Nested Virtual Private Network - draft-ietf-tsvwg-vpn-signaled-preemption-01 + draft-ietf-tsvwg-vpn-signaled-preemption-02 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,40 +24,46 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 30, 2007. + This Internet-Draft will expire on August 6, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). Abstract Some networks require communication between an interior and exterior - portion of a VPN, but have sensitivities about what information is - communicated across the boundary. This note seeks to outline the - issues and the nature of the proposed solutions. + 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 based on the framework for Integrated Services + operation over DiffServ networks as described in RFC 2998 . Table of Contents - 1. QoS in a nested VPN . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Nested VPNs . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Signaled QoS technology . . . . . . . . . . . . . . . . . 7 - 1.3. The Resource Reservation Protocol (RSVP) . . . . . . . . . 8 - 1.4. Logical structure of a VPN Router . . . . . . . . . . . . 10 + 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) . . . . . . . . . 8 + 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 @@ -67,39 +73,43 @@ boundary . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.1.1. Plaintext to Ciphertext Data Flows . . . . . . . . . . 24 3.1.2. Ciphertext to Plaintext Data Flows . . . . . . . . . . 26 3.2. VPN Routers that use the Network Guard for signaling across the cryptographic boundary . . . . . . . . . . . . 27 3.2.1. Signaling Flow . . . . . . . . . . . . . . . . . . . . 28 3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 36 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 33 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 34 -1. QoS in a nested VPN +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, but have sensitivities about what - information is communicated across the boundary. 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 + 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 @@ -110,26 +120,32 @@ 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 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. 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 points, and the use of other kinds of tunnels - including GRE, IP/IP, MPLS, and so on. + 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 + points, and the use of other kinds of tunnels including 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 @@ -168,27 +184,27 @@ some cases, even though the traffic is absolutely critical to the network. Telephone call setup exchanges have this characteristic as 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.1. Nested VPNs +1.3. Nested VPNs - One could describe such a 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: it + 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: it o receives an IP datagram from a plain text 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 [RFC2401] section 4) with that router, o encloses the encrypted datagram within another VPN (e.g. IPsec) @@ -227,21 +245,33 @@ 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. - VPN-Router | Router | VPN-Router + 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 cipher text network which, for various reasons, is itself re- encrypted and transmitted across a larger cipher text network. The reasons for 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. @@ -269,21 +299,21 @@ | 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.2. Signaled QoS technology +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 its own words, 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 @@ -326,21 +357,21 @@ 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 RSVP and NSIS. The present discussion is limited to RSVP, although any protocol that delivers a similar set of capabilities could be considered. -1.3. The Resource Reservation Protocol (RSVP) +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 @@ -401,21 +433,21 @@ 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] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC2746]. -1.4. Logical structure of a VPN Router +1.6. Logical structure of a VPN Router The conceptual structure of a VPN Router is similar to that of any 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. @@ -593,22 +625,22 @@ 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 or the same as the DSCP for the data - it carries, + 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: @@ -642,21 +674,21 @@ specify different thresholds (e. g., "to accept a new routine call, the total reserved bandwidth after admission may not exceed X; to accept a higher precedence level call, the total reserved bandwidth after admission may not exceed X+Y, and this may be achieved by preempting a lower precedence level call"), 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.3 preemption is specified in [RFC3181] and + As discussed in Section 1.5 preemption is specified in [RFC3181] and further addressed in [RFC4495]. The issue is that in many cases the 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 @@ -1008,21 +1040,25 @@ signals) into its enclave. The RESV signal originated by H6 is therefore forwarded towards H3 according to the routing of the enclave. H3 now receives the original RESV signals and deliver 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. + 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 || @@ -1148,21 +1184,21 @@ are carried in the encrypted tunnel as data, and therefore arrive at the plain text side with other data. As the plain text side participates in these reservations, some information is returned to the cipher text size to parameterize the aggregate reservation as described in Section 3.1.1 in the processing of the outbound messages. 3.2. VPN Routers that use the Network Guard for signaling across the cryptographic boundary - As described in Section 1.4 the Network Guard provides an additional + As described in Section 1.6 the Network Guard provides an additional path for the reservation signaling between the plain text and cipher text domains. _.------------. ,--'' Plain text Domain--. ,-' +--------+ +--------+ `-. ,' | Host | | Host | `. ,' +--------+ +--------+ `. ; : | +----------------------+ | @@ -1330,33 +1366,45 @@ 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 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. There are several - possible solutions: + possible solutions, which need to be carefully selected based on the + security and implementation needs of the environment: - o The two devices could use a common MAC and IP address, so that - traffic destined to one is also received by the other + o In the simplest case, the network guard and encrypt/decrypt unit + can be two independent functions which 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 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. + 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. + 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 @@ -1376,21 +1424,21 @@ 5. 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 which 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.1 + One of the reasons cited for the nesting of VPN routes in Section 1.3 are the different levels of security across the nested VPN Routers. 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 which can provide the highest security levels. If any VPN Router in the @@ -1406,40 +1454,52 @@ 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. The prepended header, therefore, 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 + [I-D.ietf-tsvwg-rsvp-ipsec] and [RFC3175]are also applicable in this + environment which 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 aggregator and deaggregator + pair that process 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. + 6. 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 [I-D.ietf-tsvwg-rsvp-ipsec], which clarified the interaction of this approach with the DSCP. 7. References 7.1. Normative References - [I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate RSVP + [I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate + Resource ReSerVation Protocol (RSVP) Reservations", - draft-ietf-tsvwg-rsvp-ipsec-01 (work in - progress), June 2006. + draft-ietf-tsvwg-rsvp-ipsec-04 (work in + progress), January 2007. [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. @@ -1465,101 +1525,119 @@ Reservation Flow", RFC 4495, May 2006. [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. 7.2. Informative References - [ITU.MLPP.1990] International Telecommunications Union, "Multilevel - Precedence and Preemption Service", ITU- - T Recommendation I.255.3, 1990. + [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. + [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. + [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. + [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. + [RFC2210] Wroclawski, J., "The Use of RSVP with + IETF Integrated Services", RFC 2210, + September 1997. - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for - the Internet Protocol", RFC 2401, November 1998. + [RFC2401] Kent, S. and R. Atkinson, "Security + Architecture for the Internet Protocol", + RFC 2401, November 1998. - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 2460, - December 1998. + [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, + [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. + [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. + [RFC2747] Baker, F., Lindell, B., and M. Talwar, + "RSVP Cryptographic Authentication", + RFC 2747, January 2000. - [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub - Application Identity Policy Element for Use with - RSVP", RFC 2872, June 2000. + [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. + [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. + [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. + [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. + [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. + [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. + [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", + [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)", + [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. - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, December 2005. + [RFC4303] Kent, S., "IP Encapsulating Security + Payload (ESP)", RFC 4303, December 2005. Authors' Addresses Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA Phone: +1-408-526-4257 @@ -1571,32 +1648,32 @@ 700 North Frederick Ave Gaithersburg, Maryland 20871 USA Phone: +1-301-240-7041 Fax: +1-301-240-5748 EMail: pratik.bose@lmco.com Full Copyright Statement - Copyright (C) The Internet Society (2006). + 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 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 + 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 @@ -1613,12 +1690,12 @@ 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. Acknowledgements Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). This document was produced - using xml2rfc v1.31 (of http://xml.resource.org/) from a source in + using xml2rfc v1.32 (of http://xml.resource.org/) from a source in RFC-2629 XML format.