draft-ietf-tsvwg-rsvp-dste-01.txt   draft-ietf-tsvwg-rsvp-dste-02.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
Bruce Davie Bruce Davie
Cisco Systems, Inc. Cisco Systems, Inc.
Michael Davenport Michael Davenport
Chris Christou Chris Christou
Booz Allen Hamilton Booz Allen Hamilton
Jerry Ash Jerry Ash
Bur Goode Bur Goode
AT&T AT&T
draft-ietf-tsvwg-rsvp-dste-01.txt draft-ietf-tsvwg-rsvp-dste-02.txt
Expires: August 2006 February 2006 Expires: October 2006 April 2006
Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels
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.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
corresponding end to end reservations) can be protected against corresponding end to end reservations) can be protected against
failure through the use of MPLS Fast Reroute failure through the use of MPLS Fast Reroute
RSVP Aggregation over MPLS TE tunnels February 2006 RSVP Aggregation over MPLS TE tunnels February 2006
This document, like [RSVP-AGG], covers aggregation of unicast This document, like [RSVP-AGG], covers aggregation of unicast
sessions. Aggregation of multicast sessions is for further study. sessions. Aggregation of multicast sessions is for further study.
1.1. Changes from previous versions 1.1. Changes from previous versions
The changes from version draft-ietf-tsvwg-rsvp-dste-01 to version
draft-ietf-tsvwg-rsvp-dste-02 are:
- clarification in text describing handling of E2E Path
- added text on handling of E2E PathTear and ResvConf.
The changes from version draft-ietf-tsvwg-rsvp-dste-00 to version The changes from version draft-ietf-tsvwg-rsvp-dste-00 to version
draft-ietf-tsvwg-rsvp-dste-01 of this draft address comments from the draft-ietf-tsvwg-rsvp-dste-01 of this draft address comments from the
"RSVP Review team" and from the Working Group Last Call. The "RSVP Review team" and from the Working Group Last Call. The
significant changes are: significant changes are:
- added text in multiple sub-sections of section 3 to describe - added text in multiple sub-sections of section 3 to describe
operations when the Aggregator and Deaggregator also behave as operations when the Aggregator and Deaggregator also behave as
IPsec security gateways. IPsec security gateways.
- added text in section 3 to further clarify relationship with - added text in section 3 to further clarify relationship with
[LSP-HIER] [LSP-HIER]
- added text in section 8 to refer to some security - added text in section 8 to refer to some security
skipping to change at page 6, line 50 skipping to change at page 7, line 5
- added definition of E2E reservation in section 2. - added definition of E2E reservation in section 2.
- removed the case where E2E reservation is a TE tunnel (already - removed the case where E2E reservation is a TE tunnel (already
covered in [LSP-HIER]) covered in [LSP-HIER])
The significant changes from version draft-lefaucheur-rsvp-dste-01 to The significant changes from version draft-lefaucheur-rsvp-dste-01 to
version draft-lefaucheur-rsvp-dste-02 of this draft were: version draft-lefaucheur-rsvp-dste-02 of this draft were:
- Alignment with RSVP operations of draft-ietf-mpls-lsp-hierarchy - Alignment with RSVP operations of draft-ietf-mpls-lsp-hierarchy
- Addition of an appendix providing an example usage scenario for - Addition of an appendix providing an example usage scenario for
information purposes information purposes
RSVP Aggregation over MPLS TE tunnels February 2006
The significant changes from version draft-lefaucheur-rsvp-dste-00 to The significant changes from version draft-lefaucheur-rsvp-dste-00 to
version draft-lefaucheur-rsvp-dste-01 of this draft were: version draft-lefaucheur-rsvp-dste-01 of this draft were:
- added discussion of the relationship to RFC 2746 [RSVP-TUN] - added discussion of the relationship to RFC 2746 [RSVP-TUN]
- added discussion of mapping policy at aggregator - added discussion of mapping policy at aggregator
- added discussion of "RSVP proxy" behavior in conjunction with - added discussion of "RSVP proxy" behavior in conjunction with
the aggregation scheme described here the aggregation scheme described here
RSVP Aggregation over MPLS TE tunnels February 2006
- added discussion on TTL processing on Deaggregator - added discussion on TTL processing on Deaggregator
2. Definitions 2. Definitions
For readability, a number of definitions from [RSVP-AGG] as well as For readability, a number of definitions from [RSVP-AGG] as well as
definitions for commonly used MPLS TE terms are provided here: definitions for commonly used MPLS TE terms are provided here:
Aggregator This is the process in (or associated with) the router Aggregator This is the process in (or associated with) the router
at the ingress edge of the aggregation region (with at the ingress edge of the aggregation region (with
respect to the end to end RSVP reservation) and respect to the end to end RSVP reservation) and
skipping to change at page 7, line 47 skipping to change at page 8, line 5
Aggregator and Deaggregator. Aggregator and Deaggregator.
An E2E RSVP reservation may be a per-flow An E2E RSVP reservation may be a per-flow
reservation. Alternatively, the E2E reservation reservation. Alternatively, the E2E reservation
may itself be an aggregate reservation of various may itself be an aggregate reservation of various
types (e.g. Aggregate IP reservation, Aggregate types (e.g. Aggregate IP reservation, Aggregate
IPsec reservation). See section 4 and 5 for more IPsec reservation). See section 4 and 5 for more
details on the types of E2E RSVP reservations. As details on the types of E2E RSVP reservations. As
per regular RSVP operations, E2E RSVP reservations per regular RSVP operations, E2E RSVP reservations
are unidirectional. are unidirectional.
RSVP Aggregation over MPLS TE tunnels February 2006
Head-end Head-end
This is the Label Switch Router responsible for This is the Label Switch Router responsible for
establishing, maintaining and tearing down a given TE establishing, maintaining and tearing down a given TE
tunnel. tunnel.
Tail-end Tail-end
This is the Label Switch Router responsible for This is the Label Switch Router responsible for
terminating a given TE tunnel terminating a given TE tunnel
RSVP Aggregation over MPLS TE tunnels February 2006
Transit LSR This is a Label Switch router that is on the path of a Transit LSR This is a Label Switch router that is on the path of a
given TE tunnel and is neither the Head-end nor the given TE tunnel and is neither the Head-end nor the
Tail-end Tail-end
3. Operations of RSVP Aggregation over TE with pre-established Tunnels 3. Operations of RSVP Aggregation over TE with pre-established Tunnels
[RSVP-AGG] supports operations both in the case where aggregate RSVP [RSVP-AGG] supports operations both in the case where aggregate RSVP
reservations are pre-established and in the case where Aggregators reservations are pre-established and in the case where Aggregators
and Deaggregators have to dynamically discover each other and and Deaggregators have to dynamically discover each other and
dynamically establish the necessary aggregate RSVP reservations. dynamically establish the necessary aggregate RSVP reservations.
skipping to change at page 8, line 48 skipping to change at page 9, line 4
The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to The signaling aspects discussed in section 6.2 of [LSP-HIER] apply to
the establishment/termination of the aggregate TE tunnels when this the establishment/termination of the aggregate TE tunnels when this
is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end is triggered by GMPLS mechanisms (e.g. as a result of an end-to-end
TE LSP establishment request received at the aggregation boundary) . TE LSP establishment request received at the aggregation boundary) .
As this document assumes pre-established tunnels, those aspects are As this document assumes pre-established tunnels, those aspects are
not relevant here. The signaling aspects discussed in section 6.1 of not relevant here. The signaling aspects discussed in section 6.1 of
[LSP-HIER] relate to the establishment/maintenance of the end-to-end [LSP-HIER] relate to the establishment/maintenance of the end-to-end
TE LSPs over the aggregate TE tunnel. This document describes how to TE LSPs over the aggregate TE tunnel. This document describes how to
use the same procedures as those specified in section 6.1 of [LSP- use the same procedures as those specified in section 6.1 of [LSP-
HIER], but for the establishment of end-to-end RSVP reservations HIER], but for the establishment of end-to-end RSVP reservations
RSVP Aggregation over MPLS TE tunnels February 2006
(instead of end-to-end TE LSPs) over the TE tunnels. This is covered (instead of end-to-end TE LSPs) over the TE tunnels. This is covered
further in section 3 of the present document. further in section 3 of the present document.
Pre-establishment of the TE tunnels may be triggered by any Pre-establishment of the TE tunnels may be triggered by any
mechanisms including for example manual configuration or automatic mechanisms including for example manual configuration or automatic
establishment of a TE tunnel mesh through dynamic discovery of TE establishment of a TE tunnel mesh through dynamic discovery of TE
Mesh membership as allowed in [AUTOMESH]. Mesh membership as allowed in [AUTOMESH].
RSVP Aggregation over MPLS TE tunnels February 2006
Procedures in the case of dynamically established TE tunnels are for Procedures in the case of dynamically established TE tunnels are for
further studies. further studies.
3.1. Reference Model 3.1. Reference Model
I----I I----I I----I I----I
H--I R I\ I-----I I------I /I R I--H H--I R I\ I-----I I------I /I R I--H
H--I I\\I I I---I I I//I I--H H--I I\\I I I---I I I//I I--H
I----I \I He/ I I T I I Te/ I/ I----I I----I \I He/ I I T I I Te/ I/ I----I
I Agg I=======================I Deag I I Agg I=======================I Deag I
skipping to change at page 9, line 46 skipping to change at page 10, line 4
The Aggregator MUST first attempt to map the E2E reservation onto a The Aggregator MUST first attempt to map the E2E reservation onto a
TE tunnel. This decision is made in accordance with routing TE tunnel. This decision is made in accordance with routing
information as well as any local policy information that may be information as well as any local policy information that may be
available at the Aggregator. Examples of such policies appear in the available at the Aggregator. Examples of such policies appear in the
following paragraphs. Just for illustration purposes, among many following paragraphs. Just for illustration purposes, among many
other criteria, such mapping policies might take into account the other criteria, such mapping policies might take into account the
Intserv service type, the Application Identity [RSVP-APPID] and/or Intserv service type, the Application Identity [RSVP-APPID] and/or
the signaled preemption [RSVP-PREEMP] of the E2E reservation (for the signaled preemption [RSVP-PREEMP] of the E2E reservation (for
example, the aggregator may take into account the E2E reservations example, the aggregator may take into account the E2E reservations
RSVP Aggregation over MPLS TE tunnels February 2006
RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold RSVP preemption priority and the MPLS TE Tunnel set-up and/or hold
priorities when mapping the E2E reservation onto an MPLS TE tunnel). priorities when mapping the E2E reservation onto an MPLS TE tunnel).
There are situations where the Aggregator is able to make a final There are situations where the Aggregator is able to make a final
mapping decision. That would be the case, for example, if there is a mapping decision. That would be the case, for example, if there is a
single TE tunnel towards the destination and if the policy is to map single TE tunnel towards the destination and if the policy is to map
any E2E RSVP reservation onto TE Tunnels. any E2E RSVP reservation onto TE Tunnels.
RSVP Aggregation over MPLS TE tunnels February 2006
There are situations where the Aggregator is not able to make a final There are situations where the Aggregator is not able to make a final
determination. That would be the case, for example, if routing determination. That would be the case, for example, if routing
identifies two DS-TE tunnels towards the destination, one belonging identifies two DS-TE tunnels towards the destination, one belonging
to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to to DS-TE Class-Type 1 and one to Class-Type 0, if the policy is to
map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel map Intserv Guaranteed Services reservations to a Class-Type 1 tunnel
and Intserv Controlled Load reservations to a Class-Type 0 tunnel, and Intserv Controlled Load reservations to a Class-Type 0 tunnel,
and if the E2E RSVP Path message advertises both Guaranteed Service and if the E2E RSVP Path message advertises both Guaranteed Service
and Controlled Load. and Controlled Load.
Whether final or tentative, the Aggregator makes a mapping decision Whether final or tentative, the Aggregator makes a mapping decision
skipping to change at page 10, line 31 skipping to change at page 10, line 39
may be based on configured information, on information available in may be based on configured information, on information available in
the MPLS TE topology database, on the current TE tunnel path, on the MPLS TE topology database, on the current TE tunnel path, on
information collected via RSVP-TE signaling, or combinations of those. information collected via RSVP-TE signaling, or combinations of those.
The Aggregator MUST then forward the E2E Path message to the The Aggregator MUST then forward the E2E Path message to the
Deaggregator (which is the tail-end of the selected TE tunnel). In Deaggregator (which is the tail-end of the selected TE tunnel). In
accordance with [LSP-HIER], the Aggregator MUST send the E2E Path accordance with [LSP-HIER], the Aggregator MUST send the E2E Path
message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object. message with an IF_ID RSVP_HOP object instead of an RSVP_HOP object.
The data interface identification MUST identify the TE Tunnel. The data interface identification MUST identify the TE Tunnel.
The preferred method for the Aggregator to send the E2E Path message To send the E2E Path message, the Aggregator MUST address it directly
is to address it directly to the Deaggregator by setting the to the Deaggregator by setting the destination address in the IP
destination address in the IP Header of the E2E Path message to the Header of the E2E Path message to the Deaggregator address. The
Deaggregator address. The Router Alert is not set in the E2E Path Router Alert is not set in the E2E Path message.
message.
An alternate method for the Aggregator to send the E2E Path is to Optionally, the Aggregator MAY also encapsulate the E2E Path message
encapsulate the E2E Path message in an IP tunnel or in the TE tunnel in an IP tunnel or in the TE tunnel itself.
itself and unicast the E2E Path message to the Deaggregator, without
the Router Alert option.
With both methods, the Router Alert is not set. Thus, the E2E Path Regardless of the encapsulation method, the Router Alert is not set.
message will not be visible to routers along the path from the Thus, the E2E Path message will not be visible to routers along the
Aggregator to the Deaggregator. Therefore, in contrast to the path from the Aggregator to the Deaggregator. Therefore, in contrast
procedures of [RSVP-AGG], the IP Protocol number need not be modified to the procedures of [RSVP-AGG], the IP Protocol number need not be
to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating "RSVP") by modified to "RSVP-E2E-IGNORE"; it MUST be left as is (indicating
the Aggregator. "RSVP") by the Aggregator.
In some environments, the Aggregator and Deaggregator MAY also act as In some environments, the Aggregator and Deaggregator MAY also act as
IPsec Security Gateways in order to provide IPsec protection to E2E IPsec Security Gateways in order to provide IPsec protection to E2E
RSVP Aggregation over MPLS TE tunnels February 2006
traffic when it transits between the Aggregator and the Deaggregator. traffic when it transits between the Aggregator and the Deaggregator.
In that case, to transmit the E2E Path message to the Deaggregator, In that case, to transmit the E2E Path message to the Deaggregator,
the Aggregator MUST send the E2E Path message into the relevant IPsec the Aggregator MUST send the E2E Path message into the relevant IPsec
tunnel terminating on the Deaggregator. tunnel terminating on the Deaggregator.
RSVP Aggregation over MPLS TE tunnels February 2006 E2E PathTear and ResvConf messages MUST be forwarded by the
Aggregator to the Deaggregator exactly like Path messages.
3.3. Handling of E2E Path message By Transit LSRs 3.3. Handling of E2E Path message By Transit LSRs
Since the E2E Path message is addressed directly to the Deaggregator Since the E2E Path message is addressed directly to the Deaggregator
and does not have Router Alert set, it is hidden from all transit and does not have Router Alert set, it is hidden from all transit
LSRs. LSRs.
3.4. Receipt of E2E Path Message by Deaggregator 3.4. Receipt of E2E Path Message by Deaggregator
On receipt of the E2E Path message addressed to it, the Deaggregator On receipt of the E2E Path message addressed to it, the Deaggregator
skipping to change at page 11, line 47 skipping to change at page 12, line 5
The Deaggregator MUST forward the E2E Path downstream towards the The Deaggregator MUST forward the E2E Path downstream towards the
receiver. In doing so, the Deaggregator sets the destination address receiver. In doing so, the Deaggregator sets the destination address
in the IP header of the E2E Path message to the IP address found in in the IP header of the E2E Path message to the IP address found in
the destination address field of the Session object. The Deaggregator the destination address field of the Session object. The Deaggregator
also sets the Router Alert. also sets the Router Alert.
An E2E PathErr sent by the Deaggregator in response to the E2E Path An E2E PathErr sent by the Deaggregator in response to the E2E Path
message (which contains an IF_ID RSVP_HOP object) SHOULD contain an message (which contains an IF_ID RSVP_HOP object) SHOULD contain an
IF_ID RSVP_HOP object. IF_ID RSVP_HOP object.
RSVP Aggregation over MPLS TE tunnels February 2006
3.5. Handling of E2E Resv Message by Deaggregator 3.5. Handling of E2E Resv Message by Deaggregator
As per regular RSVP operations, after receipt of the E2E Path, the As per regular RSVP operations, after receipt of the E2E Path, the
receiver generates an E2E Resv message which travels upstream hop-by- receiver generates an E2E Resv message which travels upstream hop-by-
hop towards the sender. hop towards the sender.
RSVP Aggregation over MPLS TE tunnels February 2006
On receipt of the E2E Resv, the Deaggregator MUST follow traditional On receipt of the E2E Resv, the Deaggregator MUST follow traditional
RSVP procedures on receipt of the E2E Resv message. This includes RSVP procedures on receipt of the E2E Resv message. This includes
performing admission control for the segment downstream of the performing admission control for the segment downstream of the
Deaggregator and forwarding the E2E Resv message to the PHOP signaled Deaggregator and forwarding the E2E Resv message to the PHOP signaled
earlier in the E2E Path message and which identifies the Aggregator. earlier in the E2E Path message and which identifies the Aggregator.
Since the E2E Resv message is directly addressed to the Aggregator Since the E2E Resv message is directly addressed to the Aggregator
and does not carry the Router Alert option (as per traditional RSVP and does not carry the Router Alert option (as per traditional RSVP
Resv procedures), the E2E Resv message is hidden from the routers Resv procedures), the E2E Resv message is hidden from the routers
between the Deaggregator and the Aggregator which, therefore, handle between the Deaggregator and the Aggregator which, therefore, handle
the E2E Resv message as a regular IP packet. the E2E Resv message as a regular IP packet.
skipping to change at page 12, line 48 skipping to change at page 13, line 5
[RFC2205] to determine the resource requirements from the Sender [RFC2205] to determine the resource requirements from the Sender
Tspec and the Flowspec contained in the Resv. Then it compares the Tspec and the Flowspec contained in the Resv. Then it compares the
resource request with the available resources of the selected TE resource request with the available resources of the selected TE
tunnel. tunnel.
If sufficient bandwidth is available on the final TE tunnel, the If sufficient bandwidth is available on the final TE tunnel, the
Aggregator MUST update its internal understanding of how much of the Aggregator MUST update its internal understanding of how much of the
TE Tunnel is in use and MUST forward the E2E Resv messages to the TE Tunnel is in use and MUST forward the E2E Resv messages to the
corresponding PHOP. corresponding PHOP.
RSVP Aggregation over MPLS TE tunnels February 2006
As noted in [RSVP-AGG], a range of policies MAY be applied to the re- As noted in [RSVP-AGG], a range of policies MAY be applied to the re-
sizing of the aggregate reservation (in this case, the TE tunnel.) sizing of the aggregate reservation (in this case, the TE tunnel.)
For example, the policy may be that the reserved bandwidth of the For example, the policy may be that the reserved bandwidth of the
tunnel can only be changed by configuration. More dynamic policies tunnel can only be changed by configuration. More dynamic policies
are also possible, whereby the aggregator may attempt to increase the are also possible, whereby the aggregator may attempt to increase the
reserved bandwidth of the tunnel in response to the amount of reserved bandwidth of the tunnel in response to the amount of
RSVP Aggregation over MPLS TE tunnels February 2006
allocated bandwidth that has been used by E2E reservations. allocated bandwidth that has been used by E2E reservations.
Furthermore, to avoid the delay associated with the increase of the Furthermore, to avoid the delay associated with the increase of the
Tunnel size, the Aggregator may attempt to anticipate the increases Tunnel size, the Aggregator may attempt to anticipate the increases
in demand and adjust the TE tunnel size ahead of actual needs by E2E in demand and adjust the TE tunnel size ahead of actual needs by E2E
reservations. In order to reduce disruptions, the aggregator SHOULD reservations. In order to reduce disruptions, the aggregator SHOULD
use "make-before-break" procedures as described in [RSVP-TE] to alter use "make-before-break" procedures as described in [RSVP-TE] to alter
the TE tunnel bandwidth". the TE tunnel bandwidth".
If sufficient bandwidth is not available on the final TE Tunnel, the If sufficient bandwidth is not available on the final TE Tunnel, the
Aggregator MUST follow the normal RSVP procedure for a reservation Aggregator MUST follow the normal RSVP procedure for a reservation
skipping to change at page 13, line 39 skipping to change at page 13, line 45
described above. described above.
In the former case, admission control over the final TE tunnel (and In the former case, admission control over the final TE tunnel (and
forwarding of E2E Resv message upstream towards the sender) would forwarding of E2E Resv message upstream towards the sender) would
only occur when the Aggregator receives the subsequent E2E Resv only occur when the Aggregator receives the subsequent E2E Resv
message (that will be sent by the Deaggregator in response to the message (that will be sent by the Deaggregator in response to the
resent E2E Path). In the latter case, admission control over the resent E2E Path). In the latter case, admission control over the
final Tunnel is carried out by Aggregator right away and if final Tunnel is carried out by Aggregator right away and if
successful the E2E Resv message is generated upstream towards the successful the E2E Resv message is generated upstream towards the
sender. sender.
On receipt of an E2E ResvConf from the Aggregator, the Deaggregator
MUST forward the E2E ResvConf downstream towards the receiver. In
doing so, the Deaggregator sets the destination address in the IP
header of the E2E ResvConf message to the IP address found in the
RESV_CONFIRM object of the corresponding Resv. The Deaggregator also
sets the Router Alert.
3.7. Forwarding of E2E traffic by Aggregator 3.7. Forwarding of E2E traffic by Aggregator
RSVP Aggregation over MPLS TE tunnels February 2006
When the Aggregator receives a data packet belonging to an E2E When the Aggregator receives a data packet belonging to an E2E
reservations currently mapped over a given TE tunnel, the Aggregator reservations currently mapped over a given TE tunnel, the Aggregator
MUST encapsulate the packet into that TE tunnel. MUST encapsulate the packet into that TE tunnel.
If the Aggregator and Deaggregator are also acting as IPsec Security If the Aggregator and Deaggregator are also acting as IPsec Security
Gateways, the Aggregator MUST also encapsulate the data packet into Gateways, the Aggregator MUST also encapsulate the data packet into
the relevant IPsec tunnel terminating on the Deaggregator before the relevant IPsec tunnel terminating on the Deaggregator before
transmission into the MPLS TE tunnel. transmission into the MPLS TE tunnel.
3.8. Removal of E2E reservations 3.8. Removal of E2E reservations
RSVP Aggregation over MPLS TE tunnels February 2006
E2E reservations are removed in the usual way via PathTear, ResvTear, E2E reservations are removed in the usual way via PathTear, ResvTear,
timeout, or as the result of an error condition. When a reservation timeout, or as the result of an error condition. When a reservation
is removed, the Aggregator MUST update its local view of the is removed, the Aggregator MUST update its local view of the
resources available on the corresponding TE tunnel accordingly. resources available on the corresponding TE tunnel accordingly.
3.9. Removal of TE Tunnel 3.9. Removal of TE Tunnel
Should a TE Tunnel go away (presumably due to a configuration change, Should a TE Tunnel go away (presumably due to a configuration change,
route change, or policy event), the aggregator behaves much like a route change, or policy event), the aggregator behaves much like a
conventional RSVP router in the face of a link failure. That is, it conventional RSVP router in the face of a link failure. That is, it
skipping to change at page 16, line 40 skipping to change at page 16, line 40
of E2E RSVP reservations including the following cases: of E2E RSVP reservations including the following cases:
(1) the E2E RSVP reservation is a per-flow reservation where the (1) the E2E RSVP reservation is a per-flow reservation where the
flow is characterized by the usual 5-tuple flow is characterized by the usual 5-tuple
(2) the E2E reservation is an aggregate reservation for multiple (2) the E2E reservation is an aggregate reservation for multiple
flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the flows as described in [RSVP-AGG] or [RSVP-GEN-AGG] where the
set of flows is characterized by the <source address, set of flows is characterized by the <source address,
destination address, DSCP> destination address, DSCP>
(3) the E2E reservation is a reservation for an IPsec protected (3) the E2E reservation is a reservation for an IPsec protected
flow. For example, where the flow is characterized by the flow. For example, where the flow is characterized by the
<source address, destination address, SPI> as described in <source address, destination address, SPI> as described in
[RSVP-IPSEC] [RSVP-IPSEC].
IPsec
6. Example Deployment Scenarios 6. Example Deployment Scenarios
6.1. Voice and Video Reservations Scenario 6.1. Voice and Video Reservations Scenario
An example application of the procedures specified in this document An example application of the procedures specified in this document
is admission control of voice and video in environments with very is admission control of voice and video in environments with very
high numbers of hosts. In the example illustrated below, hosts high numbers of hosts. In the example illustrated below, hosts
generate end-to-end per-flow reservations for each of their video generate end-to-end per-flow reservations for each of their video
streams associated with a video-conference, each of their audio streams associated with a video-conference, each of their audio
skipping to change at page 22, line 18 skipping to change at page 22, line 18
MPLS", RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels, [RSVP-TE] Awduche et al, RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC 3209, December 2001. RFC 3209, December 2001.
[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of [DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005. Diff-Serv-aware MPLS Traffic Engineering, RFC 4124, June 2005.
[LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with [LSP-HIER] Kompella et al, Label Switched Paths (LSP) Hierarchy with
Generalized Multi-Protocol Label Switching (GMPLS) Traffic Generalized Multi-Protocol Label Switching (GMPLS) Traffic
Engineering (TE), RFC 4206 Engineering (TE), RFC 4206, October 2005
, October 2005
[SEC-ARCH] Kent and Seo, Security Architecture for the Internet [SEC-ARCH] Kent and Seo, Security Architecture for the Internet
Protocol, RFC 4301, December 2005 Protocol, RFC 4301, December 2005
12. Informative References 12. Informative References
[DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270, [DIFF-MPLS] Le Faucheur et al, MPLS Support of Diff-Serv, RFC3270,
May 2002. May 2002.
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, RFC3564, July 2003. aware MPLS Traffic Engineering, RFC3564, July 2003.
[6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using [6PE] De Clercq et al, Connecting IPv6 Islands over IPv4 MPLS using
IPv6 Provider Edge Routers (6PE), work in progress IPv6 Provider Edge Routers (6PE), work in progress
[RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC [RSVP-IPSEC] Berger et al, RSVP Extensions for IPSEC Data Flows, RFC
2207 2207
[RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations, [RSVP-GEN-AGG] Le Faucheur et al, Generic Aggregate RSVP Reservations,
draft-lefaucheur-rsvp-ipsec, work in progress draft-ietf-tsvwg-rsvp-ipsec, work in progress
[RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746, [RSVP-TUN] Terzis et al., RSVP Operation Over IP Tunnels, RFC 2746,
January 2000 January 2000
[RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element, [RSVP-PREEMP] Herzog, Signaled Preemption Priority Policy Element,
RFC 3181 RFC 3181
[L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt, [L-RSVP] Manner et al., Localized RSVP, draft-manner-lrsvp-04.txt,
work in progress. work in progress.
[RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt [RSVP-PROXY] Gai et al., RSVP Proxy, draft-ietf-rsvp-proxy-03.txt
(expired), work in progress. (expired), work in progress.
RSVP Aggregation over MPLS TE tunnels February 2006
[RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC [RSVP-APPID] Bernet et al., Identity Representation for RSVP, RFC
3182. 3182.
RSVP Aggregation over MPLS TE tunnels February 2006
[AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of [AUTOMESH] Vasseur and Leroux, Routing extensions for discovery of
Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering
(TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in (TE) mesh membership, draft-vasseur-ccamp-automesh-00.txt, work in
progress. progress.
[SIP-RSVP] Camarillo, Integration of Resource Management and Session [SIP-RSVP] Camarillo, Integration of Resource Management and Session
Initiation Protocol (SIP), RFC 3312 Initiation Protocol (SIP), RFC 3312
13. Authors Address: 13. Authors Address:
skipping to change at page 24, line 4 skipping to change at page 23, line 48
Christou Christou Christou Christou
Booz Allen Hamilton Booz Allen Hamilton
8283 Greensboro Drive 8283 Greensboro Drive
McLean, VA 22102 McLean, VA 22102
USA USA
Email: christou_chris@bah.com Email: christou_chris@bah.com
Michael Davenport Michael Davenport
Booz Allen Hamilton Booz Allen Hamilton
8283 Greensboro Drive
McLean, VA 22102
RSVP Aggregation over MPLS TE tunnels February 2006 RSVP Aggregation over MPLS TE tunnels February 2006
8283 Greensboro Drive
McLean, VA 22102
USA USA
Email: davenport_michael@bah.com Email: davenport_michael@bah.com
Jerry Ash Jerry Ash
AT&T AT&T
200 Laurel Avenue 200 Laurel Avenue
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
USA USA
Email: gash@att.com Email: gash@att.com
skipping to change at page 25, line 5 skipping to change at page 24, line 48
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. this standard.
Please address the information to the IETF at ietf-ipr@ietf.org. Please address the information to the IETF at ietf-ipr@ietf.org.
RSVP Aggregation over MPLS TE tunnels February 2006
15. Disclaimer of Validity 15. Disclaimer of Validity
RSVP Aggregation over MPLS TE tunnels February 2006
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
16. Copyright Notice 16. Copyright Notice
skipping to change at page 26, line 4 skipping to change at page 25, line 51
reservations going from GW2 to GW2, PE2 serves as the reservations going from GW2 to GW2, PE2 serves as the
aggregator/head-end and PE1 serves as the de-aggregator/tail-end. aggregator/head-end and PE1 serves as the de-aggregator/tail-end.
To determine whether there is sufficient bandwidth in the MPLS core To determine whether there is sufficient bandwidth in the MPLS core
to complete a connection, the originating and destination GWs each to complete a connection, the originating and destination GWs each
send for each connection a Resource Reservation Protocol (RSVP) send for each connection a Resource Reservation Protocol (RSVP)
bandwidth request to the network PE router to which it is connected. bandwidth request to the network PE router to which it is connected.
The bandwidth request takes into account VoIP header compression, The bandwidth request takes into account VoIP header compression,
where applicable. As part of its Aggregator role, the PE router where applicable. As part of its Aggregator role, the PE router
effectively performs admission control of the bandwidth request effectively performs admission control of the bandwidth request
RSVP Aggregation over MPLS TE tunnels February 2006
generated by the GW onto the resources of the corresponding DS-TE generated by the GW onto the resources of the corresponding DS-TE
tunnel. tunnel.
RSVP Aggregation over MPLS TE tunnels February 2006
In this example, in addition to behaving as Aggregator/Deaggregator, In this example, in addition to behaving as Aggregator/Deaggregator,
PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path PE1 and PE2 behave as RSVP proxy. So when a PE receives a Path
message from a GW, it does not propagate the Path message any further. message from a GW, it does not propagate the Path message any further.
Rather, the PE performs admission control of the bandwidth signaled Rather, the PE performs admission control of the bandwidth signaled
in the Path message over the DSTE tunnel towards the destination. in the Path message over the DSTE tunnel towards the destination.
Assuming there is enough bandwidth available on that tunnel, the PE Assuming there is enough bandwidth available on that tunnel, the PE
adjusts its book-keeping of remaining available bandwidth on the adjusts its book-keeping of remaining available bandwidth on the
tunnel and generates a Resv message back towards the GW to confirm tunnel and generates a Resv message back towards the GW to confirm
resources have been reserved over the DSTE tunnel. resources have been reserved over the DSTE tunnel.
skipping to change at page 27, line 4 skipping to change at page 26, line 52
`--. ,.__,| | IP/MPLS Network / '---'- ----' `--. ,.__,| | IP/MPLS Network / '---'- ----'
'`' '' ' .._,,'`.__ _/ '---' | '`' '' ' .._,,'`.__ _/ '---' |
| '`''' | | '`''' |
C1 C2 C1 C2
Figure A1. Integration of SIP Resource Management, DSTE Figure A1. Integration of SIP Resource Management, DSTE
and RSVP Aggregation and RSVP Aggregation
[SIP-RSVP] discusses how network quality of service can be made a [SIP-RSVP] discusses how network quality of service can be made a
precondition for establishment of sessions initiated by the Session precondition for establishment of sessions initiated by the Session
Initiation Protocol (SIP). These preconditions require that the
participant reserve network resources before continuing with the
RSVP Aggregation over MPLS TE tunnels February 2006 RSVP Aggregation over MPLS TE tunnels February 2006
Initiation Protocol (SIP). These preconditions require that the
participant reserve network resources before continuing with the
session. The reservation of network resources are performed through a session. The reservation of network resources are performed through a
signaling protocol such as RSVP. signaling protocol such as RSVP.
Our example environment relies of [SIP-RSVP] to synchronize RSVP Our example environment relies of [SIP-RSVP] to synchronize RSVP
bandwidth reservations with SIP. For example, the RSVP bandwidth bandwidth reservations with SIP. For example, the RSVP bandwidth
requests may be integrated into the call setup flow as follows (See requests may be integrated into the call setup flow as follows (See
call setup flow diagram in Figure A2): call setup flow diagram in Figure A2):
- Caller C1 initiates a call by sending a SIP INVITE to VoIP - Caller C1 initiates a call by sending a SIP INVITE to VoIP
gateway GW1, which passes the INVITE along to the call control gateway GW1, which passes the INVITE along to the call control
 End of changes. 35 change blocks. 
50 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/