tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5945

 
 
 

Resource Reservation Protocol (RSVP) Proxy Approaches

Part 2 of 3, p. 9 to 34
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 9 
4.  RSVP Proxy Approaches

   This section discusses fundamental RSVP proxy approaches.

4.1.  Path-Triggered Receiver Proxy

   In this approach, it is assumed that the sender is RSVP-capable and
   takes full care of the synchronization between application
   requirements and RSVP reservations.  With this approach, the RSVP
   Receiver Proxy uses the RSVP Path messages generated by the sender as
   the cue for establishing the RSVP reservation on behalf of the
   receiver.  The RSVP Receiver Proxy is effectively acting as a slave
   making reservations (on behalf of the receiver) under the sender's
   control.  This changes somewhat the usual RSVP reservation model
   where reservations are normally controlled by receivers.  Such a
   change greatly facilitates operations in the scenario of interest
   here, which is where the receiver is not RSVP-capable.  Indeed, it
   allows the RSVP Receiver Proxy to remain application-unaware by
   taking advantage of the application awareness and RSVP awareness of
   the sender.

   With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router
   may be configured to use receipt of a regular RSVP Path message as
   the trigger for RSVP Receiver Proxy behavior.

   On receipt of the RSVP Path message, the RSVP Receiver Proxy:

   1.  establishes the RSVP Path state as per regular RSVP processing.

   2.  identifies the downstream interface towards the receiver.

   3.  sinks the Path message.

   4.  behaves as if a Resv message (whose details are discussed below)
       was received on the downstream interface.  This includes
       performing admission control on the downstream interface,
       establishing a Resv state (in case of successful admission

Top      Up      ToC       Page 10 
       control), and forwarding the Resv message upstream, sending
       periodic refreshes of the Resv message and tearing down the
       reservation if the Path state is torn down.

   In order to build the Resv message, the RSVP Receiver Proxy can take
   into account information received in the Path message.  For example,
   the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv
   message that mirrors the SENDER_TSPEC object in the received Path
   message (as an RSVP-capable receiver would typically do).

   Operation of the Path-Triggered Receiver Proxy in the case of a
   successful reservation is illustrated in Figure 3.

    |****|         ***          ***         |**********|          |----|
    | S  |---------*r*----------*r*---------| RSVP     |----------| R  |
    |****|         ***          ***         | Receiver |          |----|
                                            | Proxy    |
                                            |**********|

         ---Path---> ----Path----> ---Path---->

         <--Resv---> <---Resv----- <--Resv----

         ==================RSVP===============>

         **********************************************************>


 |****| RSVP-capable     |----| Non-RSVP-capable        ***
 | S  | Sender           | R  | Receiver                *r* regular RSVP
 |****|                  |----|                         *** router

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation

               Figure 3: Path-Triggered RSVP Receiver Proxy

   In case the reservation establishment is rejected (for example,
   because of an admission control failure on a regular RSVP router on
   the path between the RSVP-capable sender and the RSVP Receiver
   Proxy), a ResvErr message will be generated as per conventional RSVP
   operations and will travel downstream towards the RSVP Receiver
   Proxy.  While this ensures that the RSVP Receiver Proxy is aware of
   the reservation failure, conventional RSVP procedures do not cater to
   the notification of the sender of the reservation failure.  Operation
   of the Path-Triggered RSVP Receiver Proxy in the case of an admission
   control failure is illustrated in Figure 4.

Top      Up      ToC       Page 11 
    |****|         ***          ***         |**********|          |----|
    | S  |---------*r*----------*r*---------| RSVP     |----------| R  |
    |****|         ***          ***         | Receiver |          |----|
                                            | Proxy    |
                                            |**********|

         ---Path---> ----Path----> ---Path---->

                    <---Resv----- <--Resv------

                    ---ResvErr---> --ResvErr--->

         ===================RSVP===============>

         **********************************************************>


 |****| RSVP-capable     |----| Non-RSVP-capable       ***
 | S  | Sender           | R  | Receiver               *r* regular RSVP
 |****|                  |----|                        *** router

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation

         Figure 4: Path-Triggered RSVP Receiver Proxy with Failure

   Since, as explained above, in this scenario involving the RSVP
   Receiver Proxy, synchronization between an application and an RSVP
   reservation is generally performed by the sender, notifying the
   sender of reservation failure is needed.  [RFC5946] specifies RSVP
   extensions allowing such sender notification in the case of
   reservation failure in the presence of a Path-Triggered RSVP Receiver
   Proxy.

4.1.1.  Mechanisms for Maximizing the Reservation Span

   The presence in the flow path of a Path-Triggered RSVP Receiver Proxy
   (for a given flow) that strictly behaves as described previously
   would cause the Path message to be terminated and a Resv message to
   be generated towards the sender.  When the receiver is indeed not
   RSVP-capable and there is no other RSVP Receiver Proxy downstream on
   the flow path, this achieves the best achievable result of
   establishing an RSVP reservation as far downstream as the RSVP
   Receiver Proxy.

Top      Up      ToC       Page 12 
   However, if the eventual receiver was in fact RSVP-capable, it would
   be prevented from participating in RSVP signaling, since it does not
   receive any Path message.  As a result, the RSVP reservation would
   only span a subset of the path it could actually span.  A similar
   sub-optimality would exist with multiple Receiver Proxies in the path
   of the flow: the first Receiver Proxy may prevent the Path message
   from reaching the second one and therefore prevent the reservation
   from extending down to the second Receiver Proxy.

   It is desirable that, in the presence of Path-Triggered RSVP Receiver
   Proxies and of a mix of RSVP-capable and non-RSVP-capable receivers,
   the RSVP reservation spans as much of the flow path as possible.
   This can be achieved dynamically (avoiding tedious specific
   configuration), using the mechanisms described in Sections 4.1.1.1
   and 4.1.1.2.

4.1.1.1.  Dynamic Discovery of Downstream RSVP Functionality

   When generating a proxy Resv message upstream, a Receiver Proxy may
   be configured to perform dynamic discovery of downstream RSVP
   functionality.  To that end, when generating the proxy Resv message
   upstream, the Receiver Proxy forwards the Path message downstream
   instead of terminating it.  This allows an RSVP-capable receiver (or
   a downstream Receiver Proxy) to respond to the Path with an upstream
   Resv message.  On receipt of a Resv message, the Receiver Proxy
   internally converts its state from a proxied reservation to a regular
   midpoint RSVP behavior.  From then on, everything proceeds as if the
   RSVP router had behaved as a regular RSVP router at reservation
   establishment (as opposed to having behaved as an RSVP Receiver Proxy
   for that flow).

   The RSVP Receiver Proxy behavior for dynamic discovery of downstream
   RSVP functionality is illustrated in Figure 5 and is also discussed
   in Section 4.1 of [RFC5946].

Top      Up      ToC       Page 13 
      |****|         ***         |**********|   |----|
      | S  |---------*r*---------| RSVP     |---| R1 |
      |****|         ***         | Receiver |   |----|
                                 | Proxy    |
                                 |          |
                                 |          |            |****|
                                 |          |------------| R2 |
                                 |**********|            |****|

           ---Path--->  --Path--->
              (R1)        (R1)    \-------Path-->
                                  /       (R1)
           <--Resv---  <---Resv---

          ================RSVP===>

          **************************************>

           ---Path--->  --Path--->
              (R2)        (R2)    \-------------Path---->
                                  /             (R2)
           <--Resv---  <---Resv---
                                             <----Resv---

          ================RSVP===========================>

          ***********************************************>


   |****| RSVP-capable  |----| non-RSVP-capable  |****| RSVP-capable
   | S  | Sender        | R  | Receiver          | R  | Receiver
   |****|               |----|                   |****|

   ***
   *r* regular RSVP
   *** router

   (R1) = Path message contains a Session object whose destination is R1

   ***> media flow

   ==>  segment of flow path protected by RSVP reservation

       Figure 5: Dynamic Discovery of Downstream RSVP Functionality

   This dynamic discovery mechanism has the benefit that new (or
   upgraded) RSVP endpoints will automatically and seamlessly be able to
   take advantage of end-to-end reservations, without impacting the

Top      Up      ToC       Page 14 
   ability of a Receiver Proxy to proxy RSVP for other, non-RSVP-capable
   endpoints.  This mechanism also achieves the goal of automatically
   discovering the longest possible RSVP-supporting segment in a network
   with multiple Receiver Proxies along the path.  This mechanism
   dynamically adjusts to any topology and routing change.  Also, this
   mechanism dynamically handles the situation in which a receiver was
   RSVP-capable and for some reason (e.g., software downgrade) no longer
   is.  Finally, this approach requires no new RSVP protocol extensions
   and no configuration changes to the Receiver Proxy as new RSVP-
   capable endpoints come and go.

   The only identified drawbacks to this approach are:

   o  If admission control fails on the segment between the Receiver
      Proxy and the RSVP-capable receiver, the receiver will get a
      ResvErr and can take application-level signaling steps to
      terminate the call.  However, the Receiver Proxy has already sent
      a Resv upstream for this flow, so the sender will see a "false"
      reservation that is not truly end-to-end.  The actual admission
      control status will resolve itself in a short while, but the
      sender will need to roll back any permanent action (such as
      billing) that may have been taken on receipt of the phantom Resv.
      Note that if the second receiver is also a Receiver Proxy that is
      not participating in application signaling, it will convert the
      received ResvErr into a PathErr that will be received by the
      sender.

   o  If there is no RSVP-capable receiver (or other Receiver Proxy)
      downstream of the Receiver Proxy, then the Path messages sent by
      the Receiver Proxy every RSVP refresh interval (e.g., 30 seconds
      by default) will never be responded to.  However, these messages
      consume a small amount of bandwidth, and in addition would install
      some RSVP state on RSVP-capable midpoint nodes downstream of the
      first Receiver Proxy.  This is seen as a very minor sub-
      optimality.  We also observe that such resources would be consumed
      anyways if the receiver was RSVP-capable.  Still, if deemed
      necessary, to mitigate this, the Receiver Proxy can tear down any
      unanswered downstream Path state and stop sending Path messages
      for the flow (or only send them at much lower frequency) as
      further discussed in [RFC5946].

4.1.1.2.  Selective Receiver Proxy and Sender Control of Receiver Proxy

   An RSVP Receiver Proxy can be selective about the sessions that it
   terminates, based on local policy decision.  For example, an edge
   router functioning as a Receiver Proxy may behave as a proxy only for
   Path messages that are actually going to exit the domain in question,
   and not for Path messages that are transiting through it but stay

Top      Up      ToC       Page 15 
   within the domain.  As another example, the Receiver Proxy may be
   configurable to only proxy for flows addressed to a given destination
   address or destination address ranges (for which end devices are
   known to not be RSVP-capable).

   The decision to proxy a Resv for a Path may also be based on
   information signaled from the sender in the Path message.  For
   example, the sender may identify the type of application or flow in
   the Application Identity policy element ([RFC2872]) in the Path, and
   the Receiver Proxy may be configured to proxy for only certain types
   of flows.  Or, if the sender knows (for example, through application
   signaling) that the receiver is RSVP-capable, the sender can include
   an indication in a policy element to any Receiver Proxy that it ought
   not to terminate the Path (or conversely, if the receiver is known
   not to support RSVP, the sender could include an indication to
   Receiver Proxies that they ought to generate a proxy Resv message).
   The Receiver Proxy Control policy element specified in Section 4.2 of
   [RFC5946] can be used for that purpose.

