Technical Summary
This document defines how one can aggregate RSVP reservations when
entering traffic engineered (TE) MPLS tunnels. The MPLS tunnel head-end
act as an aggregator and tunnels the end-to-end RSVP reservation to the
tail-end that is the deaggregator of the reservation. The aggregator is
responsible to ensure that the RSVP reservation is fulfilled through the
tunnel. The aggregator have the knowledge about the current commitment and
behavior of the MPLS TE tunnel, and are thus able to grant or deny further
requests for resource from the aggregate, the MPLS TE tunnel represent.
This mechanism provides benefits from both RSVP aggregation and MPLS
traffic engineering.
Working Group Summary
There is strong consensus in the WG to publish this document. It has been
reviewed by several people including expert reviewers in the WG last call.
Comments raised has been addressed.
Protocol Quality
This document has been well reviewed in the WG and comments raised has
been addressed. PROTO shepherd is James Polk. Responsible AD was Magnus
Westerlund.
Note to RFC Editor
Appendix B, Page 28:
DELETE the following text:
Our example environment relies of [SIP-RSVP] to synchronize RSVP
bandwidth reservations with SIP. For example, the RSVP bandwidth
requests may be integrated into the call setup flow as follows (See
call setup flow diagram in Figure A2):
- Caller C1 initiates a call by sending a SIP INVITE to VoIP
gateway GW1, which passes the INVITE along to the call control
agent (CCA). The INVITE message may contain a list of codecs
that the calling phone can support.
- VoIP gateway GW2, chooses a compatible codec from the list and
responds with a SIP message 183 Session Progress.
- When GW1 receives the SIP response message with the SDP, it
determines how much bandwidth is required for the call.
- GW1 sends an RSVP Path message to PE1, requesting bandwidth for
the call.
- GW2 also sends an RSVP Path message to PE2.
- Assuming that the tunnel (from left to right) has sufficient
bandwidth, PE1 responds to GW1 with a Resv message
- Again assuming the tunnel (from right to left) has sufficient
bandwidth, PE2 responds to GW2 with a Resv message
- GW2 sends a SIP 200 OK message to GW1.
- GW1 sends a SIP UPDATE message to GW2.
- Upon receiving the UPDATE, GW2 sends the INVITE to the
destination phone, which responds with SIP message 180 RINGING.
- When (and if) the called party answers, the destination phone
responds with another SIP 200 OK which completes the connection
and tells the calling party that there is now reserved
bandwidth in both directions so that conversation can begin.
Le Faucheur, et al. [Page 28]
RSVP Aggregation over MPLS TE tunnels September 2006
- RTP media streams in both directions pass through the DSTE
tunnels as they traverse the MPLS network.
Le Faucheur, et al. [Page 29]
RSVP Aggregation over MPLS TE tunnels September 2006
IP-Phone/ IP-Phone/
TA-C1 GW1 PE1 CCA PE2 GW2 TA-C2
| INVITE|(SDP1) | INVITE | INVITE | | |
|---------->|-------|---------->|------------|------->| |
| 100|TRYING | | | | |
|<----------|-------|-----------| | | |
| 183|(SDP2) | | | | |
|<----------|-------|-----------|------------|--------| |
| | PATH | | | PATH | |
| |------>| | |<-------| |
| | RESV | | | RESV | |
| |<------| | |------->| |
| | | UPDATE|(SDP3) | | |
| |-------|-----------|------------|------->| |
| | | 200 OK|(SDP4) | | |
| |<------|-----------|------------|--------| INVITE |
| | | | | |---------->|
|180 RINGING| | 180|RINGING | |180 RINGING|
|<----------|<------|-----------|------------|--------|<----------|
| 200 OK | 200|OK | 200|OK | 200 OK |
|<----------|<------|-----------|<-----------|--------|<----------|
| | | | | | |
| | | DSTE|TUNNEL | | |
| RTP|MEDIA |-----------|------------| | |
|===========|=======|===========|============|========|==========>|
| | |-----------|------------| | |
| | | | | | |
| | |-----------|------------| | |
|<==========|=======|===========|============|========|===========|
| | |-----------|------------| | |
DSTE TUNNEL
Figure A2. VoIP QoS CAC using SIP with Preconditions