tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5974

 
 
 

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

Part 6 of 6, p. 83 to 102
Prev RFC Part

 


prevText      Top      Up      ToC       Page 83 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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