4.2.  Path-Triggered Sender Proxy for Reverse Direction

   In this approach, it is assumed that one endpoint is RSVP-capable and
   takes full care of the synchronization between application
   requirements and RSVP reservations.  This endpoint is the sender for
   one flow direction (which we refer to as the "forward" direction) and
   is the receiver for the flow in the opposite direction (which we
   refer to as the "reverse" direction).

   With the Path-Triggered Sender Proxy for Reverse Direction approach,
   the RSVP proxy uses the RSVP signaling generated by the receiver (for
   the reverse direction) as the cue for initiating RSVP signaling for
   the reservation in the reverse direction.  More precisely, the RSVP
   proxy can take the creation (or maintenance or teardown) of a Path
   state by the receiver as the cue to create (or maintain or tear down,
   respectively) a Path state towards the receiver.  Thus, the RSVP
   proxy is effectively acting as a Sender Proxy for the reverse
   direction under the control of the receiver (for the reverse
   direction).  Note that this assumes a degree of symmetry, for
   example, in terms of bandwidth for the two directions of the flow (as
   is currently typical for IP telephony).

   The signaling flow for the Path-Triggered Sender Proxy for Reverse
   Direction is illustrated in Figure 6.

   Path messages generated by the receiver need to transit via the RSVP
   Sender Proxy that is on the path from the sender to the receiver.  In
   some topologies, this will always be the case: for example, where the
   sender is on a stub network hanging off the RSVP Sender Proxy or

Top      Up      ToC       Page 16 
   where there is no asymmetric routing (such that if an RSVP Sender
   Proxy is on the path from receiver to sender, then it is also on the
   path from sender to receiver).  In some topologies (such as those
   involving asymmetric routing), this may not always happen naturally.
   Measures to ensure this does happen in these topologies are outside
   the scope of this document.

    |****|         ***          ***         |**********|          |----|
    | R  |---------*r*----------*r*---------| RSVP     |----------| S  |
    |****|         ***          ***         | Sender   |          |----|
                                            | Proxy    |
                                            |**********|

         ---Path---> ----Path----> ---Path---->

         <--Path---> <---Path----- <--Path----

         ---Resv---> ----Resv----> ---Resv---->

        <================RSVP==================

        <**********************************************************


 |****| RSVP-capable       |----| Non-RSVP-capable     ***
 | R  | Receiver for       | S  | Sender for           *r* regular RSVP
 |****| reverse direction  |----| reverse direction    *** router

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation
      in reverse direction

        Figure 6: Path-Triggered Sender Proxy for Reverse Direction

   Of course, the RSVP proxy may simultaneously (and typically will)
   also act as the Path-Triggered Receiver Proxy for the forward
   direction, as defined in Section 4.1.  Such an approach is most
   useful in situations involving RSVP reservations in both directions
   for symmetric flows.  This is illustrated in Figure 7.

Top      Up      ToC       Page 17 
    |****|         ***          ***         |----------|          |----|
    |S/R |---------*r*----------*r*---------| RSVP     |----------|S/R |
    |****|         ***          ***         | Receiver |          |----|
                                            | & Sender |
                                            | Proxy    |
                                            |----------|

         ---Path---> ----Path----> ---Path---->

         <--Resv---> <---Resv----- <--Resv----

         <--Path---> <---Path----- <--Path----

         ---Resv---> ----Resv----> ---Resv---->

        ================RSVP==================>
        <================RSVP==================

        **********************************************************>
        <**********************************************************


 |****| RSVP-capable     |----| Non-RSVP-capable       ***
 |S/R | Sender and       |S/R | Sender and             *r* regular RSVP
 |****| Receiver         |----| Receiver               *** router

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation
      in forward and in reverse direction

            Figure 7: Path Triggered Receiver and Sender Proxy

   With the Path-Triggered Sender Proxy for Reverse Direction approach,
   the RSVP router may be configurable to use receipt of a regular RSVP
   Path message as the trigger for Sender Proxy for Reverse Direction
   behavior.

   On receipt of the RSVP Path message for the forward direction, the
   RSVP Sender Receiver Proxy:

   1.  sinks the Path message.

   2.  behaves as if a Path message for the reverse direction (whose
       details are discussed below) had been received by the Sender
       Proxy.  This includes establishing the corresponding Path state,
       forwarding the Path message downstream, sending periodic

Top      Up      ToC       Page 18 
       refreshes of the Path message, and tearing down the Path in the
       reverse direction when the Path state in the forward direction is
       torn down.

   In order to build the Path message for the reverse direction, the
   RSVP Sender Proxy can take into account information in the received
   Path message for the forward direction.  For example, the RSVP Sender
   Proxy may mirror the SENDER_TSPEC object in the received Path
   message.

   We observe that this approach does not require any extensions to the
   existing RSVP protocol.

   In the case where reservations are required in both directions (as
   shown in Figure 7), the RSVP-capable device simply needs to behave as
   a regular RSVP sender and RSVP receiver.  It need not be aware that
   an RSVP proxy happens to be used, and the Path message it sent for
   the forward reservation also acts as the trigger for establishment of
   the reverse reservation.  However, in the case where a reservation is
   only required in the reverse direction (as shown in Figure 6), the
   RSVP-capable device has to generate Path messages in order to trigger
   the reverse-direction reservation even if no reservation is required
   in the forward direction.  Although this is not in violation of
   [RFC2205], it may not be the default behavior of an RSVP-capable
   device and therefore may need a behavioral change specifically to
   facilitate operation of the Path-Triggered Sender Proxy for Reverse
   Direction.

