draft-ietf-tsvwg-vpn-signaled-preemption-00.txt | draft-ietf-tsvwg-vpn-signaled-preemption-01.txt | |||
---|---|---|---|---|
Transport Working Group F. Baker | Transport Working Group F. Baker | |||
Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
Expires: August 30, 2006 P. Bose | Intended status: Informational P. Bose | |||
Lockheed Martin | Expires: March 30, 2007 Lockheed Martin | |||
February 26, 2006 | September 26, 2006 | |||
QoS Signaling in a Nested Virtual Private Network | QoS Signaling in a Nested Virtual Private Network | |||
draft-ietf-tsvwg-vpn-signaled-preemption-00 | draft-ietf-tsvwg-vpn-signaled-preemption-01 | |||
Status of this Memo | Status of This Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on August 30, 2006. | This Internet-Draft will expire on March 30, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
Abstract | Abstract | |||
Some networks require communication between an interior and exterior | Some networks require communication between an interior and exterior | |||
portion of a VPN, but have sensitivities about what information is | portion of a VPN, but have sensitivities about what information is | |||
communicated across the boundary. This note seeks to outline the | communicated across the boundary. This note seeks to outline the | |||
skipping to change at page 2, line 41 | skipping to change at page 2, line 48 | |||
3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 | 3.2.2. Use case with Network Guard . . . . . . . . . . . . . 29 | |||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 35 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 35 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 36 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 39 | ||||
1. QoS in a nested VPN | 1. QoS in a nested VPN | |||
More and more networks wish to guarantee secure transmission of IP | More and more networks wish to guarantee secure transmission of IP | |||
traffic for across public LANs or WANs and therefore use Virtual | traffic across public LANs or WANs and therefore use Virtual Private | |||
Private Networks. Some networks require communication between an | Networks. Some networks require communication between an interior | |||
interior and exterior portion of a VPN, but have sensitivities about | and exterior portion of a VPN, but have sensitivities about what | |||
what information is communicated across the boundary. This note | information is communicated across the boundary. This note seeks to | |||
seeks to outline the issues and the nature of the proposed solutions. | outline the issues and the nature of the proposed solutions. The | |||
The outline of the QoS solution for real-time traffic has been | outline of the QoS solution for real-time traffic has been described | |||
described at a high level in [I-D.ietf-tsvwg-mlpp-that-works] . The | at a high level in [RFC4542]. The key characteristics of this | |||
key characteristics of this proposal are that | proposal are that | |||
o it uses standardized protocols, | o it uses standardized protocols, | |||
o It includes reservation setup and teardown for guaranteed and | o It includes reservation setup and teardown for guaranteed and | |||
controlled load services using the standardized protocols, | controlled load services using the standardized protocols, | |||
o it is independent of link delay, and therefore consistent with | o it is independent of link delay, and therefore consistent with | |||
high delay*bandwidth networks as well as the more common variety, | high delay*bandwidth networks as well as the more common variety, | |||
o it has no single point of failure, such as a central reservation | o it has no single point of failure, such as a central reservation | |||
skipping to change at page 4, line 6 | skipping to change at page 4, line 6 | |||
including GRE, IP/IP, MPLS, and so on. | including GRE, IP/IP, MPLS, and so on. | |||
A note on the use of the words "priority" and "precedence" in this | A note on the use of the words "priority" and "precedence" in this | |||
document is in order. The term "priority" has been used in this | document is in order. The term "priority" has been used in this | |||
context with a variety of meanings, resulting in a great deal of | context with a variety of meanings, resulting in a great deal of | |||
confusion. The term "priority" is used in this document to identify | confusion. The term "priority" is used in this document to identify | |||
one of several possible datagram scheduling algorithms. A scheduler | one of several possible datagram scheduling algorithms. A scheduler | |||
is used when deciding which datagram will be sent next on a computer | is used when deciding which datagram will be sent next on a computer | |||
interface; a priority scheduler always chooses a datagram from the | interface; a priority scheduler always chooses a datagram from the | |||
highest priority class (queue) that is occupied, shielding one class | highest priority class (queue) that is occupied, shielding one class | |||
of traffic from jitter by passing jitter it would otherwise have | of traffic from most of the jitter by passing jitter it would | |||
experienced to another class. [RFC3181] applies the term to a | otherwise have experienced to another class. [RFC3181] applies the | |||
reservation, in a sense that this document will refer to as | term to a reservation, in a sense that this document will refer to as | |||
"precedence". The term "precedence" is used in the sense implied in | "precedence". The term "precedence" is used in the sense implied in | |||
the phrase "Multi-Level Precedence and Preemption"[ITU.MLPP.1990] ; | the phrase "Multi-Level Precedence and Preemption"[ITU.MLPP.1990] ; | |||
some classes of sessions take precedence over others, which may | some classes of sessions take precedence over others, which may | |||
result in bandwidth being admitted that might not otherwise have been | result in bandwidth being admitted that might not otherwise have been | |||
or may result in the prejudicial termination of a lower precedence | or may result in the prejudicial termination of a lower precedence | |||
session under a stated set of circumstances. For the purposes of the | session under a stated set of circumstances. For the purposes of the | |||
present discussion, "priority" is a set of algorithms applied to | present discussion, "priority" is a set of algorithms applied to | |||
datagrams, where "precedence" is a policy attribute of sessions. The | datagrams, where "precedence" is a policy attribute of sessions. The | |||
techniques of priority comparisons are used in a router or a policy | techniques of priority comparisons are used in a router or a policy | |||
decision point to implement precedence, but they are not the same | decision point to implement precedence, but they are not the same | |||
skipping to change at page 5, line 36 | skipping to change at page 5, line 36 | |||
The receiving VPN Router reverses the steps: it | The receiving VPN Router reverses the steps: it | |||
o determines what security association the datagram was received | o determines what security association the datagram was received | |||
from, | from, | |||
o decrypts the interior datagram, | o decrypts the interior datagram, | |||
o forwards the now-decapsulated datagram on a plain text interface. | o forwards the now-decapsulated datagram on a plain text interface. | |||
The use of IPsec in this manner is described as the tunnel mode of | The use of IPsec in this manner is described as the tunnel mode of | |||
[RFC2401] and [RFC2406] . | [RFC2401] and [RFC4303]. | |||
Host Host Host Host Host Host | Host Host Host Host Host Host | |||
/------------------/ /------------------/ | /------------------/ /------------------/ | |||
Router -------Router | Router -------Router | |||
| | | | |||
VPN-Router | VPN-Router | |||
|| | || | |||
|| IPsec Tunnel through routed network | || IPsec Tunnel through routed network | |||
|| | || | |||
VPN-Router | VPN-Router | |||
| | | | |||
skipping to change at page 8, line 47 | skipping to change at page 8, line 47 | |||
requirements and the network's capability to deliver them. Several | requirements and the network's capability to deliver them. Several | |||
such protocols have been developed or are under development, notably | such protocols have been developed or are under development, notably | |||
including RSVP and NSIS. The present discussion is limited to RSVP, | including RSVP and NSIS. The present discussion is limited to RSVP, | |||
although any protocol that delivers a similar set of capabilities | although any protocol that delivers a similar set of capabilities | |||
could be considered. | could be considered. | |||
1.3. The Resource Reservation Protocol (RSVP) | 1.3. The Resource Reservation Protocol (RSVP) | |||
RSVP is initially defined in [RFC2205] with a set of datagram | RSVP is initially defined in [RFC2205] with a set of datagram | |||
processing rules defined in [RFC2209] and datagram details for | processing rules defined in [RFC2209] and datagram details for | |||
Integrated Services [RFC2210] . Conceptually, this protocol | Integrated Services [RFC2210]. Conceptually, this protocol specifies | |||
specifies a way to identify data flows from a source application to a | a way to identify data flows from a source application to a | |||
destination application and request specific resources for them. The | destination application and request specific resources for them. The | |||
source may be a single machine or a set of machines listed explicitly | source may be a single machine or a set of machines listed explicitly | |||
or implied, whereas the destination may be a single machine or a | or implied, whereas the destination may be a single machine or a | |||
multicast group (and therefore all of the machines in it). Each | multicast group (and therefore all of the machines in it). Each | |||
application is specified by a transport protocol number in the IP | application is specified by a transport protocol number in the IP | |||
protocol field, or may additionally include destination and perhaps | protocol field, or may additionally include destination and perhaps | |||
source port numbers. The protocol is defined for both IPv4 [RFC0791] | source port numbers. The protocol is defined for both IPv4 [RFC0791] | |||
and IPv6 [RFC2460]. It was recognized immediately that it was also | and IPv6 [RFC2460]. It was recognized immediately that it was also | |||
necessary to provide a means to perform the same function for various | necessary to provide a means to perform the same function for various | |||
kinds of tunnels, which implies a relationship between what is inside | kinds of tunnels, which implies a relationship between what is inside | |||
and what is outside the tunnel. Definitions were therefore developed | and what is outside the tunnel. Definitions were therefore developed | |||
for IPsec [RFC2207] and [I-D.lefaucheur-rsvp-ipsec] and for more | for IPsec [RFC2207] and [I-D.ietf-tsvwg-rsvp-ipsec] and for more | |||
generic forms of tunnels [RFC2746]. With the later development of | generic forms of tunnels [RFC2746]. With the later development of | |||
the Differentiated Services Architecture [RFC2475], definitions were | the Differentiated Services Architecture [RFC2475], definitions were | |||
added to specify the DSCP [RFC2474]to be used by a standard RSVP data | added to specify the DSCP [RFC2474] to be used by a standard RSVP | |||
flow in [RFC2996] and to use a pair of IP addresses and a DSCP as the | data flow in [RFC2996] and to use a pair of IP addresses and a DSCP | |||
identifying information for a data flow [RFC3175]. | as the identifying information for a data flow [RFC3175]. | |||
In addition, the initial definition of the protocol included a | In addition, the initial definition of the protocol included a | |||
placeholder for policy information, and for preemption of | placeholder for policy information, and for preemption of | |||
reservations. This placeholder was later specified in detail in | reservations. This placeholder was later specified in detail in | |||
[RFC2750] with a view to associating a policy [RFC2872] with an | [RFC2750] with a view to associating a policy [RFC2872] with an | |||
identity [RFC3182] and thereby enabling the network to provide a | identity [RFC3182] and thereby enabling the network to provide a | |||
contracted service to an authenticated and authorized user. This was | contracted service to an authenticated and authorized user. This was | |||
integrated with the Session Initiation Protocol [RFC3261] in | integrated with the Session Initiation Protocol [RFC3261] in | |||
[RFC3312] . Preemption of a reservation is specified in the context, | [RFC3312] . Preemption of a reservation is specified in the context, | |||
in [RFC3181] which in essence specifies that a reservation installed | in [RFC3181] which in essence specifies that a reservation installed | |||
in the network using an Preemption Priority and retained using a | in the network using an Preemption Priority and retained using a | |||
separate Defending Priority may be removed by the network via an RESV | separate Defending Priority may be removed by the network via an RESV | |||
Error signal that removes the entire reservation. This has issues, | Error signal that removes the entire reservation. This has issues, | |||
however, in that the matter is often not quite so black and white. | however, in that the matter is often not quite so black and white. | |||
If the issue is that an existing reservation for 80 KBPS can no | If the issue is that an existing reservation for 80 KBPS can no | |||
longer be sustained but a 60 KBPS reservation could, it is possible | longer be sustained but a 60 KBPS reservation could, it is possible | |||
that a VoIP sender could change from a G.711 codec to a G.729 codec | that a VoIP sender could change from a G.711 codec to a G.729 codec | |||
and achieve that. Or, if there are multiple sessions in a tunnel or | and achieve that. Or, if there are multiple sessions in a tunnel or | |||
other aggregate, one of the calls could be eliminated leaving | other aggregate, one of the calls could be eliminated leaving | |||
capacity for the others. [I-D.polk-tsvwg-rsvp-bw-reduction] seeks to | capacity for the others. [RFC4495] seeks to address this issue. | |||
address this issue. | ||||
In a similar way, a capability was added to limit the possibility of | In a similar way, a capability was added to limit the possibility of | |||
control signals being spoofed or otherwise attacked [RFC2747] | control signals being spoofed or otherwise attacked [RFC2747] | |||
[RFC3097] . | [RFC3097] . | |||
[RFC3175] describes several features that are unusual in RSVP, being | [RFC3175] describes several features that are unusual in RSVP, being | |||
specifically set up to handle aggregates in a service provider | specifically set up to handle aggregates in a service provider | |||
network. It describes three key components: | network. It describes three key components: | |||
o The RFC 3175 session object, which identifies not the IP addresses | o The RFC 3175 session object, which identifies not the IP addresses | |||
skipping to change at page 10, line 20 | skipping to change at page 10, line 20 | |||
o The function of a reservation "deaggregator", which operates in | o The function of a reservation "deaggregator", which operates in | |||
the egress router and breaks the aggregate reservation and data | the egress router and breaks the aggregate reservation and data | |||
streams back out into individual data streams that may be passed | streams back out into individual data streams that may be passed | |||
to other networks. | to other networks. | |||
In retrospect, the Session Object specified by RFC 3175 is useful but | In retrospect, the Session Object specified by RFC 3175 is useful but | |||
not intrinsically necessary. If the ISP network uses tunnels, such | not intrinsically necessary. If the ISP network uses tunnels, such | |||
as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security | as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security | |||
Associations, the concepts of an aggregator and a deaggregator work | Associations, the concepts of an aggregator and a deaggregator work | |||
in the same manner, although the reservation mechanism would be that | in the same manner, although the reservation mechanism would be that | |||
of [RFC3473] and [RFC3474] [RFC2207] [I-D.lefaucheur-rsvp-ipsec] or | of [RFC3473] and [RFC3474] [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or | |||
[RFC2746] . | [RFC2746] . | |||
1.4. Logical structure of a VPN Router | 1.4. Logical structure of a VPN Router | |||
The conceptual structure of a VPN Router is similar to that of any | The conceptual structure of a VPN Router is similar to that of any | |||
other router. In its simplest form, it is physically a two or more | other router. In its simplest form, it is physically a two or more | |||
port device, similar to that shown in Figure 4 which has one or more | port device, similar to that shown in Figure 4 which has one or more | |||
interfaces to the protected enclave(s) and one or more interfaces to | interfaces to the protected enclave(s) and one or more interfaces to | |||
the outside world. On the latter, it structures some number of | the outside world. On the latter, it structures some number of | |||
tunnels (in the case of an IPsec tunnel, having security | tunnels (in the case of an IPsec tunnel, having security | |||
skipping to change at page 14, line 27 | skipping to change at page 14, line 27 | |||
the appropriate tunnel (e. g., the IPsec Security Association for its | the appropriate tunnel (e. g., the IPsec Security Association for its | |||
precedence level to the appropriate remote VPN Router). At the | precedence level to the appropriate remote VPN Router). At the | |||
remote VPN Router, it is extracted from the tunnel and passed on its | remote VPN Router, it is extracted from the tunnel and passed on its | |||
way to the target system. The data in the enclave will be marked | way to the target system. The data in the enclave will be marked | |||
with a DSCP appropriate to its application and (if there is a | with a DSCP appropriate to its application and (if there is a | |||
difference) precedence level, and the signaling datagrams (PATH and | difference) precedence level, and the signaling datagrams (PATH and | |||
RESV) are marked with a DCLASS object indicating that value. RSVP | RESV) are marked with a DCLASS object indicating that value. RSVP | |||
signaling datagrams (PATH and RESV) are marked with a DCLASS object | signaling datagrams (PATH and RESV) are marked with a DCLASS object | |||
indicating the value used for the corresponding data. The DSCP on | indicating the value used for the corresponding data. The DSCP on | |||
the signaling datagrams, however, is a DSCP for signaling, and has | the signaling datagrams, however, is a DSCP for signaling, and has | |||
the one proviso that if routing varies by DSCP then it must be a DSCP | the one provision that if routing varies by DSCP then it must be a | |||
that is routed the same way as the relevant data. The [RFC2872] | DSCP that is routed the same way as the relevant data. The [RFC2872] | |||
policy object specifies the applicable policy (e. g., "routine | policy object specifies the applicable policy (e. g., "routine | |||
service for voice traffic") and asserts a [RFC3182] credential | service for voice traffic") and asserts a [RFC3182] credential | |||
indicating its user (which may be a person or a class of persons). | indicating its user (which may be a person or a class of persons). | |||
As specified in [RFC3181] it also specifies its Preemption Priority | As specified in [RFC3181] it also specifies its Preemption Priority | |||
and its Defending Priority; these enable the Preemption Priority of a | and its Defending Priority; these enable the Preemption Priority of a | |||
new session to be compared with the Defending Priority of previously | new session to be compared with the Defending Priority of previously | |||
admitted sessions. | admitted sessions. | |||
On the cipher text side of the VPN Router, no guarantees result | On the cipher text side of the VPN Router, no guarantees result | |||
unless the VPN Router likewise sets up a reservation to the peer VPN | unless the VPN Router likewise sets up a reservation to the peer VPN | |||
Router across the cipher text domain. Thus, the VPN Router sets up | Router across the cipher text domain. Thus, the VPN Router sets up | |||
an [RFC2207] [I-D.lefaucheur-rsvp-ipsec] or [RFC3175] reservation to | an [RFC2207] [I-D.ietf-tsvwg-rsvp-ipsec] or [RFC3175] reservation to | |||
its peer. | its peer. | |||
The Session Object defined by [RFC2207] or [I-D.lefaucheur-rsvp- | The Session Object defined by [RFC2207] or | |||
ipsec] contains a field called a "virtual destination port", which | [I-D.ietf-tsvwg-rsvp-ipsec] contains a field called a "virtual | |||
allows the multiplexing of many reservations over a common security | destination port", which allows the multiplexing of many reservations | |||
association, and in the latter case, a common DSCP value. Thus, the | over a common security association, and in the latter case, a common | |||
voice traffic at every precedence level might use the EF DSCP and | DSCP value. Thus, the voice traffic at every precedence level might | |||
service as described in [RFC3246], but the reservations would be for | use the EF DSCP and service as described in [RFC3246], but the | |||
"the aggregate of voice sessions at precedence Pn between these VPN | reservations would be for "the aggregate of voice sessions at | |||
Routers". This would allow the network administration to describe | precedence Pn between these VPN Routers". This would allow the | |||
policies with multiple thresholds, such as "a new session at | network administration to describe policies with multiple thresholds, | |||
precedence Pn may be accepted if the total reserved bandwidth does | such as "a new session at precedence Pn may be accepted if the total | |||
not exceed threshold Qn; if it is necessary and sufficient to accept | reserved bandwidth does not exceed threshold Qn; if it is necessary | |||
the reservation, existing reservations at lower precedences may be | and sufficient to accept the reservation, existing reservations at | |||
preemptively reduced to make acceptance of the new session possible." | lower precedences may be preemptively reduced to make acceptance of | |||
the new session possible." | ||||
In the [RFC3175] case, since the DSCP must be used to identify both | In the [RFC3175] case, since the DSCP must be used to identify both | |||
the reservation and the corresponding data stream, the aggregate | the reservation and the corresponding data stream, the aggregate | |||
reservations for different precedence levels require different DSCP | reservations for different precedence levels require different DSCP | |||
values. | values. | |||
In either case, the fundamental necessity is for one VPN Router to | In either case, the fundamental necessity is for one VPN Router to | |||
act as what [RFC3175] calls the "aggregator" and another to act as | act as what [RFC3175] calls the "aggregator" and another to act as | |||
the "deaggregator", and extend a VPN tunnel between them. If the VPN | the "deaggregator", and extend a VPN tunnel between them. If the VPN | |||
Tunnel is an IPsec Security Association between the VPN Routers and | Tunnel is an IPsec Security Association between the VPN Routers and | |||
skipping to change at page 16, line 24 | skipping to change at page 16, line 24 | |||
the total reserved bandwidth after admission may not exceed X; to | the total reserved bandwidth after admission may not exceed X; to | |||
accept a higher precedence level call, the total reserved bandwidth | accept a higher precedence level call, the total reserved bandwidth | |||
after admission may not exceed X+Y, and this may be achieved by | after admission may not exceed X+Y, and this may be achieved by | |||
preempting a lower precedence level call"), the bandwidth Y | preempting a lower precedence level call"), the bandwidth Y | |||
effectively comes from the bandwidth in use by elastic traffic rather | effectively comes from the bandwidth in use by elastic traffic rather | |||
than forcing a preemption event. | than forcing a preemption event. | |||
2.2. Preemption in a nested VPN | 2.2. Preemption in a nested VPN | |||
As discussed in Section 1.3 preemption is specified in [RFC3181] and | As discussed in Section 1.3 preemption is specified in [RFC3181] and | |||
further addressed in [I-D.polk-tsvwg-rsvp-bw-reduction] . The issue | further addressed in [RFC4495]. The issue is that in many cases the | |||
is that in many cases the need is to reduce the bandwidth of a | need is to reduce the bandwidth of a reservation due to a change in | |||
reservation due to a change in the network, not simply to remove the | the network, not simply to remove the reservation. In the case of an | |||
reservation. In the case of an end system originated reservation, | end system originated reservation, the end system might be able to | |||
the end system might be able to accommodate the need through a change | accommodate the need through a change of codec; in the case of an | |||
of codec; in the case of an aggregate of some kind, it could reduce | aggregate of some kind, it could reduce the bandwidth it is sending | |||
the bandwidth it is sending by dropping one or more reservations | by dropping one or more reservations entirely. | |||
entirely. | ||||
In a nested VPN or other kind of aggregated reservation, this means | In a nested VPN or other kind of aggregated reservation, this means | |||
that the deaggregator (the VPN Router initiating the RESV signal for | that the deaggregator (the VPN Router initiating the RESV signal for | |||
the tunnel) must | the tunnel) must | |||
o receive the RESV Error signaling it to reduce its bandwidth, | o receive the RESV Error signaling it to reduce its bandwidth, | |||
o re-issue its RESV accordingly, | o re-issue its RESV accordingly, | |||
o identify one or more of its aggregated reservations, enough to do | o identify one or more of its aggregated reservations, enough to do | |||
skipping to change at page 22, line 23 | skipping to change at page 22, line 23 | |||
met. At R9, a problem is detected - there is not sufficient | met. At R9, a problem is detected - there is not sufficient | |||
bandwidth under the relevant policy. In the absence of precedence, | bandwidth under the relevant policy. In the absence of precedence, | |||
R9 would now return an RESV Error indicating that the reservation | R9 would now return an RESV Error indicating that the reservation | |||
could not be increased or installed. In such a case, if a pre- | could not be increased or installed. In such a case, if a pre- | |||
existing reservation of lower bandwidth already existed, the previous | existing reservation of lower bandwidth already existed, the previous | |||
reservation would remain in place but the new bandwidth would not be | reservation would remain in place but the new bandwidth would not be | |||
granted, and the originator (H6) would be informed. Let us clarify | granted, and the originator (H6) would be informed. Let us clarify | |||
what it means to be at a stated precedence: it means that the | what it means to be at a stated precedence: it means that the | |||
POLICY_DATA object in the RESV contains a Preemption Priority and a | POLICY_DATA object in the RESV contains a Preemption Priority and a | |||
Defending Priority with values specified in some memo. With | Defending Priority with values specified in some memo. With | |||
precedence, [I-D.polk-tsvwg-rsvp-bw-reduction] 's algorithm would | precedence, [RFC4495]'s algorithm would have the Preemption Priority | |||
have the Preemption Priority of the new reservation compared to the | of the new reservation compared to the Defending Priority of extant | |||
Defending Priority of extant reservations in the router, of which | reservations in the router, of which there are two: one VPN7->VPN8 at | |||
there are two: one VPN7->VPN8 at "routine" precedence and one | "routine" precedence and one VPN7->VPN8 at "priority" precedence. | |||
VPN7->VPN8 at "priority" precedence. Since the Defending Priority of | Since the Defending Priority of routine reservation is less than the | |||
routine reservation is less than the Preemption Priority of a | Preemption Priority of a "priority" reservation, the "routine" | |||
"priority" reservation, the "routine" reservation is selected. R9 | reservation is selected. R9 determines that it will accept the | |||
determines that it will accept the increase in its "priority" | increase in its "priority" reservation VPN7->VPN8 and reduce the | |||
reservation VPN7->VPN8 and reduce the corresponding "routine" | corresponding "routine" reservation. Two processes now occur in | |||
reservation. Two processes now occur in parallel: | parallel: | |||
o The routine reservation is reduced following the algorithms in | o The routine reservation is reduced following the algorithms in | |||
[I-D.polk-tsvwg-rsvp-bw-reduction] and | [RFC4495] and | |||
o The priority reservation continues according to the usual rules. | o The priority reservation continues according to the usual rules. | |||
R9 reduces its "routine" reservation by sending an RESV Error | R9 reduces its "routine" reservation by sending an RESV Error | |||
updating its internal state to reflect the reduced reservation and | updating its internal state to reflect the reduced reservation and | |||
sending an RESV Error to VPN8 requesting that it reduce its | sending an RESV Error to VPN8 requesting that it reduce its | |||
reservation to a number less than or equal to the relevant threshold | reservation to a number less than or equal to the relevant threshold | |||
less the sum of the competing reservations. VPN8, acting as a de- | less the sum of the competing reservations. VPN8, acting as a de- | |||
aggregator, makes two changes. On the "inner domain" side, it marks | aggregator, makes two changes. On the "inner domain" side, it marks | |||
its reservation down to the indicated rate (the most it is now | its reservation down to the indicated rate (the most it is now | |||
skipping to change at page 25, line 45 | skipping to change at page 25, line 45 | |||
event that this is the last aggregated session, or change the | event that this is the last aggregated session, or change the | |||
SENDER_TSPEC of the aggregated session. | SENDER_TSPEC of the aggregated session. | |||
RESV: The Plain text RESV message is sent as encrypted data to the | RESV: The Plain text RESV message is sent as encrypted data to the | |||
cipher text unit. In parallel, a trigger needs to be sent to the | cipher text unit. In parallel, a trigger needs to be sent to the | |||
cipher text unit that results in it generating the corresponding | cipher text unit that results in it generating the corresponding | |||
aggregated RESV message for the cipher text side. | aggregated RESV message for the cipher text side. | |||
RESV Error: This indicates that a RESV message received as data and | RESV Error: This indicates that a RESV message received as data and | |||
forwarded into the enclave was in error or needed to be preempted | forwarded into the enclave was in error or needed to be preempted | |||
as described in [RFC3181] or [I-D.polk-tsvwg-rsvp-bw-reduction] . | as described in [RFC3181] or [RFC4495]. In the error case, the | |||
In the error case, the message itself is sent on as encrypted | message itself is sent on as encrypted data, but a signal is sent | |||
data, but a signal is sent to the cipher text side in case the | to the cipher text side in case the error affects the cipher text | |||
error affects the cipher text reservation (such as removing or | reservation (such as removing or changing state). | |||
changing state). | ||||
RESV Tear: The RESV Tear message is sent as encrypted data to the | RESV Tear: The RESV Tear message is sent as encrypted data to the | |||
cipher text unit. In parallel, a signal is sent to the cipher | cipher text unit. In parallel, a signal is sent to the cipher | |||
text side which will trigger a RESV Tear on its reservation in the | text side which will trigger a RESV Tear on its reservation in the | |||
event that this is the last aggregated session, or reduce the | event that this is the last aggregated session, or reduce the | |||
bandwidth of an existing reservation. | bandwidth of an existing reservation. | |||
RESV Confirm: This indicates that a RESV message received as data | RESV Confirm: This indicates that a RESV message received as data | |||
and forwarded into the enclave, and is now being confirmed. This | and forwarded into the enclave, and is now being confirmed. This | |||
message is sent as encrypted data to the cipher text side, and in | message is sent as encrypted data to the cipher text side, and in | |||
skipping to change at page 28, line 9 | skipping to change at page 28, line 9 | |||
exchanging datagrams, it is somewhat more complex, but conceptually | exchanging datagrams, it is somewhat more complex, but conceptually | |||
equivalent. For example, the ciphertext router would consider an IP | equivalent. For example, the ciphertext router would consider an IP | |||
datagram received via the Network Guard (control plane) as having | datagram received via the Network Guard (control plane) as having | |||
been received from and concerning the interface used in the data | been received from and concerning the interface used in the data | |||
plane to the encrypt/decrypt unit. | plane to the encrypt/decrypt unit. | |||
3.2.1. Signaling Flow | 3.2.1. Signaling Flow | |||
Encrypt/Decrypt units may not be capable of terminating and | Encrypt/Decrypt units may not be capable of terminating and | |||
originating flows as described in Section 3.1, and policy may prevent | originating flows as described in Section 3.1, and policy may prevent | |||
knowledge of th cipher text network addresses in the plain text | knowledge of the cipher text network addresses in the plain text | |||
router. In such a case the plain text and cipher text routers may | router. In such a case the plain text and cipher text routers may | |||
use the Network Guard as the path for the signaling flows. The | use the Network Guard as the path for the signaling flows. The | |||
Network Guard performs the following functions to enable the flow of | Network Guard performs the following functions to enable the flow of | |||
reservation signaling across the cryptographic domain | reservation signaling across the cryptographic domain | |||
o Transform plain text session identifiers into cipher text session | o Transform plain text session identifiers into cipher text session | |||
identifiers and vice-versa in IP datagrams and RSVP objects (e.g. | identifiers and vice-versa in IP datagrams and RSVP objects (e.g. | |||
IP addresses) | IP addresses) | |||
o Resource management of aggregated reservations (e.g. including | o Resource management of aggregated reservations (e.g. including | |||
skipping to change at page 30, line 41 | skipping to change at page 30, line 41 | |||
routers in the interface domain. | routers in the interface domain. | |||
o CT-Router-B receives the ciphertext aggregate RSVP message and | o CT-Router-B receives the ciphertext aggregate RSVP message and | |||
sends it to the NetGrd-B. | sends it to the NetGrd-B. | |||
o The NetGrd-B transforms the ciphertext aggregate RSVP into the | o The NetGrd-B transforms the ciphertext aggregate RSVP into the | |||
plaintext aggregate RSVP message as described in Section 3.2.1 and | plaintext aggregate RSVP message as described in Section 3.2.1 and | |||
sends it to the PT-Router-B. | sends it to the PT-Router-B. | |||
The subsequent RSVP and Aggregate RSVP signaling follows a similar | The subsequent RSVP and Aggregate RSVP signaling follows a similar | |||
flow, as described in detail in [RFC3175] and [I-D.lefaucheur-rsvp- | flow, as described in detail in [RFC3175] and | |||
ipsec]to aggregate each plaintext reservation into a corresponding | [I-D.ietf-tsvwg-rsvp-ipsec]to aggregate each plaintext reservation | |||
ciphertext reservation. This ensures that RSVP capable ciphertext | into a corresponding ciphertext reservation. This ensures that RSVP | |||
routers reserve the required resources for a plaintext end to end | capable ciphertext routers reserve the required resources for a | |||
reservation. Subsequent mechanisms such as preemption or the | plaintext end to end reservation. Subsequent mechanisms such as | |||
increase and decrease of resources reserved may be applied to these | preemption or the increase and decrease of resources reserved may be | |||
reservations as described before in this document. The RSVP data | applied to these reservations as described before in this document. | |||
flow as described in Section 3.1 within the VPN router (from the | The RSVP data flow as described in Section 3.1 within the VPN router | |||
plaintext router to the ciphertext router via the Guard) provides | (from the plaintext router to the ciphertext router via the Guard) | |||
neccessary and sufficient information to routers in the ciphertext | provides necessary and sufficient information to routers in the | |||
domain to implement the QoS solution presented in the document. | ciphertext domain to implement the QoS solution presented in the | |||
document. | ||||
In this description, we have described the Network Guard as being | In this description, we have described the Network Guard as being | |||
separate from the Encrypt/Decrypt unit. This separation exists | separate from the Encrypt/Decrypt unit. This separation exists | |||
because in certain implementations it is mandated by those who | because in certain implementations it is mandated by those who | |||
specify the devices. The separation does not come for free, however; | specify the devices. The separation does not come for free, however; | |||
the separation of the devices for system engineering purposes is | the separation of the devices for system engineering purposes is | |||
expensive, and it imposes architectural problems. For example, when | expensive, and it imposes architectural problems. For example, when | |||
the Guard is used to aggregate RSVP messages or PIM routing, the | the Guard is used to aggregate RSVP messages or PIM routing, the | |||
traffic is destined to the remote VPN Router. This means that the | traffic is destined to the remote VPN Router. This means that the | |||
Guard must somehow receive and respond to, on behalf of the VPN | Guard must somehow receive and respond to, on behalf of the VPN | |||
skipping to change at page 34, line 14 | skipping to change at page 34, line 14 | |||
6. Acknowledgements | 6. Acknowledgements | |||
Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger | Doug Marquis, James Polk, Mike Tibodeau, Pete Babendreier, Roger | |||
Levesque, and Subha Dhesikan gave early review comments. | Levesque, and Subha Dhesikan gave early review comments. | |||
Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou | Comments by Sean O'Keefe, Tony De Simone, Julie Tarr, Chris Christou | |||
and their associates resulted in Section 3.2. | and their associates resulted in Section 3.2. | |||
Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik | Francois Le Faucheur, Bruce Davie, and Chris Christou (with Pratik | |||
Bose) added [I-D.lefaucheur-rsvp-ipsec], which clarified the | Bose) added [I-D.ietf-tsvwg-rsvp-ipsec], which clarified the | |||
interaction of this approach with the DSCP. | interaction of this approach with the DSCP. | |||
7. References | 7. References | |||
7.1. Normative References | 7.1. Normative References | |||
[I-D.ietf-tsvwg-mlpp-that-works] | [I-D.ietf-tsvwg-rsvp-ipsec] Faucheur, F., "Generic Aggregate RSVP | |||
Baker, F. and J. Polk, "Implementing an Emergency | Reservations", | |||
Telecommunications Service for Real Time Services in the | draft-ietf-tsvwg-rsvp-ipsec-01 (work in | |||
Internet Protocol Suite", | progress), June 2006. | |||
draft-ietf-tsvwg-mlpp-that-works-02 (work in progress), | ||||
August 2005. | ||||
[I-D.lefaucheur-rsvp-ipsec] | ||||
Faucheur, F., "Generic Aggregate RSVP Reservations", | ||||
draft-lefaucheur-rsvp-ipsec-01 (work in progress), | ||||
July 2005. | ||||
[I-D.polk-tsvwg-rsvp-bw-reduction] | ||||
Polk, J., "A Resource Reservation Extension for the | ||||
Reduction of Bandwidth of a Reservation Flow", | ||||
draft-polk-tsvwg-rsvp-bw-reduction-00 (work in progress), | ||||
October 2004. | ||||
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. | [RFC2205] Braden, B., Zhang, L., Berson, S., | |||
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | Herzog, S., and S. Jamin, "Resource | |||
Functional Specification", RFC 2205, September 1997. | ReSerVation Protocol (RSVP) -- Version 1 | |||
Functional Specification", RFC 2205, | ||||
September 1997. | ||||
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC | [RFC2207] Berger, L. and T. O'Malley, "RSVP | |||
Data Flows", RFC 2207, September 1997. | Extensions for IPSEC Data Flows", | |||
RFC 2207, September 1997. | ||||
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, | [RFC2746] Terzis, A., Krawczyk, J., Wroclawski, | |||
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000. | J., and L. Zhang, "RSVP Operation Over | |||
IP Tunnels", RFC 2746, January 2000. | ||||
[RFC2750] Herzog, S., "RSVP Extensions for Policy Control", | [RFC2750] Herzog, S., "RSVP Extensions for Policy | |||
RFC 2750, January 2000. | Control", RFC 2750, January 2000. | |||
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, | [RFC2996] Bernet, Y., "Format of the RSVP DCLASS | |||
November 2000. | Object", RFC 2996, November 2000. | |||
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, | [RFC3175] Baker, F., Iturralde, C., Le Faucheur, | |||
"Aggregation of RSVP for IPv4 and IPv6 Reservations", | F., and B. Davie, "Aggregation of RSVP | |||
for IPv4 and IPv6 Reservations", | ||||
RFC 3175, September 2001. | RFC 3175, September 2001. | |||
7.2. Informative References | [RFC4495] Polk, J. and S. Dhesikan, "A Resource | |||
Reservation Protocol (RSVP) Extension | ||||
for the Reduction of Bandwidth of a | ||||
Reservation Flow", RFC 4495, May 2006. | ||||
[ANSI.MLPP.Spec] | [RFC4542] Baker, F. and J. Polk, "Implementing an | |||
American National Standards Institute, "Telecommunications | Emergency Telecommunications Service | |||
- Integrated Services Digital Network (ISDN) - Multi-Level | (ETS) for Real-Time Services in the | |||
Precedence and Preemption (MLPP) Service Capability", | Internet Protocol Suite", RFC 4542, | |||
ANSI T1.619-1992 (R1999), 1992. | May 2006. | |||
[ANSI.MLPP.Supplement] | 7.2. Informative References | |||
American National Standards Institute, "MLPP Service | ||||
Domain Cause Value Changes", ANSI ANSI T1.619a-1994 | ||||
(R1999), 1990. | ||||
[ITU.MLPP.1990] | [ITU.MLPP.1990] International Telecommunications Union, "Multilevel | |||
International Telecommunications Union, "Multilevel | Precedence and Preemption Service", ITU- | |||
Precedence and Preemption Service", ITU-T Recommendation | T Recommendation I.255.3, 1990. | |||
I.255.3, 1990. | ||||
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, | |||
September 1981. | September 1981. | |||
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated | [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated | |||
Services in the Internet Architecture: an Overview", | Services in the Internet Architecture: an Overview", | |||
RFC 1633, June 1994. | RFC 1633, June 1994. | |||
[RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation Protocol | [RFC2209] Braden, B. and L. Zhang, "Resource ReSerVation | |||
(RSVP) -- Version 1 Message Processing Rules", RFC 2209, | Protocol (RSVP) -- Version 1 Message Processing | |||
September 1997. | Rules", RFC 2209, September 1997. | |||
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated | ||||
Services", RFC 2210, September 1997. | ||||
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the | [RFC2210] Wroclawski, J., "The Use of RSVP with IETF | |||
Internet Protocol", RFC 2401, November 1998. | Integrated Services", RFC 2210, September 1997. | |||
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security | [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for | |||
Payload (ESP)", RFC 2406, November 1998. | the Internet Protocol", RFC 2401, November 1998. | |||
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, | |||
(IPv6) Specification", RFC 2460, December 1998. | Version 6 (IPv6) Specification", RFC 2460, | |||
December 1998. | ||||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
December 1998. | December 1998. | |||
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, | |||
and W. Weiss, "An Architecture for Differentiated | Z., and W. Weiss, "An Architecture for | |||
Services", RFC 2475, December 1998. | Differentiated Services", RFC 2475, December 1998. | |||
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic | [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP | |||
Authentication", RFC 2747, January 2000. | Cryptographic Authentication", RFC 2747, | |||
January 2000. | ||||
[RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub | [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub | |||
Application Identity Policy Element for Use with RSVP", | Application Identity Policy Element for Use with | |||
RFC 2872, June 2000. | RSVP", RFC 2872, June 2000. | |||
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic | [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic | |||
Authentication -- Updated Message Type Value", RFC 3097, | Authentication -- Updated Message Type Value", | |||
April 2001. | RFC 3097, April 2001. | |||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | ||||
of Explicit Congestion Notification (ECN) to IP", | ||||
RFC 3168, September 2001. | ||||
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", | [RFC3181] Herzog, S., "Signaled Preemption Priority Policy | |||
RFC 3181, October 2001. | Element", RFC 3181, October 2001. | |||
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., | [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., | |||
Herzog, S., and R. Hess, "Identity Representation for | Moore, T., Herzog, S., and R. Hess, "Identity | |||
RSVP", RFC 3182, October 2001. | Representation for RSVP", RFC 3182, October 2001. | |||
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, | [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le | |||
J., Courtney, W., Davari, S., Firoiu, V., and D. | Boudec, J., Courtney, W., Davari, S., Firoiu, V., | |||
Stiliadis, "An Expedited Forwarding PHB (Per-Hop | and D. Stiliadis, "An Expedited Forwarding PHB (Per- | |||
Behavior)", RFC 3246, March 2002. | Hop Behavior)", RFC 3246, March 2002. | |||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., | |||
A., Peterson, J., Sparks, R., Handley, M., and E. | Johnston, A., Peterson, J., Sparks, R., Handley, M., | |||
Schooler, "SIP: Session Initiation Protocol", RFC 3261, | and E. Schooler, "SIP: Session Initiation Protocol", | |||
June 2002. | RFC 3261, June 2002. | |||
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, | [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, | |||
"Integration of Resource Management and Session Initiation | "Integration of Resource Management and Session | |||
Protocol (SIP)", RFC 3312, October 2002. | Initiation Protocol (SIP)", RFC 3312, October 2002. | |||
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching | [RFC3473] Berger, L., "Generalized Multi-Protocol Label | |||
(GMPLS) Signaling Resource ReserVation Protocol-Traffic | Switching (GMPLS) Signaling Resource ReserVation | |||
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. | Protocol-Traffic Engineering (RSVP-TE) Extensions", | |||
RFC 3473, January 2003. | ||||
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA | [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA | |||
assignments for Generalized MultiProtocol Label Switching | assignments for Generalized MultiProtocol Label | |||
(GMPLS) Resource Reservation Protocol - Traffic | Switching (GMPLS) Resource Reservation Protocol - | |||
Engineering (RSVP-TE) Usage and Extensions for | Traffic Engineering (RSVP-TE) Usage and Extensions | |||
Automatically Switched Optical Network (ASON)", RFC 3474, | for Automatically Switched Optical Network (ASON)", | |||
March 2003. | RFC 3474, March 2003. | |||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | ||||
RFC 4303, December 2005. | ||||
Authors' Addresses | Authors' Addresses | |||
Fred Baker | Fred Baker | |||
Cisco Systems | Cisco Systems | |||
1121 Via Del Rey | 1121 Via Del Rey | |||
Santa Barbara, California 93117 | Santa Barbara, California 93117 | |||
USA | USA | |||
Phone: +1-408-526-4257 | Phone: +1-408-526-4257 | |||
Fax: +1-413-473-2403 | Fax: +1-413-473-2403 | |||
Email: fred@cisco.com | EMail: fred@cisco.com | |||
Pratik Bose | Pratik Bose | |||
Lockheed Martin | Lockheed Martin | |||
700 North Frederick Ave | 700 North Frederick Ave | |||
Gaithersburg, Maryland 20871 | Gaithersburg, Maryland 20871 | |||
USA | USA | |||
Phone: +1-301-240-7041 | Phone: +1-301-240-7041 | |||
Fax: +1-301-240-5748 | Fax: +1-301-240-5748 | |||
Email: pratik.bose@lmco.com | EMail: pratik.bose@lmco.com | |||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
skipping to change at page 39, line 45 | skipping to change at page 39, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Acknowledgment | Acknowledgements | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). This document was produced | |||
using xml2rfc v1.31 (of http://xml.resource.org/) from a source in | ||||
RFC-2629 XML format. | ||||
End of changes. 53 change blocks. | ||||
179 lines changed or deleted | 165 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |