Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5974

NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling

Pages: 102
Experimental
Part 6 of 6 – Pages 83 to 102
First   Prev   None

Top   ToC   RFC5974 - Page 83   prevText

7. Security Considerations

The security requirement for the QoS NSLP is to protect the signaling exchange for establishing QoS reservations against identified security threats. For the signaling problem as a whole, these threats have been outlined in NSIS threats [RFC4081]; the NSIS framework [RFC4080] assigns a subset of the responsibility to GIST, and the remaining threats need to be addressed by NSLPs. The main issues to be handled can be summarized as:
Top   ToC   RFC5974 - Page 84
   Authorization:

      The QoS NSLP must assure that the network is protected against
      theft-of-service by offering mechanisms to authorize the QoS
      reservation requester.  A user requesting a QoS reservation might
      want proper resource accounting and protection against spoofing
      and other security vulnerabilities that lead to denial of service
      and financial loss.  In many cases, authorization is based on the
      authenticated identity.  The authorization solution must provide
      guarantees that replay attacks are either not possible or limited
      to a certain extent.  Authorization can also be based on traits
      that enable the user to remain anonymous.  Support for user
      identity confidentiality can be accomplished.

   Message Protection:

      Signaling message content should be protected against
      modification, replay, injection, and eavesdropping while in
      transit.  Authorization information, such as authorization tokens,
      needs protection.  This type of protection at the NSLP layer is
      necessary to protect messages between NSLP nodes.

   Rate Limitation:

      QNEs should perform rate-limiting on the refresh messages that
      they send.  An attacker could send erroneous messages on purpose,
      forcing the QNE to constantly reply with an error message.
      Authentication mechanisms would help in figuring out if error
      situations should be reported to the sender, or silently ignored.
      If the sender is authenticated, the QNE should reply promptly.

   Prevention of Denial-of-Service Attacks:

      GIST and QoS NSLP nodes have finite resources (state storage,
      processing power, bandwidth).  The protocol mechanisms in this
      document try to minimize exhaustion attacks against these
      resources when performing authentication and authorization for QoS
      resources.

   To some extent, the QoS NSLP relies on the security mechanisms
   provided by GIST, which by itself relies on existing authentication
   and key exchange protocols.  Some signaling messages cannot be
   protected by GIST and hence should be used with care by the QoS NSLP.
   An API must ensure that the QoS NSLP implementation is aware of the
   underlying security mechanisms and must be able to indicate which
   degree of security is provided between two GIST peers.  If a level of
   security protection for QoS NSLP messages that is required goes
   beyond the security offered by GIST or underlying security
Top   ToC   RFC5974 - Page 85
   mechanisms, additional security mechanisms described in this document
   must be used.  Due to the different usage environments and scenarios
   where NSIS is used, it is very difficult to make general statements
   without reducing its flexibility.

7.1. Trust Relationship Model

This specification is based on a model that requires trust between neighboring NSLP nodes to establish a chain-of-trust along the QoS signaling path. The model is simple to deploy, was used in previous QoS authorization environments (such as RSVP), and seems to provide sufficiently strong security properties. We refer to this model as the New Jersey Turnpike. On the New Jersey Turnpike, motorists pick up a ticket at a toll booth when entering the highway. At the highway exit, the ticket is presented and payment is made at the toll booth for the distance driven. For QoS signaling in the Internet, this procedure is roughly similar. In most cases, the data sender is charged for transmitted data traffic where charging is provided only between neighboring entities.
Top   ToC   RFC5974 - Page 86
      +------------------+  +------------------+  +------------------+
      |          Network |  |          Network |  |          Network |
      |             X    |  |             Y    |  |             Z    |
      |                  |  |                  |  |                  |
      |              ----------->          ----------->              |
      |                  |  |                  |  |                  |
      |                  |  |                  |  |                  |
      +--------^---------+  +------------------+  +-------+----------+
               |                                          .
               |                                          .
               |                                          v
            +--+---+  Data                   Data      +--+---+
            | Node |  ==============================>  | Node |
            |  A   |  Sender                Receiver   |  B   |
            +------+                                   +------+

        Legend:

        ----> Peering relationship that allows neighboring
              networks/entities to charge each other for the
              QoS reservation and data traffic

        ====> Data flow

        .... Communication to the end host

                   Figure 16: New Jersey Turnpike Model

   The model shown in Figure 16 uses peer-to-peer relationships between
   different administrative domains as a basis for accounting and
   charging.  As mentioned above, based on the peering relationship, a
   chain-of-trust is established.  There are several issues that come to
   mind when considering this type of model:

   o  The model allows authorization on a request basis or on a per-
      session basis.  Authorization mechanisms are elaborated in
      Section 7.2.  The duration for which the QoS authorization is
      valid needs to be controlled.  Combining the interval with the
      soft-state interval is possible.  Notifications from the networks
      also seem to be a viable approach.

   o  The price for a QoS reservation needs to be determined somehow and
      communicated to the charged entity and to the network where the
      charged entity is attached.  Protocols providing "Advice of
      Charge" functionality are out of scope.
Top   ToC   RFC5974 - Page 87
   o  This architecture is simple enough to allow a scalable solution
      (ignoring reverse charging, multicast issues, and price
      distribution).

   Charging the data sender as performed in the model simplifies
   security handling by demanding only peer-to-peer security protection.
   Node A would perform authentication and key establishment.  The
   established security association (together with the session key)
   would allow the user to protect QoS signaling messages.  The identity
   used during the authentication and key establishment phase would be
   used by Network X (see Figure 16) to perform the so-called policy-
   based admission control procedure.  In our context, this user
   identifier would be used to establish the necessary infrastructure to
   provide authorization and charging.  Signaling messages later
   exchanged between the different networks are then also subject to
   authentication and authorization.  However, the authenticated entity
   is thereby the neighboring network and not the end host.

   The New Jersey Turnpike model is attractive because of its
   simplicity.  S. Shenker, et al. [shenker] discuss various accounting
   implications and introduced the edge pricing model.  The edge pricing
   model shows similarity to the model described in this section, with
   the exception that mobility and the security implications are not
   addressed.

7.2. Authorization Model Examples

Various authorization models can be used in conjunction with the QoS NSLP.

7.2.1. Authorization for the Two-Party Approach

The two-party approach (Figure 17) is conceptually the simplest authorization model. +-------------+ QoS request +--------------+ | Entity |----------------->| Entity | | requesting | | authorizing | | resource |granted / rejected| resource | | |<-----------------| request | +-------------+ +--------------+ ^ ^ +...........................+ compensation Figure 17: Two-Party Approach
Top   ToC   RFC5974 - Page 88
   In this example, the authorization decision only involves the two
   entities, or makes use of previous authorization using an out-of-band
   mechanism to avoid the need for active participation of an external
   entity during the NSIS protocol execution.

   This type of model may be applicable, e.g., between two neighboring
   networks (inter-domain signaling) where a long-term contract (or
   other out-of-band mechanisms) exists to manage charging and provides
   sufficient information to authorize individual requests.

7.2.2. Token-Based Three-Party Approach

An alternative approach makes use of tokens, such as those described in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the Open Settlement Protocol [osp]. Authorization tokens are used to associate two different signaling protocols runs (e.g., SIP and NSIS) and their authorization decision with each other. The latter is a form of assertion or trait. As an example, with the authorization token mechanism, some form of authorization is provided by the SIP proxy, which acts as the resource-authorizing entity in Figure 18. If the request is authorized, then the SIP signaling returns an authorization token that can be included in the QoS signaling protocol messages to refer to the previous authorization decision. The tokens themselves may take a number of different forms, some of which may require the entity performing the QoS reservation to query the external state.
Top   ToC   RFC5974 - Page 89
     Authorization
     Token Request   +--------------+
     +-------------->| Entity C     | financial settlement
     |               | authorizing  | <..................+
     |               | resource     |                    .
     |        +------+ request      |                    .
     |        |      +--------------+                    .
     |        |                                          .
     |        |Authorization                             .
     |        |Token                                     .
     |        |                                          .
     |        |                                          .
     |        |                                          .
     |        |      QoS request                         .
   +-------------+ + Authz. Token   +--------------+     .
   |  Entity     |----------------->| Entity B     |     .
   |  requesting |                  | performing   |     .
   |  resource   |granted / rejected| QoS          |  <..+
   |      A      |<-----------------| reservation  |
   +-------------+                  +--------------+

                Figure 18: Token-Based Three-Party Approach

   For the digital money type of systems (e.g., OSP tokens), the token
   represents a limited amount of credit.  So, new tokens must be sent
   with later refresh messages once the credit is exhausted.
Top   ToC   RFC5974 - Page 90

7.2.3. Generic Three-Party Approach

Another method is for the node performing the QoS reservation to delegate the authorization decision to a third party, as illustrated in Figure 19. The authorization decision may be performed on a per- request basis, periodically, or on a per-session basis. +--------------+ | Entity C | | authorizing | | resource | | request | +-----------+--+ ^ | QoS | | QoS authz| |authz req.| | res. QoS | v +-------------+ request +--+-----------+ | Entity |----------------->| Entity B | | requesting | | performing | | resource |granted / rejected| QoS | | A |<-----------------| reservation | +-------------+ +--------------+ Figure 19: Three-Party Approach

7.3. Computing the Authorization Decision

Whenever an authorization decision has to be made there is the question about which information serves as an input to the authorizing entity. The following information items have been mentioned in the past for computing the authorization decision (in addition to the authenticated identity): Price QoS objects Policy rules Policy rules take into consideration attributes like time of day, subscription to certain services, membership, etc., when computing an authorization decision. The policies used to make the authorization are outside the scope of this document and are implementation/deployment specific.
Top   ToC   RFC5974 - Page 91

8. Acknowledgments

The authors would like to thank Eleanor Hepworth, Ruediger Geib, Roland Bless, Nemeth Krisztian, Markus Ott, Mayi Zoumaro-Djayoon, Martijn Swanink, and Ruud Klaver for their useful comments. Roland, especially, has done deep reviews of the document, making sure the protocol is well defined. Bob Braden provided helpful comments and guidance which were gratefully received.

9. Contributors

This document combines work from three individual documents. The following authors from these documents also contributed to this document: Robert Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson), and Maarten Buechli (Dante) and Eric Waegeman (Alcatel). In addition, Roland Bless has contributed considerable amounts of text all along the writing of this specification. Sven Van den Bosch was the initial editor of earlier draft versions of this document. Since version 06 of the document, Jukka Manner has taken the editorship. Yacine El Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning Schulzrinne suggested the use of the reason field in the BOUND-SESSION-ID.

10. References

10.1. Normative References

