Network Working Group                               M. Brunner (Editor)
Internet Draft                                                      NEC
Category: Informational                                   December 2002                                      March 2003

                   Requirements for Signaling Protocols

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2002). All Rights Reserved.


   This document defines requirements for signaling across different
   network environments, where different network environments mean such as across administrative and and/or
   technology domains. Signaling is mainly
   though considered for QoS Quality of
   Service such as [RSVP], The Resource Reservation Protocol, however in recent year
   years several other applications of signaling have been defined such
   as signaling for
   MPLS label distribution [RSVP-TE]. in Multiprotocol Label Switching
   or signaling to middleboxes. To achieve wide applicability of the
   requirements, the starting point is a diverse set of scenarios/use
   cases concerning various types of networks and application
   interactions. This memo present document presents the assumptions and the
   aspects not considered within scope before listing
   the requirements.  The requirements are grouped according to areas
   such as architecture and design goals, signaling flows, layering,
   performance, flexibility, security, and mobility.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC 2119.

Table of Contents

   Status of this Memo................................................1
   Table of Contents..................................................1 Contents..................................................2
   1 Introduction.....................................................2
   1.1.  Keywords....................................................3
   2 Terminology......................................................3
   3 Problem Statement and Scope......................................5 Scope......................................4
   4 Assumptions and Exclusions.......................................6 Exclusions.......................................5
   4.1 Assumptions and Non-Assumptions................................6 Non-Assumptions................................5
   4.2 Exclusions.....................................................7 Exclusions.....................................................6
   5 Requirements.....................................................9 Requirements.....................................................7
   5.1 Architecture and Design Goals..................................9 Goals..................................8
   5.2 Signaling Flows...............................................11 Flows................................................9
   5.3 Messaging.....................................................13 Messaging.....................................................10
   5.4 Control Information...........................................14 Information...........................................12
   5.5 Performance...................................................16 Performance...................................................13
   5.6 Flexibility...................................................17 Flexibility...................................................15
   5.7 Security......................................................18 Security......................................................16
   5.8 Mobility......................................................20 Mobility......................................................18
   5.9 Interworking with other protocols and techniques..............20 techniques..............18
   5.10 Operational..................................................21 Operational..................................................19
   6 Security Considerations.........................................22 Considerations.........................................19
   7 Informative References..........................................22 References......................................................19
   7.1 Normative References..........................................19
   7.2 Non-Normative References......................................20
   8 Acknowledgments.................................................22 Acknowledgments.................................................20
   9 Author's Addresses..............................................22 Addresses..............................................20
   10 Appendix: Scenarios/Use cases..................................23 cases..................................21
   10.1 Terminal Mobility............................................23 Mobility............................................21
   10.2 Cellular Networks............................................25 3G Wireless Networks.........................................23
   10.3 UMTS access..................................................26 An example scenario for 3G wireless networks.................24
   10.4 Wired part of wireless network...............................27 network...............................26
   10.5 Session Mobility.............................................29 Mobility.............................................27
   10.6 QoS reservations/negotiation s/negotiation from access to core network.....30 network................28
   10.7 QoS reservation/negotiation /negotiation over administrative boundaries...30 boundaries..............28
   10.8 QoS signaling between PSTN gateways and backbone routers.....31 routers.....29
   10.9 PSTN trunking gateway........................................32 gateway........................................30
   10.10 Application request end-to-end QoS path from the network....34 network....32

1 Introduction

   This document defines requirements for signaling across different
   network environments. It does not list any problems of existing
   signaling protocols such as [RSVP].

   In order to derive requirements for signaling it is necessary to
   first have an idea of the scope within which they are applicable.
   Therefore, we define a conceptual model of signaling on an abstract
   level. Additionally, we describe the entities involved in signaling
   and typical signaling paths. In the appendix are a list of use cases and scenarios where an NSIS protocol
   could be applied. It is though
   of helping The scenarios are used to help derive the requirements
   and to t4est test the requirements against use cases.


   The requirements listed are independent of any application. However,
   resource reservation and signaling for QoS is a pretty large field with a lot of
   interaction with other protocols, mechanisms, applications etc. related issues are used as example
   within the text. However, it QoS is not the only field where signaling
   is used in the Internet. Even if this requirement documents mainly used QoS as the
   sample application other application must Others might be possible and are also
   addressed. the use for middlebox
   communication [RFC3234].

   There are several areas related to networking aspects which are
   incomplete, for example, interaction with host and site multi-
   homing, use of anycast services, and so on. These issues should be
   considered in any future analysis work.

1.1. Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC 2119

2 Terminology

   We try to list the most often used terms in the document. However,
   don't they
   cannot be to religious about it, made precise without a more complete architectural model,
   and they are not meant to prescribe any solution in the document. All of them need refined definitions in
   follow-up documents.

   Resource Management Function (RMF): An abstract concept,
   representing the management of resources
   Where applicable, they will be defined in a domain or a node. This
   includes admission control and resource allocation.

   NSIS Domain (ND): Administrative domain where an NSIS protocol
   signals for a resource or set of resources. documents.

   NSIS Entity (NE): The function within a node, which implements an
   NSIS protocol.

   NSIS Forwarder (NF): NSIS Entity on In the path between a NI and case of path-coupled signaling, the NE will
   always be on the data path.

   NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may
   interact with local resource state management function (RMF) for
   this purpose. NSIS Forwarder functions in the network. It
   also propagates NSIS signaling further through the network. It is responsible for interpreting the
   signaling carrying the user parameters, optionally inserting or
   modifying the parameters according to domain network management

   NSIS Initiator (NI): NSIS Entity that initiates starts NSIS signaling for a
   network resource based on user to set
   up or application requirements. This can
   be located in the end system, but may reside elsewhere in network. manipulate network state.

   NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and
   can optionally interact with applications as well.

   Flow: A traffic stream (sequence of IP packets between two end
   systems) for which a specific packet level treatment is provided.
   The flow can be unicast (uni- or bi-directional) or multicast. For
   multicast, a flow can diverge into multiple flows as it propagates
   toward the receiver.  For multi-sender multicast, a flow can also
   diverge when viewed in the reverse direction (toward the senders).

   Higher Layers: The higher layer (transport protocol and application)
   functions that request QoS or any other service from the network
   layer. The trigger for the request might be generated within the end
   system, or the trigger might be provided by some entity within the
   network (e.g. application proxy or policy server).

   Data Path: the The route across the networks taken by a flow or
   aggregate, i.e. which domains/subdomains it passes through and the
   egress/ingress points for each.

   Signaling Path: the The route across the networks taken by a signaling
   flow or aggregate, i.e. which domains/subdomains it passes through
   and the egress/ingress points for each.

   Path Segment: The segment

   Path-coupled signaling: A mode of signaling where the signaling
   messages follow a path within a single

   Control Information: the information that is tied to the governs for instance data packets. Signaling
   messages are routed only through nodes (NEs) that are in the
   QoS treatment data

   Path-decoupled signaling: Signaling with independent data and
   signaling paths. Signaling messages are routed to nodes (NEs) which
   are not assumed to be applied on the data path, but which are (presumably)
   aware of it. Signaling messages will always be directly addressed to a flow or aggregate, including
   service class, flow administration, neighbor NE, and any associated security or
   accounting information.

   Provisioning: the act of actually NI/NR may have no relation at all with the
   ultimate data sender or receiver.

   Service: A generic something provided by one entity and consumed by
   another.  It can be constructed by allocating resources resources. The network
   can provide it to a flow or
   aggregate of flows, may include mechanisms such as LSP initiation
   for MPLS, packet scheduler configuration within a router, and so on.
   The mechanisms depend on the overall technology and application
   being used within the domain, and can be from static to dynamic.

   Subdomain: a network within an administrative domain using a uniform
   technology, e.g., a single QoS provisioning function to provision

   QoS Technology: a generic term for a set of protocols, standards and
   mechanisms that can be used within a QoS domain/subdomain to manage
   the QoS provided to flows or aggregates that traverse the domain.
   Examples might include MPLS, DiffServ, and so on. A QoS technology
   is associated with certain QoS provisioning techniques.

   Resource: something of value in a network infrastructure to which
   rules or policy criteria are first applied before access is granted.
   Examples of resources include the buffers in a router and bandwidth
   on an interface.

   Service: something provided by an entity and consumed by another.
   It can be constructed by allocating resources. The network can
   provide it to users users or a network node can provide it to packets.

   Sender-initiated signaling protocol: A sender-initiated signaling
   protocol is a protocol where the NSIS Initiator initiates the
   signaling on behalf of the sender of the data. What this means is
   that resource management functions are processed from the data
   sender towards the data receiver. However, the triggering instance
   is not specified.

   Receiver-initiated signaling protocol: A receiver-initiated protocol
   (e.g., [RSVP]) is a protocol, where the NSIS Responder on behalf of
   the receiver of the user data initiates the reservation. What this
   means is that resource management functions are processed from the
   data receiver back towards the data sender. However, the triggering
   instance is not specified.

3 Problem Statement and Scope

   We provide in the following a preliminary architectural picture as a
   basis for discussion. We will refer to it in the following
   requirement sections.

   A basic goal should be to re-use these wherever possible, and to
   focus requirements work at an early stage on those areas where a new
   solution is needed (e.g. an especially simple one). We also try to
   avoid defining requirements related to internal implementation

   Note that this model is intended not to constrain the technical
   approach taken subsequently, simply to allow concrete phrasing of
   requirements (e.g. requirements about placement of the NSIS

   Roughly, the scope of NSIS is assumed to be the interaction between
   the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder
   including a protocol to carry the information, and the
   syntax/semantics of the information that is exchanged. Further
   statements on assumptions/exclusions are given in the next Section.

   The main elements are:

   1. Something that starts the request for resources, state to be set up in the
   network, the NSIS Initiator.

   This might be in the end system or within some other part of the
   network. The distinguishing feature of the NSIS Initiator is that it
   acts on triggers coming (directly or indirectly) from the higher
   layers in the end systems. It needs to map the resources services requested by
   them, and also provides feedback information to the higher layers,
   which might be used by transport layer rate management algorithms or adaptive

   2. Something that assists in managing resources state further along the
   signaling path, the NSIS Forwarder.

   The NSIS Forwarder does not interact with higher layers, but
   interacts with the NSIS Initiator, NSIS Responder, and possibly one
   or more NSIS Forwarders on the signaling path, edge-to-edge or end-

   3. Something that terminates the signaling path, the NSIS Responder.

   The NSIS responder might be in an end-system or within other
   equipment. The distinguishing feature of the NSIS Initiator is that
   it responds to request requests at the end of a signaling path.

   4. The signaling path segment traverses an underlying network covering one
   or more IP hops. The underlying network might use locally different
   technology. For instance, QoS technology has to be provisioned
   appropriately for the service requested. In the QoS example, an NSIS
   Forwarder maps service-specific information to technology-related
   QoS parameters and receiving receives indications about success or failure in

   Now concentrating more on the overall end to end (multiple domain)
   aspects, in particular:

   1. The NSIS Initiator need not be located at an end system, and the
   NSIS Forwarders are not assumed to be located on the flow's data
   path. However, they must be able to identify the ingress and egress
   points for the flow's data path as it traverses the NSIS domain. Any
   signaling protocol must be able to find the appropriate NSIS


   5. We can see the network at the level of domains/subdomains rather
   than individual routers (except in the special case that the domain
   contains one link). Domains are assumed to be administrative
   entities, so security requirements apply to the signaling between

   3. Any domain may contain Resource Management Function (e.g.
   traffic engineering, admission control, policy and so on). These are
   assumed to interact with the NSIS Initiator, Responder, and
   Forwarders using standard mechanisms.

   4. The placement of the NSIS Initiators and NSIS Forwarders is not

4 Assumptions and Exclusions

4.1 Assumptions and Non-Assumptions

   1. The NSIS signaling could run end to end, end to edge, end-to-edge, or edge to edge-to-
   edge, or network-to-network ((between providers), depending on what
   point in the network acts as the NSIS initiator, and how far towards the
   other end of the network the signaling propagates. In general, we
   could expect NSIS Forwarders to become more 'dense' towards the
   edges of the network, but this is not a requirement. An over-
   provisioned For example, in
   the case of QoS, an over-provisioned domain might contain no NSIS
   Forwarders at all (and be NSIS transparent); at the other extreme,
   NSIS Forwarders might be placed at every router. In the latter case,
   QoS provisioning can be carried out in a local implementation-dependent implementation-
   dependent way without further signaling, whereas in the case of
   remote NSIS Forwarders, a
   provisioning protocol might be needed to control the
   routers along the path. This provisioning protocol is then independent of the end-
   end-to-end NSIS signaling.

   2. We do not consider 'pure' end-to-end signaling that is not
   interpreted anywhere within the network. Such signaling is an
   application-layer a higher-
   layer issue and IETF protocols such as SIP etc. can be used.

   3. Where the signaling does cover several NSIS domains or
   subdomains, domains, we do not exclude
   that different signaling protocols are used in each path segment. domain. We only
   place requirements on the universality of the control information
   that is being transported. (The goals here would be to allow the use
   of signaling protocols, which are matched to the characteristics of
   the portion of the network being traversed.) Note that the outcome
   of NSIS work might result in various protocols or various flavors of the same protocol.
   This implies the need for the translation of information into domain
   specific format as well.

   4. We assume that the service definitions a NSIS Initiator can ask
   for are known in advance of the signaling protocol running. For
   instance in the QoS example, the service definition includes QoS
   parameters, lifetime of QoS guarantee etc., or any other service-
   specific parameters.

   There are many ways service requesters get to know about it. available
   services. There might be standardized services, the definition can
   be negotiated together with a contract, the service definition is
   published in some on-line directory (e.g., at a Web page, etc. page), and so

   5. We assume that there are means for the discovery of NSIS entities
   in order to know the signaling peers (solutions include static
   configuration, automatically discovered, or implicitly runs over the
   right nodes, nodes along the data path, etc.) The discovery of the NSIS
   entities has security implications that need to be addressed
   properly. These implications
   largely depend on the chosen protocol. For some security mechanisms (i.e. Kerberos, pre-shared
   secret) it is required to know the identity of the other entity.
   Hence the discovery mechanism may provide means to learn this
   identity, which is then later used to retrieve the required keys and

   6. NSIS assumes to operate with networks using standard ("normal")
   L3 routing. Where "normal" layer 3 routing and the determination of next data
   node selection is not specified more exactly on purpose. done by NSIS.

4.2 Exclusions

   1. Development of specific mechanisms and algorithms for application
   and transport layer adaptation are not considered, nor are the
   protocols that would support it.

   2. Specific mechanisms (APIs and so on) for interaction between
   transport/applications and the network layer are not considered,
   except to clarify the requirements on the negotiation capabilities
   and information semantics that would be needed of the signaling

   3. Specific mechanisms and protocols for provisioning or other
   network control functions within a domain/subdomain are not
   considered. The goal is to reuse existing functions and protocols
   unchanged. However, NSIS itself can be used for signaling within a
   domain/subdomain performing provisioning.

   For instance in the QoS example, it means that the setting of QoS
   mechanisms in a domain is out of scope, but if we have a tunnel,
   NSIS could also be used for tunnel setup with QoS guaranties. guarantees. It
   should be possible to exploit these mechanisms optimally within the
   end-to-end context. Consideration of how to do this might generate
   new requirements for NSIS however. For example, the information
   needed by a NSIS Forwarder to manage a radio subnetwork needs to be provided by the
   NSIS solution.

   4. Specific mechanisms (APIs and so on) for interaction between the
   network layer and underlying provisioning mechanisms are not

   5. Interaction with resource management capabilities is not
   considered. Standard protocols might be used for this. This may
   imply requirements for the sort of information that should be
   exchanged between the NSIS entities.

   6. Security implications related to multicasting are outside the
   scope of the signaling protocol.

   7. Protection of non-signaling messages is outside the scope of the

   The protection of non-signaling messages (including data traffic
   following a reservation) is not directly considered by a signaling
   protocol. The protection of data messages transmitted along the
   provisioned path is outside the scope of a signaling protocol.
   Regarding data traffic there is an interaction with accounting
   (metering) and edge routers might require packets to be integrity
   protected to be able to securely assign incoming data traffic to a
   particular user.

   Additionally there might be an interaction with IPSec protected
   traffic experiencing service-specific treatment and the established
   state created due manage a radio subnetwork needs to signaling. One example of such an be
   provided by the NSIS solution.

   4. Specific mechanisms (APIs and so on) for interaction is between the different flow identification with
   network layer and without IPSec protection.

   Many security properties underlying provisioning mechanisms are likely to not

   5. Interaction with resource management or other internal state
   management capabilities is not considered. Standard protocols might
   be application specific and used for this. This may imply requirements for the sort of
   information that should be provided by exchanged between the corresponding application layer NSIS entities.

   6. Security implications related to multicasting are outside the
   scope of the signaling protocol.


   7. Service definitions and in particular QoS services and classes
   are out of scope. Together with the service definition any
   definition of service specific parameters are not considered in this
   document. Only the base NSIS signaling protocol for transporting the
   service information are addressed.


   8. Similarly, specific methods, protocols, and ways to express
   service information in the Application/Session level are not
   considered (e.g., SDP, SIP, RTSP, etc.).


   9. The specification of any extensions needed to signal information
   via application level protocols (e.g. SDP), and the mapping on NSIS
   information are considered outside of the scope of NSIS working
   group, as this work is in the direct scope of other IETF working
   groups (e.g. MMUSIC).


   10. Handoff decision and trigger sources: An NSIS protocol is not
   used to trigger handoffs in mobile IP, nor is it used to decide
   whether to handoff or not. As soon as or in some situation even
   before a handoff happened, an NSIS protocol might be used for
   signaling for the particular service again. The basic underlying
   assumption is that the route comes first (defining the path) and the
   signaling comes after it (following the path). This doesn't prevent
   a signaling application at some node interacting with something that
   modifies the path, but the requirement is then just for NSIS to live
   with that possibility. However, NSIS must interwork with several
   protocols for mobility management.


   11. Service monitoring is out of scope. It is heavily dependent on
   the type of the application and or transport service, and in what
   scenario it is used.

5 Requirements

   This section defines more detailed requirements for a signaling
   solution, respecting the framework, scoping assumptions, and
   terminology considered earlier. The requirements are in subsections,
   grouped roughly according to general technical aspects: architecture
   and design goals, topology issues, parameters, performance,
   security, information, and flexibility.

   Two general (and potentially contradictory) goals for the solution
   are that it should be applicable in a very wide range of scenarios,
   and at the same time lightweight in implementation complexity and
   resource consumption requirements in nodes. NSIS Entities. One approach to
   this is that the solution could deal with certain requirements via
   modular components or capabilities, which are optional to implement
   or use in individual nodes.

   In order to prioritize the various requirements we informally define
   different 'parts of the network'. In the different parts of the
   network a particular requirement might have a different priority.

   The parts of the networks we differentiate are the host-to-first
   router, the access network, and the core network. The host to first
   router part includes all the layer 2 technologies to access to the
   Internet. In many cases, there is an application and/or user running
   on the host initiating signaling. The access network can be
   characterized by low capacity links, medium speed IP processing
   capabilities, and it might consist of a complete layer 2 network as
   well. The core network characteristics include high-speed forwarding
   capacities and inter-domain issues. These divisions between network
   types are not strict and do not appear in all networks, but where
   they do exist they may influence signaling requirements and will be
   highlighted as necessary.

5.1 Architecture and Design Goals

   This section contains requirements related to desirable overall
   characteristics of a solution, e.g. enabling flexibility, or
   independence of parts of the framework.

5.1.1 MUST be applicable for different technologies.

   The signaling protocol MUST work with various QoS and non-QoS
   technologies. The basic information exchanged over the signaling
   protocol MUST be in such detail and quantity that it is useful for
   various technologies.

5.1.2 NSIS SHOULD provide resource availability information on request

   NSIS SHOULD provide a mechanism to check whether resources are state to be setup
   is available without setting it up. For the resource reservation
   example this translates into checking resource availability without
   performing a resource reservation. In some scenarios, e.g., the mobile
   terminal scenario, it is required to query, whether resources are
   available, without performing a reservation on the resource.


5.1.2 NSIS MUST be designed modularly

   A modular design allows for more lightweight implementations, if
   fewer features are needed. Mutually exclusive solutions are
   supported. Examples for modularity:

   - Work over any kind of network (narrowband versus broadband, error-
   prone versus reliable, ...). This implies low bandwidth signaling signaling,
   and elimination of redundant information MUST be supported if

   - Uni- State setup for uni- and bi-directional reservations are flows is possible

   - Extensible in the future with different add-ons for certain
   environments or scenarios

   - Protocol layering, where appropriate. This means NSIS MUST provide
   a base protocol, which can be adapted to different environments.


5.1.3 NSIS MUST decouple protocol and information

   The signaling protocol MUST be clearly separated from the control
   information being transported. This provides for the independent
   development of these two aspects of the solution, and allows for
   this control information to be carried within other protocols,
   including application layer ones, existing ones or those being
   developed in the future. The gained flexibility gained in the transport of
   transported allows for the applicability of the same protocol in
   various scenarios.

   However, note that the information carried needs to be standardized;
   otherwise interoperability is difficult to achieve.

5.1.5 NSIS MUST reuse existing provisioning
   Reuse existing functions and protocols for provisioning within a
   domain/subdomain unchanged. (Motivation: 'Don't re-invent the


5.1.4 NSIS MUST support independence of signaling and provisioning network control

   The signaling MUST be independent of the paradigm and mechanism of
   network control. E.g., in the case of signaling for QoS, the
   independence of the signaling protocol from the QoS provisioning
   allows for using the NSIS protocol together with various QoS
   technologies in various scenarios.

5.1.7 NSIS MUST be application independent

   The signaling protocol MUST be independent of the application. The
   control information SHOULD be application independent, because we
   look into network level signaling.

   The requirement relates to the way using the signaling interacts NSIS protocol together with
   upper layer functions (users, applications, and various QoS administration),
   and lower layer technologies.

   Opaque application information MAY get transported in the signaling
   message, without being handled
   technologies in the network. Development and
   deployment of new applications various scenarios.

5.1.5 NSIS SHOULD be possible without impacting
   the network infrastructure. able to carry opaque objects

   NSIS SHOULD be able to pass around opaque objects, which are
   interpreted only by some NSIS-capable nodes.

5.2 Signaling Flows

   This section contains requirements related to the possible signaling
   flows that should be supported, e.g. over what parts of the flow
   path, between what entities (end-systems, routers, middle boxes,
   management systems), in which direction.

5.2.1 The placement of NSIS Initiator, Forwarder, and Responder
     anywhere in the network MUST be
     free allowed

   The protocol MUST work in various scenarios such as host-to-network-
   to-host, edge-to-edge, (e.g., just within one providers provider's domain),
   user-to-network (from end system into the network, ending, e.g., at
   the entry to the network and vice versa), and network-to-network
   (e.g., between providers).

   Placing the NSIS Forwarder and NSIS Initiator functions at different
   locations allows for various scenarios to work with the same

5.2.2 No constraint NSIS MUST be posed the signaling support path-coupled and NSIS Forwarders to
     be in the data path.

   There is a set of scenarios, where signaling is not on the data
   path. SHOULD NOT exclude path-
     decoupled signaling.

   The NSIS Forwarder being in the data path is one extreme case
   and useful in many cases. Therefore the case of having NSIS entities
   on the data path only path-coupled signaling mode MUST be supported.

   There are going to be cases where a centralized entity will take a
   decision about service requests. In this case, there is no need to
   have the data follow the signaling path, or have the NSIS signaling
   follow the data path.

   messages are going to be cases without a centralized entity managing
   resources and the signaling will be used as a tool for resource
   management. For various reasons (such as efficient use of expensive
   bandwidth), one will want to have fine-grained, fast, and very
   dynamic control of the resources in the network.

   There routed only through nodes (NEs) that are going to be cases where there will be neither signaling
   nor a centralized entity (over-provisioning). Nothing has to be done

   One can capture the requirement with the following, different
   wording: If one views the domain as a virtual router then NSIS
   signaling used between those virtual routers MUST follow the same
   path as the data.

   Routing in the data

   However, there is a set of scenarios, where signaling protocol along an independent path is desired
   by network operators/designers. Ideally, the capability to route the
   protocol along an independent path would give not on the network
   data path. Therefore, NSIS SHOULD NOT exclude the option path-decoupled
   signaling mode, where signaling messages are routed to manage bandwidth utilization through
   the topology.

   There nodes (NEs),
   which are other possibilities as well. An NSIS protocol MUST accept
   all of these possibilities with a strong focus not assumed to be on the on-path
   signaling. data path, but which are aware of

5.2.3 Concealment of topology and technology information SHOULD be

   The NSIS protocol SHOULD allow for hiding the internal structure of
   a NSIS domain from end-nodes and from other networks. Hence an
   adversary should not be able to learn the internal structure of a
   network with the help of the signaling protocol.

   In various scenarios, topology information should be hidden for
   various reasons. From a business point of view, some administrations
   don't want to reveal the topology and technology used.

5.2.4 Transparent signaling through networks SHOULD be possible

   It SHOULD be possible that the signaling for some flows traverse traverses
   path segments transparently, i.e., without interpretation at NSIS
   Forwarders within the network. An example would be a subdomain
   within a core network, which only interpreted signaling for
   aggregates established at the domain edge, with the flow-related signaling for
   individual flows passing transparently through it.

   In other words, NSIS SHOULD work in hierarchical scenarios, where
   big pipes/trunks are setup using NSIS signaling, but also flows
   which run within that big pipe/trunk are setup using NSIS.

5.3 Messaging

5.3.1 Explicit release erasure of resources state MUST be possible

   When state along a resource reservation path is no longer necessary, e.g. e.g., because the
   application terminates, or because a mobile host experienced a hand-
   off, it MUST be possible to explicitly release resources. In general
   explicit release enhances erase the overall network utilization. state explicitly.

5.3.2 Automatic release of resources state after failure SHOULD be possible

   When the NSIS Initiator goes down, the resources state it requested in the
   network SHOULD be released, since they it will no longer be necessary.

   After detection of a failure in the network, any NSIS
   Forwarder/Initiator MUST be able to release a reservation state it is involved in.
   For example, this may require signaling of the "Release after
   Failure" message upstream as well as downstream, or soft state
   timing out of reservations. out.

   The goal is to prevent stale state within the network and adds
   robustness to the operation of NSIS. So in other words, an NSIS
   signaling protocol or mechanisms MUST provide means for an NSIS
   entity to discover and remove local stale state.

   Note that this might need to work together with a notification

5.3.3 NSIS SHOULD allow for sending notifications upstream

   NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS
   Forwarder upstream, if there is a state change inside the network.
   There are various types of network changes for instance among them:

   Recoverable errors: the network nodes can locally repair this type
   error. The network nodes do not have to notify the users of the
   error immediately. This is a condition when the danger of
   degradation (or actual short term degradation) of the provided
   service was overcome by the network (NSIS Forwarder) itself.

   Unrecoverable errors: the network nodes cannot handle this type of
   error, and have to notify the users as soon as possible.

   Service degradation/severe congestion: degradation: In case the service cannot be provided
   completely but partially only. only partially.

   Repair indication: If an error occurred and it has been fixed, this
   triggers the sending of a notification.

   Service upgrade available: If a previously requested better service
   becomes available.

   The content of the notification is very service specific, but it is
   must at least carry type information. Additionally, it may carry the
   location of the state change.

   The notifications may or may not be in response to a NSIS message.
   This means an NSIS entity has to be able to handle notifications at
   any time.

   Note however, that there are a number of security consideration
   needs to be solved with notification, even more important if the
   notification is sent without prior request (asynchronously). The
   problem basically is, that everybody could send notifications to any
   NSIS entity and the NSIS entity most likely reacts on the
   notification. E.g., For example, if it gets an error notification it might
   teardown the reservation,
   erase state, even if everything is ok. So the notification might
   depend on security associations between the sender of the
   notification and its receiver. If a hop-by-hop security mechanism is
   chosen, this implies also that notifications need to be sent on the
   reverse path.

5.3.4 Feedback about success of service request

.3.4 Establishment and refusal to set up state MUST be provided notified.
   An NR MUST acknowledge establishment of state on behalf of the NI
   requesting establishment of that state.  A request for service refusal to set up state
   MUST be answered at least replied with yes a negative acknowledgement by the NE refusing
   to set up state. It MUST be sent to the NI. Depending on the
   signaling application the (positive or no.
   However, it negative) notifications may
   have to pass through further NEs upstream. Information on the reason
   of the refusal to set up state MAY be useful made available.  For example,
   in case of the resource reservation example, together with a negative answer to also get a
   description of what
   answer, the amount of resources a request is possible. So an
   opaque element MAY available might also be included into the answer. The element heavily
   depends on the service requested. returned.

5.3.5 NSIS MUST allow for local information exchange

   The signaling protocol MUST be able to exchange local information
   between NSIS Forwarders located within one single administrative
   domain. The local information exchange is performed by a number of
   separate messages not belonging to an end-to-end signaling process.
   Local information might, for example, be IP addresses, severe
   congestion notification, addresses , notification
   of successful or erroneous processing of signaling messages. messages, or
   other conditions.

   In some cases, the NSIS signaling protocol MAY carry identification
   of the NSIS Forwarders located at the boundaries of a domain.
   However, the identification of edge should not be visible to the end
   host (NSIS Initiator) and only applies within one administrative

5.4 Control Information

   This section contains requirements related to the control
   information that needs to be exchanged.

5.4.1 Mutability information on parameters SHOULD be possible

   It SHOULD be possible for the NSIS initiator to control the
   mutability of the signaled information. This prevents them from
   being changed in a non-recoverable way. The NSIS initiator SHOULD be
   able to control what is requested end to end, without the request
   being gradually mutated as it passes through a sequence of domains.
   This implies that in case of changes made on the parameters, the
   original requested ones must still be available.

   Note that we do not require anything about particular parameters
   being changed.

   Additionally, note that a the provider or that of the particular requested
   requested, can still influence the provisioning but in the signaling
   message the request should stay the same.

5.4.2 It SHOULD be possible to add and remove local domain information

   It SHOULD be possible for the Resource Management Function to add and remove local scope elements.
   Compared to Requirement 5.3.5 this requirement does use the normal
   signaling process and message exchange for transporting local
   information. E.g., For example, at the entrance to a domain domain-specific domain-
   specific information is added, which is used in this domain only,
   and the information is removed again when a signaling message leaves
   the domain. The motivation is in the economy of re-use re-using the
   protocol for domain internal signaling of various information
   pieces. Where additional information is needed within a particular
   domain, it should be possible to carry this at the same time as the
   end-to-end information.

5.4.3 State MUST be addressed independent of flow identification

   Addressing or identifying state MUST be independent of the flow
   identifier (flow end-points, topological addresses). Various
   scenarios in the mobility area require this independence because
   flows resulting from handoff might have changed end-points etc. but
   still have the same service requirement. Also several proxy-based
   signaling methods profit from such independence.

5.4.4 Modification of already reserved resources established state SHOULD be seamless

   In many case, the reservation established state needs to be updated (up (in QoS
   example upgrade or downgrade). downgrade of resource usage). This SHOULD happen
   seamlessly without service interruption. At least the signaling
   protocol should allow for it, even if some data path elements might
   not be capable of doing so.

5.4.5 Grouping of signaling for several micro-flows MAY be provided

   NSIS MAY group signaling information for several micro-flow into one
   signaling message. The goal of this is the optimization in terms of
   setup delay, which can happen in parallel. This helps applications
   requesting several flows at once. Also potential refreshes (in case
   of a soft state solution) might profit from grouping.

   However, the network MUST NOT needs not know that a relationship between the
   grouped flows exists. There MUST NOT be any transactional semantic
   associated with the grouping. It is only meant for optimization
   purposes and each reservation MUST be handled separately from each

5.5 Performance

   This section discusses performance requirements and evaluation
   criteria and the way in which these could and should be traded off
   against each other in various parts of the solution.

   Scalability is a must anyway. always an important requirement for signaling
   protocols. However, depending on the type of scalability and its importance
   varies from one scenario the
   question to which extends the protocol must be scalable. another.

   Note that many of the performance issues are heavily dependent on
   the scenario assumed and are normally a trade-off between speed,
   reliability, complexity, and scalability. The trade-off varies in
   different parts of the network. For example, in radio access
   networks low bandwidth consumption will overweight outweigh the low latency
   requirement, while in core networks it may be reverse.

5.5.1 Scalability

   NSIS MUST be scalable in the number of messages received by a
   signaling communication partner (NSIS Initiator, NSIS Forwarder, and
   NSIS Responder). The major concern lies in the core of the network,
   where large numbers of messages arrive.

   It MUST be scalable in number of hand-offs in mobile environments.
   This mainly applies in access networks, because the core is
   transparent to mobility in most cases.

   It MUST be scalable in the number of interactions for setting up a
   state. This applies for end-systems setting up several
   reservations. states. Some
   servers might be expected to setup a large number of reservations. states.

   Scalability in the number amount of state per entity MUST be achieved for
   NSIS Forwarders in the core of the network.


   Scalability in CPU use usage MUST be achieved on end terminals and
   intermediate nodes in case of many reservations state setup processes at the same time and intermediate nodes mainly
   in the core.

5.5.2 NSIS SHOULD allow for low latency in setup

   NSIS SHOULD allow for low latency setup of reservations. states. This is only
   needed in scenarios, where reservations state setups are in required on a short time
   scale (e.g. handover in mobile environments), or where human
   interaction is immediately concerned (e.g., voice communication
   setup delay).

5.5.3 NSIS MUST allow for low bandwidth consumption for the signaling

   NSIS MUST allow for low bandwidth consumption in certain access
   networks. Again only small sets of scenarios call for low bandwidth,
   mainly those where wireless links are involved.

5.5.4 NSIS SHOULD allow to constrain load on devices

   The NSIS architecture SHOULD give the ability to constrain the load
   (CPU load, memory space, signaling bandwidth consumption and
   signaling intensity) on devices where it is needed. One of the
   reasons is that the protocol handling should have a minimal impact
   on interior (core) nodes.

   This can be achieved by many different methods. Examples, and this
   are only examples, Examples include
   message aggregation, by ignoring
   signaling message, header compression, or minimizing
   functionality. The framework may choose any method as long as the
   requirement is met.

5.5.5 NSIS SHOULD target the highest possible network utilization

   This requirement applies specifically to QoS signaling.

   There are networking environments that require high network
   utilization for various reasons, and the signaling protocol SHOULD
   to its best ability support high resource utilization while
   maintaining appropriate service quality.

   In networks where resources are very expensive (as is the case for
   many wireless networks), efficient network utilization for signaling
   traffic is of critical financial importance.  On the other hand
   there are other parts of the network where high utilization is not

5.6 Flexibility

   This section lists the various ways the protocol can flexibly be

5.6.1 Flow aggregation

   NSIS MUST allow for flow aggregation, including the capability to
   select and change the level of aggregation.

5.6.2 Flexibility in the placement of the NSIS Initiator Initiator/Responder

   NSIS MUST be flexible in placing an NSIS Initiator. Initiator and NSIS
   Responder. The NSIS Initiator might be located at the sender sending or the receiver
   receiving side of content. But also a data stream, and the NSIS Responder naturally on
   the other side.

   Also network-initiated reservations signaling and termination MUST be allowed in
   various scenarios such as PSTN gateways, some VPNs, and mobility.
   This means the NSIS Initiator and NSIS Responder might not be at the
   end points of the data stream.

5.6.3 Flexibility in the initiation of re-negotiation state change

   The NSIS Initiator or the NSIS Responder SHOULD be able to initiate
   a re-negotiation or change of state. In the example of resource reservation this is
   often referred to as resource re-negotiation. It can happen due to
   various reasons, such as local resource shortage (CPU, memory on
   end-system) or a user changed application preference/profiles.

5.6.4 SOULD SHOULD support network-initiated re-negotiation state change

   NSIS SHOULD support network-initiated re-negotiation. This state change. In the QoS
   example, this is used in cases, where the network is not able to
   further guarantee resources and want wants to e.g. downgrade a resource

5.6.5 Uni / bi-directional reservation state setup

   Both unidirectional as well as bi-direction reservations state setup SHOULD be
   possible. With bi-directional reservations state setup we mean here reservations
   having that the state for
   bi-directional data flows is setup. The bi-directional data flows
   have the same end-points. But end-points, but the path in the two directions does
   not need to be the same.

   The goal of a bi-directional reservation state setup is mainly an optimization
   in terms of setup delay. There is no requirements on constrains such
   as use of the same data path etc.

5.7 Security

   This section discusses security-related requirements. For a
   discussion of security threats see [SEC-THR]. The NSIS
   protocol MUST provide means for security, but it MUST be allowed
   that nodes implementing NSIS signaling do not need use the security

5.7.1 Authentication of signaling requests

   A signaling protocol MUST make provision for enabling various
   entities to be authenticated against each other using strong
   authentication mechanisms. The term strong authentication points to
   the fact that weak plain-text password mechanisms must not be used
   for authentication.

5.7.2 Resource Request Authorization

   The signaling protocol MUST provide means to authorize resource state setup
   requests. This requirement demands a hook to interact with a policy
   entity to request authorization data. This allows an authenticated
   entity to be associated with authorization data and to verify the
   request. Authorization prevents reservations state setup by unauthorized entities, reservations
   setups violating policies, and theft of service. Additionally it
   limits denial of service attacks against parts of the network or the
   entire network caused by unrestricted reservations. state setups. Additionally it
   might be helpful to provide some means to inform other protocols of
   participating nodes within the same administrative domain about a
   previous successful authorization event.

5.7.3 Integrity protection

   The signaling protocol MUST provide means to protect the message
   payloads against modifications. Integrity protection prevents an
   adversary from modifying parts of the signaling message and from
   mounting denial of service or theft of service type of attacks
   against network elements participating in the protocol execution.

5.7.4 Replay protection

   To prevent replay of previous signaling messages the signaling
   protocol MUST provide means to detect old i.e. already transmitted
   signaling messages. A solution must cover issues of synchronization
   problems in the case of a restart or a crash of a participating
   network element.

5.7.5 Hop-by-hop security

   Hop-by-Hop security SHOULD be supported. It is a well known and
   proven concept in Quality-of-Service and other signaling protocols
   that allows intermediate nodes that actively participate in the
   protocol to modify the messages as it is required by processing rule.
   rules. Note that this requirement does not exclude end-to-end or network-to-
   network-to-network security of a signaling message. End-to-end
   security between the initiator and the responder may be used to
   provide protection of non-mutable data fields. Network-to-network
   security refers to the protection of messages over various hops but
   not in an end-to-end manner i.e. protected over a particular network.

5.7.6 Identity confidentiality and location privacy network topology hiding

   Identity confidentiality SHOULD be supported. It enables privacy and
   avoids profiling of entities by adversary eavesdropping the signaling
   traffic along the path. The identity used in the process of
   authentication may also be hidden to a limited extent from a network
   to which the initiator is attached. However the identity MUST provide
   enough information for the nodes in the access network to collect
   accounting data.

   Location privacy MAY be supported. It is an issue for the initiator
   who triggers the signaling protocol. In some scenarios the initiator
   may not network to collect
   accounting data.

   Network topology hiding MAY be willing supported to reveal location information prevent entities along
   the path to learn the responder as
   part topology of the signaling procedure. a network. Supporting this property
   might conflict with a diagnostic capability.

5.7.7 Denial-of-service attacks

   A signaling protocol SHOULD provide prevention of Denial-of-service
   attacks. To effectively prevent denial-of-service attacks it is
   necessary that the used security and protocol mechanisms MUST have
   low computation computational complexity to verify a resource state setup request prior to
   authenticating the requesting entity. Additionally the signaling
   protocol and the used security mechanisms SHOULD NOT require large
   resource consumption on NSIS Entities (for example main memory or
   other additional message exchanges) before a successful
   authentication was is done.

5.7.8 Confidentiality of signaling messages

   Based on the signaling information exchanged between nodes
   participating in the signaling protocol an adversary may learn both
   the identities and the content of the signaling messages. To prevent
   this from happening, confidentiality of the signaling message in a
   hop-by-hop manner MAY be provided. Note that the protection can be
   provided on a hop-by-hop basis for most message payloads since it is
   required that entities which actively participating in the signaling
   protocol must be able to read and eventually modify the content of
   the signaling messages.

5.7.9 Ownership of a reservation state
   When existing reservations states have to be modified then there is a need to use
   a reservation session identifier to uniquely identify the established state. A
   signaling protocol MUST provide the appropriate means of security protection to
   prevent other entities to modify state without having
   the proper ownership. adversaries from modifying state.

5.8 Mobility

5.8.1 Allow efficient service re-establishment after handover

   Handover is an essential function in wireless networks. After
   handover, the reservation states may need to be completely or partially re-
   established due to route changes. The re-establishment may be
   requested by the mobile node itself or triggered by the access point
   that the mobile node is attached to.  In the first case, the
   signaling MUST allow efficient re-establishment after handover.  Re-
   establishment after handover MUST be as quick as possible so that
   the mobile node does not experience service interruption or service
   degradation. The re-establishment SHOULD be localized, and not
   require end-to-end signaling.

5.9 Interworking with other protocols and techniques

   Hooks SHOULD be provided to enable efficient interworking between
   various protocols and techniques including: including the following listed.

5.9.1 MUST interwork with IP tunneling

   IP tunneling for various applications MUST be supported. More
   specifically tunneling for IPSec tunnels are of importance as
   discussed in Section 4.2. importance. This mainly impacts
   the identification of flows. Using IPSec When using IPSec, parts of information
   commonly used for flow identification (e.g. transport protocol
   information and ports) may not be accessible due to encryption.

5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6

5.9.3 MUST be independent from charging model

   Signaling MUST NOT be constrained by charging models or the charging
   infrastructure used.

5.9.4 SHOULD provide hooks for AAA protocols

   The NSIS SHOULD be developed with respect to be able to collect
   usage records from one or more network elements.

5.9.5 SHOULD interwork with seamless handoff protocols

   An NSIS protocol SHOULD interwork with seamless handoff protocols
   such as context transfer and candidate access router (CAR)

5.9.6 MAY interwork with non-traditional routing
   NSIS assumes traditional L3 routing, but networks, which do non-
   traditional L3 non-traditional
   routing, should not break it.

5.10 Operational

5.10.1 Ability to assign transport quality to signaling messages.

   The NSIS architecture SHOULD allow the network operator to assign
   the NSIS protocol messages a certain transport quality. As signaling
   opens up for possible denial-of-service attacks, this requirement
   gives the network operator a mean, means, but also the obligation, to
   trade-off between signaling latency and the impact (from the
   signaling messages) on devices within his/her the network. From protocol
   design this requirement states that the protocol messages SHOULD be
   detectable, at least where the control and assignment of the
   messages priority is done.

   Furthermore, the protocol design must take into account reliability
   concerns. Communication reliability is seen as part of the quality
   assigned to signaling messages. So procedures MUST be defined how an
   NSIS signaling system behaves if some kind of request it sent stays
   without answer.
   unanswered. The basic transport protocol to be used between adjacent
   NSIS units Entities MAY ensure message integrity and reliable transport.

5.10.2 Graceful fail over

   Any unit participating in NSIS signaling MUST NOT cause further
   damage to other systems involved in NSIS signaling when it has to go
   out of service.

5.10.3 Graceful handling of NSIS entity problems

   NSIS peers entities SHOULD be able to detect the a malfunctioning peer. It may
   notify the NSIS Initiator or another NSIS entity involved in the
   signaling process. The NSIS peer may handle the problem itself e.g.
   switching to a backup NSIS entity. In the latter case note that
   synchronization of state between the primary and the backup entity
   is needed.

6 Security Considerations

   Section 5.7 of this document provides security related requirements
   of a signaling protocol.

7 Informative References

7.1 Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2 Non-Normative References

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

   [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
   Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
   December 2001.

   [RFC3234] B. Carpenter, S. Brim, "Middleboxes: Taxonomy and Issues",
   RFC 3234, February 2002.

8 Acknowledgments

   Quite a number of people have been involved in the discussion of the
   document, adding some ideas, requirements, etc. We list them without
   a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
   (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
   Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),
   Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
   University Berlin), Xiaoming Fu (Technical University Berlin), Hans-
   Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph
   Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya

   Some text and/or ideas for text, requirements, scenarios have been
   taken from an Internet Draft written by the following authors: David
   Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis
   (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University
   of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
   Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
   actively contributed new text to this document as well.

   Another Internet Draft impacting this document has been written by
   Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel).
   These people contributed also new text.

   Thanks also to Kwok Ho Chan (Nortel) for text changes.

9 Author's Addresses

   Marcus Brunner (Editor)
   NEC Europe Ltd.
   Network Laboratories
   Kurfuersten-Anlage 34 36
   D-69115 Heidelberg

   Robert Hancock
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   Eleanor Hepworth
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   Cornelia Kappler
   Siemens AG
   Berlin 13623

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munchen

10 Appendix: Scenarios/Use cases

   In the following we describe scenarios, which are important to
   cover, and which allow us to discuss various requirements. Some
   regard this as use cases to be covered defining the use of a
   signaling protocol. In general, these scenarios consider the
   specific case of signaling for QoS (resource reservation), although
   many of the issues carry over directly to other signaling types.

10.1 Terminal Mobility

   The scenario we are looking at is the case where a mobile terminal
   (MT) changes from one access point to another access point. The
   access points are located in separate QoS domains. We assume Mobile
   IP to handle mobility on the network layer in this scenario and
   consider the various extensions (i.e., IETF proposals) to Mobile IP,
   in order to provide 'fast handover' for roaming Mobile Terminals.
   The goal to be achieved lies in providing, keeping, and adapting the
   requested QoS for the ongoing IP sessions in case of handover.
   Furthermore, the negotiation of QoS parameters with the new domain
   via the old connection might be needed, in order to support the
   different 'fast handover' proposals within the IETF.

   The entities involved in this scenario include a mobile terminal,
   access points, an access network manager, and communication partners
   of the MT (the other end(s) of the communication association).
   From a technical point of view, terminal mobility means changing the
   access point of a mobile terminal (MT). However, technologies might
   change in various directions (access technology, QoS technology,
   administrative domain). If the access points are within one specific
   QoS technology (independent of access technology) we call this
   intra-QoS technology handoff. In the case of an inter-QoS technology
   handoff, one change from e.g. a DiffServ to an IntServ domain,
   however still using the same access technology. Finally, if the
   access points are using different access technologies we call it
   inter-technology hand-off.

   The following issues are of special importance in this scenario:

   1) Handoff decision

   - The QoS management requests handoff. The QoS management can decide
   to change the access point, since the traffic conditions of the new
   access point are better supporting the QoS requirements. The metric
   may be different (optimized towards a single or a group/class of
   users). Note that the MT or the network (see below) might trigger
   the handoff.

   - The mobility management forces handoff. This can have several
   reasons. The operator optimizes his network, admission is no longer
   granted (e.g. emptied prepaid condition). Or another example is when
   the MT is reaching the focus of another base station. However, this
   might be detected via measurements of QoS on the physical layer and
   is therefore out of scope of QoS signaling in IP. Note again that
   the MT or the network (see below) might trigger the handoff.

   - This scenario shows that local decisions might not be enough. The
   rest of the path to the other end of the communication needs to be
   considered as well. Hand-off decisions in a QoS domain do not only
   depend on the local resource availability, e.g., the wireless part,
   but involve the rest of the path as well. Additionally,
   decomposition of an end-to-end reservation signaling might be needed, in order
   to change only parts of it.

   2) Trigger sources

   - Mobile terminal: If the end-system QoS management identifies
   another (better-suited) access point, it will request the handoff
   from the terminal itself. This will be especially likely in the case
   that two different provider networks are involved. Another important
   example is when the current access point bearer disappears (e.g.
   removing the Ethernet cable). In this case, the NSIS Initiator is
   basically located on the mobile terminal.

   - Network (access network manager): Sometimes, the handoff trigger
   will be issued from the network management to optimize the overall
   load situation. Most likely this will result in changing the base-
   station of a single providers network. Most likely the NSIS
   Initiator is located on a system within the network.

   3) Integration with other protocols

   - Interworking with other protocol must be considered in one or the
   other form. E.g., it might be worth combining QoS signaling between
   different QoS domains with mobility signaling at hand-over.

   4) Handover rates
   In mobile networks, the admission control process has to cope with
   far more admission requests than call setups alone would generate.
   For example, in the GSM (Global System for Mobile communications)
   case, mobility usually generates an average of one to two handovers
   per call. For third generation networks (such as UMTS), where it is
   necessary to keep radio links to several cells simultaneously
   (macro-diversity), the handover rate is significantly higher.

   5) Fast reservations s

   Handover can also cause packet losses. This happens when the
   processing of an admission request causes a delayed handover to the
   new base station. In this situation, some packets might be
   discarded, and the overall speech quality might be degraded
   significantly. Moreover, a delay in handover may cause degradation
   for other users. In the worst-case scenario, a delay in handover may
   cause the connection to be dropped if the handover occurred due to
   bad air link quality. Therefore, it is critical that QoS signaling
   in connection with handover be carried out very quickly.

   6) Call blocking in case of overload

   Furthermore, when the network is overloaded, it is preferable to
   keep reservations s for previously established flows while blocking new requests.
   Therefore, the resource reservation requests in connection with
   handover should be given higher priority than new requests for
   resource reservation.

10.2 Cellular 3G Wireless Networks

   In this scenario, the user is using the packet service services of a 3rd
   generation cellular system, e.g. UMTS. wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The
   region between the End Host and the edge node Edge Node (Edge Router)
   connecting the cellular wireless network to another QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is considered
   to be a single QoS domain.

   The issues in such an environment regarding QoS include:

   1) Cellular systems 3G wireless networks provide their own QoS technology with
   specialized parameters to co-ordinate the QoS provided by both the
   radio access and wired access network. For example, in a UMTS
   network, one aspect of GPRS is that it can be considered as a QoS
   technology; provisioning networks. Provisioning of QoS
   technologies within GPRS is a 3G wireless network can be described mainly in
   terms of calling UMTS bearer classes.  This classes, service options and service
   instances. These QoS technology needs technologies need to be invoked with suitable
   parameters when higher layers trigger a request for QoS, and this therefore involves QoS. Therefore
   these involve mapping of the requested
   IP higher layer QoS parameters
   onto these UMTS specific bearer classes. This classes or service instances. The request for
   allocation of resources might be triggered by IP signaling messages at the IP
   level that pass passes across the
   cellular wireless system, and possibly other QoS domains, to negotiate for
   network resources.
   domains. Typically, cellular system wireless network specific messages
   invoke are invoked
   to setup the underlying cellular system QoS technology bearer classes or service instances in
   parallel with the IP layer QoS negotiation, to allocate the resources
   within the
   cellular system.

   2) radio access network.

   2) The IP signaling messages are initiated by the NSIS initiator and
   interpreted by the NSIS Forwarder. The most efficient placement of
   the NSIS Initiators Initiator and NSIS Forwarders (terminology Forwarder has not been determined in the framework given here). 3G
   wireless networks, but a few potential scenarios can be envisioned.
   The NSIS Initiator could be located at the End Host e.g. UE or MS
   (triggered by applications), the GGSN/PDSN, Access Gateway or at a node that is
   not directly on the data path, such as a bandwidth broker. In
   the second case, the GGSN/PDSN Policy Decision Function.
   The Access Gateway could either be acting act as a proxy NSIS Initiator on behalf of
   the UE/MS or an End Host with little capabilities, and/or managing
   aggregate Host. The Policy Decision Function that controls
   per-flow/aggregate resources with respect to the session within its
   QoS domain (the UMTS core network).
   The IP signaling messages are interpreted by the NSIS Forwarders,
   which may be located at the GGSN/PDSN, and in any QoS sub-domains
   within (e.g. the cellular system.

   3) Initiation of IP-level QoS negotiation. IP-level QoS re-
   negotiation 3G wireless network) may be initiated by either act as a proxy NSIS
   Initiator for the End Host, UE/MS or by the
   network, based on current network loads, which might change
   depending Access Gateway. Depending on the location
   placement of the end host.

   4) NSIS Initiator, the NSIS Forwarder may be located
   at an appropriate point in the 3G wireless network.

   3) The networks are designed and mainly used need for speech
   communication (at least so far).

   Note that re-negotiation of resources in comparison a new 3G wireless
   domain due to UE/MS mobility. In this case the previous scenario emphasis is much
   less on NSIS Initiator and
   the NSIS Forwarder should detect mobility aspects, because mobility is mainly handled on
   the lower layer. events and autonomously
   trigger re-negotiation of resources.

10.3 UMTS access An example scenario for 3G wireless networks

   The UMTS 3G wireless access scenario is shown in Figure 1. The Proxy-Call
   State Control Function/Policy Control Function (P-CSCF/PCF) (P-CSCF) is the outbound SIP proxy of the visited domain, i.e. the domain where the
   mobile user wants to set-up a call. (only used
   in IMS). The Access Gateway GPRS Support Node
   (GGSN) is the egress router of the UMTS domain 3G wireless
   domain and it connects the radio access network to the Edge Router
   (ER) of the backbone IP network. The Policy Decision Function (PDF)
   is an entity responsible for controlling bearer level resource
   allocations/de-allocations in relation to session level services
   e.g. SIP. The Policy Decision Function may also control the Access
   Gateway to open and connects close the UMTS
   access network gates and to the Edge Router (ER) of the core IP network. configure per-flow
   policies, i.e. to authorize or forbid user traffic. The
   P-CSCF/PCF communicates with P-CSCF (only
   used in IMS) and the GGSN via Access Gateway communicate with the COPS protocol. Policy
   Decision Function, for network resource allocation/de-allocation
   decisions. The User Equipment (UE) or the Mobile Station (MS)
   consists of a Mobile Terminal (MT) and Terminal Equipment (TE), e.g.
   a laptop.

                +--------->| P-CSCF |-------> |---------> SIP signaling
               /           +--------+
              / SIP            :
             :             +--------+   NSIS            |
             |                 |
             |              +-----+            +----------------+
             |  PCF   |---------|              | PDF |<---------->| NSIS Forwarder |<--->
             :             +--------+              +-----+            +----------------+
             :                 :
             :                 : COPS
             :                 :
           +----+          +--------+
             |                 |                  ^
             |                 |                  |
             |                 |                  |
             |                 |COPS              |
             |                 |                  |
         +------+          +---------+            |
         | UE/MS|----------| Access  |<-----------+     +----+
         +------+          | UE |----------|  GGSN  |------| Gateway |------------------| ER |
           +----+          +--------+
                           +---------+                  +----+

                  Figure 1: UMTS 3G wireless access scenario

   In this scenario the GGSN has the role of Access Gate. According to
   3GPP standardization, the PCF is responsible for the policy-based
   control of the end-user service in the UMTS access network (i.e.
   from UE to GGSN). In the current UMTS release R.5, the PCF is part
   of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF
   may evolve to an open standardized interface. In any case the PCF

   The PDF has all the required QoS information for per-flow or
   aggregate admission control in
   the UMTS access network (which it gets 3G wireless networks. It receives
   resource allocation/de-allocation requests from the P-CSCF and/or GGSN).
   Access Gateway etc. and responds with policy decisions. Hence the PCF would
   PDF may be the appropriate a candidate entity to host the functionality of the NSIS
   Initiator, initiating the "NSIS" QoS signaling towards the core backbone
   IP network. The PCF/P-CSCF On the other hand, the UE/MS may act as the NSIS
   Initiator or the Access Gateway may act as a Proxy NSIS Initiator on
   behalf of the UE/MS. In the former case, the P-CSCF/PDF has to do
   the mapping from codec type (derived from SIP/SDP signaling) to IP traffic
   descriptor. SDP extensions to explicitly signal codec types and media descriptors (derived from
   SIP/SDP signaling) to IP traffic descriptor. In the latter case, the
   UE/MS may use any appropriate QoS signaling mechanism as the NSIS
   Initiator. If the Access Gateway is acting as the Proxy NSIS
   initiator on behalf of the UE/MS, then it may have to do the mapping
   of parameters from radio access specific QoS information are
   useful to avoid the need to store codec information in the PCF and to allow for more flexibility and accurate description of the IP QoS traffic parameters. The PCF also controls
   parameters before forwarding the GGSN request to open and close the gates and to configure per-flow policers, i.e. to authorize or
   forbid user traffic. NSIS Forwarder.

   The NSIS Forwarder is (of course) currently not part of the standard UMTS 3G wireless
   architecture. However, to achieve end-to-end QoS a NSIS Forwarder is
   needed such that the PCF NSIS Initiators can request a QoS connection to
   the IP network. As in the previous example, the NSIS Forwarder could
   manage a set of pre-provisioned resources in the IP network, i.e.
   bandwidth pipes, and the NSIS Forwarder performs per-flow admission
   control into these pipes. In this way, a connection can be made
   between two
   UMTS 3G wireless access networks, and hence, end-to-end QoS
   can be achieved. In this case the NSIS Initiator and NSIS Forwarder
   are clearly two separate logical entities. The Access Gateway or/and
   the Edge Router in Fig.1 may contain the NSIS Forwarder
   functionality, depending upon the placement of the NSIS Initiator as
   discussed in scenario 2 in section 10.2. This use case clearly
   illustrates the need for an "NSIS" QoS signaling protocol between
   NSIS Initiator and NSIS Forwarder. An important application of such
   a protocol may be its use in the
   inter-connection end-to-end establishment of UMTS networks over an IP backbone. a
   connection with specific QoS characteristics between a mobile host
   and another party (e.g. end host or content server).

10.4 Wired part of wireless network

   A wireless network, seen from a QoS domain perspective, usually
   consists of three parts: a wireless interface part (the "radio
   interface"), a wired part of the wireless network (i.e., Radio
   Access Network) and the backbone of the wireless network, as shown
   in Figure 2. Note that this figure should not be seen as an
   architectural overview of wireless networks but rather as showing
   the conceptual QoS domains in a wireless network.

   In this scenario, a mobile host can roam and perform a handover
   procedure between base stations/access routers. In this scenario the
   NSIS QoS protocol can be applied between a base station and the
   gateway (GW).  In this case a GW can also be considered as a local
   handover anchor point. Furthermore, in this scenario the NSIS QoS
   protocol can also be applied either between two GWs, or between two
   edge routers (ER).

   |--|                   |--|
   |MH|---                 .
   |--|  / |-------|       .
        /--|base   | |--|  .
           |-------| |--|  . |--| back- |--|  |---|              |----|
        -- |-------| |--|  . |--| bone  |--|  |---|              |----|
   |--| \  |base   |-|ER|...     .
   |MH|  \ |station| |--|        .
   |--|--- |-------|             .          MH  = mobile host
                              |--|          ER  = edge router
      <---->                  |GW|          GW  = gateway
     Wireless link            |--|          BGW = border gateway
                                            ... = interior nodes
       Wired part of wireless network

                Wireless Network

      Figure 2. QoS architecture of wired part of wireless network

   Each of these parts of the wireless network impose different issues
   to be solved on the QoS signaling solution being used:

   - Wireless interface: The solution for the air interface link
     has to ensure flexibility and spectrum efficient transmission
     of IP packets.  However, this link layer QoS can be solved in
     the same way as any other last hop problem by allowing a
     host to request the proper QoS profile.

   - Wired part of the wireless network:  This is the part of
     the network that is closest to the base stations/access
     routers.  It is an IP network although some parts logically
     perform tunneling of the end user data. In cellular networks,
     the wired part of the wireless network is denoted as a
     radio access network.

     This part of the wireless network has different
     characteristics when compared to traditional IP networks:

         1. The network supports a high proportion of real-time
            traffic.  The majority of the traffic transported in the
            wired part of the wireless network is speech, which is
            very sensitive to delays and delay variation (jitter).

         2. The network must support mobility. Many wireless
            networks are able to provide a combination of soft
            and hard handover procedures. When handover occurs,
            reservations need to be established on new paths.
            The establishment time has to be as short as possible
            since long establishment times for reservations s degrade
            the performance of the wireless network.  Moreover,
            for maximal utilization of the radio spectrum, frequent
            handover operations are required.

         3. These links are typically rather bandwidth-limited.

         4. The wired transmission in such a network contains a
            relatively high volume of expensive leased lines.
            Overprovisioning might therefore be prohibitively

         5. The radio base stations are spread over a wide
            geographical area and are in general situated a large
            distance from the backbone.

   - Backbone of the wireless network: the requirements imposed
     by this network are similar to the requirements imposed by
     other types of backbone networks.

   Due to these very different characteristics and requirements, often
   contradictory, different QoS signaling solutions might be needed in
   each of the three network parts.

10.5 Session Mobility

   In this scenario, a session is moved from one end-system to another.
   Ongoing sessions are kept and QoS parameters need to be adapted,
   since it is very likely that the new device provides different
   capabilities. Note that it is open which entity initiates the move,
   which implies that the NSIS Initiator might be triggered by
   different entities.

   User mobility (i.e., a user changing the device and therefore moving
   the sessions to the new device) is considered to be a special case
   within the session mobility scenario.

   Note that this scenario is different from terminal mobility. Not the
   terminal (end-system) has moved to a different access point. Both
   terminals are still connected to an IP network at their original

   The issues include:

   1) Keeping the QoS guarantees negotiated implies that the end-
   point(s) of communication are changed without changing the
   reservations. s.

   2) The trigger of the session move might be the user or any other
   party involved in the session.

10.6 QoS reservations/negotiation s/negotiation from access to core network

   The scenario includes the signaling between access networks and core
   networks in order to setup and change reservations s together with potential

   The issues to be solved in this scenario are different from previous

   1) The entity of reservation is most likely an aggregate.

   2) The time scales of reservations s might be different (long living
   reservations s of
   aggregates, less often re-negotiation).

   3) The specification of the traffic (amount of traffic), a
   particular QoS is guaranteed for, needs to be changed. E.g., in case
   additional flows are added to the aggregate, the traffic
   specification of the flow needs to be added if it is not already
   included in the aggregates specification.

   4) The flow specification is more complex including network
   addresses and sets of different address for the source as well as
   for the destination of the flow.

10.7 QoS reservation/negotiation /negotiation over administrative boundaries

   Signaling between two or more core networks to provide QoS is
   handled in this scenario. This might also include access to core
   signaling over administrative boundaries. Compared to the previous
   one it adds the case, where the two networks are not in the same
   administrative domain. Basically, it is the inter-domain/inter
   provider signaling which is handled in here.

   The domain boundary is the critical issue to be resolved. Which as
   various flavors of issues a QoS signaling protocol has to be
   concerned with.

   1) Competing administrations: Normally, only basic information
   should be exchanged, if the signaling is between competing
   administrations. Specifically information about core network
   internals (e.g., topology, technology, etc.) should not be
   exchanged. Some information exchange about the "access points" of
   the core networks (which is topology information as well) may need
   to be exchanged, because it is needed for proper signaling.

   2) Additionally, as in scenario 4, signaling most likely is based on
   aggregates, with all the issues raise there.

   3) Authorization: It is critical that the NSIS Initiator is
   authorized to perform a QoS path setup.

   4) Accountability: It is important to notice that signaling might be
   used as an entity to charge money for, therefore the interoperation
   with accounting needs to be available.

10.8 QoS signaling between PSTN gateways and backbone routers

   A PSTN gateway (i.e., host) requires information from the network
   regarding its ability to transport voice traffic across the network.
   The voice quality will suffer due to packet loss, latency and
   jitter. Signaling is used to identify and admit a flow for which
   these impairments are minimized.  In addition, the disposition of
   the signaling request is used to allow the PSTN GW to make a call
   routing decision before the call is actually accepted and delivered
   to the final destination.

   PSTN gateways may handle thousands of calls simultaneously and there
   may be hundreds of PSTN gateways in a single provider network. These
   numbers are likely to increase as the size of the network increases.
   The point being that scalability is a major issue.

   There are several ways that a PSTN gateway can acquire assurances
   that a network can carry its traffic across the network. These

     1. Over-provisioning a high availability network.
     2. Handling admission control through some policy server
        that has a global view of the network and its resources.
     3. Per PSTN GW pair admission control.
     4. Per call admission control (where a call is defined as
        the 5-tuple used to carry a single RTP flow).

   Item 1 requires no signaling at all and is therefore outside the
   scope of this working group.

   Item 2 is really a better informed version of 1, but it is also
   outside the scope of this working group as it relies on a particular
   telephony signaling protocol rather than a packet admission control

   Item 3 is initially attractive, as it appears to have reasonable
   scaling properties, however, its scaling properties only are
   effective in cases where there are relatively few PSTN GWs. In the
   more general case were a PSTN GW reduces to a single IP phone
   sitting behind some access network, the opportunities for
   aggregation are reduced and the problem reduces to item 4.

   Item 4 is the most general case. However, it has the most difficult
   scaling problems. The objective here is to place the requirements on
   Item 4 such that a scalable per-flow admission control protocol or
   protocol suite may be developed.

   The case where per-flow signaling extends to individual IP end-
   points allows the inclusion of IP phones on cable, DSL, wireless or
   other access networks in this scenario.

   Call Scenario

   A PSTN GW signals end-to-end for some 5-tuple defined flow a
   bandwidth and QoS requirement. Note that the 5-tuple might include
   masking/wildcarding. The access network admits this flow according
   to its local policy and the specific details of the access

   At the edge router (i.e., border node), the flow is admitted, again
   with an optional authentication process, possibly involving an
   external policy server.  Note that the relationship between the PSTN
   GW and the policy server and the routers and the policy server is
   outside the scope of NSIS. The edge router then admits the flow into
   the core of the network, possibly using some aggregation technique.

   At the interior nodes, the NSIS host-to-host signaling should either
   be ignored or invisible as the Edge router performed the admission
   control decision to some aggregate.

   At the inter-provider router (i.e., border node), again the NSIS
   host-to-host signaling should either be ignored or invisible, as the
   Edge router has performed an admission control decision about an
   aggregate across a carrier network.

10.9 PSTN trunking gateway

   One of the use cases for the NSIS signaling protocol is the scenario
   of interconnecting PSTN gateways with an IP network that supports
   Four different scenarios are considered here.
     1. In-band QoS signaling is used. In this case the Media Gateway
        (MG) will be acting as the NSIS Initiator and the Edge Router
        (ER) will be the NSIS Forwarder. Hence, the ER should do
        admission control (into pre-provisioned traffic trunks) for the
        individual traffic flows. This scenario is not further
        considered here.

     2. Out-of-band signaling in a single domain, the NSIS forwarder is
        integrated in the MGC. In this case no NSIS protocol is
     3. Out-of-band signaling in a single domain, the NSIS forwarder is
        a separate box. In this case NSIS signaling is used between the
        MGC and the NSIS Forwarder.
     4. Out-of-band signaling between multiple domains, the NSIS
        Forwarder (which may be integrated in the MGC) triggers the
        NSIS Forwarder of the next domain.

   When the out-of-band QoS signaling is used the Media Gateway
   Controller (MGC) will be acting as the NSIS Initiator.

   In the second scenario the voice provider manages a set of traffic
   trunks that are leased from a network provider. The MGC does the
   admission control in this case. Since the NSIS Forwarder acts both
   as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is
   required. This scenario is shown in Figure 3.

     +-------------+    ISUP/SIGTRAN     +-----+              +-----+
     | SS7 network |---------------------| MGC |--------------| SS7 |
     +-------------+             +-------+-----+---------+    +-----+
           :                    /           :             \
           :                   /            :              \
           :                  /    +--------:----------+    \
           :          MEGACO /    /         :           \    \
           :                /    /       +-----+         \    \
           :               /    /        | NMS |          \    \
           :              /     |        +-----+          |     \
           :              :     |                         |     :
    +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
    | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
    +--------------+  +----+     \                       /   +----+
                                  \     QoS network     /

                 Figure 3: PSTN trunking gateway scenario

   In the third scenario, the voice provider does not lease traffic
   trunks in the network. Another entity may lease traffic trunks and
   may use a NSIS Forwarder to do per-flow admission control. In this
   case the NSIS signaling is used between the MGC and the NSIS
   Forwarder, which is a separate box here. Hence, the MGC acts only as
   a NSIS Initiator. This scenario is depicted in Figure 4.

      +-------------+    ISUP/SIGTRAN     +-----+              +-----+
      | SS7 network |---------------------| MGC |--------------| SS7 |
      +-------------+             +-------+-----+---------+    +-----+
            :                    /           :             \
            :                   /         +-----+           \
            :                  /          | NF  |            \
            :                 /           +-----+             \
            :                /               :                 \
            :               /       +--------:----------+       \
            :       MEGACO :       /         :           \       :
            :              :      /       +-----+         \      :
            :              :     /        | NMS |          \     :
            :              :     |        +-----+          |     :
            :              :     |                         |     :
     +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
     | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
     +--------------+  +----+     \                       /   +----+
                                   \     QoS network     /

                 Figure 4: PSTN trunking gateway scenario

   In the fourth scenario multiple transport domains are involved. In
   the originating network either the MGC may have an overview on the
   resources of the overlay network or a separate NSIS Forwarder will
   have the overview. Hence, depending on this either the MGC or the
   NSIS Forwarder of the originating domain will contact the NSIS
   Forwarder of the next domain. The MGC always acts as a NSIS
   Initiator and may also be acting as a NSIS Forwarder in the first

10.10  Application request end-to-end QoS path from the network

   This is actually the easiest case, nevertheless might be most often
   used in terms of number of users. So multimedia application requests
   a guaranteed service from an IP network. We assume here that the
   application is somehow able to specify the network service. The
   characteristics here are that many hosts might do it, but that the
   requested service is low capacity (bounded by the access line).
   Additionally, we assume no mobility and standard devices.

   QOS for Virtual Private Networks

   In a Virtual Private Network (VPN) a variety of tunnels might be
   used between its edges. These tunnels could be for example, IP-Sec,
   GRE, and IP-IP. One of the most significant issues in VPNs is
   related to how a flow is identified and what quality a flow gets. A
   flow identification might consist among others of the transport
   protocol port numbers. In an IP-Sec tunnel this will be problematic
   since the transport protocol information is encrypted.

   There are two types of L3 VPNs, distinguished by where the endpoints
   of the tunnels exist. The endpoints of the tunnels may either be on
   the customer (CPE) or the provider equipment or provider edge (PE).

   Virtual Private networks are also likely to request bandwidth or
   other type of service in addition to the premium services the PSTN
   GW are likely to use.

   Tunnel end points at the Customer premises

   When the endpoints are the CPE, the CPE may want to signal across
   the public IP network for a particular amount of bandwidth and QoS
   for the tunnel aggregate. Such signaling may be useful when a
   customer wants to vary their network cost with demand, rather than
   paying a flat rate. Such signaling exists between the two CPE
   routers. Intermediate access and edge routers perform the same exact
   call admission control, authentication and aggregation functions
   performed by the corresponding routers in the PSTN GW scenario with
   the exception that the endpoints are the CPE tunnel endpoints rather
   than PSTN GWs and the 5-tuple used to describe the RTP flow is
   replaced with the corresponding flow spec to uniquely identify the
   tunnels. Tunnels may be of any variety (e.g. IP-Sec, GRE, IP-IP).

   In such a scenario, NSIS would actually allow partly for customer
   managed VPNs, which means a customer can setup VPNs by subsequent
   NSIS signaling to various end-point. Plus the tunnel end-points are
   not necessarily bound to an application. The customer administrator
   might be the one triggering NSIS signaling.

   Tunnel end points at the provider premises

   In the case were the tunnel end-points exist on the provider edge,
   requests for bandwidth may be signaled either per flow, where a flow
   is defined from a customers address space, or between customer

   In the case of per flow signaling, the PE router must map the
   bandwidth request to the tunnel carrying traffic to the destination
   specified in the flow spec. Such a tunnel is a member of an
   aggregate to which the flow must be admitted. In this case, the
   operation of admission control is very similar to the case of the
   PSTN GW with the additional level of indirection imposed by the VPN
   tunnel. Therefore, authentication, accounting and policing may be
   required on the PE router.

   In the case of per site signaling, a site would need to be
   identified. This may be accomplished by specifying the network
   serviced at that site through an IP prefix. In this case, the
   admission control function is performed on the aggregate to the PE
   router connected to the site in question.

Full Copyright Statement

  Copyright (C) The Internet Society (2002). All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works. However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an


   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights, which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive