draft-ietf-tsvwg-rsvp-dste-03.txt   draft-ietf-tsvwg-rsvp-dste-04.txt 
Internet Draft Francois Le Faucheur Internet Draft Francois Le Faucheur
Editor Editor
Cisco Systems, Inc. Cisco Systems, Inc.
draft-ietf-tsvwg-rsvp-dste-03.txt draft-ietf-tsvwg-rsvp-dste-04.txt
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Contributing Authors...........................................6 2. Contributing Authors...........................................6
3. Definitions....................................................7 3. Definitions....................................................7
4. Operations of RSVP Aggregation over TE with pre-established 4. Operations of RSVP Aggregation over TE with pre-established
Tunnels...........................................................8 Tunnels...........................................................8
4.1. Reference Model...........................................9 4.1. Reference Model...........................................9
4.2. Receipt of E2E Path message By the Aggregator............10 4.2. Receipt of E2E Path message By the Aggregator............10
4.3. Handling of E2E Path message By Transit LSRs.............11 4.3. Handling of E2E Path message By Transit LSRs.............11
4.4. Receipt of E2E Path Message by Deaggregator..............11 4.4. Receipt of E2E Path Message by Deaggregator..............12
4.5. Handling of E2E Resv Message by Deaggregator.............12 4.5. Handling of E2E Resv Message by Deaggregator.............12
4.6. Handling of E2E Resv Message by the Aggregator...........13 4.6. Handling of E2E Resv Message by the Aggregator...........13
4.7. Forwarding of E2E traffic by Aggregator..................14 4.7. Forwarding of E2E traffic by Aggregator..................14
4.8. Removal of E2E reservations..............................14 4.8. Removal of E2E reservations..............................14
4.9. Removal of TE Tunnel.....................................15 4.9. Removal of TE Tunnel.....................................15
4.10. Example Signaling Flow..................................16 4.10. Example Signaling Flow..................................16
5. IPv4 and IPv6 Applicability...................................17 5. IPv4 and IPv6 Applicability...................................17
6. E2E Reservations Applicability................................17 6. E2E Reservations Applicability................................17
7. Example Deployment Scenarios..................................17 7. Example Deployment Scenarios..................................17
7.1. Voice and Video Reservations Scenario....................17 7.1. Voice and Video Reservations Scenario....................17
7.2. PSTN/3G Voice Trunking Scenario..........................18 7.2. PSTN/3G Voice Trunking Scenario..........................18
8. Optional Use of RSVP Proxy on RSVP Aggregator.................19 8. Security Considerations.......................................19
9. Security Considerations.......................................21 9. IANA Considerations...........................................20
10. IANA Considerations..........................................22 10. Acknowledgments..............................................20
11. Acknowledgments..............................................22 11. Normative References.........................................20
12. Normative References.........................................22 12. Informative References.......................................21
13. Informative References.......................................23 13. Editor's Address:............................................22
14. Editor's Address:............................................24 Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator.......23
Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for
VoIP Call Admission Control (CAC)................................25 VoIP Call Admission Control (CAC)................................25
1. Introduction 1. Introduction
The Integrated Services (Intserv) [INT-SERV] architecture provides a The Integrated Services (Intserv) [INT-SERV] architecture provides a
means for the delivery of end-to-end Quality of Service (QoS) to means for the delivery of end-to-end Quality of Service (QoS) to
applications over heterogeneous networks. applications over heterogeneous networks.
[RSVP] defines the Resource reSerVation Protocol which can be used by [RSVP] defines the Resource reSerVation Protocol which can be used by
applications to request resources from the network. The network applications to request resources from the network. The network
responds by explicitely admitting or rejecting these RSVP requests. responds by explicitely admitting or rejecting these RSVP requests.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
2746 [RSVP-TUN]. It differs from that specification in the following 2746 [RSVP-TUN]. It differs from that specification in the following
ways ways
- Whereas RFC 2746 describes operation with IP tunnels, this - Whereas RFC 2746 describes operation with IP tunnels, this
document describes operation over MPLS tunnels. One consequence document describes operation over MPLS tunnels. One consequence
of this difference is the need to deal with penultimate hop of this difference is the need to deal with penultimate hop
popping (PHP). popping (PHP).
- MPLS-TE tunnels inherently reserve resources, whereas the - MPLS-TE tunnels inherently reserve resources, whereas the
tunnels in RFC 2746 do not have resource reservations by tunnels in RFC 2746 do not have resource reservations by
default. This leads to some simplifications in the current default. This leads to some simplifications in the current
document. document.
- There is exactly one reservation per MPLS-TE tunnel, whereas - This document builds on the fact that there is exactly one
RFC 2746 permits many reservations per tunnel. aggregate reservation per MPLS-TE tunnel, whereas RFC 2746
permits a model where one reservation is established on the
tunnel path for each end-to-end flow.
- We have assumed in the current document that a given MPLS-TE - We have assumed in the current document that a given MPLS-TE
tunnel will carry reserved traffic and nothing but reserved tunnel will carry reserved traffic and nothing but reserved
traffic, which negates the requirement of RFC 2746 to traffic, which negates the requirement of RFC 2746 to
distinguish reserved and non-reserved traffic traversing the distinguish reserved and non-reserved traffic traversing the
same tunnel by using distinct encapsulations. same tunnel by using distinct encapsulations.
- There may be several MPLS-TE tunnels that share common head and - There may be several MPLS-TE tunnels that share common head and
tail end routers, with head-end policy determining which tunnel tail end routers, with head-end policy determining which tunnel
is appropriate for a particular flow. This scenario does not is appropriate for a particular flow. This scenario does not
appear to be addressed in RFC 2746. appear to be addressed in RFC 2746.
skipping to change at page 11, line 10 skipping to change at page 11, line 13
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
and selects a TE tunnel. Before forwarding the E2E Path message and selects a TE tunnel. Before forwarding the E2E Path message
towards the receiver, the Aggregator SHOULD update the ADSPEC inside towards the receiver, the Aggregator SHOULD update the ADSPEC inside
the E2E Path message to reflect the impact of the MPLS TE cloud onto the E2E Path message to reflect the impact of the MPLS TE cloud onto
the QoS achievable by the E2E flow. This update is a local matter and the QoS achievable by the E2E flow. This update is a local matter and
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.
Updating the ADSPEC allow receivers that take into account the
information collected in the ADSPEC within the network (such as delay
and bandwidth estimates) to make more informed reservation decisions.
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.
To send the E2E Path message, the Aggregator MUST address it directly To send the E2E Path message, the Aggregator MUST address it directly
to the Deaggregator by setting the destination address in the IP to the Deaggregator by setting the destination address in the IP
Header of the E2E Path message to the Deaggregator address. The Header of the E2E Path message to the Deaggregator address. The
skipping to change at page 19, line 23 skipping to change at page 19, line 23
------ ------ ------ ------
GW = VoIP Gateway GW = VoIP Gateway
Agg = Aggregator (TE Tunnel Head-end) Agg = Aggregator (TE Tunnel Head-end)
Deagg = Deaggregator (TE Tunnel Tail-end) Deagg = Deaggregator (TE Tunnel Tail-end)
T = Transit LSR T = Transit LSR
/ = Aggregate Gateway to Gateway E2E RSVP reservation / = Aggregate Gateway to Gateway E2E RSVP reservation
== = TE Tunnel == = TE Tunnel
8. Optional Use of RSVP Proxy on RSVP Aggregator 8. Security Considerations
A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are
being, discussed in the IETF in order to allow a network node to
behave as an RSVP proxy which:
- originates the Resv Message (in response to the Path message) on
behalf of the destination node
- originates the Path message (in response to some trigger) on
behalf of the source node.
We observe that such approaches may optionally be used in conjunction
with the aggregation of RSVP reservations over MPLS TE tunnels as
specified in this document. In particular, we consider the case where
the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy.
As discussed in [RSVP-PROXY]:
"The proxy functionality does not imply merely generating a single
Resv message. Proxying the Resv involves installing state in the node
doing the proxy i.e. the proxying node should act as if it had
received a Resv from the true endpoint. This involves reserving
resources (if required), sending periodic refreshes of the Resv
message and tearing down the reservation if the Path is torn down."
Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may
effectively perform resource reservation over the MPLS TE Tunnel (and
hence over the whole segment between the RSVP Aggregator and the RSVP
Deaggregator) even if the RSVP signaling only takes place upstream of
the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator).
Also, the RSVP Proxy can generate the Path message on behalf of the
remote source host in order to achieve reservation in the return
direction (i.e. from RSVP aggregator/Deaggregator to host).
The resulting Signaling Flow is illustrated below, covering
reservations for both directions:
I----I I--------------I I------I I--------------I I----I
I I I Aggregator/ I I MPLS I I Aggregator/ I I I
IHostI I Deaggregator/I I cloudI I Deaggregator/I IHostI
I I I RSVP Proxy I I I I RSVP Proxy I I I
I----I I--------------I I------I I--------------I I----I
==========TE Tunnel==========>
<========= TE Tunnel==========
Path Path
------------> (1)-\ /-(i) <----------
Resv I I Resv
<------------ (2)-/ \-(ii) ------------>
Path Path
<------------ (3) (iii) ------------>
Resv Resv
------------> <------------
(1)(i) : Aggregator/Deaggregator/Proxy receives Path message,
selects the TE tunnel, performs admission control over the TE Tunnel.
(1) and (i) happens independently of each other.
(2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message
towards Host. (2) is triggered by (1) and (ii) is triggered by (i).
Before generating this Resv message, the Aggregator/Proxy performs
admission control of the corresponding reservation over the TE tunnel
that will eventually carry the corresponding traffic.
(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message
towards Host for reservation in return direction. The actual trigger
for this depends on the actual RSVP proxy solution. As an example,
(3) and (iii) may simply be triggered respectively by (1) and (i).
Note that the details of the signaling flow may vary slightly
depending on the actual approach used for RSVP Proxy. For example, if
the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional
PathRequest message would be needed from host to
Aggregator/Deaggregator/Proxy in order to trigger the generation of
the Path message for return direction.
But regardless of the details of the call flow and of the actual RSVP
Proxy approach, RSVP proxy may optionally be deployed in combination
with RSVP Aggregation over MPLS TE Tunnels, in such a way which
ensures (when used on both the Host-Aggregator and Deaggregator-Host
sides, and when both end systems support RSVP) that:
(i) admission control and resource reservation is performed on
every segment of the end-to-end path (i.e. between source
host and Aggregator, over the TE Tunnel between the
Aggregator and Deaggregator which itself has been subject
to admission control by MPLS TE, between Deaggregator and
destination host)
(ii) this is achieved in both direction
(iii) RSVP signaling is localized between hosts and
Aggregator/Deaggregator, which may result in significant
reduction in reservation establishment delays (and in turn
in post dial delay in the case where these reservations
are pre-conditions for voice call establishment),
particularly in the case where the MPLS TE tunnels span
long distances with high propagation delays.
9. Security Considerations
The security issues inherent to the use of RSVP, RSVP Aggregation and The security issues inherent to the use of RSVP, RSVP Aggregation and
MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP- MPLS TE apply. Those can be addressed as discussed in [RSVP], [RSVP-
AGG] and [RSVP-TE]. AGG] and [RSVP-TE].
Section 7 of [LSP-HIER] discusses security considerations stemming Section 7 of [LSP-HIER] discusses security considerations stemming
from the fact that the implicit assumption of a binding between data from the fact that the implicit assumption of a binding between data
interface and the interface over which a control message is sent is interface and the interface over which a control message is sent is
no longer valid. These security considerations are equally applicable no longer valid. These security considerations are equally applicable
to the present document. to the present document.
skipping to change at page 22, line 8 skipping to change at page 20, line 5
There are also potential risks that such resizing results in There are also potential risks that such resizing results in
significant computation and signaling as well as churn on tunnel significant computation and signaling as well as churn on tunnel
paths. Such risks can be mitigated by configuration options allowing paths. Such risks can be mitigated by configuration options allowing
control of TE tunnel dynamic resizing (maximum Te tunnel size, control of TE tunnel dynamic resizing (maximum Te tunnel size,
maximum resizing frequency,...) and/or possibly by the use of TE maximum resizing frequency,...) and/or possibly by the use of TE
preemption. preemption.
If the Aggregator and Deaggregator are also acting as IPsec Security If the Aggregator and Deaggregator are also acting as IPsec Security
Gateways, the Security Considerations of [SEC-ARCH] apply. Gateways, the Security Considerations of [SEC-ARCH] apply.
10. IANA Considerations 9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. Acknowledgments 10. Acknowledgments
This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER] This document builds on the [RSVP-AGG], [RSVP-TUN] and [LSP-HIER]
specifications. Also, we would like to thank Tom Phelan, John Drake, specifications. Also, we would like to thank Tom Phelan, John Drake,
Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol Arthi Ayyangar, Fred Baker, Subha Dhesikan, Kwok-Ho Chan, Carol
Iturralde and James Gibson for their input into this document. Iturralde and James Gibson for their input into this document.
12. Normative References 11. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC2119, March 1997. Requirement Levels, RFC2119, March 1997.
[RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology, [RFC3668] S. Bradner, Intellectual Property Rights in IETF Technology,
RFC 3668, February 2004. RFC 3668, February 2004.
[BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March [BCP-78], S. Bradner, IETF Rights in Contributions, RFC3978, March
2005. 2005.
skipping to change at page 23, line 21 skipping to change at page 21, line 18
[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, October 2005 Engineering (TE), RFC 4206, 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
13. 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
skipping to change at page 24, line 13 skipping to change at page 22, line 10
3182. 3182.
[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
14. Editor's Address: 13. Editor's Address:
Francois Le Faucheur Francois Le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3 Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille 400, Avenue de Roumanille
06410 Biot Sophia-Antipolis 06410 Biot Sophia-Antipolis
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
IPR Statements IPR Statements
skipping to change at page 25, line 18 skipping to change at page 23, line 16
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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Appendix A - Example Usage of RSVP Aggregation over DSTE Tunnels for Appendix A - Optional Use of RSVP Proxy on RSVP Aggregator
A number of approaches ([RSVP-PROXY], [L-RSVP]) have been, or are
being, discussed in the IETF in order to allow a network node to
behave as an RSVP proxy which:
- originates the Resv Message (in response to the Path message) on
behalf of the destination node
- originates the Path message (in response to some trigger) on
behalf of the source node.
We observe that such approaches may optionally be used in conjunction
with the aggregation of RSVP reservations over MPLS TE tunnels as
specified in this document. In particular, we consider the case where
the RSVP Aggregator/Deaggregator also behaves as the RSVP proxy.
The information is this Appendix is purely informational and
illustrative.
As discussed in [RSVP-PROXY]:
"The proxy functionality does not imply merely generating a single
Resv message. Proxying the Resv involves installing state in the node
doing the proxy i.e. the proxying node should act as if it had
received a Resv from the true endpoint. This involves reserving
resources (if required), sending periodic refreshes of the Resv
message and tearing down the reservation if the Path is torn down."
Hence, when behaving as the RSVP Proxy, the RSVP Aggregator may
effectively perform resource reservation over the MPLS TE Tunnel (and
hence over the whole segment between the RSVP Aggregator and the RSVP
Deaggregator) even if the RSVP signaling only takes place upstream of
the MPLS TE Tunnel (i.e. between the host and the RSVP aggregator).
Also, the RSVP Proxy can generate the Path message on behalf of the
remote source host in order to achieve reservation in the return
direction (i.e. from RSVP aggregator/Deaggregator to host).
The resulting Signaling Flow is illustrated below, covering
reservations for both directions:
I----I I--------------I I------I I--------------I I----I
I I I Aggregator/ I I MPLS I I Aggregator/ I I I
IHostI I Deaggregator/I I cloudI I Deaggregator/I IHostI
I I I RSVP Proxy I I I I RSVP Proxy I I I
I----I I--------------I I------I I--------------I I----I
==========TE Tunnel==========>
<========= TE Tunnel==========
Path Path
------------> (1)-\ /-(i) <----------
Resv I I Resv
<------------ (2)-/ \-(ii) ------------>
Path Path
<------------ (3) (iii) ------------>
Resv Resv
------------> <------------
(1)(i) : Aggregator/Deaggregator/Proxy receives Path message,
selects the TE tunnel, performs admission control over the TE Tunnel.
(1) and (i) happens independently of each other.
(2)(ii) : Aggregator/Deaggregator/Proxy generates the Resv message
towards Host. (2) is triggered by (1) and (ii) is triggered by (i).
Before generating this Resv message, the Aggregator/Proxy performs
admission control of the corresponding reservation over the TE tunnel
that will eventually carry the corresponding traffic.
(3)(iii) : Aggregator/Deaggregator/Proxy generates the Path message
towards Host for reservation in return direction. The actual trigger
for this depends on the actual RSVP proxy solution. As an example,
(3) and (iii) may simply be triggered respectively by (1) and (i).
Note that the details of the signaling flow may vary slightly
depending on the actual approach used for RSVP Proxy. For example, if
the [L-RSVP] approach was used instead of [RSVP-PROXY], an additional
PathRequest message would be needed from host to
Aggregator/Deaggregator/Proxy in order to trigger the generation of
the Path message for return direction.
But regardless of the details of the call flow and of the actual RSVP
Proxy approach, RSVP proxy may optionally be deployed in combination
with RSVP Aggregation over MPLS TE Tunnels, in such a way which
ensures (when used on both the Host-Aggregator and Deaggregator-Host
sides, and when both end systems support RSVP) that:
(i) admission control and resource reservation is performed on
every segment of the end-to-end path (i.e. between source
host and Aggregator, over the TE Tunnel between the
Aggregator and Deaggregator which itself has been subject
to admission control by MPLS TE, between Deaggregator and
destination host)
(ii) this is achieved in both direction
(iii) RSVP signaling is localized between hosts and
Aggregator/Deaggregator, which may result in significant
reduction in reservation establishment delays (and in turn
in post dial delay in the case where these reservations
are pre-conditions for voice call establishment),
particularly in the case where the MPLS TE tunnels span
long distances with high propagation delays.
Appendix B - Example Usage of RSVP Aggregation over DSTE Tunnels for
VoIP Call Admission Control (CAC) VoIP Call Admission Control (CAC)
This Appendix presents an example scenario where the mechanisms This Appendix presents an example scenario where the mechanisms
described in this document are used, in combination with other described in this document are used, in combination with other
mechanisms specified by the IETF, to achieve Call Admission Control mechanisms specified by the IETF, to achieve Call Admission Control
(CAC) of Voice over IP (VoIP) traffic over the packet core. (CAC) of Voice over IP (VoIP) traffic over the packet core.
The information is that Appendix is purely informational and The information is that Appendix is purely informational and
illustrative. illustrative.
skipping to change at page 25, line 45 skipping to change at page 26, line 9
GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For GW2 are aggregated by PE1 and PE2 over the DS-TE tunnels. For
reservations going from GW1 to GW2, PE1 serves as the reservations going from GW1 to GW2, PE1 serves as the
aggregator/head-end and PE2 serves as the de-aggregator/tail-end. For aggregator/head-end and PE2 serves as the de-aggregator/tail-end. For
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, As part of its Aggregator role, the PE router effectively performs
where applicable. As part of its Aggregator role, the PE router admission control of the bandwidth request generated by the GW onto
effectively performs admission control of the bandwidth request the resources of the corresponding DS-TE tunnel.
generated by the GW onto the resources of the corresponding DS-TE
tunnel.
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 22 skipping to change at page 27, line 26
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
agent (CCA). The INVITE message may contain a list of codecs agent (CCA). The INVITE message may contain a list of codecs
that the calling phone can support. that the calling phone can support.
- VoIP gateway GW2, chooses a compatible codec from the list and - VoIP gateway GW2, chooses a compatible codec from the list and
responds with a SIP message 183 Session Progress. responds with a SIP message 183 Session Progress.
- When GW1 receives the SIP response message and learns the codec - When GW1 receives the SIP response message with the SDP, it
to be used, it knows how much bandwidth is required for the determines how much bandwidth is required for the call.
call.
- GW1 sends an RSVP Path message to PE1, requesting bandwidth for - GW1 sends an RSVP Path message to PE1, requesting bandwidth for
the call. the call.
- GW2 also sends an RSVP Path message to PE2. - GW2 also sends an RSVP Path message to PE2.
- Assuming that the tunnel (from left to right) has sufficient - Assuming that the tunnel (from left to right) has sufficient
bandwidth, PE1 responds to GW1 with a Resv message bandwidth, PE1 responds to GW1 with a Resv message
- Again assuming the tunnel (from right to left) has sufficient - Again assuming the tunnel (from right to left) has sufficient
 End of changes. 14 change blocks. 
127 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/