4.3.  Inspection-Triggered Proxy

   In this approach, it is assumed that the RSVP proxy is on the data
   path of "packets of interest", that it can inspect such packets on
   the fly as they transit through it, and that it can infer information
   from these packets of interest to determine what RSVP reservations
   need to be established, as well as when and with what characteristics
   (possibly also using some configured information).

   One example of "packets of interest" could be application-level
   signaling.  An RSVP proxy capable of inspecting SIP signaling for a
   multimedia session or RTSP signaling for video streaming can obtain
   from such signaling information about when a multimedia session is up
   or when a video is going to be streamed.  It can also identify the
   addresses and ports of senders and receivers and can determine the
   bandwidth of the corresponding flows.  It can also determine when the
   reservation is no longer needed and tear it down.  Thus, such an RSVP
   proxy can determine all necessary information to synchronize RSVP
   reservations to application requirements.  This is illustrated in
   Figure 8.

Top      Up      ToC       Page 19 
                              |-------------|
                              | Application |
                              | Signaling   |
                              | Entity      |
                              |-------------|
                                  /   \
                                 /     \
                                /       \
        <///////////////////////         \\\\\\\\\\\\\\\\\\\\\\\\>

    |----|        |********|      ***        |********|          |----|
    | S  |--------| RSVP   |------*r*--------| RSVP   |----------| R  |
    |----|        | Proxy  |      ***        | Proxy  |          |----|
                  |********|                 |********|

                          =======RSVP=======>

         ********************************************************>


 |----| Non-RSVP-capable   |----| Non-RSVP-capable      ***
 | S  | Sender             | R  | Receiver              *r* regular RSVP
 |----|                    |----|                       *** router

 </\> application-level signaling

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation

                 Figure 8: Inspection-Triggered RSVP Proxy

   Another example of "packets of interest" could be transport control
   messages (e.g., the Real-time Transport Control Protocol (RTCP)
   [RFC3550]) traveling alongside the application flow itself (i.e.,
   media packets).  An RSVP proxy capable of detecting the transit of
   packets from a particular flow can attempt to establish a reservation
   corresponding to that flow.  Characteristics of the reservation may
   be derived by various methods such as from configuration, flow
   measurement, or a combination of those.  However, these methods
   usually come with their respective operational drawbacks:
   configuration involves an operational cost and may hinder
   introduction of new applications, and measurement is reactive so that
   accurate reservation may lag actual traffic.

   In the case of reservation failure, the Inspection-Triggered RSVP
   Proxy does not have a direct mechanism for notifying the application
   (since it is not participating itself actively in application

Top      Up      ToC       Page 20 
   signaling) so that the application is not in a position to take
   appropriate action (for example, terminate the corresponding
   session).  To mitigate this problem, the Inspection-Triggered RSVP
   Proxy may differently mark the Differentiated Services codepoint
   (DSCP) ([RFC2474]) of flows for which an RSVP reservation has been
   successfully proxied from the flows for which a reservation is not in
   place.  In some situations, the Inspection-Triggered Proxy might be
   able to modify the "packets of interest" (e.g., application signaling
   messages) to convey some hint to applications that the corresponding
   flows cannot be guaranteed by RSVP reservations.

   With the Inspection-Triggered Proxy approach, the RSVP proxy is
   effectively required to attempt to build application awareness by
   traffic inspection and then is somewhat limited in the actions it can
   take in case of reservation failure.  Depending on the "packets of
   interest" used by the RSVP proxy to trigger the reservation, there is
   a risk that the RSVP proxy will end up establishing a reservation for
   a media flow that actually never starts.  However, this can be
   mitigated by the timing out and tearing down of an unnecessary
   reservation by the RSVP proxy when no corresponding media flow is
   observed.  This flow observation and timeout approach can also be
   used to tear down reservations that were rightfully established for a
   flow but are no longer needed because the flow stopped.

   The Inspection-Triggered approach is also subject to the general
   limitations associated with data inspection.  This includes being
   impeded by encryption or tunneling, or being dependent on some
   topology constraints such as relying on the fact that both the
   packets of interest and the corresponding flow packets always transit
   through the same RSVP proxy.

   Nonetheless, this may be a useful approach in specific environments.
   Note also that this approach does not require any change to the RSVP
   protocol.

   With the Inspection-Triggered RSVP Proxy approach, the RSVP router
   may be configurable to use and interpret some specific packets of
   interest as the trigger for RSVP Receiver Proxy behavior.

   When operating off signaling traffic, the Inspection-Triggered RSVP
   Proxy may be able to detect from the signaling that the endpoint is
   capable of establishing an RSVP reservation (e.g., in the case of
   SIP, via the inspection of the [RFC3312]/[RFC4032] precondition), in
   which case it would not behave as a proxy for that endpoint.  Also,
   the Inspection-Triggered RSVP Proxy may inspect RSVP signaling, and
   if it sees RSVP signaling for the flow of interest, it can disable
   its Sender Proxy behavior for that flow (or that sender).
   Optionally, through RSVP signaling inspection, the Sender Proxy might

Top      Up      ToC       Page 21 
   also gradually "learn" (possibly with some timeout) which sender is
   RSVP-capable and which is not.  These mechanisms can facilitate
   gradual and dynamic migration from the proxy model towards the end-
   to-end RSVP model as more and more endpoints become RSVP-capable.

4.4.  STUN-Triggered Proxy

   In this approach, the RSVP proxy takes advantage of the application
   awareness provided by the Session Traversal Utilities for NAT (STUN)
   ([RFC5389]) signaling to synchronize RSVP reservations with
   application requirements.  The STUN signaling is sent from endpoint
   to endpoint.  This is illustrated in Figure 9.  In this approach, a
   STUN message triggers the RSVP proxy.


    |----|        |********|      ***        |********|          |----|
    | S  |--------| RSVP   |------*r*--------| RSVP   |----------| R  |
    |----|        | Proxy  |      ***        | Proxy  |          |----|
                  |********|                 |********|

         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>

                          =======RSVP=======>

         ********************************************************>


 |----| Non-RSVP-capable   |----| Non-RSVP-capable      ***
 | S  | Sender             | R  | Receiver              *r* regular RSVP
 |----|                    |----|                       *** router

 ^^^> STUN message flow (over same UDP ports as media flow)

 ==>  segment of flow path protected by RSVP reservation

 ***> RTP media flow

                      Figure 9: STUN-Triggered Proxy

   For unicast flows, [RFC5245] is a widely adopted approach for Network
   Address Translator (NAT) traversal.  For our purposes of triggering
   RSVP proxy behavior, we rely on the Interactive Connectivity
   Establishment (ICE) protocol's connectivity check, which is based on
   the exchange of STUN Binding Request messages between hosts to verify
   connectivity (see Section 2.2 of [RFC5245]).  The STUN message could
   also include (yet to be specified) STUN attributes to indicate
   information such as the bandwidth and application requesting the
   flow, which would allow the RSVP proxy agent to create an

Top      Up      ToC       Page 22 
   appropriately sized reservation for each flow.  Including such new
   STUN attributes in the ICE connectivity check messages would
   facilitate operation of the RSVP proxy.  To ensure RSVP reservations
   are only established when needed, the RSVP proxy needs to
   distinguish, among all the STUN messages, the ones that reflect (with
   high likelihood) an actual upcoming media flow.  This can be achieved
   by identifying the STUN messages associated with an ICE connectivity
   check.  In turn, this can be achieved through (some combination of)
   the following checks:

   o  if, as discussed above, new STUN attributes (e.g., conveying the
      flow bandwidth) are indeed defined in the future in view of
      facilitating STUN-Triggered reservations, then the presence of
      these attributes would reveal that the STUN message is part of an
      ICE connectivity check.

   o  the presence of the PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, or
      ICE-CONTROLLING attributes reveals that the STUN message is part
      of an ICE connectivity check.

   o  the RSVP proxy may wait for a STUN message containing the USE-
      CANDIDATE attribute indicating the selected ICE "path" to trigger
      reservation only for the selected "path".  This allows the RSVP
      proxy to only trigger a reservation for the "path" actually
      selected and therefore for the media flow that will actually be
      established (for example, when ICE is being used for IPv4/v6 path
      selection).

   o  the RSVP proxy configuration could contain some information
      facilitating determination of when to perform RSVP proxy
      reservation and when not to.  For example, the RSVP proxy
      configuration could contain the IP addresses of the STUN servers
      such that STUN messages to/from those addresses are known to not
      be part of an ICE connectivity check.  As another example, the
      RSVP proxy configuration could contain information identifying the
      set of Differentiated Services codepoint (DSCP) values that the
      media flows requiring reservation use, so that STUN messages not
      using one of these DSCP values are known to not be part of an ICE
      connectivity check.

   Despite these checks, there is always a potential risk that the RSVP
   proxy will end up establishing a reservation for a media flow that
   actually never starts.  However, this is limited to situations in
   which the end-systems are interested enough in establishing
   connectivity for a flow but never transmit.  Also, this can be
   mitigated by timing out and tear down of an unnecessary reservation
   by the RSVP proxy when no corresponding media flow is observed.

Top      Up      ToC       Page 23 
   The RSVP proxy agent can inform endpoints of an RSVP reservation
   failure implicitly by dropping the ICE connectivity check message or
   explicitly by sending ICMP messages back to the endpoint.  This
   allows reasonably effective synchronization between RSVP reservations
   handled by the RSVP proxies and the application running on non-RSVP-
   capable endpoints.  It also has the benefits of operating through
   NATs.

   For multicast flows (or certain kinds of unicast flows that don't or
   can't use ICE), a STUN Indication message [RFC5389] could be used to
   carry the (yet to be defined) STUN attributes mentioned earlier to
   indicate the flow bandwidth, thereby providing a benefit similar to
   the ICE connectivity check.  STUN Indication messages are not
   acknowledged by the receiver and have the same scalability as the
   underlying multicast flow.

   The corresponding extensions to ICE and STUN for such a STUN-
   Triggered RSVP Proxy approach are beyond the scope of this document.
   They may be defined in the future in a separate document.  As the
   STUN-Triggered RSVP Proxy approach uses STUN in a way (i.e., to
   trigger reservations) that is beyond its initial intended purpose,
   the potential security implications need to be considered by the
   operator.

   ICE connectivity checks are not always used for all flows.  When the
   STUN-Triggered RSVP Proxy approach is used, it can establish RSVP
   reservations for flows for which ICE connectivity is performed.
   However, the STUN-Triggered RSVP Proxy will not establish a
   reservation for flows for which an ICE connectivity check is not
   performed.  Those flows either will not benefit from an RSVP
   reservation or can benefit from an RSVP reservation established
   through other means (end-to-end RSVP, other forms of RSVP proxy).

   The STUN-Triggered approach relies on interception and inspection of
   STUN messages.  Thus, this approach may be impeded by encryption or
   tunneling.

4.5.  Application_Entity-Controlled Proxy

   In this approach, it is assumed that an entity involved in the
   application-level signaling controls an RSVP proxy that is located in
   the data path of the application flows (i.e., "on-path").  With this
   approach, the RSVP proxy does not itself attempt to determine the
   application reservation requirements.  Instead, the RSVP proxy is
   instructed by the entity participating in application-level signaling
   to establish, maintain, and tear down reservations as needed by the
   application flows.  In other words, with this approach, the solution
   for synchronizing RSVP signaling with application-level requirements

Top      Up      ToC       Page 24 
   is to rely on an application-level signaling entity that controls an
   RSVP proxy function that sits in the flow data path.  This approach
   allows control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or
   both.

   Operation of the Application_Entity-Controlled Proxy is illustrated
   in Figure 10.

                        |---------|        |---------|
               /////////|  App    |////\\\\|  App    |\\\\\\\\
              /         | Entity  |        | Entity  |        \
             /          |---------|        |---------|         \
            /               //                \\                \
           /               //                  \\                \
          /               //                    \\                \
         /               //                      \\                \
        /               //                        \\                \
    |----|          |********|      ***       |*********|         |----|
    | S  |----------|        |------*r*-------|         |---------| R  |
    |----|          | RSVP   |      ***       | RSVP    |         |----|
                    | Sender |                | Receiver|
                    | Proxy  |                | Proxy   |
                    |********|                |*********|

                            =======RSVP=======>

         ********************************************************>


 |----| Non-RSVP-capable   |----| Non-RSVP-capable      ***
 | S  | Sender             | R  | Receiver              *r* regular RSVP
 |----|                    |----|                       *** router

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation

 /\   Application signaling (e.g., SIP)

 //   RSVP proxy control interface

              Figure 10: Application_Entity-Controlled Proxy

   As an example, the Application_Entity-Controlled Proxy may be used in
   the context of SIP servers ([RFC3261]) or Session Border Controllers
   (SBCs) (see [RFC5853] for a description of SBCs) to establish RSVP
   reservations for multimedia sessions.  In that case, the application
   entity may be the signaling component of the SBC.

Top      Up      ToC       Page 25 
   This RSVP proxy approach does not require any extension to the RSVP
   protocol.  However, it relies on an RSVP proxy control interface
   allowing control of the RSVP proxy by an application signaling
   entity.  This RSVP proxy control interface is beyond the scope of
   this document.  Candidate protocols for realizing such an interface
   include the IETF Network Configuration (NETCONF) Protocol ([RFC4741],
   [RFC5277]), the Web Services protocol ([W3C]), the QoS Policy
   Information Model (QPIM) ([RFC3644]), and Diameter ([RFC3588]).  This
   interface can rely on soft states or hard states.  Clearly, when hard
   states are used, those need to be converted appropriately by the RSVP
   proxy entities into the corresponding RSVP soft states.  As an
   example, [RFC5866] is intended to allow control of RSVP proxy via
   Diameter.

   In general, the application entity is not expected to maintain
   awareness of which RSVP Receiver Proxy is on the path to which
   destination.  However, in the particular cases where it does so
   reliably, we observe that the application entity could control the
   RSVP Sender Proxy and Receiver Proxy so that aggregate RSVP
   reservations are used between those, instead of one reservation per
   flow.  For example, these aggregate reservations could be of the
   RSVP-AGGREGATE type, as specified in [RFC3175], or of the GENERIC-
   AGGREGATE type, as specified in [RFC4860].  Such aggregate
   reservations could be used so that a single reservation can be used
   for multiple (possibly all) application flows transiting via the same
   RSVP Sender Proxy and the same RSVP Receiver Proxy.

   For situations in which only the RSVP Sender Proxy has to be
   controlled by this interface, the interface may be realized through
   the simple use of RSVP itself, over a Generic Routing Encapsulation
   (GRE) tunnel from the application entity to the RSVP Sender Proxy.
   This particular case is further discussed in Section 4.5.1.  Another
   particular case of interest is where the application signaling entity
   resides on the same device as the RSVP proxy.  In that case, this
   interface may be trivially realized as an internal API.  An example
   environment based on this particular case is illustrated in
   Section 4.5.2.

   The application entity controlling the RSVP proxy (e.g., a SIP Call
   Agent) would often be aware of a number of endpoint capabilities, and
   it has to be aware of which endpoint can be best "served" by which
   RSVP proxy anyways.  So it is reasonable to assume that such an
   application is aware of whether a given endpoint is RSVP-capable or
   not.  The application may also consider the QoS preconditions and QoS
   mechanisms signaled by an endpoint as per [RFC3312]/[RFC4032] and
   [RFC5432].  The information about endpoint RSVP capability can then
   be used by the application to decide whether to trigger proxy
   behavior or not for a given endpoint.  This can facilitate gradual

Top      Up      ToC       Page 26 
   and dynamic migration from the proxy model towards the end-to-end
   RSVP model as more and more endpoints become RSVP-capable.

   In some environments, the application entities (e.g., SIP back-to-
   back user agents) that need to control the RSVP proxies would already
   be deployed independently of the use, or not, of the
   Application_Entity-Controlled Proxy approach.  In this case, the
   activation of the RSVP proxy approach should not introduce
   significant disruption in the application signaling path.  In some
   environments, additional application entities may need to be deployed
   to control the RSVP proxies.  In this case, the network operator
   needs to consider the associated risks of disruption to the
   application signaling path.

4.5.1.  Application_Entity-Controlled Sender Proxy Using "RSVP over GRE"

   This approach is simply a particular case of the more general
   Application_Entity-Controlled Proxy, but where only RSVP Sender
   Proxies need to be controlled by the application, and where RSVP is
   effectively used as the control protocol between the application-
   signaling entity and the RSVP Sender Proxy.

   In this approach, the RSVP messages (e.g., RSVP Path message) are
   effectively generated by the application entity and logically
   "tunneled" to the RSVP Sender Proxy via GRE tunneling.  This is to
   ensure that the RSVP messages follow the exact same path as the flow
   they protect (as required by RSVP operations) on the segment of the
   end-to-end path that is to be subject to RSVP reservations.

   Figure 11 illustrates such an environment.

Top      Up      ToC       Page 27 
                                |-------------|
                    ////////////| Application |\\\\\\\\\
                   /            | Entity      |         \
                  /             |-------------|          \
                 /                 /=/                    \
                /                 /=/                      \
               /                 /=/                        \
              /                 /=/                          \
             /                 /=/                            \
            /                 /=/                              \
           /                 /=/                                \
          /                 /=/                                  \
     |----|           |********|           ***                 |****|
     | S  |-----------| RSVP   |-----------*r*-----------------| R  |
     |----|           | Sender |           ***                 |****|
                      | Proxy  |
                      |********|

                              =========RSVP====================>

          *****************************************************>


  |----| non-RSVP-capable     |----| RSVP-capable       ***
  | S  | Sender               | R  | Receiver           *r* regular RSVP
  |----|                      |----|                    *** router

  ***> media flow

  ==>  segment of flow path protected by RSVP reservation

  /\    Application-level signaling

  /=/  GRE-tunneled RSVP (Path messages)

         Figure 11: Application_Entity-Controlled Sender Proxy via
                              "RSVP over GRE"

   With the Application_Entity-Controlled Sender Proxy using "RSVP Over
   GRE", the application entity:

   o  generates a Path message on behalf of the sender, corresponding to
      the reservation needed by the application, and maintains the
      corresponding Path state.  The Path message built by the
      application entity is exactly the same as would be built by the
      actual sender (if it was RSVP-capable), with one single exception,
      which is that the application entity puts its own IP address as
      the RSVP previous hop.  In particular, it is recommended that the

Top      Up      ToC       Page 28 
      source address of the Path message built by the application entity
      be set to the IP address of the sender (not of the application
      entity).  This helps ensure that, in the presence of non-RSVP
      routers and of load-balancing in the network where the load-
      balancing algorithm takes into account the source IP address, the
      Path message generated by the application entity follows the exact
      same path as the actual stream sourced by the sender.

   o  encapsulates the Path message into a GRE tunnel whose destination
      address is the RSVP Sender Proxy, i.e., an RSVP router sitting on
      the data path for the flow (and upstream of the segment that
      requires QoS guarantees via RSVP reservation).

   o  processes the corresponding received RSVP messages (including Resv
      messages) as per regular RSVP.

   o  synchronizes the RSVP reservation state with application-level
      requirements and signaling.

   Note that since the application entity encodes its own IP address as
   the previous RSVP hop inside the [RFC2205] RSVP_HOP object of the
   Path message, the RSVP router terminating the GRE tunnel naturally
   addresses all the RSVP messages traveling upstream hop-by-hop (such
   as Resv messages) to the application entity (without having to
   encapsulate those in a reverse-direction GRE tunnel towards the
   application entity).

4.5.2.  Application_Entity-Controlled Proxy via Co-Location

   This approach is simply a particular case of the more general
   Application_Entity-Controlled Proxy, but where the application entity
   is co-located with the RSVP proxy.  As an example, Session Border
   Controllers (SBCs) with on-board SIP agents could implement RSVP
   proxy functions and make use of such an approach to achieve session
   admission control over the SBC-to-SBC segment using RSVP signaling.

   Figure 12 illustrates operations of the Application_Entity-Controlled
   RSVP Proxy via co-location.

Top      Up      ToC       Page 29 
                  |---------|               |---------|
          ////////| App     |////////\\\\\\\| App     |\\\\\\\\\
         /        | Entity  |               | Entity  |         \
        /         |         |               |         |          \
    |----|        |*********|      ***      |*********|         |----|
    | S  |--------| RSVP    |------*r*------| RSVP    |---------| R  |
    |----|        | Sender  |      ***      | Receiver|         |----|
                  | Proxy   |               | Proxy   |
                  |*********|               |*********|

                           =======RSVP======>

         *******************************************************>


 |----| Non-RSVP-capable   |----| Non-RSVP-capable      ***
 | S  | Sender             | R  | Receiver              *r* regular RSVP
 |----|                    |----|                       *** router

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation

 /\   Application-level signaling

      Figure 12: Application_Entity-Controlled Proxy via Co-Location

   This RSVP proxy approach does not require any protocol extensions.
   We also observe that when multiple sessions are to be established on
   paths sharing the same RSVP Sender Proxy and the same RSVP Receiver
   Proxy, the RSVP proxies have the option to establish aggregate RSVP
   reservations (as defined in ([RFC3175] or [RFC4860]) for a group of
   sessions, instead of establishing one RSVP reservation per session.

4.6.  Policy_Server-Controlled Proxy

   In this approach, it is assumed that a policy server, which is
   located in the control plane of the network, controls an RSVP proxy
   that is located in the data path of the application flows (i.e., "on-
   path").  In turn, the policy server is triggered by an entity
   involved in the application-level signaling.  With this approach, the
   RSVP proxy does not itself attempt to determine the application
   reservation requirements, but instead is instructed by the policy
   server to establish, maintain, and tear down reservations as needed
   by the application flows.  Moreover, the entity participating in
   application-level signaling does not attempt to understand the
   specific reservation mechanism (i.e., RSVP) or the topology of the
   network layer, but instead it simply asks the policy server to

Top      Up      ToC       Page 30 
   perform (or tear down) a reservation.  In other words, with this
   approach, the solution for synchronizing RSVP signaling with
   application-level requirements is to rely on an application-level
   entity that controls a policy server that, in turn, controls an RSVP
   proxy function that sits in the flow data path.  This approach allows
   control of an RSVP Sender Proxy, an RSVP Receiver Proxy, or both.

   Operation of the Policy_Server-Controlled proxy is illustrated in
   Figure 13.

Top      Up      ToC       Page 31 
                                |---------|
                   /////////////|  App    |\\\\\\\\\\\\\\
                  /             | Entity  |              \
                 /              |---------|               \
                /                    I                     \
               /                     I                      \
              /                 |----------|                 \
             /                  |  Policy  |                  \
            /                   |  Server  |                   \
           /                    |----------|                    \
          /                    //          \\                    \
         /                    //            \\                    \
        /                    //              \\                    \
    |----|           |********|      ***     |*********|          |----|
    | S  |-----------|        |------*r*-----|         |----------| R  |
    |----|           | RSVP   |      ***     | RSVP    |          |----|
                     | Sender |              | Receiver|
                     | Proxy  |              | Proxy   |
                     |********|              |*********|

                             =====RSVP========>

        **********************************************************>


 |----| Non-RSVP-capable   |----| Non-RSVP-capable      ***
 | S  | Sender             | R  | Receiver              *r* regular RSVP
 |----|                    |----|                       *** router

 ***> media flow

 ==>  segment of flow path protected by RSVP reservation

 /\   Application signaling (e.g., SIP)

 //   RSVP proxy control interface

 I    Interface between application entity and policy server

                 Figure 13: Policy_Server-Controlled Proxy

   This RSVP proxy approach does not require any extension to the RSVP
   protocol.  However, as with the Application_Entity-Controlled Proxy
   approach presented in Figure 10, this approach relies on an RSVP
   proxy control interface allowing control of the RSVP proxy (by the
   policy server in this case).  This RSVP proxy control interface is
   beyond the scope of this document.  Considerations about candidate
   protocols for realizing such an interface can be found in

Top      Up      ToC       Page 32 
   Section 4.5.  Again, for situations in which only the RSVP Sender
   Proxy has to be controlled by this interface, the interface may be
   realized through the simple use of RSVP itself, over a GRE tunnel
   from the policy server to the RSVP Sender Proxy.  This is similar to
   what is presented in Section 4.5.1, except that the "RSVP over GRE"
   interface is used in this case by the policy server (instead of the
   application entity).

   The interface between the application entity and the policy server is
   beyond the scope of this document.

4.7.  RSVP-Signaling-Triggered Proxy

   An RSVP proxy can also be triggered and controlled through extended
   RSVP signaling from the remote end that is RSVP-capable (and supports
   these RSVP extensions for proxy control).  For example, an RSVP-
   capable sender could send a new or extended RSVP message explicitly
   requesting an RSVP proxy on the path towards the receiver to behave
   as an RSVP Receiver Proxy and also to trigger a reverse-direction
   reservation, thus also behaving as an RSVP Sender Proxy.  The new or
   extended RSVP message sent by the sender could also include
   attributes (e.g., bandwidth) for the reservations to be signaled by
   the RSVP proxy.

   The challenges in these explicit signaling schemes include the
   following:

   o  How can the nodes determine when a reservation request ought to be
      proxied and when it should not, and accordingly invoke appropriate
      signaling procedures?

   o  How does the node sending the messages explicitly triggering the
      proxy know where the proxy is located, e.g., determine an IP
      address of the proxy that should reply to the signaling?

   o  How is all the information needed by a Sender Proxy to generate a
      Path message actually communicated to the proxy?

   An example of such a mechanism is presented in [QOS-MOBILE].  This
   scheme is primarily targeted to local access network reservations
   whereby an end host can request resource reservations for both
   incoming and outgoing flows only over the access network.  This may
   be useful in environments where the access network is typically the
   bottleneck while the core is comparatively over-provisioned, as may
   be the case with a number of radio access technologies.  In this
   proposal, messages targeted to the proxy are flagged with one bit in
   all RSVP messages.  Similarly, all RSVP messages sent back by the
   proxy are also flagged.  The use of such a flag allows

Top      Up      ToC       Page 33 
   differentiating between proxied and end-to-end reservations.  For
   triggering an RSVP Receiver Proxy, the sender of the data sends a
   Path message that is marked with the mentioned flag.  The Receiver
   Proxy is located on the signaling and data path, eventually gets the
   Path message, and replies back with a Resv message.  A node triggers
   an RSVP Sender Proxy with a newly defined Path_Request message, which
   instructs the proxy to send Path messages towards the triggering
   node.  The node then replies back with a Resv.  More details can be
   found in [QOS-MOBILE].

   Such an RSVP-Signaling-Triggered Proxy approach would require RSVP
   signaling extensions (that are outside the scope of this document).
   However, it could provide more flexibility in the control of the
   proxy behavior (e.g., control of reverse reservation parameters) than
   would the Path-Triggered approaches defined in Section 4.1 and
   Section 4.2.

   Through potential corresponding protocol extensions, an RSVP-
   Signaling-Triggered Proxy approach could facilitate operation (e.g.,
   reduce or avoid the need for associated configuration) in hybrid
   environments involving both reservations established end-to-end and
   reservations established via RSVP proxies.  For example, [QOS-MOBILE]
   proposed a mechanism allowing an end-system to control whether a
   reservation can be handled by an RSVP proxy on the path, or is to be
   established end-to-end.

4.8.  Reachability Considerations

   There may be situations in which the RSVP Receiver Proxy is reachable
   by the sender, while the receiver itself is not.  In such situations,
   it is possible that the RSVP Receiver Proxy is not always aware that
   the receiver is unreachable, and consequently may accept to establish
   an RSVP reservation on behalf of that receiver.  This would result in
   unnecessary reservation establishment and unnecessary network
   resource consumption.

   This is not considered a significant practical concern for a number
   of reasons.  First, in many cases, if the receiver is not reachable
   from the sender, it will not be reachable for application signaling
   either, and so application-level session establishment will not be
   possible in the first place.  Secondly, where the receiver is
   unreachable from the sender but is reachable for application-level
   signaling (say, because session establishment is performed through an
   off-path SIP agent that uses a different logical topology to
   communicate with the receiver), then the sender may detect that the
   receiver is unreachable before attempting reservation establishment.
   This may be achieved through mechanisms such as ICE's connectivity
   check ([RFC5245]).  Finally, even if the sender does not detect that

Top      Up      ToC       Page 34 
   the receiver is unreachable before triggering the RSVP reservation
   establishment, it is very likely that the application will quickly
   realize this lack of connectivity (e.g., the human accepting the
   phone call on the receiver side will not hear the human's voice on
   the sender side) and therefore tear down the session (e.g., hang up
   the phone), which in turn will trigger RSVP reservation release.

   Nonetheless, it is recommended that network administrators consider
   the above in light of their particular environment when deploying
   RSVP proxies.

   The mirror considerations apply for situations involving an RSVP
   Sender Proxy and where the sender cannot reach the destination while
   the RSVP Sender Proxy can.



(page 34 continued on part 3)

Next RFC Part