The IESG has approved the following document: - 'Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels ' <draft-ietf-tsvwg-rsvp-dste-05.txt> as a Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-dste-05.txt 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 _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