[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010. [RFC5975] Ash, G., Bader, A., Kappler, C., and D. Oran, "QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)", RFC 5975, October 2010.

10.2. Informative References

[NSIS-AUTH] Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, Ed., "Authorization for NSIS Signaling Layer Protocols", Work in Progress, May 2010.
Top   ToC   RFC5974 - Page 92
   [NSIS-MOB]   Sanda, T., Fu, X., Jeong, S., Manner, J., and H.
                Tschofenig, "NSIS Protocols operation in Mobile
                Environments", Work in Progress, May 2010.

   [RFC1633]    Braden, B., Clark, D., and S. Shenker, "Integrated
                Services in the Internet Architecture: an Overview",
                RFC 1633, June 1994.

   [RFC2205]    Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                1 Functional Specification", RFC 2205, September 1997.

   [RFC2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
                Services", RFC 2210, September 1997.

   [RFC2961]    Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
                and S. Molendini, "RSVP Refresh Overhead Reduction
                Extensions", RFC 2961, April 2001.

   [RFC3175]    Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
                "Aggregation of RSVP for IPv4 and IPv6 Reservations",
                RFC 3175, September 2001.

   [RFC3520]    Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
                "Session Authorization Policy Element", RFC 3520,
                April 2003.

   [RFC3521]    Hamer, L-N., Gage, B., and H. Shieh, "Framework for
                Session Set-up with Media Authorization", RFC 3521,
                April 2003.

   [RFC3726]    Brunner, M., "Requirements for Signaling Protocols",
                RFC 3726, April 2004.

   [RFC4080]    Hancock, R., Karagiannis, G., Loughney, J., and S. Van
                den Bosch, "Next Steps in Signaling (NSIS): Framework",
                RFC 4080, June 2005.

   [RFC4081]    Tschofenig, H. and D. Kroeselberg, "Security Threats for
                Next Steps in Signaling (NSIS)", RFC 4081, June 2005.

   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                May 2008.

   [RFC5234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234, January 2008.
Top   ToC   RFC5974 - Page 93
   [RFC5973]    Stiemerling, M., Tschofenig, H., Aoun, C., and E.
                Davies, "NAT/Firewall NSIS Signaling Layer Protocol
                (NSLP)", RFC 5973, October 2010.

   [RFC5977]    Bader, A., Westberg, L., Karagiannis, G., Kappler, C.,
                Tschofenig, H., and T. Phelan, "RMD-QOSM: The NSIS
                Quality-of-Service Model for Resource Management in
                Diffserv", RFC 5977, October 2010.

   [lrsvp]      Manner, J. and K. Raatikainen, "Localized QoS Management
                for Multimedia Applications in Wireless Access
                Networks", IASTED IMSA, Technical Specification 101 321,
                p. 193-200, August 2004.

   [opwa95]     Breslau, L., "Two Issues in Reservation Establishment",
                Proc. ACM SIGCOMM '95, Cambridge MA, August 1995.

   [osp]        ETSI, "Telecommunications and Internet Protocol
                Harmonization Over Networks (TIPHON); Open Settlement
                Protocol (OSP) for Inter-Domain pricing, authorization,
                and usage exchange", Technical Specification 101 321,
                version 4.1.1.

   [qos-auth]   Tschofenig, H., "QoS NSLP Authorization Issues", Work
                in Progress, June 2003.

   [shenker]    Shenker, S., et al., "Pricing in computer networks:
                Reshaping the research agenda", Proc. of TPRC 1995,
                1995.
Top   ToC   RFC5974 - Page 94

Appendix A. Abstract NSLP-RMF API

This appendix is purely informational and provides an abstract API between the QoS NSLP and the RMF. It should not be taken as a strict rule for implementors, but rather it helps clarify the interface between the NSLP and RMF.

A.1. Triggers from QOS-NSLP towards RMF

The QoS-NSLP triggers the RMF/QOSM functionality by using the sendrmf() primitive: int sendrmf(sid, nslp_req_type, qspec, authorization_info, NSLP_objects, filter, features_in, GIST_API_triggers, incoming_interface, outgoing_interface) o sid: SESSION-ID - The NSIS session identifier o nslp_req_type: indicates type of request: * RESERVE * QUERY * RESPONSE * NOTIFY o qspec: the QSPEC object, if present o authorization_info: the AUTH_SESSION object, if present o NSLP_objects: data structure that contains a list with received QoS-NSLP objects. This list can be used by, e.g., local applications, network management, or policy control modules: * RII * RSN * BOUND-SESSION-ID list * REFRESH-PERIOD * SESSION-ID-LIST * RSN-LIST
Top   ToC   RFC5974 - Page 95
      *  INFO-SPEC

      *  MSG-ID

      *  BOUND-MSG-ID

   o  filter: the information for packet filtering, based on the MRI and
      the PACKET-CLASSIFIER object.

   o  features_in: it represents the flags included in the common header
      of the received QOS-NSLP message, but also additional triggers:

      *  BREAK

      *  REQUEST REDUCED REFRESHES

      *  RESERVE-INIT

      *  TEAR

      *  REPLACE

      *  ACK-REQ

      *  PROXY

      *  SCOPING

      *  synchronization_required: this attribute is set (see Sections
         Section 4.6 and Section 4.7.1, for example) when the QoS-NSLP
         functionality supported by a QNE Egress receives a non-tearing
         RESERVE message that includes a MSG-ID or a BOUND-MSG-ID
         object, and the BINDING_CODE value of the BOUND-SESSION-ID
         object is equal to one of the following values:

         +  Tunnel and end-to-end sessions

         +  Aggregate sessions

      *  GIST_API_triggers: it represents the attributes that are
         provided by GIST to QoS-NSLP via the GIST API:

         +  NSLPID

         +  Routing-State-Check

         +  SII-Handle
Top   ToC   RFC5974 - Page 96
         +  Transfer-Attributes

         +  GIST-Hop-Count

         +  IP-TTL

         +  IP-Distance

   o  incoming_interface: the ID of the incoming interface.  Used only
      when the QNE reserves resources on incoming interface.  Default is
      0 (no reservations on incoming interface)

   o  outgoing_interface: the ID of the outgoing interface.  Used only
      when the QNE reserves resources on outgoing interface.  Default is
      0 (no reservations on outgoing interface)

A.2. Triggers from RMF/QOSM towards QOS-NSLP

The RMF triggers the QoS-NSLP functionality using the "recvrmf()" and "config()" primitives to perform either all or a subset of the features listed below. The recvrmf() primitive represents either a response to a request that has been sent via the API by the QoS-NSLP or an asynchronous notification. Note that when the RMF/QOSM receives a request via the API from the QoS-NSLP function, one or more "recvrmf()" response primitives can be sent via the API towards QoS-NSLP. In this way, the QOS-NSLP can generate one or more QoS-NSLP messages that can be used, for example, in the situation that the arrival of one end-to- end RESERVE triggers the generation of two (or more) RESERVE messages: an end-to-end RESERVE message and one (or more) intra- domain (local) RESERVE message. The config() primitive is used to configure certain features, such as QNE type, stateful or stateless operation, or bypassing of end-to-end messages. Note that the selection of the subset of triggers is controlled by the QoS Model. int recvrmf(sid, nslp_resp_type, qspec, authorization_info, status, NSLP_objects, filter, features_out, GIST_API_triggers incoming_interface, outgoing_interface) o sid: SESSION-ID - The NSIS session identifier
Top   ToC   RFC5974 - Page 97
   o  nslp_resp_type: indicates type of response:

      *  RESERVE

      *  QUERY

      *  RESPONSE

      *  NOTIFY

   o  qspec: the QSPEC object, if present

   o  authorization_info: the AUTHO_SESSION object, if present

   o  status: boolean that notifies the status of the reservation and
      can be used by QOS-NSLP to include in the INFO-SPEC object:

      *  RESERVATION_SUCCESSFUL

      *  TEAR_DOWN_SUCCESSFUL

      *  NO RESOURCES

      *  RESERVATION_FAILURE

      *  RESERVATION_PREEMPTED: reservation was preempted

      *  AUTHORIZATION_FAILED: authorizing the request failed

      *  MALFORMED_QSPEC: request failed due to malformed qspec

      *  SYNCHRONIZATION_FAILED: Mismatch synchronization between an
         end-to-end RESERVE and an intra-domain RESERVE (see Sections
         Section 4.6 and Section 4.7.1)

      *  CONGESTION_SITUATION: Possible congestion situation occurred on
         downstream path

      *  QoS Model Error

   o  NSLP_objects: data structure that contains a list with QoS-NSLP
      objects that can be used by QoS-NSLP when the QNE is a QNI, QNR,
      QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress:

      *  RII

      *  RSN
Top   ToC   RFC5974 - Page 98
      *  BOUND-SESSION-ID list

      *  REFRESH-PERIOD

      *  SESSION-ID-LIST

      *  RSN-LIST

      *  MSG-ID

      *  BOUND-MSG-ID

   o  filter: it represents the MRM-related PACKET CLASSIFIER

   o  features_out: it represents (among others) the flags that can be
      used by the QOS-NSLP for newly generated QoS-NSLP messages:

      *  BREAK

      *  REQUEST REDUCED REFRESHES

      *  RESERVE-INIT

      *  TEAR

      *  REPLACE

      *  ACK-REQ

      *  PROXY

      *  SCOPING

      *  BYPASSING - when the outgoing message should be bypassed, then
         it includes the required bypassing level.  Otherwise, it is
         empty.  It can be set only by QNI_Ingress, QNR_Ingress,
         QNI_Egress, or QNR_Egress.  It can be unset only by
         QNI_Ingress, QNR_Ingress, QNI_Egress, or QNR_Egress.

      *  BINDING () - when BINDING is required, then it includes a
         BOUND-SESSION-ID list.  Otherwise, it is empty.  It can only be
         requested by the following QNE types: QNI, QNR, QNI_Ingress,
         QNR_Ingress, QNI_Egress, or QNR_Egress.
Top   ToC   RFC5974 - Page 99
      *  NEW_SID - it requests to generate a new session with a new
         SESSION-ID.  If the QoS-NSLP generates a new SESSION-ID, then
         the QoS-NSLP has to return the value of this new SESSION-ID to
         the RMF/QOSM.  It can be requested by a QNI, QNR, QNI_Ingress,
         QNI_Egress, QNR_Ingress, or QNR_Egress.

      *  NEW_RSN - it requests to generate a new RSN.  If the QoS-NSLP
         generates a new RSN, then the QoS-NSLP has to return the value
         of this new RSN to the RMF/QOSM.

      *  NEW_RII - it requests to generate a new RII.  If the QoS-NSLP
         generates a new RII, then the QoS-NSLP has to return the value
         of this new RII to the RMF/QOSM.

   o  GIST_API_triggers: it represents the attributes that are provided
      to GIST via QoS-NSLP via the GIST API:

      *  NSLPID

      *  SII-Handle

      *  Transfer-Attributes

      *  GIST-Hop-Count

      *  IP-TTL

      *  ROUTING-STATE-CHECK (if set, it requires that GIST create a
         routing state)

   o  incoming_interface: the ID of the incoming interface.  Used only
      when the QNE reserves resources on the incoming interface.
      Default is 0 (no reservations on the incoming interface).

   o  outgoing_interface: the ID of the outgoing interface.  Used only
      when the QNE reserves resources on the outgoing interface.
      Default is 0 (no reservations on the outgoing interface).

A.3. Configuration Interface

The config() function is meant for configuring per-session settings, from the RMF towards the NSLP. int config(sid, qne_type, state_type, bypassing_type) o sid: SESSION-ID - The NSIS session identifier
Top   ToC   RFC5974 - Page 100
   o  qne_type: it defines the type of a QNE

      *  QNI

      *  QNI_Ingress: the QNE is a QNI and an Ingress QNE

      *  QNE: the QNE is not a QNI or QNR

      *  QNE_Interior: the QNE is an Interior QNE, but it is not a QNI
         or QNR

      *  QNI_Egress: the QNE is a QNI and an Egress QNE

      *  QNR

      *  QNR_Ingress: the QNE is a QNR and an Ingress QNE

      *  QNR_Egress: the QNE is a QNR and an Egress QNE

   o  state_type: it defines if the QNE keeps QoS-NSLP operational
      states

      *  STATEFUL

      *  STATELESS

   o  bypassing_type: it defines if a QNE bypasses end-to-end messages
      or not

Appendix B. Glossary

AAA: Authentication, Authorization, and Accounting EAP: Extensible Authentication Protocol MRI: Message Routing Information (see [RFC5971]) NAT: Network Address Translator NSLP: NSIS Signaling Layer Protocol (see [RFC4080]) NTLP: NSIS Transport Layer Protocol (see [RFC4080]) OPWA: One Pass With Advertising OSP: Open Settlement Protocol PIN: Policy-Ignorant Node
Top   ToC   RFC5974 - Page 101
   QNE: an NSIS Entity (NE), which supports the QoS NSLP (see Section 2)

   QNI: the first node in the sequence of QNEs that issues a reservation
   request for a session (see Section 22)

   QNR: the last node in the sequence of QNEs that receives a
   reservation request for a session (see Section 22)

   QSPEC: Quality-of-Service Specification

   RII: Request Identification Information

   RMD: Resource Management for Diffserv

   RMF: Resource Management Function

   RSN: Reservation Sequence Number

   RSVP: Resource Reservation Protocol (see [RFC2205])

   SII: Source Identification Information

   SIP: Session Initiation Protocol

   SLA: Service Level Agreement
Top   ToC   RFC5974 - Page 102

Authors' Addresses

Jukka Manner Aalto University Department of Communications and Networking (Comnet) P.O. Box 13000 FIN-00076 Aalto Finland Phone: +358 9 470 22481 EMail: jukka.manner@tkk.fi URI: http://www.netlab.tkk.fi/~jmanner/ Georgios Karagiannis University of Twente/Ericsson P.O. Box 217 Enschede 7500 AE The Netherlands EMail: karagian@cs.utwente.nl Andrew McDonald Roke Manor Research Ltd Old Salisbury Lane Romsey, Hampshire S051 0ZN United Kingdom EMail: andrew.mcdonald@roke.co.uk