--- 1/draft-ietf-tsvwg-vpn-signaled-preemption-00.txt 2006-09-27 22:12:26.000000000 +0200 +++ 2/draft-ietf-tsvwg-vpn-signaled-preemption-01.txt 2006-09-27 22:12:26.000000000 +0200 @@ -1,21 +1,21 @@ Transport Working Group F. Baker Internet-Draft Cisco Systems -Expires: August 30, 2006 P. Bose - Lockheed Martin - February 26, 2006 +Intended status: Informational P. Bose +Expires: March 30, 2007 Lockheed Martin + September 26, 2006 QoS Signaling in a Nested Virtual Private Network - draft-ietf-tsvwg-vpn-signaled-preemption-00 + draft-ietf-tsvwg-vpn-signaled-preemption-01 -Status of this Memo +Status of This Memo By submitting this Internet-Draft, each author represents that any 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 other groups may also distribute working documents as Internet- Drafts. @@ -24,21 +24,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 30, 2006. + This Internet-Draft will expire on March 30, 2007. Copyright Notice Copyright (C) The Internet Society (2006). 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 @@ -73,36 +73,33 @@ 3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 35 - - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 - Intellectual Property and Copyright Statements . . . . . . . . . . 39 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 36 1. QoS in a nested VPN More and more networks wish to guarantee secure transmission of IP - traffic for 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 [I-D.ietf-tsvwg-mlpp-that-works] . The - key characteristics of this proposal are that + 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 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 @@ -128,23 +125,23 @@ including GRE, IP/IP, MPLS, and so on. 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 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 + 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 @@ -202,21 +199,21 @@ The receiving VPN Router reverses the steps: it o determines what security association the datagram was received from, o decrypts the interior datagram, o forwards the now-decapsulated datagram on a plain text interface. The use of IPsec in this manner is described as the tunnel mode of - [RFC2401] and [RFC2406] . + [RFC2401] and [RFC4303]. Host Host Host Host Host Host /------------------/ /------------------/ Router -------Router | VPN-Router || || IPsec Tunnel through routed network || VPN-Router | @@ -333,60 +330,59 @@ 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) 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 + 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 [I-D.lefaucheur-rsvp-ipsec] and for more + for IPsec [RFC2207] and [I-D.ietf-tsvwg-rsvp-ipsec] and for more generic forms of tunnels [RFC2746]. With the later development of the Differentiated Services Architecture [RFC2475], definitions were - added to specify the 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]. + added to specify the 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 in the context, in [RFC3181] which in essence specifies that a reservation 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. [I-D.polk-tsvwg-rsvp-bw-reduction] seeks to - address this issue. + 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] . [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 @@ -402,21 +398,21 @@ 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] [I-D.lefaucheur-rsvp-ipsec] or + of [RFC3473] and [RFC3474] [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC2746] . 1.4. 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 @@ -553,49 +549,50 @@ 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 proviso that if routing varies by DSCP then it must be a DSCP - that is routed the same way as the relevant data. The [RFC2872] + 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 cipher text side of the VPN Router, no guarantees result unless the VPN Router likewise sets up a reservation to the peer VPN Router across the cipher text domain. Thus, the VPN Router sets up - an [RFC2207] [I-D.lefaucheur-rsvp-ipsec] or [RFC3175] reservation to + an [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC3175] reservation to its peer. - The Session Object defined by [RFC2207] or [I-D.lefaucheur-rsvp- - ipsec] 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 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 - the reservation, existing reservations at lower precedences may be - preemptively reduced to make acceptance of the new session possible." + The Session Object defined by [RFC2207] or + [I-D.ietf-tsvwg-rsvp-ipsec] 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 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 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 @@ -646,28 +643,27 @@ 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 - further addressed in [I-D.polk-tsvwg-rsvp-bw-reduction] . 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. + 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 @@ -935,33 +931,33 @@ 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 pre- existing 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, [I-D.polk-tsvwg-rsvp-bw-reduction] '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: + 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 - [I-D.polk-tsvwg-rsvp-bw-reduction] and + [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 de- aggregator, makes two changes. On the "inner domain" side, it marks its reservation down to the indicated rate (the most it is now @@ -1096,25 +1092,24 @@ event that this is the last aggregated session, or change the SENDER_TSPEC of the aggregated session. RESV: The Plain text RESV message is sent as encrypted data to the cipher text unit. In parallel, a trigger needs to be sent to the cipher text unit that results in it generating the corresponding aggregated RESV message for the cipher text side. RESV Error: This indicates that a RESV message received as data and forwarded into the enclave was in error or needed to be preempted - as described in [RFC3181] or [I-D.polk-tsvwg-rsvp-bw-reduction] . - In the error case, the message itself is sent on as encrypted - data, but a signal is sent to the cipher text side in case the - error affects the cipher text reservation (such as removing or - changing state). + 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 cipher text side in case the error affects the cipher text + reservation (such as removing or changing state). RESV Tear: The RESV Tear message is sent as encrypted data to the cipher text unit. In parallel, a signal is sent to the cipher text side which 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 cipher text side, and in @@ -1199,21 +1194,21 @@ 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. 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 th cipher text network addresses in the plain text + knowledge of the cipher text network addresses in the plain text router. In such a case the plain text and cipher text routers may 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 Transform plain text session identifiers into cipher text session identifiers and vice-versa in IP datagrams and RSVP objects (e.g. IP addresses) o Resource management of aggregated reservations (e.g. including @@ -1312,31 +1307,32 @@ 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 [I-D.lefaucheur-rsvp- - ipsec]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 - neccessary and sufficient information to routers in the ciphertext - domain to implement the QoS solution presented in the document. + flow, as described in detail in [RFC3175] and + [I-D.ietf-tsvwg-rsvp-ipsec]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. 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 @@ -1419,183 +1415,173 @@ 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.lefaucheur-rsvp-ipsec], which clarified the + 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-mlpp-that-works] - Baker, F. and J. Polk, "Implementing an Emergency - Telecommunications Service for Real Time Services in the - Internet Protocol Suite", - draft-ietf-tsvwg-mlpp-that-works-02 (work in progress), - August 2005. - - [I-D.lefaucheur-rsvp-ipsec] - Faucheur, F., "Generic Aggregate RSVP Reservations", - draft-lefaucheur-rsvp-ipsec-01 (work in progress), - July 2005. - - [I-D.polk-tsvwg-rsvp-bw-reduction] - Polk, J., "A Resource Reservation Extension for the - Reduction of Bandwidth of a Reservation Flow", - draft-polk-tsvwg-rsvp-bw-reduction-00 (work in progress), - October 2004. + [I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate RSVP + Reservations", + draft-ietf-tsvwg-rsvp-ipsec-01 (work in + progress), June 2006. - [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. - Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 - Functional Specification", RFC 2205, September 1997. + [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. + [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. + [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. + [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. + [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", + [RFC3175] Baker, F., Iturralde, C., Le Faucheur, + F., and B. Davie, "Aggregation of RSVP + for IPv4 and IPv6 Reservations", RFC 3175, September 2001. -7.2. Informative References + [RFC4495] Polk, J. and S. Dhesikan, "A Resource + Reservation Protocol (RSVP) Extension + for the Reduction of Bandwidth of a + Reservation Flow", RFC 4495, May 2006. - [ANSI.MLPP.Spec] - American National Standards Institute, "Telecommunications - - Integrated Services Digital Network (ISDN) - Multi-Level - Precedence and Preemption (MLPP) Service Capability", - ANSI T1.619-1992 (R1999), 1992. + [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. - [ANSI.MLPP.Supplement] - American National Standards Institute, "MLPP Service - Domain Cause Value Changes", ANSI ANSI T1.619a-1994 - (R1999), 1990. +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. [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. + [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation + Protocol (RSVP) -- Version 1 Message Processing + Rules", RFC 2209, September 1997. - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. + [RFC2210] Wroclawski, J., "The Use of RSVP with IETF + Integrated Services", RFC 2210, September 1997. - [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security - Payload (ESP)", RFC 2406, 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, 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. + 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. - - [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition - of Explicit Congestion Notification (ECN) to IP", - RFC 3168, September 2001. + 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. + "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. + [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. + 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. 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 + 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 + EMail: pratik.bose@lmco.com Full Copyright Statement Copyright (C) The Internet Society (2006). 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 @@ -1623,14 +1609,16 @@ 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. -Acknowledgment +Acknowledgements - Funding for the RFC Editor function is currently provided by the - Internet Society. + 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 + RFC-2629 XML format.