doc: Add RFC documents

1 files changed, 2523 insertions, 0 deletions

diff --git a/doc/rfc/rfc4094.txt b/doc/rfc/rfc4094.txt
new file mode 100644
index 0000000..aa40abd
--- /dev/null
+++ b/doc/rfc/rfc4094.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Network Working Group                                          J. Manner
+Request for Comments: 4094                                         X. Fu
+Category: Informational                                         May 2005
+
+
+      Analysis of Existing Quality-of-Service Signaling Protocols
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document reviews some of the existing Quality of Service (QoS)
+   signaling protocols for an IP network.  The goal here is to learn
+   from them and to avoid common misconceptions.  Further, we need to
+   avoid mistakes during the design and implementation of any new
+   protocol in this area.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. RSVP and RSVP Extensions ........................................4
+      2.1. Basic Design ...............................................4
+           2.1.1. Signaling Model .....................................4
+           2.1.2. Soft State ..........................................5
+           2.1.3. Two-Pass Signaling Message Exchanges ................5
+           2.1.4. Receiver-Based Resource Reservation .................5
+           2.1.5. Separation of QoS Signaling from Routing ............5
+      2.2. RSVP Extensions ............................................6
+           2.2.1. Simple Tunneling ....................................6
+           2.2.2. IPsec Interface .....................................6
+           2.2.3. Policy Interface ....................................6
+           2.2.4. Refresh Reduction ...................................7
+           2.2.5. RSVP over RSVP ......................................8
+           2.2.6. IEEE 802-Style LAN Interface ........................8
+           2.2.7. ATM Interface .......................................9
+           2.2.8. DiffServ Interface ..................................9
+           2.2.9. Null Service Type ...................................9
+           2.2.10. MPLS Traffic Engineering ..........................10
+           2.2.11. GMPLS and RSVP-TE .................................11
+
+
+
+
+Manner & Fu                  Informational                      [Page 1]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+           2.2.12. GMPLS Operation at UNI and E-NNI Reference
+                   Points ............................................12
+           2.2.13. MPLS and GMPLS Future Extensions ..................12
+           2.2.14. ITU-T H.323 Interface .............................13
+           2.2.15. 3GPP Interface ....................................13
+      2.3. Extensions for New Deployment Scenarios ...................14
+      2.4. Conclusion ................................................15
+   3. RSVP Transport Mechanism Issues ................................16
+      3.1. Messaging Reliability .....................................16
+      3.2. Message Packing ...........................................17
+      3.3. MTU Problem ...............................................17
+      3.4. RSVP-TE vs. Signaling Protocol for RT Applications ........18
+      3.5. What Would Be a Better Alternative? .......................18
+   4. RSVP Protocol Performance Issues ...............................19
+      4.1. Processing Overhead .......................................19
+      4.2. Bandwidth Consumption .....................................20
+   5. RSVP Security and Mobility .....................................21
+      5.1. Security ..................................................21
+      5.2. Mobility Support ..........................................22
+   6. Other QoS Signaling Proposals ..................................23
+      6.1. Tenet and ST-II ...........................................23
+      6.2. YESSIR ....................................................24
+           6.2.1. Reservation Functionality ..........................24
+           6.2.2. Conclusion .........................................25
+      6.3. Boomerang .................................................25
+           6.3.1. Reservation Functionality ..........................25
+           6.3.2. Conclusions ........................................26
+      6.4. INSIGNIA ..................................................26
+   7. Inter-Domain Signaling .........................................27
+      7.1. BGRP ......................................................27
+      7.2. SICAP .....................................................27
+      7.3. DARIS .....................................................28
+   8. Security Considerations ........................................30
+   9. Summary ........................................................30
+   10. Contributors ..................................................31
+   11. Acknowledgements ..............................................31
+   12. Appendix A: Comparison of RSVP to the NSIS Requirements .......32
+   13. Normative References ..........................................38
+   14. Informative References ........................................38
+
+
+
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                      [Page 2]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+1.  Introduction
+
+   This document reviews some of the existing QoS signaling protocols
+   for an IP network.  The goal here is to learn from them and to avoid
+   common misconceptions.  Further, we need to avoid mistakes during the
+   design and implementation of any new protocol in this area.
+
+   There have been a number of historic attempts to deliver QoS or
+   generic signaling to the Internet.  In the early years, it was
+   believed that multicast would be popular for the majority of
+   communications; thus, both RSVP and earlier ST-II were designed in a
+   way that is multicast-oriented.
+
+   ST-II was developed as a reservation protocol for point-to-multipoint
+   communication.  However, since it is sender-initiated, it does not
+   scale with the number of receivers in a multicast group.  Its
+   processing is fairly complex.  Since every sender needs to set up its
+   own reservation, the total amount of reservation states is large.
+   RSVP was then designed to provide support for multipoint-to-
+   multipoint reservation setup in a more efficient way.  However, its
+   complexity, scalability, and ability to meet new requirements have
+   been criticized.
+
+   YESSIR (YEt another Sender Session Internet Reservations) [PS98] and
+   Boomerang [FNM+99] are examples of protocols designed after RSVP.
+   Both were meant to be simpler than RSVP.  YESSIR is an extension to
+   RTCP, whereas Boomerang is used with ICMP.
+
+   Previously, a lot of work has been targeted at creating a new
+   signaling protocol for resource control.  Istvan Cselenyi suggested
+   having a QoSSIG BOF in IETF47, for identifying problems in QoS
+   signaling, but failed to get enough support [URL1].  Some people
+   argued, "in many ways, RSVP improved upon ST-2, and it did start out
+   simpler, but it resulted in a design with complexity and
+   scalability", while others thought that "new knowledge and
+   requirements" made RSVP insufficient.  Some concluded that there is
+   no simpler way to handle the same problem than RSVP.
+
+   Michael Welzl organized a special session "ABR to the Internet" in
+   SCI 2001, and gathered some inputs for requesting an "ABR to the
+   Internet" BOF in IETF#51, which was intended to introduce explicit
+   rate-feedback-related mechanisms for the Internet (e2e, edge2edge).
+   This failed because of "missing community interest".
+
+   OPENSIG [URL2] has been involved in the Internet signaling for years.
+   Ping Pan initiated a SIGLITE [URL3] BOF mailing list to investigate
+   lightweight Internet signaling.  Finally, NSIS BOF was successful,
+   and the NSIS WG was formed.
+
+
+
+Manner & Fu                  Informational                      [Page 3]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   The most mature and original protocols are presented in their own
+   sections, and other QoS signaling protocols are presented in later
+   subsections.  The presented protocols are chosen based on relevance
+   to the work within NSIS.  The aim is not to review every existing
+   protocol.
+
+2.  RSVP and RSVP Extensions
+
+   RSVP (the Resource Reservation Protocol) [ZDSZ93] [RFC2205] [BEBH96]
+   has evolved from ST-II to provide end-to-end QoS signaling services
+   for application data streams.  Hosts use RSVP to request a specific
+   quality of service (QoS) from the network for particular application
+   flows.  Routers use RSVP to deliver QoS requests to all routers along
+   the data path.  RSVP also can maintain and refresh states for a
+   requested QoS application flow.
+
+   By original design, RSVP fits well into the framework of the
+   Integrated Services (IntServ) [RFC2210] [BEBH96] with certain
+   modularity and scalability.
+
+   RSVP carries QoS signaling messages through the network, visiting
+   each node along the data path.  To make a resource reservation at a
+   node, the RSVP module communicates with two local decision modules,
+   admission control and policy control.  Admission control determines
+   whether the node has sufficient available resources to supply the
+   requested QoS.  Policy control provides authorization for the QoS
+   request.  If either check fails, the RSVP module returns an error
+   notification to the application process that originated the request.
+   If both checks succeed, the RSVP module sets parameters in a packet
+   classifier and packet scheduler to obtain the desired QoS.
+
+2.1.  Basic Design
+
+   The design of RSVP distinguished itself by a number of fundamental
+   ways; particularly, soft state management, two-pass signaling message
+   exchanges, receiver-based resource reservation, and separation of QoS
+   signaling from routing.
+
+2.1.1.  Signaling Model
+
+   The RSVP signaling model is based on a special handling of multicast.
+   The sender of a multicast flow advertises the traffic characteristics
+   periodically to the receivers via "Path" messages.  Upon receipt of
+   an advertisement, a receiver may generate a "Resv" message to reserve
+   resources along the flow path from the sender.  Receiver reservations
+   may be heterogeneous.  To accommodate the multipoint-to-multipoint
+   multicast applications, RSVP was designed to support a vector of
+   reservation attributes called the "style".  A style describes whether
+
+
+
+Manner & Fu                  Informational                      [Page 4]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   all senders of a multicast group share a single reservation and which
+   receiver is applied.  The "Scope" object additionally provides the
+   explicit list of senders.
+
+2.1.2.  Soft State
+
+   Because the number of receivers in a multicast flow is likely to
+   change, and the flow of delivery paths might change during the life
+   of an application flow, RSVP takes a soft-state approach in its
+   design, creating and removing the protocol states (Path and Resv
+   states) in routers and hosts incrementally over time.  RSVP sends
+   periodic refresh messages (Path and Resv) to maintain its states and
+   to recover from occasional lost messages.  In the absence of refresh
+   messages, the RSVP states automatically time out and are deleted.
+   States may also be deleted explicitly by PathTear, PathErr with
+   Path_State_Removed flag, or ResvTear Message.
+
+2.1.3.  Two-Pass Signaling Message Exchanges
+
+   The receiver in an application flow is responsible for requesting the
+   desired QoS from the sender.  To do this, the receiver issues an RSVP
+   QoS request on behalf of the local application.  The request
+   propagates to all routers in reverse direction of the data paths
+   toward the sender.  In this process, RSVP requests might be merged,
+   resulting in a protocol that scales well when there are a large
+   number of receivers.
+
+2.1.4.  Receiver-Based Resource Reservation
+
+   Receiver-initiation is critical for RSVP to set up multicast sessions
+   with a large number of heterogeneous receivers.  A receiver initiates
+   a reservation request at a leaf of the multicast distribution tree,
+   traveling toward the sender.  Whenever a reservation is found to
+   already exist in a node in the distribution tree, the new request
+   will be merged with the existing reservation.  This could result in
+   fewer signaling operations for the RSVP nodes in the multicast tree
+   close to the sender but could introduce a restriction to receiver-
+   initiation.
+
+2.1.5.  Separation of QoS Signaling from Routing
+
+   RSVP messages follow normal IP routing.  RSVP is not a routing
+   protocol, but rather is designed to operate with current and future
+   unicast and multicast routing protocols.  The routing protocols are
+   responsible for choosing the routes to use to forward packets, and
+   RSVP consults local routing tables to obtain routes.  RSVP is
+   responsible only for reservation setup along a data path.
+
+
+
+
+Manner & Fu                  Informational                      [Page 5]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   A number of messages and objects have been defined for the protocol.
+   A detailed description is given in [RFC2205].
+
+2.2.  RSVP Extensions
+
+   RSVP [RFC2205] was originally designed to support real-time
+   applications over the Internet.  Over the past several years, the
+   demand for multicast-capable real-time teleconferencing, which many
+   people had envisioned to be one of the key Internet applications that
+   could benefit from network-wide deployment of RSVP, has never
+   materialized.  Instead, RSVP-TE [RFC3209], a RSVP extension for
+   traffic engineering, has been widely deployed by a large number of
+   network providers to support MPLS applications.
+
+   There are a large number of protocol extensions based on RSVP.  Some
+   provide additional features, such as security and scalability, to the
+   original protocol.  Some introduce additional interfaces to other
+   services, such as DiffServ.  And some simply define new applications,
+   such as MPLS and GMPLS, that are completely irrelevant from
+   protocol's original intent.
+
+   In this section, we list only IETF-based RFCs and a limited set of
+   other organizations' specifications.  Informational RFCs (e.g.,
+   RFC2998 [RFC2998]) and work-in-progress I-Ds (e.g., proxy) are not
+   covered here.
+
+2.2.1.  Simple Tunneling
+
+   [RFC2746] describes an IP tunneling enhancement mechanism that allows
+   RSVP to make reservations across all IP-in-IP tunnels, basically by
+   recursively applying RSVP over the tunnel portion of the path.
+
+2.2.2.  IPsec Interface
+
+   RSVP can support IPsec on a per-address, per-protocol basis instead
+   of on a per flow basis.  [RFC2207] extends RSVP by using the IPsec
+   Security Parameter Index (SPI) in place of the UDP/TCP-like ports.
+   This introduces a new FILTER_SPEC object, which contains the IPsec
+   SPI, and a new SESSION object.
+
+2.2.3.  Policy Interface
+
+   [RFC2750] specifies the format of POLICY_DATA objects and RSVP's
+   handling of policy events.  It introduces objects that are
+   interpreted only by policy-aware nodes (PEPs) that interact with
+   policy decision points (PDPs).  Nodes that are unable to interpret
+   the POLICY_DATA objects are called policy-ignorant nodes (PINs).  The
+
+
+
+
+Manner & Fu                  Informational                      [Page 6]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   content of the POLICY_DATA object itself is protected only between
+   PEPs and therefore provides end-to-middle or middle-to-middle
+   security.
+
+   [RFC2749] specifies the usage of COPS policy services in RSVP
+   environments.  [RFC3181] specifies a preemption priority policy
+   element (PREEMPTION_PRI) for use by RSVP POLICY_DATA Object.
+   [RFC3520] describes how authorization provided by a separate protocol
+   (such as SIP) can be reused with the help of an authorization token
+   within RSVP.  The token might therefore contain either the authorized
+   information itself (e.g., QoS parameters) or a reference to those
+   values.  The token might be unprotected (which is strongly
+   discouraged) or protected based on symmetric or asymmetric
+   cryptography.  Moreover, the document describes how to provide the
+   host with encoded session authorization information as a POLICY_DATA
+   object.
+
+2.2.4.  Refresh Reduction
+
+   [RFC2961] describes mechanisms to reduce processing overhead
+   requirements of refresh messages, eliminate the state synchronization
+   latency incurred when an RSVP message is lost, and refresh state
+   without the transmission of whole refresh messages.  It defines the
+   following objects: MESSAGE_ID, MESSAGE_ID_ACK, MESSAGE_ID_NACK,
+   MESSAGE_ID LIST, MESSAGE_ID SRC_LIST, and MESSAGE_ID MCAST_LIST
+   objects.  Three new RSVP message types are defined:
+
+   1) Bundle messages consist of a bundle header followed by a body
+      consisting one or more standard RSVP messages.  Bundle messages
+      help in scaling RSVP to reduce processing overhead and bandwidth
+      consumption.
+
+   2) ACK messages carry one or more MESSAGE_ID_ACK or MESSAGE_ID_NACK
+      objects.  ACK messages are sent between neighboring RSVP nodes to
+      detect message loss and to support reliable RSVP message delivery
+      on a per-hop basis.
+
+   3) Srefresh messages carry one or more MESSAGE_ID LIST, MESSAGE_ID
+      SRC_LIST, and MESSAGE_ID MCAST_LIST objects.  They correspond to
+      Path and Resv messages that establish the states.  Srefresh
+      messages are used to refresh RSVP states without transmitting
+      standard Path or Resv messages.
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                      [Page 7]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+2.2.5.  RSVP over RSVP
+
+   [RFC3175] allows installation of one or more aggregated reservations
+   in an aggregation region; thus, the number of individual RSVP
+   sessions can be reduced.  The protocol type is swapped from RSVP to
+   RSVP-E2E-IGNORE in E2E (standard) Path, PathTear, and ResvConf
+   messages when they enter the aggregation region, and is swapped back
+   when they leave.  In addition to a new PathErr code
+   (NEW_AGGREGATE_NEEDED), three new objects are introduced:
+
+   1) SESSION object, which contains two values: the IP Address of the
+      aggregate session destination, and the Differentiated Services
+      Code Point (DSCP) that it will use on the E2E data the reservation
+      contains.
+
+   2) SENDER_TEMPLATE object, which identifies the aggregating router
+      for the aggregate reservation.
+
+   3) FILTER_SPEC object, which identifies the aggregating router for
+      the aggregate reservation, and is syntactically identical to the
+      SENDER_TEMPLATE object.
+
+   From the perspective of RSVP signaling and the handling of data
+   packets in the aggregation region, these cases are equivalent to that
+   of aggregating E2E RSVP reservations.  The only difference is that
+   E2E RSVP signaling does not take place and cannot therefore be used
+   as a trigger, so some additional knowledge is required for setting up
+   the aggregate reservation.
+
+2.2.6.  IEEE 802-Style LAN Interface
+
+   [RFC2814] introduces an RSVP LAN_NHOP address object that keeps track
+   of the next L3 hop as the PATH message traverses an L2 domain between
+   two L3 entities (RSVP PHOP and NHOP nodes).  Both layer-2 and layer-3
+   addresses are included in the LAN_NHOP; the RSVP_HOP_L2 object is
+   used to include the Layer-2 address (L2ADDR) of the previous hop,
+   complementing the L3 address information included in the RSVP_HOP
+   object (RSVP_HOP_L3 address).
+
+   To provide sufficient information for debugging or resource
+   management, RSVP diagnostic messages (DREQ and DREP) are defined in
+   [RFC2745] to collect and report RSVP state information along the path
+   from a receiver to a specific sender.
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                      [Page 8]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+2.2.7.  ATM Interface
+
+   [RFC2379] and [RFC2380] define RSVP over ATM implementation
+   guidelines and requirements to interwork with the ATM (Forum) UNI
+   3.x/4.0.  [RFC2380] states that the RSVP (control) messages and RSVP
+   associated data packets must not be sent on the same virtual circuits
+   (VCs), and that an explicit release of RSVP associated QoS VCs must
+   be performed once the VC for forwarding RSVP control messages
+   terminates.  Although a separate control VC is also possible for
+   forwarding RSVP control messages, [RFC2379] recommends creating a
+   best-effort short-cut first (if one does not exist), which can allow
+   setting up RSVP-triggered VCs to use the best-effort end-point.  (A
+   short-cut is a point-to-point VC where the two end-points are located
+   in different IP subnets.)  For data flows, the subnet senders must
+   establish all QoS VCs, and the RSVP-enabled subnet receiver must be
+   able to accept incoming QoS VCs.  RSVP must request that the
+   configurable inactivity timers of VCs be set to "infinite".  If it is
+   too complex to do this at the VC receiver, RSVP over ATM
+   implementations are required not to use an inactivity timer to clear
+   any received connections.  For dynamic QoS, the replacement of VC
+   should be done gracefully.
+
+2.2.8.  DiffServ Interface
+
+   RFC2996 [RFC2996] introduces a DCLASS Object to carry Differentiated
+   Services Code Points (DSCPs) in RSVP message objects.  If the network
+   element determines that the RSVP request is admissible to the
+   DiffServ network, one or more DSCPs corresponding to the behavior
+   aggregate are determined, and will be carried by the DCLASS Object
+   added to the RESV message upstream toward the RSVP sender.
+
+2.2.9.  Null Service Type
+
+   For some applications, service parameters are specified by the
+   network, not by the application; e.g., enterprise resource planning
+   (ERP) applications.  The Null Service [RFC2997] allows applications
+   to identify themselves to network QoS policy agents using RSVP
+   signaling, but does not require them to specify resource
+   requirements.  QoS policy agents in the network respond by applying
+   QoS policies appropriate for the application (as determined by the
+   network administrator).  The RSVP sender offers the new service type,
+   'Null Service Type', in the ADSPEC that is included with the PATH
+   message.  A new TSPEC corresponding to the new service type is added
+   to the SENDER_TSPEC.  In addition, the RSVP sender will typically
+   include with the PATH message policy objects identifying the user,
+   application and sub-flow, which will be used for network nodes to
+   manage the correspondent traffic flow.
+
+
+
+
+Manner & Fu                  Informational                      [Page 9]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+2.2.10.  MPLS Traffic Engineering
+
+   RSVP-TE [RFC3209] specifies the core extensions to RSVP for
+   establishing constraint-based explicitly routed LSPs in MPLS networks
+   using RSVP as a signaling protocol.  RSVP-TE is intended for use by
+   label switching routers (as well as hosts) to establish and maintain
+   LSP-tunnels and to reserve network resources for such LSP-tunnels.
+
+   RFC3209 defines a new Hello message (for rapid node failure
+   detection).
+
+   RFC3209 also defines new C-Types (LSP_TUNNEL_IPv4 and
+   LSP_TUNNEL_IPv6) for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC
+   objects.  Here, a session is the association of LSPs that support the
+   LSP-tunnel.  The traffic on an LSP can be classified as the set of
+   packets that are assigned the same MPLS label value at the
+   originating node of an LSP-tunnel.
+
+   The following 5 new objects are also defined:
+
+   1) EXPLICIT_ROUTE object (ERO), which is incorporated into RSVP Path
+      messages, encapsulating a concatenation of hops that constitutes
+      the explicitly routed path.  Using this object, the paths taken by
+      label-switched RSVP-MPLS flows can be pre-determined independently
+      of conventional IP routing.
+
+   2) LABEL_REQUEST object.  To establish an LSP tunnel, the sender can
+      create a Path message with a LABEL_REQUEST object.  A node that
+      sends a LABEL_REQUEST object MUST be ready to accept and correctly
+      process a LABEL object in the corresponding Resv messages.
+
+   3) LABEL object.  Each node that receives a Resv message containing a
+      LABEL object uses that label for outgoing traffic associated with
+      this LSP tunnel.
+
+   4) SESSION_ATTRIBUTE object, which can be added to Path messages to
+      aid in session identification and diagnostics.  Additional control
+      information, such as setup and holding priorities, resource
+      affinities, and local-protection, are also included in this
+      object.
+
+   5) RECORD_ROUTE object (RRO).  The RECORD_ROUTE object may appear in
+      both Path and Resv messages.  It is used to collect detailed path
+      information and is useful for loop detection and for diagnostics.
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 10]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   Section 5 of [RFC3270] further specifies the extensions to RSVP to
+   establish LSPs supporting DiffServ in MPLS networks, introducing a
+   new DIFFSERV Object (applicable in the Path messages), and using
+   pre-configured or signaled "EXP<-->PHB mapping" (e.g., [RFC3270]).
+
+   RSVP-TE provides a way to indicate an unnumbered link in its Explicit
+   Route and Record Route Objects through [RFC3477].  This specifies the
+   following extensions:
+
+   - An Unnumbered Interface ID Subobject, which is a subobject of the
+     Explicit Route Object (ERO) used to specify unnumbered links.
+
+   - An LSP_TUNNEL_INTERFACE_ID Object, to allow the adjacent LSR to
+     form or use an identifier for an unnumbered Forwarding Adjacency.
+
+   - A new subobject of the Record Route Object, used to record that the
+     LSP path traversed an unnumbered link.
+
+2.2.11.  GMPLS and RSVP-TE
+
+   GMPLS RSVP-TE [RFC3473] is an extension of RSVP-TE.  It enables the
+   provisioning of data-paths within networks supporting a variety of
+   switching types including packet and cell switching networks, layer
+   two networks, TDM networks, and photonic networks.
+
+   It defines the new Notify message (for general event notification),
+   which may contain notifications being sent, with respect to each
+   listed LSP, both upstream and downstream.  Notify messages can be
+   used for expedited notification of failures and other events to nodes
+   responsible for restoring failed LSPs.  A Notify message is sent
+   without the router alert option.
+
+   A number of new RSVP-TE (sub)objects are defined in GMPLS RSVP-TE for
+   general uses of MPLS:
+
+   - a Generalized Label Request Object;
+
+   - a Generalized Label Object;
+
+   - a Suggested Label Object;
+
+   - a Label Set Object (to restrict label choice);
+
+   - an Upstream_Label object (to support bidirectional LSPs);
+
+   - a Label ERO subobject;
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 11]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   - IF_ID RSVP_HOP objects (IPv4 & IPv6; to identify interfaces in
+     out-of-band signaling or in bundled links);
+
+   - IF_ID ERROR_SPEC objects (IPv4 & IPv6; to identify interfaces in
+     out-of-band signaling or in bundled links);
+
+   - an Acceptable Label Set object (to support negotiation of label
+     values in particular for bidirectional LSPs)
+
+   - a Notify Request object (may be inserted in a Path or Resv message
+     to indicate where a notification of LSP failure is to be sent)
+
+   - a Restart_Cap Object (used on Hello messages to identify recovery
+     capabilities)
+
+   - an Admin Status Object (to notify each node along the path of the
+     status of the LSP, and to control that state).
+
+2.2.12.  GMPLS Operation at UNI and E-NNI Reference Points
+
+   The ITU-T defines network reference points that separate
+   administrative or operational parts of the network.  The reference
+   points are designated as:
+
+   - User to Network Interfaces (UNIs) if they lie between the user or
+     user network and the core network, or
+
+   - External Network to Network Interfaces (E-NNIs) if they lie between
+     peer networks, network domains, or subnetworks.
+
+   GMPLS is applicable to the UNI and E-NNI without further
+   modification, and no new messages, objects, or C-Types are required.
+   See [OVERLAY].
+
+2.2.13.  MPLS and GMPLS Future Extensions
+
+   At the time of writing, MPLS and GMPLS are being extended by the MPLS
+   and CCAMP Working Groups to support additional sophisticated
+   functions.  This will inevitably lead to the introduction of new
+   C-Types for existing objects, and to the requirement for new objects
+   (CNums).  It is possible that new messages will also be introduced.
+
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 12]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   Some of the key features and functions being introduced include the
+   following:
+
+   - Protection and restoration.  Features will be developed to provide
+      - end-to-end protection
+      - segment protection
+      - various protection schemes (1+1, 1:1, 1:n)
+      - support of extra traffic on backup LSPs
+   - Diverse path establishment for protection and load sharing.
+   - Establishment of point-to-multipoint paths.
+   - Inter-area and inter-AS path establishment with
+      - explicit path control
+      - bandwidth reservation
+      - path diversity
+   - Support for the requirements of Automatic Switched Optical Network
+     (ASON) signaling as defined by the ITU-T, including call and
+     connection separation.
+   - Crankback during LSP setup.
+
+2.2.14.  ITU-T H.323 Interface
+
+   ITU-T H.323 ([H.323]) recommends the IntServ resource reservation
+   procedure using RSVP.  The information as to whether an endpoint
+   supports RSVP should be conveyed during the H.245 [H.245] capability
+   exchange phase, by setting appropriate qOSMode fields.  If both
+   endpoints are RSVP-capable, when opening an H.245 logical channel, a
+   receiver port ID should be conveyed to the sender by the
+   openLogicalChannelAck message.  Only after that can a "Path - Resv -
+   ResvConf" process take place.  The timer of waiting for ResvConf
+   message will be set by the endpoint.  If this timer expires or RSVP
+   reservation fails at any point during an H.323 call, the action is up
+   to the vendor.  Once a ResvConf message is sent or received, the
+   endpoints should stop reservation timers and resume with the H.323
+   call procedures.  Only explicit release of reservations are supported
+   in [H.323].  Before sending a closeLogicalChannel message for a
+   stream, a sender should send a PathTear message if an RSVP session
+   has been previous created for that stream.  After receiving a
+   closeLogicalChannel, a receiver should send a ResvTear similarly.
+   Only the FF style is supported, even for point-to-multipoint calls.
+
+2.2.15.  3GPP Interface
+
+   Third Generation Partnership Project (3GPP) TS 23.207
+   ([3GPP-TS23207]) specifies the QoS signaling procedure with policy
+   control within the Universal Mobile Telecommunications System (UMTS)
+   end-to-end QoS architecture.  When using RSVP, the signaling source
+   and/or destination are the User Equipments (UEs, devices that allow
+   users access to network services) that locate in the Mobile
+
+
+
+Manner & Fu                  Informational                     [Page 13]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   Originating (MO) side and the Mobile Terminating (MT) side.  An RSVP
+   signaling process can either trigger or be triggered by the (COPS)
+   PDP Context establishment/modification process.  The operation of
+   refreshing states is not specified in [3GPP-TS23207].  If a
+   bidirectional reservation is needed, the RSVP signaling exchange must
+   be performed twice between the end-points.  The authorization token
+   and flow identifier(s) in a policy data object should be included in
+   the RSVP messages sent by the UE, if the token is available in the
+   UE.  When both RSVP and Service-based Local Policy are used, the
+   Gateway GPRS Support Node (GGSN, the access point of the network)
+   should use the policy information to decide whether to accept and
+   forward Path/Resv messages.
+
+2.3.  Extensions for New Deployment Scenarios
+
+   As a well-acknowledged protocol in the Internet, RSVP is expected
+   more and more to provide a more generic service for various signaling
+   applications.  However, RSVP messages were designed in a way to
+   support end-to-end QoS signaling optimally.  To meet the increasing
+   demand that a signaling protocol also operate in host-to-edge and
+   edge-to-edge ways, and that it serve for some other signaling
+   purposes in addition to end-to-end QoS signaling, RSVP needs to be
+   made more flexible and applicable for more generic signaling.
+
+   RSVP proxies [BEGD02] extend RSVP by originating or receiving the
+   RSVP message on behalf of the end node(s), so that applications may
+   still benefit from reservations that are not truly end-to-end.
+   However, there are certainly scenarios where an application would
+   want to explicitly convey its non-QoS purposed (as well as QoS) data
+   from a host into the network, or from an ingress node to an egress
+   node of an administrative domain.  It must do so without burdening
+   the network with excess messaging overhead.  Typical examples are an
+   end host desiring a firewall service from its provider's network and
+   MPLS label setup within an MPLS domain.
+
+   RSVP requires support from network routers and user space
+   applications.  Domains not supporting RSVP are traversed
+   transparently.  Unfortunately, like other IP options, RSVP messages
+   implemented by way of IP alert option may be dropped by some routers
+   [FJ02].  Although applications need to be built with RSVP libraries,
+   one article presents a mechanism that would allow any host to benefit
+   from RSVP mechanisms without applications' awareness [MHS02].
+
+   A somewhat similar deployment benefit can be gained from the
+   Localized RSVP (LRSVP) [JR03] [MSK+04].  The documents present the
+   concept of local RSVP-based reservation that alone can be used to
+   trigger reservation within an access network.  In those cases, an
+   end-host may request QoS from its own access network without the
+
+
+
+Manner & Fu                  Informational                     [Page 14]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   cooperation of a correspondent node outside the access network.  This
+   would be especially helpful when the correspondent node is unaware of
+   RSVP.  A proxy node responds to the messages sent by the end host and
+   enables both upstream and downstream reservations.  Furthermore, the
+   scheme allows for faster reservation repairs following a handover by
+   triggering the proxy to assist in an RSVP local repair.
+
+   Still, in end-hosts that are low in processing power and
+   functionality, having an RSVP daemon run and take care of the
+   signaling may introduce unnecessary overhead.  One article [Kars01]
+   proposes to create a remote API so that the daemon would in fact run
+   on the end-host's default router and the end-host application would
+   send its requests to that daemon.
+
+   Another potential problem lies in the limited size of signaled data
+   due to the limitation of message size.  An RSVP message must fit
+   entirely into a single non-fragmented IP datagram.  Bundle messages
+   [RFC2961] can aggregate multiple RSVP messages within a single PDU,
+   but they still only occupy one IP datagram (i.e., approximately 64K).
+   If it exceeds the MTU, the datagram is fragmented by IP and
+   reassembled at the recipient node.
+
+2.4.  Conclusion
+
+   A good signaling protocol should be transparent to the applications.
+   RSVP has proven to be a very well designed protocol.  However, it has
+   a number of fundamental protocol design issues that require more
+   careful re-evaluation.
+
+   The design of RSVP was originally targeted at multicast applications.
+   The result has been that the message processing within nodes is
+   somewhat heavy, mainly due to flow merging.  Still, merging rules
+   should not appear in the specification as they are QoS-specific.
+
+   RSVP has a comprehensive set of filtering styles, including
+   Wildcard-Filter (WF), Fixed-Filter (FF), and Shared-Explicit (SE),
+   and is not tied to certain QoS objects.  (RSVP is not tied to IntServ
+   Guaranteed Service/Controlled Load (GS/CL) specifications.)  Objects
+   were designed to be modular, but Xspecs (TSPEC, etc.) are more or
+   less QoS-specific and should be more generalized; there is no clear
+   layering/separation between the signaled data and signaling protocol.
+
+   RSVP uses a soft state mechanism to maintain states and allows each
+   node to define its own refresh timer.  The protocol is also
+   independent of underlying routing protocols.  Still, in mobile
+   networks the movement of the mobile nodes may not properly trigger a
+   reservation refresh for the new path, and therefore a mobile node may
+   be left without a reservation up to the length of the refresh timer.
+
+
+
+Manner & Fu                  Informational                     [Page 15]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   Furthermore, RSVP does not work properly with changing end-point
+   identifiers; that is, if one of the IP addresses of a mobile node
+   changes, the filters may not be able to identify the flow that had a
+   reservation.
+
+   From the security point of view, RSVP does provide the basic building
+   blocks for deploying the protocol in various environments to protect
+   its messages from forgery and modification.  Hop-by-hop protection is
+   provided.  However, the current RSVP security mechanism does not
+   provide non-repudiation and protection against message deletion; the
+   two-way peer authentication and key management procedures are still
+   missing.
+
+   Finally, since the publication of the RSVP standard, tens of
+   extensions have emerged that allow for much wider deployment than
+   RSVP was originally designed for -- for instance, the Subnet
+   Bandwidth Manager, the NULL service type, aggregation, operation over
+   tunneling, and MPLS, as well as diagnostic messages.
+
+   Domains not supporting RSVP are traversed transparently by default.
+   Unfortunately, like other IP options, RSVP messages implemented by
+   way of IP alert option may be dropped by some routers.  Also, the
+   maximal size of RSVP message is limited.
+
+   The transport mechanisms, performance, security, and mobility issues
+   are detailed in the following sections.
+
+3.  RSVP Transport Mechanism Issues
+
+3.1.  Messaging Reliability
+
+   RSVP messages are defined as a new IP protocol (that is, a new ptype
+   in the IP header).  RSVP Path messages must be delivered end-to-end.
+   For the transit routers to intercept the Path messages, a new IP
+   Router Alert option [RFC2113] was introduced.  This design is simple
+   to implement and efficient to run.  As shown from the experiments in
+   [PS00], with minor kernel changes IP option processing introduces
+   very little overhead on a Free BSD box.
+
+   However, RSVP does not have a good message delivery mechanism.  If a
+   message is lost on the wire, the next re-transmit cycle by the
+   network would be one soft-state refresh interval later.  By default,
+   a soft-state refresh interval is 30 seconds.
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 16]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   To overcome this problem, [PS97] introduced a staged refresh timer
+   mechanism, which has been defined as a RSVP extension in [RFC2961].
+   The staged refresh timer mechanism retransmits RSVP messages until
+   the receiving node acknowledges.  It can address the reliability
+   problem in RSVP.
+
+   However, during the mechanism's implementation, a lot of effort had
+   to be spent on per-session timer maintenance, message retransmission
+   (e.g., avoid message bursts), and message sequencing.  In addition,
+   we have to make an effort to try to separate the transport functions
+   from protocol processing.  For example, if a protocol extension
+   requires a natural RSVP session time-out (such as RSVP-TE one-to-one
+   fast-reroute [FAST-REROUTE]), we have to turn off the staged refresh
+   timers.
+
+3.2.  Message Packing
+
+   According to RSVP [RFC2205], each RSVP message can only contain
+   information for one session.  In a network that has a reasonably
+   large number of RSVP sessions, this constraint imposes a heavy
+   processing burden on the routers.  Many router OSes are based on
+   UNIX.  [PS00] showed that the UNIX socket I/O processing is not very
+   sensitive to packet size.  In fact, processing small packets takes
+   almost as much CPU overhead as processing large ones.  However,
+   processing too many individual messages can easily cause congestion
+   at socket I/O interfaces.
+
+   To overcome this problem, RFC2961 introduced the message bundling
+   mechanism.  The bundling mechanism packs multiple RSVP messages
+   between two adjacent nodes into a single packet.  In one deployed
+   router platform, the bundling mechanism has improved the number of
+   RSVP sessions that a router can handle from 2,000 to over 7,000.
+
+3.3.  MTU Problem
+
+   RSVP does not support message fragmentation and reassembly at
+   protocol level.  If the size of a RSVP message is larger than the
+   link MTU, the message will be fragmented.  The routers simply cannot
+   detect and process RSVP message fragments.
+
+   There is no solution for the MTU problem.  Fortunately, at places
+   where RSVP-TE has been used, either the amount of per-session RSVP
+   data is never too large, or the link MTU is adjustable; PPP and Frame
+   Relay can always increase or decrease the MTU sizes.  For example, on
+   some routers, a Frame Relay interface can support a link MTU size up
+   to 9600 bytes.  Currently, the RSVP MTU problem is not a realistic
+   concern in MPLS networks.
+
+
+
+
+Manner & Fu                  Informational                     [Page 17]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   However, when and if RSVP is used for end-user applications, for
+   which network security is an essential and critical concern, it is
+   possible that the size of RSVP messages can be larger than the link
+   MTU.  Note that end-users will most likely have to deal with a small
+   1500-byte Ethernet MTU.
+
+3.4.  RSVP-TE vs. Signaling Protocol for RT Applications
+
+   RSVP-TE works in an environment that is different from what the
+   original RSVP has been designed for: in MPLS networks, the RSVP
+   sessions that are used to support Label-Switched Paths (LSPs) do not
+   change frequently.
+
+   In fact, the network operators typically set up the MPLS LSPs so that
+   they cannot switch too quickly.  For example, the operators often
+   regulate the Constraint-based Shortest Path First (CSPF) computation
+   interval to prevent or delay a large volume of user traffic from
+   shifting from one session to another during LSP path optimization.
+   (CSPF is a routing algorithm that operates from the network edge to
+   compute the "most" optimal routes for the LSPs.)  As a result, RSVP-
+   TE does not have to handle a large amount of "triggered" (new or
+   modified)  messages.  Most of the messages are refresh messages,
+   which can be handled by the mechanisms introduced in RFC2961.  In
+   particular, in the Summary Refresh extension [RFC2961], each RSVP
+   refresh message can be represented as a 4-byte ID.  The routers can
+   simply exchange the IDs to refresh RSVP sessions.  With the full
+   implementation of RFC2961, MPLS routers do not have any RSVP scaling
+   issue.  On one deployed router platform, it can support over 50,000
+   RSVP sessions in a stable backbone network.
+
+   On the other hand, in many of the new applications for which a
+   signaling protocol is required, the user session duration can be
+   relatively short.  The dynamics of adding/dropping user sessions
+   could introduce a large number of "triggered" messages in the
+   network.  This can clearly introduce a substantial amount of
+   processing overhead to the routers.  This is one area where a new
+   signaling protocol may be needed to reduce the processing complexity
+   in the resource reservation process.
+
+3.5.  What Would Be a Better Alternative?
+
+   A good signaling protocol should be transparent to the applications.
+   On the other hand, the design of a signaling protocol must take the
+   intended and potential applications into consideration.
+
+   With the addition of RFC2961, RSVP-TE is sufficient to support its
+   intended application, MPLS, within the backbone.  There is no
+   significant transport-layer problem that needs to be solved.
+
+
+
+Manner & Fu                  Informational                     [Page 18]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   In the last several years, a number of new applications have emerged
+   that are proposed to need IP signaling, beyond the traditional ones
+   associated with quality of service and resource allocation.  On-path
+   firewall control/NAT traversal (synergistic with the midcom design of
+   [RFC3303]) is one of these.  There are far-out applications such as
+   depositing active network code in network devices.  Next-generation
+   signaling protocols dealing with novel applications, with network
+   security requirements, and with the MTU problems described above,
+   will prevent the re-use of the existing RSVP transport mechanism.
+
+   If a new transport protocol is needed, the protocol must be able to
+   handle the following:
+
+   - reliable messaging;
+
+   - message packing;
+
+   - the MTU problem;
+
+   - small triggered message volume.
+
+4.  RSVP Protocol Performance Issues
+
+4.1.  Processing Overhead
+
+   By "processing overhead" we mean the amount of processing required to
+   handle messages belonging to a reservation session.  This is the
+   processing required in addition to the processing needed for routing
+   an (ordinary) IP packet.  The processing overhead of RSVP originates
+   from two major issues:
+
+   1) Complexity of the protocol elements.  First, RSVP itself is per-
+      flow based; thus the number of states is proportional to RSVP
+      session number.  Path and Resv states have to be maintained in
+      each RSVP router for each session (and Path state also has to
+      record the reverse route for the correspondent Resv message).
+      Second, being receiver-initiated, RSVP optimizes various merging
+      operations for multicast reservations while the Resv message is
+      processed.  To handle multicast, other mechanisms such as
+      reservation styles, scope object, and blockade state, are also
+      required to be presented in the basic protocol.  This not only
+      adds sources of failures and errors, but also complicates the
+      state machine [Fu02].  Third, the same RSVP signaling messages are
+      used not only for maintaining the state, but also for dealing with
+      recovery of signaling message loss and discovery of route change.
+      Thus, although protocol elements that represent the actual data
+      (e.g., QoS parameters) specification are separated from signaling
+      elements, the processing overhead needed for all RSVP messages is
+
+
+
+Manner & Fu                  Informational                     [Page 19]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+      not marginal.  Finally, the possible variations of the order and
+      existence of objects increases the complexity of message parsing
+      and internal message and state representation.
+
+   2) Implementation-specific Overhead.  There are two ways to send and
+      receive RSVP messages: either as "raw" IP datagrams with protocol
+      number 46, or as encapsulated UDP datagrams, which increase the
+      efficiency of RSVP processing.  Typical RSVP implementations are
+      user-space daemons interacting with the kernel; thus, state
+      management, message sending, and reception would affect the
+      efficiency of the protocol processing.  For example, in the recent
+      version of the implementation described in [KSS01], the relative
+      execution costs for the message sending/reception system calls
+      "sendto", "select", and "recvmsg" were 14-16%, 6-7%, 9-10%,
+      individually, of the total execution cost.  [KSS01] also found
+      that state (memory) management can use up to 17-18% of the total
+      execution cost, but it is possible to decrease that cost to 6-7%,
+      if appropriate action is taken to replace the standard memory
+      management with dedicated memory management for state information.
+      RSVP/routing, RSVP/policy control, and RSVP/traffic control
+      interfaces can also pose different overhead depending on
+      implementation.  For example, the RSVP/routing overhead has been
+      measured to be approximately 11-12% of the total execution cost
+      [KSS01].
+
+4.2.  Bandwidth Consumption
+
+   By "bandwidth consumption" we mean the amount of bandwidth used
+   during the lifetime of a session: to set up a reservation session, to
+   keep the session alive, and finally to close it.
+
+   RSVP messages are sent either to trigger a new reservation or to
+   refresh an existing reservation.  In standard RSVP, Path/Resv
+   messages are used for triggering and refreshing/recovering
+   reservations, identically, which results in an increased size of
+   refresh messages.  The hop-by-hop refreshment may reduce the
+   bandwidth consumption for RSVP, but could result in more sources of
+   error/failure events.  [RFC2961] presents a way to bundle standard
+   RSVP messages and reduces the refreshment redundancy by Srefresh
+   message.
+
+
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 20]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   Thus, the following formula represents the bandwidth consumption in
+   bytes for an RSVP session lasting n seconds:
+
+      F(n) = (bP + bR) + ((n/Ri) * (bP + bR)) + bPt
+
+      bP:  IP payload size of Path message
+      bR:  IP payload size of Resv message
+      bPt: IP payload size of Path Tear message
+      Ri:  refresh interval
+
+   For example, for a simple Controlled Load reservation without
+   security and identification requirements (where bP is 172 bytes, bR
+   is 92, bPt is 44 bytes, and Ri is 30 seconds), the bandwidth
+   consumption would be as follows:
+
+      F(n) = (172 + 92) + ((n/30) * (172 + 92)) + 44
+
+           = 308 + (264n/30) bytes
+
+5.  RSVP Security and Mobility
+
+5.1.  Security
+
+   To allow a process on a system to securely identify the owner and the
+   application of the communicating process (e.g., user id) and to
+   convey this information in RSVP messages (PATH or RESV) in a secure
+   manner, [RFC3182] specifies the encoding of identities as RSVP
+   POLICY_DATA Object.  However, to provide ironclad security
+   protection, cryptographic authentication combined with authorization
+   has to be provided.  Such a functionality is typically offered by
+   authentication and key exchange protocols.  Solely including a user
+   identifier is insufficient.
+
+   To provide hop-by-hop integrity and authentication of RSVP messages,
+   an RSVP message may contain an INTEGRITY object ([RFC2747]) using a
+   keyed message digest.  Since intermediate routers need to modify and
+   process the content of the signaling message, a hop-by-hop security
+   architecture based on a chain-of-trust is used.  However, with the
+   different usage of RSVP as described throughout this document and
+   with new requirements, a re-evaluation of the original assumptions
+   might be necessary.
+
+   RFC2747 provides protection against forgery and message modification.
+   However, this does not provide non-repudiation or protect against
+   message deletion.  In the current RSVP security scheme, the two-way
+   peer authentication and key management procedures are still missing.
+
+   The security issues have been well analyzed in [Tsch03].
+
+
+
+Manner & Fu                  Informational                     [Page 21]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+5.2.  Mobility Support
+
+   Two issues raise concern when a mobile node (MN) uses RSVP: the flow
+   identifier and reservation refresh.  When an MN changes locations, it
+   may need to change one of its assigned IP addresses.  An MN may have
+   an IP address by which it is reachable by nodes outside the access
+   network, and an IP address used to support local mobility management.
+   Depending on the mobility management mechanism, a handover may force
+   a change in any of these addresses.  As a consequence, the filters
+   associated with a reservation may not identify the flow anymore, and
+   the resource reservation is ineffective until a refresh with a new
+   set of filters is initialized.
+
+   The second issue relates to following the movement of a mobile node.
+   RFC2205 defines that Path messages can perform a local repair of
+   reservation paths.  When the route between the communicating end
+   hosts changes, a Path message will set the state of the reservation
+   on the new route, and a subsequent Resv message will make the
+   resource reservation.  Therefore, by sending a Resv message a host
+   cannot alone update the reservation, and thus it cannot perform a
+   local repair before a Path message has passed.  Also, in order to
+   provide fast adaptation to routing changes without the overhead of
+   short refresh periods, the local routing protocol module can notify
+   the RSVP process of route changes for particular destinations.  The
+   RSVP process should use this information to trigger a quick refresh
+   of state for these destinations, using the new route (Section 3.6,
+   [RFC2205]).  However, not all local mobility protocols affect routing
+   directly in routers (not even Mobile IP), and thus mobility may not
+   be noticed at RSVP routers.  Therefore, it may take a relatively long
+   time before a reservation is refreshed following a handover.
+
+   There have been several designs for extensions to RSVP to allow for
+   more seamless mobility.  One solution is presented in [MSK+04], in
+   which one section discusses the coupling of RSVP and the mobility
+   management mechanisms and proposes small extensions to RSVP to handle
+   the handover event better, among other things.  The extension allows
+   the mobile host to request a Path for the downstream reservation when
+   a handover has happened.
+
+   Another example is Mobile RSVP (MRSVP) [TBA01], which is an extension
+   to standard RSVP.  It is based on advance reservations, where
+   neighboring access points keep resources reserved for mobile nodes
+   moving to their coverage area.  When a mobile node requests
+   resources, the neighboring access points are checked, too, and a
+   passive reservation is done around the mobile nodes' current
+   location.
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 22]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   The problem with the various "advance reservation" schemes is that
+   they require topological information of the access network and,
+   usually, advance knowledge of the handover event.  Furthermore, the
+   way the resources reserved in advance are used in the neighboring
+   service areas is an open issue.  A good overview of these different
+   schemes can be found in [MA01].
+
+   The interactions of RSVP and Mobile IP have been well documented in
+   [Thom02].
+
+6.  Other QoS Signaling Proposals
+
+6.1.  Tenet and ST-II
+
+   Tenet and ST-II are two original QoS signaling protocols for the
+   Internet.
+
+   In the original Tenet architecture [BFM+96], the receiver sends a
+   reservation request toward the source.  Each network node along the
+   way makes the reservation.  Once the request arrives at the source,
+   the source sends another Relax message back toward to the receiver,
+   and has the option to modify the previous reservation at each node.
+
+   ST-II [RFC1819] basically works in the following way: a sender
+   originates a Connect message to a set of receivers.  Each
+   intermediate node determines the next hop subnets, and makes
+   reservations on the links going to these next hops.  Upon receiving a
+   Connect indication, a receiver must send back either an Accept or a
+   Refuse message to the sender.  In the case of an Accept, the receiver
+   may further reduce the resource request by updating the returned flow
+   specifications.
+
+   ST-II consists of two protocols: ST for the data transport and the
+   Stream Control Message Protocol (SCMP) for all control functions.
+   ST is simple and contains only a single PDU format, which is designed
+   for fast and efficient data forwarding in order to achieve low
+   communication delays.  SCMP packets are transferred within ST
+   packets.
+
+   ST-II has no built-in soft states; thus, it requires that the network
+   be responsible for correctness.  It is sender-initiated, and the
+   overhead for ST-II to handle group membership dynamics is higher than
+   that for RSVP [MESZ94].  ST-II does not provide security, but
+   [RFC1819] describes some objects related to charging.
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 23]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+6.2.  YESSIR
+
+   YESSIR (YEt another Sender Session Internet Reservations) [PS98] is a
+   resource reservation protocol that seeks to simplify the process of
+   establishing reserved flows while preserving many unique features
+   introduced in RSVP.  Simplicity is measured in terms of control
+   message processing, data packet processing, and user-level
+   flexibility.  Features such as robustness, advertising network
+   service availability, and resource sharing among multiple senders are
+   also supported in the proposal.
+
+   The proposed mechanism generates reservation requests by senders to
+   reduce the processing overhead.  It is built as an extension to the
+   Real-Time Transport Control Protocol (RTCP), taking advantage of
+   Real-Time Protocol (RTP).  YESSIR also introduces a concept called
+   partial reservation, in which, for certain types of applications, the
+   reservation requests can be passed to the next hop, even though there
+   are not enough resources on a local node.  The local node can rely on
+   optimized retries to complete the reservations.
+
+6.2.1.  Reservation Functionality
+
+   YESSIR [PS98] was designed for one-way, sender-initiated end-to-end
+   resource reservation.  It also uses soft state to maintain states.
+   It supports resource query (similar to RSVP diagnosis message),
+   advertising (similar to RSVP ADSPEC), shared reservation, partial
+   reservations, and flow merging.
+
+   To support multicast, YESSIR simplifies the reservation styles to
+   individual and shared reservation styles.  Individual reservations
+   are made separately for each sender, whereas shared reservations
+   allocate resources that can be used by all senders in an RTP session.
+   Although RSVP supports shared reservation (SE and WF styles) from the
+   receiver's direction, YESSIR handles the shared reservation style
+   from the sender's direction; thus, new receivers can re-use the
+   existing reservation of the previous sender.
+
+   It has been shown that the YESSIR one-pass reservation model has
+   better performance and lower processing cost than a regular two-way
+   signaling protocol, such as RSVP [PS98].  The bandwidth consumption
+   of YESSIR is somewhat lower than that of, for example, RSVP, because
+   it does not require additional IP and transport headers.  Bandwidth
+   consumption is limited to the extension header size.
+
+   YESSIR does not have any particular support for mobility, and the
+   security of YESSIR relies on RTP/RTCP security measures.
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 24]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+6.2.2.  Conclusion
+
+   YESSIR requires support in applications since it is an integral part
+   of RTCP.  Similarly, it requires network routers to inspect RTCP
+   packets to identify reservation requests and refreshes.  Routers
+   unaware of YESSIR forward the RTCP packets transparently.
+
+6.3.  Boomerang
+
+   Boomerang [FNM+99] is a another resource reservation protocol for IP
+   networks.  The protocol has only one message type and a single
+   signaling loop for reservation setup and teardown, and it has no
+   requirements on the far end node.  Instead, it concentrates the
+   intelligence in the Initiating Node (IN).
+
+   In addition, the Boomerang protocol allows for sender- or receiver-
+   oriented reservations and resource query.  Flows are identified with
+   the common 5-tuple, and the QoS can be specified by various means;
+   e.g., service class and bit rate.  In the initial implementation,
+   Boomerang messages are transported in ICMP ECHO/REPLY messages.
+
+6.3.1.  Reservation Functionality
+
+   Boomerang can only be used for unicast sessions; no support for
+   multicast exists.  The requested QoS can be specified with various
+   methods, and both ends of a communication session can make a
+   reservation for their transmitted flow.
+
+   The authors of Boomerang show in [FNS02] that the processing of the
+   protocol is considerably lower than that of the ISI RSVP daemon
+   implementation.  However, this is mainly due to the limited
+   functionality provided by the protocol compared to that provided by
+   RSVP.
+
+   Boomerang messages are quite short and consume a relatively low
+   amount of link bandwidth.  This is due to the limited functionality
+   of the protocol; for example, no security-specific information or
+   policy-based interaction is provided.  Being sender oriented, the
+   bandwidth consumption mostly affects the downstream direction, from
+   the sender to the receiver.
+
+   As Boomerang is sender oriented, there is no need to store backward
+   information.  This reduces the signaling required.  The rest of the
+   issues that were identified with RSVP apply with Boomerang.  No
+   security mechanism is specified for Boomerang.
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 25]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   The Boomerang protocol has deployment issues similar to those of any
+   host-network-host protocol.  It requires an implementation at both
+   communicating nodes and in routers.  Boomerang-unaware routers should
+   be able to forward Boomerang messages transparently.  Still,
+   firewalls often drop ICMP packets, making the protocol useless.
+
+6.3.2.  Conclusions
+
+   Boomerang seems to be a very lightweight protocol and efficient in
+   its own scenarios.  However, the apparent low processing overhead and
+   bandwidth consumption results from the limited functionality.  No
+   support for multicast or any security features are present, which
+   allows for a different functionality than RSVP, which the authors
+   like to compare Boomerang to.
+
+6.4.  INSIGNIA
+
+   INSIGNIA [LGZC00] is proposed as a very simple signaling mechanism
+   for supporting QoS in mobile ad-hoc networks.  It avoids the need for
+   separate signaling by carrying the QoS signaling data along with the
+   normal data in IP packets using IP packet header options.  This
+   approach, known as "in-band signaling", is proposed as more suitable
+   in the rapidly changing environment of mobile networks since the
+   signaled QoS information is not tied to a particular path.  It also
+   allows the flows to be rapidly established and, thus, is suitable for
+   short-lived and dynamic flows.
+
+   INSIGNIA aims to minimize signaling by reducing the number of
+   parameters that are provided to the network.  It assumes that real-
+   time flows may tolerate some loss, but are very delay sensitive so
+   that the only QoS information needed is the required minimum and
+   maximum bandwidth.
+
+   The INSIGNIA protocol operates at the network layer and assumes that
+   link status sensing and access schemes are provided by lower-layer
+   entities.  The usefulness of the scheme depends on the MAC layers,
+   but this is undefined, so INSIGNIA can run over any MAC layer.  The
+   protocol requires that each router maintains per-flow state.
+
+   The INSIGNIA system implicitly supports mobility.  A near-minimal
+   amount of information is exchanged with the network.  To achieve
+   this, INSIGNIA makes many assumptions about the nature of traffic
+   that a source will send.  This may also simplify admission control
+   and buffer allocation.  The system basically assumes that "real-time"
+   will be defined as a maximum delay, and the user can simply request
+   real-time service for a particular quantity of traffic.
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 26]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   After handover, data that was transmitted to the old base station can
+   be forwarded to the new base station, so no data loss should occur.
+   However, there is no way to differentiate between re-routed and new
+   traffic, so priority cannot be given to handover traffic, for
+   example.
+
+   INSIGNIA, however, (completely) lacks a security framework and does
+   not investigate how to secure signaled QoS data in an ad-hoc network,
+   where relatively weak trust or even no trust exists between the
+   participating nodes.  Therefore, authorization and charging
+   especially might be a challenge.  The security protection of in-band
+   signaling is costly since the data delivery itself experiences
+   increased latency if security processing is done hop-by-hop.  Because
+   the QoS signaling information is encoded into the flow label and
+   end-to-end addressing is used, it is very difficult to provide
+   security other than IPsec in tunnel mode.
+
+7.  Inter-Domain Signaling
+
+   This section gives a short overview of protocols designed for inter-
+   domain signaling.
+
+7.1.  BGRP
+
+   Border Gateway Reservation Protocol (BGRP) [BGRP] is a signaling
+   protocol for inter-domain aggregated resource reservation for unicast
+   traffic.  BGRP builds a sink tree for each of the stub domains.  Each
+   sink tree aggregates bandwidth reservations from all data sources in
+   the network.  BGRP maintains these aggregated reservations using soft
+   state and relies on Differentiated Services for data forwarding.
+
+   In terms of message processing load, BGRP scales state storage and
+   bandwidth.  Because backbone routers only maintain the sink tree
+   information, the total number of reservations at each router scales
+   linearly with the number of Internet domains.
+
+7.2.  SICAP
+
+   SICAP (Shared-segment Inter-domain Control Aggregation protocol)
+   [SGV03] is an inter-domain signaling solution that performs shared-
+   segment aggregation [SGV02] on the Autonomous System (AS) level in
+   order to reduce state required at Boundary Routers (BRs).  SICAP
+   performs aggregation based on path segments that different
+   reservations share.  Thus, reservations may be merged into aggregates
+   that do not necessarily extend all the way to the reservation's
+   destination.  The motivation for creating "shorter" aggregates is
+   that, on one hand, their ability to accommodate future requests more
+   easily, and, on the other hand, the minimization of aggregates
+
+
+
+Manner & Fu                  Informational                     [Page 27]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   created and consequently, the reduction of state required to manage
+   established reservations.  However, in contrast to the sink-tree
+   approach (used by BGRP [BGRP]), the shared-segment approach
+   introduces intermediate de-aggregation locations.  These are ASes
+   where aggregates may experience "re-aggregation".  At these
+   locations, routers that perform aggregation (AS egress routers) have
+   to keep track of the mapping between reservations and aggregates.
+   One possible way to do this is to keep each reservation identifier
+   and the corresponding resources stored at each aggregator.  However,
+   this solution incurs a high state penalty.  SICAP avoids this state
+   penalty by keeping track of the mapping between aggregates and
+   reservations at the level of destination domains rather than
+   explicitly map individual reservations to aggregates.  In other
+   words, SICAP maintains, per aggregate, a list of the destination
+   prefixes advertised by the destination AS an aggregate provides
+   access to.
+
+   Pan et al. show that BGRP scales well in terms of control state,
+   message processing, and bandwidth efficiency, when compared to RSVP
+   without aggregation.  However, partially given that BGRP was the
+   first approach to explore the issue of inter-domain control
+   aggregation in detail, they did not provide a comparison with other
+   aggregation protocols.
+
+   SICAP and BGRP messaging sequences are similar, and consequently,
+   these protocols attain the same signaling load.  This load is exactly
+   the same as that attained by proposals that do not perform
+   aggregation, given that SICAP and BGRP exchange messages per
+   individual reservation.  In terms of bandwidth, both protocols
+   provision aggregates with the exact bandwidth required by their
+   merged reservations.  Therefore, the major difference between SICAP
+   and BGRP is state maintained at BRs, which is significantly reduced
+   by SICAP.  We consider this to be of importance not so much for
+   offering a better-performing alternative to BGRP, but for quantifying
+   the performance improvements that might still be available in the
+   research field of control path aggregation.  Finally, to deal with
+   the possible problem of the signaling load, SICAP uses an over-
+   reservation mechanism [SGV03b], whose design took into consideration
+   a possible support for BGRP.
+
+7.3.  DARIS
+
+   Dynamic Aggregation of Reservations for Internet Services (DARIS)
+   [Bless02] [Bless04] defines an inter-domain aggregation scheme for
+   resource reservations.  Basically, it aggregates reservations along
+   Autonomous System (AS) paths (or parts thereof).  A set of
+   reservations whose data paths share a common sequence of ASes are
+   integrated into a joint reservation aggregate along that shared sub-
+
+
+
+Manner & Fu                  Informational                     [Page 28]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   path.  All entities within the aggregate, except for aggregate
+   starting and end point, can remove state information of the included
+   individual reservations, thereby saving states.  They just need to
+   hold the necessary information about the encompassing aggregate.
+   Moreover, these intermediate ASes are no longer involved in signaling
+   that is related to the aggregated reservations.  If more aggregate
+   resources are reserved than were actually required, the capacity of
+   the aggregate does not need to be adapted with every new or released
+   reservation (thereby reducing the number of message exchanges).
+
+   An aggregate between two ASes is created as soon as a threshold k is
+   exceeded that describes the active number of unidirectional
+   reservations between them.  It is, however, possible to apply
+   different aggregation triggers.  Furthermore, DARIS allows aggregates
+   to be nested hierarchically.  Therefore, the existence of shorter
+   aggregates does not prevent the creation of longer (and thus more
+   efficient) aggregates, and vice versa.  An evaluation of recent BGP
+   routing information in [Bless02] showed that 92% of all end-to-end
+   paths contain at least four ASes.  Consequently, an aggregate from
+   edge AS to edge AS can span four or more ASes, thus saving states and
+   signaling message processing in at least two ASes.
+
+   There is, however, a small chance that a reservation cannot be
+   included in a new aggregate, because it was already aggregated
+   elsewhere.  This so-called "aggregation conflict" is caused by the
+   prior removal of state information related to individual reservations
+   within intermediate ASes of the encompassing aggregate.  This may
+   also bring difficulties if reservations or aggregates are re-routed
+   between ASes.  One must be careful when considering how to define
+   sophisticated adaptation techniques for these special cases, because
+   they seem to become very complex.
+
+   The signaling protocol DMSP (Domain Manager Signaling Protocol)
+   supports aggregation by special extensions that reduce the
+   reservation setup time for more than one round-trip time in some
+   cases (e.g., if an aggregate's capacity must be increased before a
+   new reservation can be included).  Details can be found in [Bless02].
+
+   The DARIS concept was evaluated by using a simulation with a topology
+   that was derived from real BGP routing table information and
+   comprised more than 5500 ASes.  In comparison to a non-aggregated
+   scenario, the number of saved states lay in the range of one to two
+   orders of magnitude, and similar results were obtained with respect
+   to the number of signaling messages.  Though [Bless02] describes
+   DARIS in the context of distributed Domain Management entities
+   (similar to a bandwidth broker), it can be applied in a router-based
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 29]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   resource management environment, too.  This will achieve a higher
+   degree of distribution, which is beneficial for large ASes, which are
+   highly interconnected.
+
+   A general issue with aggregation is that it is not the aggregating
+   and de-aggregating ASes that profit from their initiated aggregates,
+   but all intermediate ASes within an aggregate.  Therefore, some
+   incentive for aggregate creation has to be given.  This may lead to
+   novel cost models that have to be developed for aggregation concepts
+   in the future.
+
+8.  Security Considerations
+
+   This document does not present new technology or protocols.  Thus,
+   there are no explicit security issues.  Still, individual protocols
+   include different levels of security issues and those are highlighted
+   in the relevant sections and references.
+
+9.  Summary
+
+   Supporting flow-based soft state reservations has been proven useful.
+   Still, there have been different ways to improve the performance,
+   including refresh reduction and aggregation.  However, some of the
+   main concerns with these signaling protocols are the complexity of
+   the protocol, which affects implementations and processing overhead,
+   and the security of the signaling.  Especially, a proper scheme to
+   handle authentication and authorization of QoS resource requests and
+   a framework for providing signaling message security seem to be
+   missing from most protocols.  RSVP has a mechanism to protect
+   signaling messages based on manually distributed keys and concepts
+   for authorization, but they seem to be insufficient for a dynamic and
+   mobile environment.  [Tsch03] provides more details on security
+   properties provided by RSVP.  Moreover, secure and efficient
+   signaling to and from mobile nodes has been one of the critical
+   challenges not fully met by existing protocols.
+
+   Moving QoS signaling protocols into a generic messenger can provide
+   much adoption.  It is expected that the development of future
+   protocols should learn from the lessons of existing ones.
+   Nevertheless, the tradeoffs between the expected functionality,
+   protocol complexity/performance would still be taken into account.
+   For example, RSVP uses the two-way signaling mechanism, whereas
+   YESSIR employs only one-pass signaling.  Both can be shown to out-
+   perform the other in specific carefully chosen signaling scenarios.
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 30]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+10.  Contributors
+
+   This document is part of the work done in the NSIS Working Group.
+   The document was initially written by Jukka Manner and Xiaoming Fu.
+   Since the first version, Martin Karsten has provided text about the
+   processing overhead of RSVP, and Hannes Tschofenig has provided text
+   about various security issues in the protocols.  Henning Schulzrinne
+   and Ping Pan have provided more information on RSVP transportation
+   after the second revision.  Kireeti Kompella and Adrian Farrel
+   provided a review and updates to the discussion on RSVP-TE and GMPLS.
+
+11.  Acknowledgements
+
+   We would like to acknowledge Bob Braden and Vlora Rexhepi for their
+   useful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 31]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+12.  Appendix A: Comparison of RSVP to the NSIS Requirements
+
+   This section provides a comparison of RSVP to the requirements
+   identified as part of the work in NSIS [RFC3726].  The numbering
+   follows the division in the requirements document.
+
+   5.1.  Architecture and Design Goals
+
+      5.1.1.  NSIS SHOULD Provide Availability Information on Request
+
+        RSVP itself does not support query-type of operations.  However,
+        the RSVP diagnosis messages extension [RFC2745] provides a means
+        to query resource availability.
+
+      5.1.2.  NSIS MUST Be Designed Modularly
+
+        RSVP was designed to be modular by way of TLV objects, however
+        it is regarded being lack of sufficient extensibility in various
+        kind of signalling applications.
+
+      5.1.3.  NSIS MUST Decouple Protocol and Information
+
+        RSVP is decoupled from the IntServ QoS specifications.  Still,
+        the concept of sessions in RSVP are somewhat coupled to the
+        information it carries.
+
+      5.1.4.  NSIS MUST Support Independence of Signaling and Network
+              Control Paradigm
+
+        The IntServ information carried by RSVP does not tie the QoS
+        provisioning mechanisms.
+
+      5.1.5.  NSIS SHOULD Be Able To Carry Opaque Objects
+
+        RSVP supports this.
+
+   5.2.  Signaling Flows
+
+      5.2.1.  The Placement of NSIS Initiator, Forwarder, and Responder
+              Anywhere in the Network MUST Be Allowed
+
+        Standard RSVP works only end-to-end, although the RSVP proxy
+        [BEGD02] and the Localized RSVP [MSK+04] have relaxed this
+        assumption.  RSVP relies on receiver-initiation way to perform
+        QoS reservations.
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 32]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+      5.2.2.  NSIS MUST support Path-Coupled and MAY Support Path-
+              Decoupled Signaling
+
+        Standard RSVP is path-coupled, but the Subnet Bandwidth
+        Manager (SBM) work makes RSVP somewhat path-decoupled.
+
+      5.2.3.  Concealment of Topology and Technology Information SHOULD
+              Be Possible
+
+        RSVP itself does not provide such capability.
+
+      5.2.4.  Transparent Signaling through Networks SHOULD Be Possible
+
+        RSVP messages are intercepted and evaluated in each RSVP router,
+        and thus they may not cross certain RSVP-routers unnoticed.
+        Still, the message processing rules allow unknown RSVP messages
+        to be forwarded unharmed.
+
+   5.3.  Messaging
+
+      5.3.1.  Explicit Erasure of State MUST Be Possible
+
+        Supported by the PathTear and ResvTear messages.
+
+      5.3.2.  Automatic Release of State After Failure MUST Be Possible
+
+        On error reservation states are torn down with PathTear
+        messages.
+
+      5.3.3.  NSIS SHOULD Allow for Sending Notifications Upstream
+
+        There are two notifications in RSVP, confirm of a reservation
+        set-up and tear down of reservation states as a result of
+        errors.
+
+      5.3.4.  Establishment and Refusal To Set Up State MUST Be Notified
+
+        PathErr and ResvErr messages provide refusal to set up state in
+        RSVP.
+
+      5.3.5.  NSIS MUST Allow for Local Information Exchange
+
+        RSVP NULL service type [RFC2997] provides such a feature.
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 33]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   5.4.  Control Information
+
+      5.4.1.  Mutability Information on Parameters SHOULD Be Possible
+
+        Rspec and Adspec are mutable; Tspec is (generally) end-to-end
+        not mutable.
+
+      5.4.2.  It SHOULD Be Possible To Add and Remove Local Domain
+              Information
+
+        RSVP aggregation [RFC3175] and NULL service type [RFC2997] can
+        provide such a feature.
+
+      5.4.3.  State MUST Be Addressed Independent of Flow Identification
+
+        RSVP states are tied to the flows, thus this requirement is not
+        met.
+
+      5.4.4.  Modification of Already Established State SHOULD Be
+              Seamless
+
+        Modifications of a reservation is possible with RSVP.
+
+      5.4.5.  Grouping of Signaling for Several Micro-Flows MAY Be
+              Provided
+
+        Aggregated RSVP and RFC2961 allow this.
+
+   5.5.  Performance
+
+      5.5.1.  Scalability
+
+        RSVP scales linearly to the number of reservation states.
+
+      5.5.2.  NSIS SHOULD Allow for Low Latency in Setup
+
+        Setting up an RSVP reservation takes one round-trip time and the
+        processing times are each RSVP router.
+
+      5.5.3.  NSIS MUST Allow for Low Bandwidth Consumption for the
+              Signaling Protocol
+
+        The initial reservations messages can not be compressed, but the
+        refresh interval can be adjusted to consume less bandwidth, at
+        the expense of possible inefficient resource usage.
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 34]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+      5.5.4.  NSIS SHOULD Allow To Constrain Load on Devices
+
+        See discussions on RSVP performance (section 4).
+
+      5.5.5.  NSIS SHOULD Target the Highest Possible Network
+              Utilization
+
+        This depends on the IntServ service types, Controlled Load can
+        provide better overall utilization than Guaranteed Service.
+
+   5.6.  Flexibility
+
+      5.6.1.  Flow Aggregation
+
+        Aggregated RSVP and RFC2961 allow this.
+
+      5.6.2.  Flexibility in the Placement of the NSIS
+              Initiator/Responder
+
+        RSVP allows receiver as initiator of reservations.
+
+      5.6.3.  Flexibility in the Initiation of State Change
+
+        RSVP receivers can initiate the state change during its
+        refreshment.
+
+      5.6.4.  SHOULD Support Network-Initiated State Change
+
+        As RSVP supports hop-by-hop refreshment, this is made possible.
+
+      5.6.5.  Uni / Bi-Directional State Setup
+
+        RSVP is only uni-directional.
+
+   5.7.  Security
+
+      5.7.1.  Authentication of Signaling Requests
+
+        Authentication is available in RSVP.
+
+      5.7.2.  Request Authorization
+
+        Authorization with a PDP is possible in RSVP.
+
+      5.7.3.  Integrity Protection
+
+        The INTEGRITY Object is available in RSVP.
+
+
+
+
+Manner & Fu                  Informational                     [Page 35]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+      5.7.4.  Replay Protection
+
+        The INTEGRITY Object to replay protect the content of the
+        signaling messages between two RSVP nodes.
+
+      5.7.5.  Hop-By-Hop Security
+
+        The RSVP security model works only hop-by-hop.
+
+      5.7.6.  Identity Confidentiality and Network Topology Hiding
+
+        The INTEGRITY Object can be used for this purpose.
+
+      5.7.7.  Denial-Of-Service Attacks
+
+        Challenging with RSVP.
+
+      5.7.8.  Confidentiality of Signaling Messages
+
+        Not supported by RSVP.
+
+      5.7.9. Ownership of State
+
+        Challenging with RSVP.
+
+   5.8.  Mobility
+
+      5.8.1.  Allow Efficient Service Re-Establishment After Handover
+
+        Works for upstream but may not be achieved for the downstream
+        if mobility is not noticed at the cross-over router.
+
+   5.9.  Interworking with Other Protocols and Techniques
+
+      5.9.1.  MUST Interwork with IP Tunneling
+
+        RFC 2746 discusses these issues.
+
+      5.9.2.  MUST NOT Constrain either to IPv4 or IPv6
+
+        RSVP supports both IP versions.
+
+      5.9.3.  MUST Be Independent from Charging Model
+
+        RSVP does not discuss this.
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 36]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+      5.9.4.  SHOULD Provide Hooks for AAA Protocols
+
+        COPS and RSVP work together.
+
+      5.9.5.  SHOULD Work with Seamless Handoff Protocols
+
+        Not supported by RSVP.  Still, [RFC2205] suggests that route
+        changes should be indicated to the local RSVP daemon, which can
+        then initiate state refresh.
+
+      5.9.6.  MUST Work with Traditional Routing
+
+        RSVP expects traditional routing.
+
+   5.10.  Operational
+
+      5.10.1.  Ability to Assign Transport Quality to Signaling Messages
+
+        This is a network design issue, but is possible with DiffServ.
+
+      5.10.2.  Graceful Fail Over
+
+        RSVP supports this.
+
+      5.10.3.  Graceful Handling of NSIS Entity Problems
+
+        RSVP itself does not supports this.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 37]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+13.  Normative References
+
+   [RFC3726]      Brunner, M., "Requirements for Signaling Protocols",
+                  RFC 3726, April 2004.
+
+14.  Informative References
+
+   [3GPP-TS23207] 3GPP TS 23.207 V5.6.0, End-to-end Quality of Service
+                  (QoS) Concept and Architecture, Release 5, December
+                  2002.
+
+   [BEBH96]       Braden, R., Estrin, D., Berson, S., Herzog, and D.
+                  Zappala, "The Design of the RSVP Protocol", ISI Final
+                  Technical Report, July 1996.
+
+   [BEGD02]       Y. Bernet, N. Elfassy, S. Gai, and D. Dutt, "RSVP
+                  Proxy", Work in Progress, March 2002.
+
+   [BFM+96]       A. Banerjea, D. Ferrari, B. Mah, M. Moran, D. Verma,
+                  and H.  Zhang, "The Tenet Real-Time Protocol Suite:
+                  Design, Implementation, and Experiences", IEEE/ACM
+                  Transactions on Networking, Volume 4, Issue 1,
+                  February 1996, pp. 1-10.
+
+   [BGRP]         P. Pan, E, Hahne, and H. Schulzrinne, "BGRP: A Tree-
+                  Based Aggregation Protocol for Inter-domain
+                  Reservations", Journal of Communications and Networks,
+                  Vol. 2, No. 2, June 2000, pp. 157-167.
+
+   [Bless02]      R. Bless, "Dynamic Aggregation of Reservations for
+                  Internet Services", Proceedings of the Tenth
+                  International Conference on Telecommunication Systems
+                  - Modeling and Analysis (ICTSM 10), Vol. 1, pp. 26-38,
+                  October 3-6 2002, Monterey, California, available at
+                  http://www.tm.uka.de/doc/2003/ictsm-daris-journal-
+                  crc-web.pdf.
+
+   [Bless04]      R. Bless, "Towards Scalable Management of QoS-based
+                  End-to- End Services" (PDF), Proceedings of NOMS 2004
+                  (IEEE/IFIP 2004 Network Operations and Management
+                  Symposium), April 2004, Seoul, Korea.
+
+   [FAST-REROUTE] P. Pan, G. Swallow, and A. Atlas, "Fast Reroute
+                  Extensions to RSVP-TE for LSP Tunnels", Work in
+                  Progress, January 2004.
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 38]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   [FNM+99]       G. Feher, K. Nemeth, M. Maliosz, I. Cselenyi, J.
+                  Bergkvist, D. Ahlard, T. Engborg, "Boomerang A Simple
+                  Protocol for Resource Reservation in IP Networks",
+                  IEEE RTAS, 1999.
+
+   [FNS02]        G. Feher, K. Nemeth, and I. Cselenyi, "Performance
+                  evaluation framework for IP resource reservation
+                  signalling". Performance Evaluation 48 (2002), pp.
+                  131-156.
+
+   [FJ02]         P. Fransson and A. Jonsson, "The need for an
+                  alternative to IPv4-options", in RVK (RadioVetenskap
+                  och Kommunikation), Stockholm, Sweden, pp. 162-166,
+                  June 2002.
+
+   [Fu02]         X. Fu, C. Kappler, and H. Tschofenig, "Analysis on
+                  RSVP Regarding Multicast". Technical Report No. IFI-
+                  TB-2002-001, ISSN 1611-1044, Institute for
+                  Informatics, University of Goettingen, Oct 2002.
+
+   [H.245]        ITU-T Recommendation H.245, Control Protocol for
+                  Multimedia Communication, July 2000.
+
+   [H.323]        ITU-T Recommendation H.323, Packet-based Multimedia
+                  Communications Systems, Nov. 2000.
+
+   [JR03]         Jukka Manner, Kimmo Raatikainen, "Localized QoS
+                  Management for Multimedia Applications in Wireless
+                  Access Networks". IASTED International Conference on
+                  Internet and Multimedia Systems and Applications (IMSA
+                  2003), August, 2003, pp. 193-200.
+
+   [Kars01]       M. Karsten, "Experimental Extensions to RSVP -- Remote
+                  Client and One-Pass Signalling".  IWQoS 2001,
+                  Karlsruhe, Germany, June 2001.
+
+   [KSS01]        M. Karsten, Jens Schmitt, Ralf Steinmetz,
+                  "Implementation and Evaluation of the KOM RSVP
+                  Engine", IEEE Infocom 2001.
+
+   [LGZC00]       S. Lee, A. Gahng-Seop, X. Zhang, A.
+                  Campbell,"INSIGNIA: An IP-Based Quality of Service
+                  Framework for Mobile Ad Hoc Networks".  Journal of
+                  Parallel and Distributed Computing (Academic Press),
+                  Special issue on Wireless and Mobile Computing and
+                  Communications, Vol. 60, Number 4, April, 2000, pp.
+                  374-406.
+
+
+
+
+Manner & Fu                  Informational                     [Page 39]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   [MA01]         B. Moon, and H. Aghvami, "RSVP Extensions for Real-
+                  Time Services in Wireless Mobile Networks".  IEEE
+                  Communications Magazine, December 2001, pp. 52-59.
+
+   [MESZ94]       D. Mitzel, D. Estrin, S. Shenker, and L. Zhang, "An
+                  Architectural Comparison of ST-II and RSVP", Infocom
+                  1994.
+
+   [MHS02]        Y Miao, W. Hwang, and C. Shieh, "A transparent
+                  deployment method of RSVP-aware applications on UNIX".
+                  Computer Networks, 40 (2002), pp. 45-56.
+
+   [MSK+04]       J. Manner, T. Suihko, M. Kojo, M. Liljeberg, K.
+                  Raatikainen, "Localized RSVP", Work in Progress,
+                  September 2004.
+
+   [OVERLAY]      G. Swallow, J. Drake, H. Ishimatsu, and Y. Rekhter,
+                  "GMPLS UNI: RSVP Support for the Overlay Model", Work
+                  in Progress, February 2004.
+
+   [PS97]         P. Pan and H. Schulzrinne, "Staged refresh timers for
+                  RSVP", Global Internet, Phoenix, Arizona, November
+                  1997.
+
+   [PS98]         P. Pan, and H. Schulzrinne, "YESSIR: A Simple
+                  Reservation Mechanism for the Internet". Proceedings
+                  of NOSSDAV, Cambridge, UK, July 1998.
+
+   [PS00]         P. Pan, and H. Schulzrinne, "PF_IPOPTION: A kernel
+                  extension for IP option packet processing", Technical
+                  Memorandum 10009669-02TM, Bell Labs, Lucent
+                  Technologies, Murray Hill, NJ, June 2000.
+
+   [RFC1819]      Delgrossi, L. and L. Berger, "Internet Stream Protocol
+                  Version 2 (ST2) Protocol Specification - Version
+                  ST2+", RFC 1819, August 1995.
+
+   [RFC2113]      Katz, D., "IP Router Alert Option", RFC 2113, February
+                  1997.
+
+   [RFC2205]      Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
+                  Jamin, "Resource ReSerVation Protocol (RSVP) --
+                  Version 1 Functional Specification", RFC 2205,
+                  September 1997.
+
+   [RFC2207]      Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
+                  Data Flows", RFC 2207, September 1997.
+
+
+
+
+Manner & Fu                  Informational                     [Page 40]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   [RFC2210]      Wroclawski, J., "The Use of RSVP with IETF Integrated
+                  Services", RFC 2210, September 1997.
+
+   [RFC2379]      Berger, L., "RSVP over ATM Implementation Guidelines",
+                  BCP 24, RFC 2379, August 1998.
+
+   [RFC2380]      Berger, L., "RSVP over ATM Implementation
+                  Requirements", RFC 2380, August 1998.
+
+   [RFC2745]      Terzis, A., Braden, B., Vincent, S., and L. Zhang,
+                  "RSVP Diagnostic Messages", RFC 2745, January 2000.
+
+   [RFC2746]      Terzis, A., Krawczyk, J., Wroclawski, J., and L.
+                  Zhang, "RSVP Operation Over IP Tunnels", RFC 2746,
+                  January 2000.
+
+   [RFC2747]      Baker, F., Lindell, B., and M. Talwar, "RSVP
+                  Cryptographic Authentication", RFC 2747, January 2000.
+
+   [RFC2749]      Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan,
+                  R., and A. Sastry, "COPS usage for RSVP", RFC 2749,
+                  January 2000.
+
+   [RFC2750]      Herzog, S., "RSVP Extensions for Policy Control", RFC
+                  2750, January 2000.
+
+   [RFC2814]      Yavatkar, R., Hoffman, D., Bernet, Y., Baker, F., and
+                  M. Speer, "SBM (Subnet Bandwidth Manager): A Protocol
+                  for RSVP-based Admission Control over IEEE 802-style
+                  networks", RFC 2814, May 2000.
+
+   [RFC2961]      Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi,
+                  F., and S. Molendini, "RSVP Refresh Overhead Reduction
+                  Extensions", RFC 2961, April 2001.
+
+   [RFC2996]      Bernet, Y., "Format of the RSVP DCLASS Object", RFC
+                  2996, November 2000.
+
+   [RFC2997]      Bernet, Y., Smith, A., and B. Davie, "Specification of
+                  the Null Service Type", RFC 2997, November 2000.
+
+   [RFC2998]      Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang,
+                  L., Speer, M., Braden, R., Davie, B., Wroclawski, J.,
+                  and E. Felstaine, "A Framework for Integrated Services
+                  Operation over Diffserv Networks", RFC 2998, November
+                  2000.
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 41]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   [RFC3175]      Baker, F., Iturralde, C., Le Faucheur, F., and B.
+                  Davie, "Aggregation of RSVP for IPv4 and IPv6
+                  Reservations", RFC 3175, September 2001.
+
+   [RFC3181]      Herzog, S., "Signaled Preemption Priority Policy
+                  Element", RFC 3181, October 2001
+
+   [RFC3182]      Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
+                  T., Herzog, S., and R. Hess, "Identity Representation
+                  for RSVP", RFC 3182, October 2001.
+
+   [RFC3209]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+                  V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
+                  LSP Tunnels", RFC 3209, December 2001.
+
+   [RFC3270]      Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
+                  Vaananen, P., Krishnan, R., Cheval, P., and J.
+                  Heinanen, "Multi-Protocol Label Switching (MPLS)
+                  Support of Differentiated Services", RFC 3270, May
+                  2002.
+
+   [RFC3303]      Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
+                  and A. Rayhan, "Middlebox communication architecture
+                  and framework", RFC 3303, August 2002.
+
+   [RFC3473]      Berger, L., "Generalized Multi-Protocol Label
+                  Switching (GMPLS) Signaling Resource ReserVation
+                  Protocol-Traffic Engineering (RSVP-TE) Extensions",
+                  RFC 3473, January 2003.
+
+   [RFC3477]      Kompella, K. and Y. Rekhter, "Signalling Unnumbered
+                  Links in Resource ReSerVation Protocol - Traffic
+                  Engineering (RSVP-TE)", RFC 3477, January 2003.
+
+   [RFC3520]      Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
+                  "Session Authorization Policy Element", RFC 3520,
+                  April 2003.
+
+   [SGV02]        R. Sofia, R. Guerin, and P. Veiga, "An Investigation
+                  of Inter-Domain Control Aggregation Procedures",
+                  International Conference on Networking Protocols, ICNP
+                  2002, Paris, France, November 2002.
+
+   [SGV03]        R. Sofia, R. Guerin, and P. Veiga. SICAP, a Shared-
+                  segment Inter-domain Control Aggregation Protocol.
+                  High Performance Switching and Routing, HPSR 2003,
+                  Turin, Italy, June 2003.
+
+
+
+
+Manner & Fu                  Informational                     [Page 42]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+   [SGV03b]       R. Sofia, R. Guerin, and P. Veiga. A Study of Over-
+                  reservation for Inter-Domain Control Aggregation
+                  Protocols. Technical report (short version under
+                  submission), University of Pennsylvania, May 2003,
+                  available at http://einstein.seas.upenn.edu/mnlab/
+                  publications.html.
+
+   [TBA01]        A. Talukdar, B. Badrinath, and A. Acharya, "MRSVP: A
+                  Resource Reservation Protocol for an Integrated
+                  Services Network with Mobile Hosts", Wireless
+                  Networks, vol. 7, no. 1, pp. 5-19, 2001.
+
+   [Thom02]       M. Thomas, "Analysis of Mobile IP and RSVP
+                  Interactions", Work in Progress, October 2002.
+
+   [Tsch03]       H. Tschofenig, "RSVP Security Properties", Work in
+                  Progress, February 2004.
+
+   [ZDSZ93]       L. Zhang, S. Deering, D. Estrin, and D. Zappala,
+                  "RSVP: A New Resource Reservation Protocol", IEEE
+                  Network, Volume 7, Pages 8-18, September 1993.
+
+   [URL1]         http://www.atm.tut.fi/list-archive/diffserv/thrd3.html
+
+   [URL2]         OPENSIG http://comet.columbia.edu/opensig/
+
+   [URL3]         SIGLITE http://www1.cs.columbia.edu/~pingpan/projects/
+                  siglite.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 43]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+Authors' Addresses
+
+   Jukka Manner
+   Department of Computer Science
+   University of Helsinki
+   P.O. Box 68 (Gustav Hallstrominkatu 2b)
+   FIN-00014 HELSINKI
+   Finland
+
+   Phone: +358-9-191-51298
+   Fax:   +358-9-191-51120
+   EMail: jmanner@cs.helsinki.fi
+
+
+   Xiaoming Fu
+   Institute for Informatics
+   Georg-August-University of Goettingen
+   Lotzestrasse 16-18
+   37083 Goettingen
+   Germany
+
+   Phone: +49-551-39-14411
+   Fax:   +49-551-39-14403
+   EMail: fu@cs.uni-goettingen.de
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 44]
+
+RFC 4094               Analysis of QoS Signaling                May 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Manner & Fu                  Informational                     [Page 45]
+