draft-ietf-nsis-req-06.txt   draft-ietf-nsis-req-07.txt 
Network Working Group M. Brunner (Editor) Network Working Group M. Brunner (Editor)
Internet Draft NEC Internet Draft NEC
Category: Informational December 2002 Category: Informational March 2003
Requirements for Signaling Protocols Requirements for Signaling Protocols
<draft-ietf-nsis-req-06.txt> <draft-ietf-nsis-req-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
This document defines requirements for signaling across different This document defines requirements for signaling across different
network environments, where different network environments mean network environments, such as across administrative and/or
across administrative and technology domains. Signaling is mainly technology domains. Signaling is mainly considered for Quality of
though for QoS such as [RSVP], however in recent year several other Service such as The Resource Reservation Protocol, however in recent
applications of signaling have been defined such as signaling for years several other applications of signaling have been defined such
MPLS label distribution [RSVP-TE]. To achieve wide applicability of as signaling for label distribution in Multiprotocol Label Switching
the requirements, the starting point is a diverse set of or signaling to middleboxes. To achieve wide applicability of the
scenarios/use cases concerning various types of networks and requirements, the starting point is a diverse set of scenarios/use
application interactions. This memo present the assumptions and the cases concerning various types of networks and application
aspects not considered within scope before listing the requirements interactions. This document presents the assumptions before listing
grouped according to areas such as architecture and design goals, the requirements. The requirements are grouped according to areas
signaling flows, layering, performance, flexibility, security, and such as architecture and design goals, signaling flows, layering,
mobility. performance, flexibility, security, and mobility.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
Abstract...........................................................1 Abstract...........................................................1
Table of Contents..................................................1 Table of Contents..................................................2
1 Introduction.....................................................2 1 Introduction.....................................................2
1.1. Keywords....................................................3
2 Terminology......................................................3 2 Terminology......................................................3
3 Problem Statement and Scope......................................5 3 Problem Statement and Scope......................................4
4 Assumptions and Exclusions.......................................6 4 Assumptions and Exclusions.......................................5
4.1 Assumptions and Non-Assumptions................................6 4.1 Assumptions and Non-Assumptions................................5
4.2 Exclusions.....................................................7 4.2 Exclusions.....................................................6
5 Requirements.....................................................9 5 Requirements.....................................................7
5.1 Architecture and Design Goals..................................9 5.1 Architecture and Design Goals..................................8
5.2 Signaling Flows...............................................11 5.2 Signaling Flows................................................9
5.3 Messaging.....................................................13 5.3 Messaging.....................................................10
5.4 Control Information...........................................14 5.4 Control Information...........................................12
5.5 Performance...................................................16 5.5 Performance...................................................13
5.6 Flexibility...................................................17 5.6 Flexibility...................................................15
5.7 Security......................................................18 5.7 Security......................................................16
5.8 Mobility......................................................20 5.8 Mobility......................................................18
5.9 Interworking with other protocols and techniques..............20 5.9 Interworking with other protocols and techniques..............18
5.10 Operational..................................................21 5.10 Operational..................................................19
6 Security Considerations.........................................22 6 Security Considerations.........................................19
7 Informative References..........................................22 7 References......................................................19
8 Acknowledgments.................................................22 7.1 Normative References..........................................19
9 Author's Addresses..............................................22 7.2 Non-Normative References......................................20
10 Appendix: Scenarios/Use cases..................................23 8 Acknowledgments.................................................20
10.1 Terminal Mobility............................................23 9 Author's Addresses..............................................20
10.2 Cellular Networks............................................25 10 Appendix: Scenarios/Use cases..................................21
10.3 UMTS access..................................................26 10.1 Terminal Mobility............................................21
10.4 Wired part of wireless network...............................27 10.2 3G Wireless Networks.........................................23
10.5 Session Mobility.............................................29 10.3 An example scenario for 3G wireless networks.................24
10.6 QoS reservations/negotiation from access to core network.....30 10.4 Wired part of wireless network...............................26
10.7 QoS reservation/negotiation over administrative boundaries...30 10.5 Session Mobility.............................................27
10.8 QoS signaling between PSTN gateways and backbone routers.....31 10.6 QoS s/negotiation from access to core network................28
10.9 PSTN trunking gateway........................................32 10.7 QoS /negotiation over administrative boundaries..............28
10.10 Application request end-to-end QoS path from the network....34 10.8 QoS signaling between PSTN gateways and backbone routers.....29
10.9 PSTN trunking gateway........................................30
10.10 Application request end-to-end QoS path from the network....32
1 Introduction 1 Introduction
This document defines requirements for signaling across different This document defines requirements for signaling across different
network environments. It does not list any problems of existing network environments. It does not list any problems of existing
signaling protocols such as [RSVP]. signaling protocols such as [RSVP].
In order to derive requirements for signaling it is necessary to In order to derive requirements for signaling it is necessary to
first have an idea of the scope within which they are applicable. first have an idea of the scope within which they are applicable.
Therefore, we define a conceptual model of signaling on an abstract Therefore, we list use cases and scenarios where an NSIS protocol
level. Additionally, we describe the entities involved in signaling could be applied. The scenarios are used to help derive requirements
and typical signaling paths. In the appendix are a list of use cases and to test the requirements against use cases.
and scenarios where an NSIS protocol could be applied. It is though
of helping derive the requirements and to t4est the requirements
against use cases.
QoS and signaling for QoS is a pretty large field with a lot of The requirements listed are independent of any application. However,
interaction with other protocols, mechanisms, applications etc. resource reservation and QoS related issues are used as example
However, it is not the only field where signaling is used in the within the text. However, QoS is not the only field where signaling
Internet. Even if this requirement documents mainly used QoS as the is used in the Internet. Others might be the use for middlebox
sample application other application must be possible and are also communication [RFC3234].
addressed.
There are several areas related to networking aspects which are There are several areas related to networking aspects which are
incomplete, for example, interaction with host and site multi- incomplete, for example, interaction with host and site multi-
homing, use of anycast services, and so on. These issues should be homing, use of anycast services, and so on. These issues should be
considered in any future analysis work. considered in any future analysis work.
2 Terminology 1.1. Keywords
We try to list the most often used terms in the document. However, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
don't be to religious about it, they are not meant to prescribe any "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
solution in the document. All of them need refined definitions in this document are to be interpreted as described in RFC 2119
follow-up documents. [KEYWORDS].
Resource Management Function (RMF): An abstract concept, 2 Terminology
representing the management of resources in a domain or a node. This
includes admission control and resource allocation.
NSIS Domain (ND): Administrative domain where an NSIS protocol We list the most often used terms in the document. However, they
signals for a resource or set of resources. cannot be made precise without a more complete architectural model,
and they are not meant to prescribe any solution in the document.
Where applicable, they will be defined in protocol documents.
NSIS Entity (NE): The function within a node, which implements an NSIS Entity (NE): The function within a node, which implements an
NSIS protocol. NSIS protocol. In the case of path-coupled signaling, the NE will
always be on the data path.
NSIS Forwarder (NF): NSIS Entity on the path between a NI and NR, NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may
which may interact with local resource management function (RMF) for interact with local state management functions in the network. It
this purpose. NSIS Forwarder also propagates NSIS signaling further also propagates NSIS signaling further through the network.
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
policy.
NSIS Initiator (NI): NSIS Entity that initiates NSIS signaling for a NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set
network resource based on user or application requirements. This can up or manipulate network state.
be located in the end system, but may reside elsewhere in network.
NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well. can optionally interact with applications as well.
Flow: A traffic stream (sequence of IP packets between two end Flow: A traffic stream (sequence of IP packets between two end
systems) for which a specific packet level treatment is provided. systems) for which a specific packet level treatment is provided.
The flow can be unicast (uni- or bi-directional) or multicast. For The flow can be unicast (uni- or bi-directional) or multicast. For
multicast, a flow can diverge into multiple flows as it propagates multicast, a flow can diverge into multiple flows as it propagates
toward the receiver. For multi-sender multicast, a flow can also toward the receiver. For multi-sender multicast, a flow can also
diverge when viewed in the reverse direction (toward the senders). diverge when viewed in the reverse direction (toward the senders).
Higher Layers: The higher layer (transport protocol and application) Data Path: The route across the networks taken by a flow or
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 route across the networks taken by a flow or
aggregate, i.e. which domains/subdomains it passes through and the aggregate, i.e. which domains/subdomains it passes through and the
egress/ingress points for each. egress/ingress points for each.
Signaling Path: the route across the networks taken by a signaling Signaling Path: The route across the networks taken by a signaling
flow or aggregate, i.e. which domains/subdomains it passes through flow or aggregate, i.e. which domains/subdomains it passes through
and the egress/ingress points for each. and the egress/ingress points for each.
Path Segment: The segment of a path within a single Path-coupled signaling: A mode of signaling where the signaling
domain/subdomain. messages follow a path that is tied to the data packets. Signaling
messages are routed only through nodes (NEs) that are in the data
Control Information: the information the governs for instance the path.
QoS treatment to be applied to a flow or aggregate, including the
service class, flow administration, and any associated security or
accounting information.
Provisioning: the act of actually allocating resources 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
resources.
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 or a network node can provide it to packets.
Sender-initiated signaling protocol: A sender-initiated signaling Path-decoupled signaling: Signaling with independent data and
protocol is a protocol where the NSIS Initiator initiates the signaling paths. Signaling messages are routed to nodes (NEs) which
signaling on behalf of the sender of the data. What this means is are not assumed to be on the data path, but which are (presumably)
that resource management functions are processed from the data aware of it. Signaling messages will always be directly addressed to
sender towards the data receiver. However, the triggering instance the neighbor NE, and the NI/NR may have no relation at all with the
is not specified. ultimate data sender or receiver.
Receiver-initiated signaling protocol: A receiver-initiated protocol Service: A generic something provided by one entity and consumed by
(e.g., [RSVP]) is a protocol, where the NSIS Responder on behalf of another. It can be constructed by allocating resources. The network
the receiver of the user data initiates the reservation. What this can provide it to users or a network node can provide it to packets.
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 3 Problem Statement and Scope
We provide in the following a preliminary architectural picture as a We provide in the following a preliminary architectural picture as a
basis for discussion. We will refer to it in the following basis for discussion. We will refer to it in the following
requirement sections. 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
aspects.
Note that this model is intended not to constrain the technical Note that this model is intended not to constrain the technical
approach taken subsequently, simply to allow concrete phrasing of approach taken subsequently, simply to allow concrete phrasing of
requirements (e.g. requirements about placement of the NSIS requirements (e.g. requirements about placement of the NSIS
Initiator.) Initiator.)
Roughly, the scope of NSIS is assumed to be the interaction between Roughly, the scope of NSIS is assumed to be the interaction between
the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder the NSIS Initiator and NSIS Forwarder(s), and NSIS Responder
including a protocol to carry the information, and the including a protocol to carry the information, and the
syntax/semantics of the information that is exchanged. Further syntax/semantics of the information that is exchanged. Further
statements on assumptions/exclusions are given in the next Section. statements on assumptions/exclusions are given in the next Section.
The main elements are: The main elements are:
1. Something that starts the request for resources, the NSIS 1. Something that starts the request for state to be set up in the
Initiator. network, the NSIS Initiator.
This might be in the end system or within some other part of the 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 network. The distinguishing feature of the NSIS Initiator is that it
acts on triggers coming (directly or indirectly) from the higher acts on triggers coming (directly or indirectly) from the higher
layers in the end systems. It needs to map the resources requested layers in the end systems. It needs to map the services requested by
by them, and also provides feedback information to the higher them, and also provides feedback information to the higher layers,
layers, which might be used by transport layer rate management or which might be used by transport layer algorithms or adaptive
adaptive applications. applications.
2. Something that assists in managing resources further along the 2. Something that assists in managing state further along the
signaling path, the NSIS Forwarder. signaling path, the NSIS Forwarder.
The NSIS Forwarder does not interact with higher layers, but The NSIS Forwarder does not interact with higher layers, but
interacts with the NSIS Initiator, NSIS Responder, and possibly one interacts with the NSIS Initiator, NSIS Responder, and possibly one
or more NSIS Forwarders on the signaling path, edge-to-edge or end- or more NSIS Forwarders on the signaling path, edge-to-edge or end-
to-end. to-end.
3. Something that terminates the signaling path, the NSIS Responder. 3. Something that terminates the signaling path, the NSIS Responder.
The NSIS responder might be in an end-system or within other The NSIS responder might be in an end-system or within other
equipment. The distinguishing feature of the NSIS Initiator is that equipment. The distinguishing feature of the NSIS Initiator is that
it responds to request at the end of a signaling path. it responds to requests at the end of a signaling path.
4. The path segment traverses an underlying network covering one or 4. The signaling path traverses an underlying network covering one
more IP hops. The underlying network might use locally different or more IP hops. The underlying network might use locally different
technology. For instance, QoS technology has to be provisioned technology. For instance, QoS technology has to be provisioned
appropriately for the service requested. In the QoS example, an NSIS appropriately for the service requested. In the QoS example, an NSIS
Forwarder maps service-specific information to technology-related Forwarder maps service-specific information to technology-related
QoS parameters and receiving indications about success or failure in QoS parameters and receives indications about success or failure in
response. response.
Now concentrating more on the overall end to end (multiple domain) 5. We can see the network at the level of domains/subdomains rather
aspects, in particular: than individual routers (except in the special case that the domain
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
Forwarder.
2. We 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 contains one link). Domains are assumed to be administrative
entities, so security requirements apply to the signaling between entities, so security requirements apply to the signaling between
them. them.
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
fixed.
4 Assumptions and Exclusions 4 Assumptions and Exclusions
4.1 Assumptions and Non-Assumptions 4.1 Assumptions and Non-Assumptions
1. The NSIS signaling could run end to end, end to edge, or edge to 1. The NSIS signaling could run end to end, end-to-edge, or edge-to-
edge, or network-to-network ((between providers), depending on what edge, or network-to-network ((between providers), depending on what
point in the network acts as the initiator, and how far towards the point in the network acts as NSIS initiator, and how far towards the
other end of the network the signaling propagates. In general, we other end of the network the signaling propagates. In general, we
could expect NSIS Forwarders to become more 'dense' towards the could expect NSIS Forwarders to become more 'dense' towards the
edges of the network, but this is not a requirement. An over- edges of the network, but this is not a requirement. For example, in
provisioned domain might contain no NSIS Forwarders at all (and be the case of QoS, an over-provisioned domain might contain no NSIS
NSIS transparent); at the other extreme, NSIS Forwarders might be Forwarders at all (and be NSIS transparent); at the other extreme,
placed at every router. In the latter case, provisioning can be NSIS Forwarders might be placed at every router. In the latter case,
carried out in a local implementation-dependent way without further QoS provisioning can be carried out in a local implementation-
signaling, whereas in the case of remote NSIS Forwarders, a dependent way without further signaling, whereas in the case of
provisioning protocol might be needed to control the routers along remote NSIS Forwarders, a protocol might be needed to control the
the path. This provisioning protocol is then independent of the end- routers along the path. This protocol is then independent of the
to-end NSIS signaling. end-to-end NSIS signaling.
2. We do not consider 'pure' end-to-end signaling that is not 2. We do not consider 'pure' end-to-end signaling that is not
interpreted anywhere within the network. Such signaling is an interpreted anywhere within the network. Such signaling is a higher-
application-layer issue and IETF protocols such as SIP etc. can be layer issue and IETF protocols such as SIP etc. can be used.
used.
3. Where the signaling does cover several NSIS domains or 3. Where the signaling does cover several domains, we do not exclude
subdomains, we do not exclude that different signaling protocols are that different signaling protocols are used in each domain. We only
used in each path segment. We only place requirements on the place requirements on the universality of the control information
universality of the control information that is being transported. that is being transported. (The goals here would be to allow the use
(The goals here would be to allow the use of signaling protocols, of signaling protocols, which are matched to the characteristics of
which are matched to the characteristics of the portion of the the portion of the network being traversed.) Note that the outcome
network being traversed.) Note that the outcome of NSIS work might of NSIS work might result in various flavors of the same protocol.
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 4. We assume that the service definitions a NSIS Initiator can ask
for are known in advance of the signaling protocol running. For for are known in advance of the signaling protocol running. For
instance in the QoS example, the service definition includes QoS instance in the QoS example, the service definition includes QoS
parameters, lifetime of QoS guarantee etc., or any other service- parameters, lifetime of QoS guarantee etc., or any other service-
specific parameters. specific parameters.
There are many ways service requesters get to know about it. There There are many ways service requesters get to know about available
might be standardized services, the definition can be negotiated services. There might be standardized services, the definition can
together with a contract, the service definition is published at a be negotiated together with a contract, the service definition is
Web page, etc. published in some on-line directory (e.g., at a Web page), and so
on.
5. We assume that there are means for the discovery of NSIS entities 5. We assume that there are means for the discovery of NSIS entities
in order to know the signaling peers (solutions include static in order to know the signaling peers (solutions include static
configuration, automatically discovered, or implicitly runs over the configuration, automatically discovered, or implicitly runs over the
right nodes, etc.) The discovery of the NSIS entities has security right nodes along the data path, etc.) The discovery of the NSIS
implications that need to be addressed properly. These implications entities has security implications that need to be addressed
largely depend on the chosen protocol. For some security mechanisms properly. For some security mechanisms (i.e. Kerberos, pre-shared
(i.e. Kerberos, pre-shared secret) it is required to know the secret) it is required to know the identity of the other entity.
identity of the other entity. Hence the discovery mechanism may Hence the discovery mechanism may provide means to learn this
provide means to learn this identity, which is then later used to identity, which is then later used to retrieve the required keys and
retrieve the required keys and parameters. parameters.
6. NSIS assumes to operate with networks using standard ("normal") 6. NSIS assumes layer 3 routing and the determination of next data
L3 routing. Where "normal" is not specified more exactly on purpose. node selection is not done by NSIS.
4.2 Exclusions 4.2 Exclusions
1. Development of specific mechanisms and algorithms for application 1. Development of specific mechanisms and algorithms for application
and transport layer adaptation are not considered, nor are the and transport layer adaptation are not considered, nor are the
protocols that would support it. protocols that would support it.
2. Specific mechanisms (APIs and so on) for interaction between 2. Specific mechanisms (APIs and so on) for interaction between
transport/applications and the network layer are not considered, transport/applications and the network layer are not considered,
except to clarify the requirements on the negotiation capabilities except to clarify the requirements on the negotiation capabilities
and information semantics that would be needed of the signaling and information semantics that would be needed of the signaling
protocol. protocol.
3. Specific mechanisms for provisioning within a domain/subdomain 3. Specific mechanisms and protocols for provisioning or other
are not considered. However, NSIS can be used for signaling within a network control functions within a domain/subdomain are not
domain/subdomain performing provisioning. For instance in the QoS considered. The goal is to reuse existing functions and protocols
example, it means that the setting of QoS mechanisms in a domain is unchanged. However, NSIS itself can be used for signaling within a
out of scope, but if we have a tunnel, NSIS could also be used for domain/subdomain.
tunnel setup with QoS guaranties. It should be possible to exploit
these mechanisms optimally within the end-to-end context. For instance in the QoS example, it means that the setting of QoS
Consideration of how to do this might generate new requirements for mechanisms in a domain is out of scope, but if we have a tunnel,
NSIS however. For example, the information needed by a NSIS NSIS could also be used for tunnel setup with QoS guarantees. It
Forwarder to manage a radio subnetwork needs to be provided by the should be possible to exploit these mechanisms optimally within the
NSIS solution. 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 4. Specific mechanisms (APIs and so on) for interaction between the
network layer and underlying provisioning mechanisms are not network layer and underlying provisioning mechanisms are not
considered. considered.
5. Interaction with resource management capabilities is not 5. Interaction with resource management or other internal state
considered. Standard protocols might be used for this. This may management capabilities is not considered. Standard protocols might
imply requirements for the sort of information that should be be used for this. This may imply requirements for the sort of
exchanged between the NSIS entities. information that should be exchanged between the NSIS entities.
6. Security implications related to multicasting are outside the 6. Security implications related to multicasting are outside the
scope of the signaling protocol. scope of the signaling protocol.
7. Protection of non-signaling messages is outside the scope of the 7. Service definitions and in particular QoS services and classes
protocol
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 to signaling. One example of such an interaction is
the different flow identification with and without IPSec protection.
Many security properties are likely to be application specific and
may be provided by the corresponding application layer protocol.
8. Service definitions and in particular QoS services and classes
are out of scope. Together with the service definition any are out of scope. Together with the service definition any
definition of service specific parameters are not considered in this definition of service specific parameters are not considered in this
document. Only the base NSIS signaling protocol for transporting the document. Only the base NSIS signaling protocol for transporting the
service information are addressed. service information are addressed.
9. Similarly, specific methods, protocols, and ways to express 8. Similarly, specific methods, protocols, and ways to express
service information in the Application/Session level are not service information in the Application/Session level are not
considered (e.g., SDP, SIP, RTSP, etc.). considered (e.g., SDP, SIP, RTSP, etc.).
10. The specification of any extensions needed to signal information 9. The specification of any extensions needed to signal information
via application level protocols (e.g. SDP), and the mapping on NSIS via application level protocols (e.g. SDP), and the mapping on NSIS
information are considered outside of the scope of NSIS working information are considered outside of the scope of NSIS working
group, as this work is in the direct scope of other IETF working group, as this work is in the direct scope of other IETF working
groups (e.g. MMUSIC). groups (e.g. MMUSIC).
11. Handoff decision and trigger sources: An NSIS protocol is not 10. Handoff decision and trigger sources: An NSIS protocol is not
used to trigger handoffs in mobile IP, nor is it used to decide 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 whether to handoff or not. As soon as or in some situation even
before a handoff happened, an NSIS protocol might be used for before a handoff happened, an NSIS protocol might be used for
signaling for the particular service again. The basic underlying signaling for the particular service again. The basic underlying
assumption is that the route comes first (defining the path) and the assumption is that the route comes first (defining the path) and the
signaling comes after it (following the path). This doesn't prevent signaling comes after it (following the path). This doesn't prevent
a signaling application at some node interacting with something that a signaling application at some node interacting with something that
modifies the path, but the requirement is then just for NSIS to live modifies the path, but the requirement is then just for NSIS to live
with that possibility. However, NSIS must interwork with several with that possibility. However, NSIS must interwork with several
protocols for mobility management. protocols for mobility management.
12. Service monitoring is out of scope. It is heavily dependent on 11. Service monitoring is out of scope. It is heavily dependent on
the type of the application and or transport service, and in what the type of the application and or transport service, and in what
scenario it is used. scenario it is used.
5 Requirements 5 Requirements
This section defines more detailed requirements for a signaling This section defines more detailed requirements for a signaling
solution, respecting the framework, scoping assumptions, and solution, respecting the framework, scoping assumptions, and
terminology considered earlier. The requirements are in subsections, terminology considered earlier. The requirements are in subsections,
grouped roughly according to general technical aspects: architecture grouped roughly according to general technical aspects: architecture
and design goals, topology issues, parameters, performance, and design goals, topology issues, parameters, performance,
security, information, and flexibility. security, information, and flexibility.
Two general (and potentially contradictory) goals for the solution Two general (and potentially contradictory) goals for the solution
are that it should be applicable in a very wide range of scenarios, are that it should be applicable in a very wide range of scenarios,
and at the same time lightweight in implementation complexity and and at the same time lightweight in implementation complexity and
resource requirements in nodes. One approach to this is that the resource consumption requirements in NSIS Entities. One approach to
solution could deal with certain requirements via modular components this is that the solution could deal with certain requirements via
or capabilities, which are optional to implement in individual modular components or capabilities, which are optional to implement
nodes. or use in individual nodes.
In order to prioritize the various requirements we define different In order to prioritize the various requirements we informally define
'parts of the network'. In the different parts of the network a different 'parts of the network'. In the different parts of the
particular requirement might have a different priority. network a particular requirement might have a different priority.
The parts of the networks we differentiate are the host-to-first 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, the access network, and the core network. The host to first
router part includes all the layer 2 technologies to access to the router part includes all the layer 2 technologies to access to the
Internet. In many cases, there is an application and/or user running Internet. In many cases, there is an application and/or user running
on the host initiating signaling. The access network can be on the host initiating signaling. The access network can be
characterized by low capacity links, medium speed IP processing characterized by low capacity links, medium speed IP processing
capabilities, and it might consist of a complete layer 2 network as capabilities, and it might consist of a complete layer 2 network as
well. The core network characteristics include high-speed forwarding well. The core network characteristics include high-speed forwarding
capacities and inter-domain issues. These divisions between network capacities and inter-domain issues. These divisions between network
skipping to change at page 10, line 4 skipping to change at page 8, line 25
on the host initiating signaling. The access network can be on the host initiating signaling. The access network can be
characterized by low capacity links, medium speed IP processing characterized by low capacity links, medium speed IP processing
capabilities, and it might consist of a complete layer 2 network as capabilities, and it might consist of a complete layer 2 network as
well. The core network characteristics include high-speed forwarding well. The core network characteristics include high-speed forwarding
capacities and inter-domain issues. These divisions between network capacities and inter-domain issues. These divisions between network
types are not strict and do not appear in all networks, but where types are not strict and do not appear in all networks, but where
they do exist they may influence signaling requirements and will be they do exist they may influence signaling requirements and will be
highlighted as necessary. highlighted as necessary.
5.1 Architecture and Design Goals 5.1 Architecture and Design Goals
This section contains requirements related to desirable overall This section contains requirements related to desirable overall
characteristics of a solution, e.g. enabling flexibility, or characteristics of a solution, e.g. enabling flexibility, or
independence of parts of the framework. independence of parts of the framework.
5.1.1 MUST be applicable for different technologies. 5.1.1 NSIS SHOULD provide availability information on request
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 SHOULD provide resource availability information on request
NSIS SHOULD provide a mechanism to check whether resources are NSIS SHOULD provide a mechanism to check whether state to be setup
available without performing a reservation. In some scenarios, e.g., is available without setting it up. For the resource reservation
the mobile terminal scenario, it is required to query, whether example this translates into checking resource availability without
resources are available, without performing a reservation on the performing resource reservation. In some scenarios, e.g., the mobile
resource. terminal scenario, it is required to query, whether resources are
available, without performing a reservation on the resource.
5.1.3 NSIS MUST be designed modularly 5.1.2 NSIS MUST be designed modularly
A modular design allows for more lightweight implementations, if A modular design allows for more lightweight implementations, if
fewer features are needed. Mutually exclusive solutions are fewer features are needed. Mutually exclusive solutions are
supported. Examples for modularity: supported. Examples for modularity:
- Work over any kind of network (narrowband versus broadband, error- - Work over any kind of network (narrowband versus broadband, error-
prone versus reliable, ...). This implies low bandwidth signaling prone versus reliable, ...). This implies low bandwidth signaling,
and redundant information MUST be supported if necessary. and elimination of redundant information MUST be supported if
necessary.
- Uni- and bi-directional reservations are possible - State setup for uni- and bi-directional flows is possible
- Extensible in the future with different add-ons for certain - Extensible in the future with different add-ons for certain
environments or scenarios environments or scenarios
- Protocol layering, where appropriate. This means NSIS MUST provide - Protocol layering, where appropriate. This means NSIS MUST provide
a base protocol, which can be adapted to different environments. a base protocol, which can be adapted to different environments.
5.1.4 NSIS MUST decouple protocol and information 5.1.3 NSIS MUST decouple protocol and information
The signaling protocol MUST be clearly separated from the control The signaling protocol MUST be clearly separated from the control
information being transported. This provides for the independent information being transported. This provides for the independent
development of these two aspects of the solution, and allows for development of these two aspects of the solution, and allows for
this control information to be carried within other protocols, this control information to be carried within other protocols,
including application layer ones, existing ones or those being including application layer ones, existing ones or those being
developed in the future. The gained flexibility in the information developed in the future. The flexibility gained in the transport of
transported allows for the applicability of the same protocol in information allows for the applicability of the same protocol in
various scenarios. various scenarios.
However, note that the information carried needs to be standardized; However, note that the information carried needs to be standardized;
otherwise interoperability is difficult to achieve. otherwise interoperability is difficult to achieve.
5.1.5 NSIS MUST reuse existing provisioning 5.1.4 NSIS MUST support independence of signaling and network control
Reuse existing functions and protocols for provisioning within a
domain/subdomain unchanged. (Motivation: 'Don't re-invent the
wheel'.)
5.1.6 NSIS MUST support independence of signaling and provisioning
paradigm paradigm
The signaling MUST be independent of the paradigm and mechanism of The signaling MUST be independent of the paradigm and mechanism of
provisioning. E.g., in the case of signaling for QoS, the network control. E.g., in the case of signaling for QoS, the
independence of the signaling protocol from the QoS provisioning independence of the signaling protocol from the QoS provisioning
allows for using the NSIS protocol together with various QoS allows for using the NSIS protocol together with various QoS
technologies in various scenarios. technologies in various scenarios.
5.1.7 NSIS MUST be application independent 5.1.5 NSIS SHOULD be able to carry opaque objects
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 the signaling interacts with
upper layer functions (users, applications, and QoS administration),
and lower layer technologies.
Opaque application information MAY get transported in the signaling NSIS SHOULD be able to pass around opaque objects, which are
message, without being handled in the network. Development and interpreted only by some NSIS-capable nodes.
deployment of new applications SHOULD be possible without impacting
the network infrastructure.
5.2 Signaling Flows 5.2 Signaling Flows
This section contains requirements related to the possible signaling This section contains requirements related to the possible signaling
flows that should be supported, e.g. over what parts of the flow flows that should be supported, e.g. over what parts of the flow
path, between what entities (end-systems, routers, middle boxes, path, between what entities (end-systems, routers, middle boxes,
management systems), in which direction. management systems), in which direction.
5.2.1 The placement of NSIS Initiator, Forwarder, Responder MUST be 5.2.1 The placement of NSIS Initiator, Forwarder, and Responder
free anywhere in the network MUST be allowed
The protocol MUST work in various scenarios such as host-to-network- The protocol MUST work in various scenarios such as host-to-network-
to-host, edge-to-edge, (e.g., just within one providers domain), to-host, edge-to-edge, (e.g., just within one provider's domain),
user-to-network (from end system into the network, ending, e.g., at 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 the entry to the network and vice versa), and network-to-network
(e.g., between providers). (e.g., between providers).
Placing the NSIS Forwarder and NSIS Initiator functions at different Placing the NSIS Forwarder and NSIS Initiator functions at different
locations allows for various scenarios to work with the same locations allows for various scenarios to work with the same
protocol. protocol.
5.2.2 No constraint MUST be posed the signaling and NSIS Forwarders to 5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path-
be in the data path. decoupled signaling.
There is a set of scenarios, where signaling is not on the data
path. 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 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 signaling
follow the data path.
There 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 are going to be cases where there will be neither signaling
nor a centralized entity (over-provisioning). Nothing has to be done
anyway.
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 the signaling protocol along an independent path is desired The path-coupled signaling mode MUST be supported. NSIS signaling
by network operators/designers. Ideally, the capability to route the messages are routed only through nodes (NEs) that are in the data
protocol along an independent path would give the network path.
designer/operator the option to manage bandwidth utilization through
the topology.
There are other possibilities as well. An NSIS protocol MUST accept However, there is a set of scenarios, where signaling is not on the
all of these possibilities with a strong focus on the on-path data path. Therefore, NSIS SHOULD NOT exclude the path-decoupled
signaling. signaling mode, where signaling messages are routed to nodes (NEs),
which are not assumed to be on the data path, but which are aware of
it.
5.2.3 Concealment of topology and technology information SHOULD be 5.2.3 Concealment of topology and technology information SHOULD be
possible possible
The NSIS protocol SHOULD allow for hiding the internal structure of The NSIS protocol SHOULD allow for hiding the internal structure of
a NSIS domain from end-nodes and from other networks. Hence an a NSIS domain from end-nodes and from other networks. Hence an
adversary should not be able to learn the internal structure of a adversary should not be able to learn the internal structure of a
network with the help of the signaling protocol. network with the help of the signaling protocol.
In various scenarios, topology information should be hidden for In various scenarios, topology information should be hidden for
various reasons. From a business point of view, some administrations various reasons. From a business point of view, some administrations
don't want to reveal the topology and technology used. don't want to reveal the topology and technology used.
5.2.4 Transparent signaling through networks SHOULD be possible 5.2.4 Transparent signaling through networks SHOULD be possible
It SHOULD be possible that the signaling for some flows traverse It SHOULD be possible that the signaling for some flows traverses
path segments transparently, i.e., without interpretation at NSIS path segments transparently, i.e., without interpretation at NSIS
Forwarders within the network. An example would be a subdomain Forwarders within the network. An example would be a subdomain
within a core network, which only interpreted signaling for within a core network, which only interpreted signaling for
aggregates established at the domain edge, with the flow-related aggregates established at the domain edge, with the signaling for
signaling passing transparently through it. individual flows passing transparently through it.
In other words, NSIS SHOULD work in hierarchical scenarios, where In other words, NSIS SHOULD work in hierarchical scenarios, where
big pipes/trunks are setup using NSIS signaling, but also flows big pipes/trunks are setup using NSIS signaling, but also flows
which run within that big pipe/trunk are setup using NSIS. which run within that big pipe/trunk are setup using NSIS.
5.3 Messaging 5.3 Messaging
5.3.1 Explicit release of resources MUST be possible 5.3.1 Explicit erasure of state MUST be possible
When a resource reservation is no longer necessary, e.g. because the When state along a path is no longer necessary, e.g., because the
application terminates, or because a mobile host experienced a hand- application terminates, or because a mobile host experienced a hand-
off, it MUST be possible to explicitly release resources. In general off, it MUST be possible to erase the state explicitly.
explicit release enhances the overall network utilization.
5.3.2 Automatic release of resources after failure SHOULD be possible 5.3.2 Automatic release of state after failure SHOULD be possible
When the NSIS Initiator goes down, the resources it requested in the When the NSIS Initiator goes down, the state it requested in the
network SHOULD be released, since they will no longer be necessary. network SHOULD be released, since it will no longer be necessary.
After detection of a failure in the network, any NSIS After detection of a failure in the network, any NSIS
Forwarder/Initiator MUST be able to release a reservation it is Forwarder/Initiator MUST be able to release state it is involved in.
involved in. For example, this may require signaling of the "Release For example, this may require signaling of the "Release after
after Failure" message upstream as well as downstream, or soft state Failure" message upstream as well as downstream, or soft state
timing out of reservations. timing out.
The goal is to prevent stale state within the network and adds The goal is to prevent stale state within the network and adds
robustness to the operation of NSIS. So in other words, an NSIS robustness to the operation of NSIS. So in other words, an NSIS
signaling protocol or mechanisms MUST provide means for an NSIS signaling protocol or mechanisms MUST provide means for an NSIS
entity to discover and remove local stale state. entity to discover and remove local stale state.
Note that this might need to work together with a notification Note that this might need to work together with a notification
mechanism. mechanism.
5.3.3 NSIS SHOULD allow for sending notifications upstream 5.3.3 NSIS SHOULD allow for sending notifications upstream
skipping to change at page 13, line 52 skipping to change at page 11, line 25
Recoverable errors: the network nodes can locally repair this type Recoverable errors: the network nodes can locally repair this type
error. The network nodes do not have to notify the users of the error. The network nodes do not have to notify the users of the
error immediately. This is a condition when the danger of error immediately. This is a condition when the danger of
degradation (or actual short term degradation) of the provided degradation (or actual short term degradation) of the provided
service was overcome by the network (NSIS Forwarder) itself. service was overcome by the network (NSIS Forwarder) itself.
Unrecoverable errors: the network nodes cannot handle this type of Unrecoverable errors: the network nodes cannot handle this type of
error, and have to notify the users as soon as possible. error, and have to notify the users as soon as possible.
Service degradation/severe congestion: In case the service cannot be Service degradation: In case the service cannot be provided
provided completely but partially only. completely but only partially.
Repair indication: If an error occurred and it has been fixed, this Repair indication: If an error occurred and it has been fixed, this
triggers the sending of a notification. triggers the sending of a notification.
Service upgrade available: If a previously requested better service Service upgrade available: If a previously requested better service
becomes available. becomes available.
The content of the notification is very service specific, but it is The content of the notification is very service specific, but it is
must at least carry type information. Additionally, it may carry the must at least carry type information. Additionally, it may carry the
location of the state change. location of the state change.
The notifications may or may not be in response to a NSIS message. 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 This means an NSIS entity has to be able to handle notifications at
any time. any time.
Note however, that there are a number of security consideration Note however, that there are a number of security consideration
needs to be solved with notification, even more important if the needs to be solved with notification, even more important if the
notification is sent without prior request (asynchronously). The notification is sent without prior request (asynchronously). The
problem basically is, that everybody could send notifications to any problem basically is, that everybody could send notifications to any
NSIS entity and the NSIS entity most likely reacts on the NSIS entity and the NSIS entity most likely reacts on the
notification. E.g., if it gets an error notification it might notification. For example, if it gets an error notification it might
teardown the reservation, even if everything is ok. So the erase state, even if everything is ok. So the notification might
notification might depend on security associations between the depend on security associations between the sender of the
sender of the notification and its receiver. If a hop-by-hop notification and its receiver. If a hop-by-hop security mechanism is
security mechanism is chosen, this implies also that notifications chosen, this implies also that notifications need to be sent on the
need to be sent on the reverse path. reverse path.
5.3.4 Feedback about success of service request MUST be provided
A request for service MUST be answered at least with yes or no. .3.4 Establishment and refusal to set up state MUST be notified.
However, it may be useful in case of a negative answer to also get a An NR MUST acknowledge establishment of state on behalf of the NI
description of what amount of resources a request is possible. So an requesting establishment of that state. A refusal to set up state
opaque element MAY be included into the answer. The element heavily MUST be replied with a negative acknowledgement by the NE refusing
depends on the service requested. to set up state. It MUST be sent to the NI. Depending on the
signaling application the (positive or negative) notifications may
have to pass through further NEs upstream. Information on the reason
of the refusal to set up state MAY be made available. For example,
in the resource reservation example, together with a negative
answer, the amount of resources available might also be returned.
5.3.5 NSIS MUST allow for local information exchange 5.3.5 NSIS MUST allow for local information exchange
The signaling protocol MUST be able to exchange local information The signaling protocol MUST be able to exchange local information
between NSIS Forwarders located within one single administrative between NSIS Forwarders located within one single administrative
domain. The local information exchange is performed by a number of domain. The local information exchange is performed by a number of
separate messages not belonging to an end-to-end signaling process. separate messages not belonging to an end-to-end signaling process.
Local information might, for example, be IP addresses, severe Local information might, for example, be IP addresses , notification
congestion notification, notification of successful or erroneous of successful or erroneous processing of signaling messages, or
processing of signaling messages. other conditions.
In some cases, the NSIS signaling protocol MAY carry identification In some cases, the NSIS signaling protocol MAY carry identification
of the NSIS Forwarders located at the boundaries of a domain. of the NSIS Forwarders located at the boundaries of a domain.
However, the identification of edge should not be visible to the end However, the identification of edge should not be visible to the end
host (NSIS Initiator) and only applies within one administrative host (NSIS Initiator) and only applies within one administrative
domain. domain.
5.4 Control Information 5.4 Control Information
This section contains requirements related to the control This section contains requirements related to the control
skipping to change at page 15, line 4 skipping to change at page 12, line 34
However, the identification of edge should not be visible to the end However, the identification of edge should not be visible to the end
host (NSIS Initiator) and only applies within one administrative host (NSIS Initiator) and only applies within one administrative
domain. domain.
5.4 Control Information 5.4 Control Information
This section contains requirements related to the control This section contains requirements related to the control
information that needs to be exchanged. information that needs to be exchanged.
5.4.1 Mutability information on parameters SHOULD be possible 5.4.1 Mutability information on parameters SHOULD be possible
It SHOULD be possible for the NSIS initiator to control the It SHOULD be possible for the NSIS initiator to control the
mutability of the signaled information. This prevents from being mutability of the signaled information. This prevents them from
changed in a non-recoverable way. The NSIS initiator SHOULD be able being changed in a non-recoverable way. The NSIS initiator SHOULD be
to control what is requested end to end, without the request being able to control what is requested end to end, without the request
gradually mutated as it passes through a sequence of domains. This being gradually mutated as it passes through a sequence of domains.
implies that in case of changes made on the parameters, the original This implies that in case of changes made on the parameters, the
requested ones must still be available. original requested ones must still be available.
Note that we do not require anything about particular parameters Note that we do not require anything about particular parameters
being changed. being changed.
Additionally, note that a provider or that particular services Additionally, note that the provider of the particular requested
requested, can still influence the provisioning but in the signaling services can still influence the provisioning but in the signaling
message the request should stay the same. message the request should stay the same.
5.4.2 SHOULD possible to add and remove local domain information 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 It SHOULD be possible to add and remove local scope elements.
and remove local scope elements. Compared to Requirement 5.3.5 this Compared to Requirement 5.3.5 this requirement does use the normal
requirement does use the normal signaling process and message signaling process and message exchange for transporting local
exchange for transporting local information. E.g., at the entrance information. For example, at the entrance to a domain domain-
to a domain domain-specific information is added, which is used in specific information is added, which is used in this domain only,
this domain only, and the information is removed again when a and the information is removed again when a signaling message leaves
signaling message leaves the domain. The motivation is in the the domain. The motivation is in the economy of re-using the
economy of re-use the protocol for domain internal signaling of protocol for domain internal signaling of various information
various information pieces. Where additional information is needed pieces. Where additional information is needed within a particular
within a particular domain, it should be possible to carry this at domain, it should be possible to carry this at the same time as the
the same time as the end-to-end information. end-to-end information.
5.4.3 State MUST be addressed independent of flow identification 5.4.3 State MUST be addressed independent of flow identification
Addressing or identifying state MUST be independent of the flow Addressing or identifying state MUST be independent of the flow
identifier (flow end-points, topological addresses). Various identifier (flow end-points, topological addresses). Various
scenarios in the mobility area require this independence because scenarios in the mobility area require this independence because
flows resulting from handoff might have changed end-points etc. but flows resulting from handoff might have changed end-points etc. but
still have the same service requirement. Also several proxy-based still have the same service requirement. Also several proxy-based
signaling methods profit from such independence. signaling methods profit from such independence.
5.4.4 Modification of already reserved resources SHOULD be seamless 5.4.4 Modification of already established state SHOULD be seamless
In many case, the reservation needs to be updated (up or downgrade). In many case, the established state needs to be updated (in QoS
This SHOULD happen seamlessly without service interruption. At least example upgrade or downgrade of resource usage). This SHOULD happen
the signaling protocol should allow for it, even if some data path seamlessly without service interruption. At least the signaling
elements might not be capable of doing so. 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 5.4.5 Grouping of signaling for several micro-flows MAY be provided
NSIS MAY group signaling information for several micro-flow into one NSIS MAY group signaling information for several micro-flow into one
signaling message. The goal of this is the optimization in terms of signaling message. The goal of this is the optimization in terms of
setup delay, which can happen in parallel. This helps applications setup delay, which can happen in parallel. This helps applications
requesting several flows at once. Also potential refreshes (in case requesting several flows at once. Also potential refreshes (in case
of a soft state solution) might profit from grouping. of a soft state solution) might profit from grouping.
However, the network MUST NOT know that a relationship between the However, the network needs not know that a relationship between the
grouped flows exists. There MUST NOT be any transactional semantic grouped flows exists. There MUST NOT be any transactional semantic
associated with the grouping. It is only meant for optimization associated with the grouping. It is only meant for optimization
purposes and each reservation MUST be handled separately from each purposes.
other.
5.5 Performance 5.5 Performance
This section discusses performance requirements and evaluation This section discusses performance requirements and evaluation
criteria and the way in which these could and should be traded off criteria and the way in which these could and should be traded off
against each other in various parts of the solution. against each other in various parts of the solution.
Scalability is a must anyway. However, depending on the scenario the Scalability is always an important requirement for signaling
question to which extends the protocol must be scalable. protocols. However, the type of scalability and its importance
varies from one scenario to another.
Note that many of the performance issues are heavily dependent on Note that many of the performance issues are heavily dependent on
the scenario assumed and are normally a trade-off between speed, the scenario assumed and are normally a trade-off between speed,
reliability, complexity, and scalability. The trade-off varies in reliability, complexity, and scalability. The trade-off varies in
different parts of the network. For example, in radio access different parts of the network. For example, in radio access
networks low bandwidth consumption will overweight the low latency networks low bandwidth consumption will outweigh the low latency
requirement, while in core networks it may be reverse. requirement, while in core networks it may be reverse.
5.5.1 Scalability 5.5.1 Scalability
NSIS MUST be scalable in the number of messages received by a NSIS MUST be scalable in the number of messages received by a
signaling communication partner (NSIS Initiator, NSIS Forwarder, and signaling communication partner (NSIS Initiator, NSIS Forwarder, and
NSIS Responder). The major concern lies in the core of the network, NSIS Responder). The major concern lies in the core of the network,
where large numbers of messages arrive. where large numbers of messages arrive.
It MUST be scalable in number of hand-offs in mobile environments. It MUST be scalable in number of hand-offs in mobile environments.
This mainly applies in access networks, because the core is This mainly applies in access networks, because the core is
transparent to mobility in most cases. transparent to mobility in most cases.
It MUST be scalable in the number of interactions for setting up a It MUST be scalable in the number of interactions for setting up a
reservation. This applies for end-systems setting up several state. This applies for end-systems setting up several states. Some
reservations. Some servers might be expected to setup a large number servers might be expected to setup a large number of states.
of reservations.
Scalability in the number of state per entity MUST be achieved for Scalability in the amount of state per entity MUST be achieved for
NSIS Forwarders in the core of the network. NSIS Forwarders in the core of the network.
And Scalability in CPU use MUST be achieved on end terminals in case Scalability in CPU usage MUST be achieved on end terminals and
of many reservations at the same time and intermediate nodes mainly intermediate nodes in case of many state setup processes at the same
in the core. time.
5.5.2 NSIS SHOULD allow for low latency in setup 5.5.2 NSIS SHOULD allow for low latency in setup
NSIS SHOULD allow for low latency setup of reservations. This is NSIS SHOULD allow for low latency setup of states. This is only
only needed in scenarios, where reservations are in a short time needed in scenarios, where state setups are required on a short time
scale (e.g. handover in mobile environments), or where human scale (e.g. handover in mobile environments), or where human
interaction is immediately concerned (e.g., voice communication interaction is immediately concerned (e.g., voice communication
setup delay). setup delay).
5.5.3 NSIS MUST allow for low bandwidth consumption for signaling 5.5.3 NSIS MUST allow for low bandwidth consumption for the signaling
protocol protocol
NSIS MUST allow for low bandwidth consumption in certain access NSIS MUST allow for low bandwidth consumption in certain access
networks. Again only small sets of scenarios call for low bandwidth, networks. Again only small sets of scenarios call for low bandwidth,
mainly those where wireless links are involved. mainly those where wireless links are involved.
5.5.4 NSIS SHOULD allow to constrain load on devices 5.5.4 NSIS SHOULD allow to constrain load on devices
The NSIS architecture SHOULD give the ability to constrain the load The NSIS architecture SHOULD give the ability to constrain the load
(CPU load, memory space, signaling bandwidth consumption and (CPU load, memory space, signaling bandwidth consumption and
signaling intensity) on devices where it is needed. One of the signaling intensity) on devices where it is needed. One of the
reasons is that the protocol handling should have a minimal impact reasons is that the protocol handling should have a minimal impact
on interior (core) nodes. on interior (core) nodes.
This can be achieved by many different methods. Examples, and this This can be achieved by many different methods. Examples include
are only examples, include message aggregation, by ignoring message aggregation, header compression, or minimizing
signaling message, header compression, or minimizing functionality. functionality. The framework may choose any method as long as the
The framework may choose any method as long as the requirement is requirement is met.
met.
5.5.5 NSIS SHOULD target highest possible network utilization 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 There are networking environments that require high network
utilization for various reasons, and the signaling protocol SHOULD utilization for various reasons, and the signaling protocol SHOULD
to its best ability support high resource utilization while to its best ability support high resource utilization while
maintaining appropriate service quality. maintaining appropriate service quality.
In networks where resources are very expensive (as is the case for In networks where resources are very expensive (as is the case for
many wireless networks), efficient network utilization is of many wireless networks), efficient network utilization for signaling
critical financial importance. On the other hand there are other traffic is of critical financial importance. On the other hand
parts of the network where high utilization is not required. there are other parts of the network where high utilization is not
required.
5.6 Flexibility 5.6 Flexibility
This section lists the various ways the protocol can flexibly be This section lists the various ways the protocol can flexibly be
employed. employed.
5.6.1 Flow aggregation 5.6.1 Flow aggregation
NSIS MUST allow for flow aggregation, including the capability to NSIS MUST allow for flow aggregation, including the capability to
select and change the level of aggregation. select and change the level of aggregation.
5.6.2 Flexibility in the placement of the NSIS Initiator 5.6.2 Flexibility in the placement of the NSIS Initiator/Responder
NSIS MUST be flexible in placing an NSIS Initiator. The NSIS NSIS MUST be flexible in placing an NSIS Initiator and NSIS
Initiator might be the sender or the receiver of content. But also Responder. The NSIS Initiator might be located at the sending or the
network-initiated reservations MUST be allowed in various scenarios receiving side of a data stream, and the NSIS Responder naturally on
such as PSTN gateways, some VPNs, and mobility. the other side.
Also network-initiated 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 state change
5.6.3 Flexibility in the initiation of re-negotiation
The NSIS Initiator or the NSIS Responder SHOULD be able to initiate The NSIS Initiator or the NSIS Responder SHOULD be able to initiate
a re-negotiation or change the reservation due to various reasons, a change of state. In the example of resource reservation this is
such as local resource shortage (CPU, memory on end-system) or a often referred to as resource re-negotiation. It can happen due to
user changed application preference/profiles. various reasons, such as local resource shortage (CPU, memory on
end-system) or a user changed application preference/profiles.
5.6.4 SOULD support network-initiated re-negotiation 5.6.4 SHOULD support network-initiated state change
NSIS SHOULD support network-initiated re-negotiation. This is used NSIS SHOULD support network-initiated state change. In the QoS
in cases, where the network is not able to further guarantee example, this is used in cases, where the network is not able to
resources and want to e.g. downgrade a reservation. further guarantee resources and wants to e.g. downgrade a resource
reservation.
5.6.5 Uni / bi-directional reservation 5.6.5 Uni / bi-directional state setup
Both unidirectional as well as bi-direction reservations SHOULD be Both unidirectional as well as bi-direction state setup SHOULD be
possible. With bi-directional reservations we mean here reservations possible. With bi-directional state setup we mean that the state for
having the same end-points. But the path in the two directions does bi-directional data flows is setup. The bi-directional data flows
have the same end-points, but the path in the two directions does
not need to be the same. not need to be the same.
The goal of a bi-directional reservation is mainly an optimization The goal of a bi-directional state setup is mainly an optimization
in terms of setup delay. There is no requirements on constrains such in terms of setup delay. There is no requirements on constrains such
as use the same data path etc. as use of the same data path etc.
5.7 Security 5.7 Security
This section discusses security-related requirements. For a This section discusses security-related requirements. The NSIS
discussion of security threats see [SEC-THR]. The NSIS protocol MUST protocol MUST provide means for security, but it MUST be allowed
provide means for security, but it MUST be allowed that nodes that nodes implementing NSIS signaling do not need use the security
implementing NSIS signaling do not need use the security means. means.
5.7.1 Authentication of signaling requests 5.7.1 Authentication of signaling requests
A signaling protocol MUST make provision for enabling various A signaling protocol MUST make provision for enabling various
entities to be authenticated against each other using strong entities to be authenticated against each other using strong
authentication mechanisms. The term strong authentication points to authentication mechanisms. The term strong authentication points to
the fact that weak plain-text password mechanisms must not be used the fact that weak plain-text password mechanisms must not be used
for authentication. for authentication.
5.7.2 Resource Authorization 5.7.2 Request Authorization
The signaling protocol MUST provide means to authorize resource The signaling protocol MUST provide means to authorize state setup
requests. This requirement demands a hook to interact with a policy requests. This requirement demands a hook to interact with a policy
entity to request authorization data. This allows an authenticated entity to request authorization data. This allows an authenticated
entity to be associated with authorization data and to verify the entity to be associated with authorization data and to verify the
resource request. Authorization prevents reservations by unauthorized request. Authorization prevents state setup by unauthorized entities,
entities, reservations violating policies, and theft of service. setups violating policies, and theft of service. Additionally it
Additionally it limits denial of service attacks against parts of the limits denial of service attacks against parts of the network or the
network or the entire network caused by unrestricted reservations. entire network caused by unrestricted state setups. Additionally it
Additionally it might be helpful to provide some means to inform might be helpful to provide some means to inform other protocols of
other protocols of participating nodes within the same administrative participating nodes within the same administrative domain about a
domain about a previous successful authorization event. previous successful authorization event.
5.7.3 Integrity protection 5.7.3 Integrity protection
The signaling protocol MUST provide means to protect the message The signaling protocol MUST provide means to protect the message
payloads against modifications. Integrity protection prevents an payloads against modifications. Integrity protection prevents an
adversary from modifying parts of the signaling message and from adversary from modifying parts of the signaling message and from
mounting denial of service or theft of service type of attacks mounting denial of service or theft of service type of attacks
against network elements participating in the protocol execution. against network elements participating in the protocol execution.
5.7.4 Replay protection 5.7.4 Replay protection
To prevent replay of previous signaling messages the signaling To prevent replay of previous signaling messages the signaling
protocol MUST provide means to detect old i.e. already transmitted protocol MUST provide means to detect old i.e. already transmitted
skipping to change at page 19, line 23 skipping to change at page 17, line 10
protocol MUST provide means to detect old i.e. already transmitted protocol MUST provide means to detect old i.e. already transmitted
signaling messages. A solution must cover issues of synchronization signaling messages. A solution must cover issues of synchronization
problems in the case of a restart or a crash of a participating problems in the case of a restart or a crash of a participating
network element. network element.
5.7.5 Hop-by-hop security 5.7.5 Hop-by-hop security
Hop-by-Hop security SHOULD be supported. It is a well known and Hop-by-Hop security SHOULD be supported. It is a well known and
proven concept in Quality-of-Service and other signaling protocols proven concept in Quality-of-Service and other signaling protocols
that allows intermediate nodes that actively participate in the that allows intermediate nodes that actively participate in the
protocol to modify the messages as it is required by processing rule. protocol to modify the messages as it is required by processing
Note that this requirement does not exclude end-to-end or network-to- rules. Note that this requirement does not exclude end-to-end or
network security of a signaling message. End-to-end security between network-to-network security of a signaling message. End-to-end
the initiator and the responder may be used to provide protection of security between the initiator and the responder may be used to
non-mutable data fields. Network-to-network security refers to the provide protection of non-mutable data fields. Network-to-network
protection of messages over various hops but not in an end-to-end security refers to the protection of messages over various hops but
manner i.e. protected over a particular network. not in an end-to-end manner i.e. protected over a particular network.
5.7.6 Identity confidentiality and location privacy 5.7.6 Identity confidentiality and network topology hiding
Identity confidentiality SHOULD be supported. It enables privacy and Identity confidentiality SHOULD be supported. It enables privacy and
avoids profiling of entities by adversary eavesdropping the signaling avoids profiling of entities by adversary eavesdropping the signaling
traffic along the path. The identity used in the process of traffic along the path. The identity used in the process of
authentication may also be hidden to a limited extent from a network authentication may also be hidden to a limited extent from a network
to which the initiator is attached. However the identity MUST provide to which the initiator is attached. However the identity MUST provide
enough information for the nodes in the access network to collect enough information for the nodes in the access network to collect
accounting data. accounting data.
Location privacy MAY be supported. It is an issue for the initiator Network topology hiding MAY be supported to prevent entities along
who triggers the signaling protocol. In some scenarios the initiator the path to learn the topology of a network. Supporting this property
may not be willing to reveal location information to the responder as might conflict with a diagnostic capability.
part of the signaling procedure.
5.7.7 Denial-of-service attacks 5.7.7 Denial-of-service attacks
A signaling protocol SHOULD provide prevention of Denial-of-service A signaling protocol SHOULD provide prevention of Denial-of-service
attacks. To effectively prevent denial-of-service attacks it is attacks. To effectively prevent denial-of-service attacks it is
necessary that the used security and protocol mechanisms MUST have necessary that the used security and protocol mechanisms MUST have
low computation complexity to verify a resource request prior to low computational complexity to verify a state setup request prior to
authenticating the requesting entity. Additionally the signaling authenticating the requesting entity. Additionally the signaling
protocol and the used security mechanisms SHOULD NOT require large protocol and the used security mechanisms SHOULD NOT require large
resource consumption (for example main memory or other additional resource consumption on NSIS Entities (for example main memory or
message exchanges) before a successful authentication was done. other additional message exchanges) before a successful
authentication is done.
5.7.8 Confidentiality of signaling messages 5.7.8 Confidentiality of signaling messages
Based on the signaling information exchanged between nodes Based on the signaling information exchanged between nodes
participating in the signaling protocol an adversary may learn both participating in the signaling protocol an adversary may learn both
the identities and the content of the signaling messages. To prevent the identities and the content of the signaling messages. To prevent
this from happening, confidentiality of the signaling message in a this from happening, confidentiality of the signaling message in a
hop-by-hop manner MAY be provided. Note that the protection can be 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 provided on a hop-by-hop basis for most message payloads since it is
required that entities which actively participating in the signaling required that entities which actively participating in the signaling
protocol must be able to read and eventually modify the content of protocol must be able to read and eventually modify the content of
the signaling messages. the signaling messages.
5.7.9 Ownership of a reservation 5.7.9 Ownership of state
When existing states have to be modified then there is a need to use
When existing reservations have to be modified then there is a need a session identifier to uniquely identify the established state. A
to use a reservation identifier to uniquely identify the established signaling protocol MUST provide means of security protection to
state. A signaling protocol MUST provide the appropriate security prevent adversaries from modifying state.
protection to prevent other entities to modify state without having
the proper ownership.
5.8 Mobility 5.8 Mobility
5.8.1 Allow efficient service re-establishment after handover 5.8.1 Allow efficient service re-establishment after handover
Handover is an essential function in wireless networks. After Handover is an essential function in wireless networks. After
handover, the reservation may need to be completely or partially re- handover, the states may need to be completely or partially re-
established due to route changes. The re-establishment may be established due to route changes. The re-establishment may be
requested by the mobile node itself or triggered by the access point requested by the mobile node itself or triggered by the access point
that the mobile node is attached to. In the first case, the that the mobile node is attached to. In the first case, the
signaling MUST allow efficient re-establishment after handover. Re- signaling MUST allow efficient re-establishment after handover. Re-
establishment after handover MUST be as quick as possible so that establishment after handover MUST be as quick as possible so that
the mobile node does not experience service interruption or service the mobile node does not experience service interruption or service
degradation. The re-establishment SHOULD be localized, and not degradation. The re-establishment SHOULD be localized, and not
require end-to-end signaling. require end-to-end signaling.
5.9 Interworking with other protocols and techniques 5.9 Interworking with other protocols and techniques
Hooks SHOULD be provided to enable efficient interworking between Hooks SHOULD be provided to enable efficient interworking between
various protocols and techniques including: various protocols and techniques including the following listed.
5.9.1 MUST interwork with IP tunneling 5.9.1 MUST interwork with IP tunneling
IP tunneling for various applications MUST be supported. More IP tunneling for various applications MUST be supported. More
specifically tunneling for IPSec tunnels are of importance as specifically IPSec tunnels are of importance. This mainly impacts
discussed in Section 4.2. This mainly impacts the identification of the identification of flows. When using IPSec, parts of information
flows. Using IPSec parts of information used for flow identification commonly used for flow identification (e.g. transport protocol
(e.g. transport protocol information and ports) may not be accessible information and ports) may not be accessible due to encryption.
due to encryption.
5.9.2 The solution MUST NOT constrain either to IPv4 or IPv6 5.9.2 MUST NOT constrain either to IPv4 or IPv6
5.9.3 MUST be independent from charging model 5.9.3 MUST be independent from charging model
Signaling MUST NOT be constrained by charging models or the charging Signaling MUST NOT be constrained by charging models or the charging
infrastructure used. infrastructure used.
5.9.4 SHOULD provide hooks for AAA protocols 5.9.4 SHOULD provide hooks for AAA protocols
The NSIS SHOULD be developed with respect to be able to collect The NSIS SHOULD be developed with respect to be able to collect
usage records from one or more network elements. usage records from one or more network elements.
5.9.5 SHOULD interwork with seamless handoff protocols 5.9.5 SHOULD interwork with seamless handoff protocols
skipping to change at page 21, line 19 skipping to change at page 19, line 4
The NSIS SHOULD be developed with respect to be able to collect The NSIS SHOULD be developed with respect to be able to collect
usage records from one or more network elements. usage records from one or more network elements.
5.9.5 SHOULD interwork with seamless handoff protocols 5.9.5 SHOULD interwork with seamless handoff protocols
An NSIS protocol SHOULD interwork with seamless handoff protocols An NSIS protocol SHOULD interwork with seamless handoff protocols
such as context transfer and candidate access router (CAR) such as context transfer and candidate access router (CAR)
discovery. discovery.
5.9.6 MAY interwork with non-traditional routing 5.9.6 MAY interwork with non-traditional routing
NSIS assumes L3 routing, but networks, which do non-traditional
NSIS assumes traditional routing, but networks, which do non- routing, should not break it.
traditional L3 routing, should not break it.
5.10 Operational 5.10 Operational
5.10.1 Ability to assign transport quality to signaling messages. 5.10.1 Ability to assign transport quality to signaling messages.
The NSIS architecture SHOULD allow the network operator to assign The NSIS architecture SHOULD allow the network operator to assign
the NSIS protocol messages a certain transport quality. As signaling the NSIS protocol messages a certain transport quality. As signaling
opens up for possible denial-of-service attacks, this requirement opens up for possible denial-of-service attacks, this requirement
gives the network operator a mean, but also the obligation, to gives the network operator a means, but also the obligation, to
trade-off between signaling latency and the impact (from the trade-off between signaling latency and the impact (from the
signaling messages) on devices within his/her network. From protocol signaling messages) on devices within the network. From protocol
design this requirement states that the protocol messages SHOULD be design this requirement states that the protocol messages SHOULD be
detectable, at least where the control and assignment of the detectable, at least where the control and assignment of the
messages priority is done. messages priority is done.
Furthermore, the protocol design must take into account reliability Furthermore, the protocol design must take into account reliability
concerns. Communication reliability is seen as part of the quality concerns. Communication reliability is seen as part of the quality
assigned to signaling messages. So procedures MUST be defined how an assigned to signaling messages. So procedures MUST be defined how an
NSIS signaling system behaves if some kind of request it sent stays NSIS signaling system behaves if some kind of request it sent stays
without answer. The basic transport protocol to be used between unanswered. The basic transport protocol to be used between adjacent
adjacent NSIS units MAY ensure message integrity and reliable NSIS Entities MAY ensure message integrity and reliable transport.
transport.
5.10.2 Graceful fail over 5.10.2 Graceful fail over
Any unit participating in NSIS signaling MUST NOT cause further Any unit participating in NSIS signaling MUST NOT cause further
damage to other systems involved in NSIS signaling when it has to go damage to other systems involved in NSIS signaling when it has to go
out of service. out of service.
5.10.3 Graceful handling of NSIS entity problems 5.10.3 Graceful handling of NSIS entity problems
NSIS peers SHOULD be able to detect the malfunctioning peer. It may NSIS entities SHOULD be able to detect a malfunctioning peer. It may
notify the NSIS Initiator or another NSIS entity involved in the notify the NSIS Initiator or another NSIS entity involved in the
signaling process. The NSIS peer may handle the problem itself e.g. signaling process. The NSIS peer may handle the problem itself e.g.
switching to a backup NSIS entity. In the latter case note that switching to a backup NSIS entity. In the latter case note that
synchronization of state between the primary and the backup entity synchronization of state between the primary and the backup entity
is needed. is needed.
6 Security Considerations 6 Security Considerations
Section 5.7 of this document provides security related requirements Section 5.7 of this document provides security related requirements
of a signaling protocol. of a signaling protocol.
7 Informative References 7 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., [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, A., Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource Protocol (RSVP) -- Version 1 Functional Specification",
Specification", RFC 2205, September 1997. RFC 2205, September 1997.
[RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001. December 2001.
[RFC3234] B. Carpenter, S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002.
8 Acknowledgments 8 Acknowledgments
Quite a number of people have been involved in the discussion of the Quite a number of people have been involved in the discussion of the
document, adding some ideas, requirements, etc. We list them without document, adding some ideas, requirements, etc. We list them without
a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
(NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC),
Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical Juergen Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
University Berlin), Xiaoming Fu (Technical University Berlin), Hans- University Berlin), Xiaoming Fu (Technical University Berlin), Hans-
Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph
skipping to change at page 22, line 54 skipping to change at page 20, line 50
Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel). Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel).
These people contributed also new text. These people contributed also new text.
Thanks also to Kwok Ho Chan (Nortel) for text changes. Thanks also to Kwok Ho Chan (Nortel) for text changes.
9 Author's Addresses 9 Author's Addresses
Marcus Brunner (Editor) Marcus Brunner (Editor)
NEC Europe Ltd. NEC Europe Ltd.
Network Laboratories Network Laboratories
Kurfuersten-Anlage 34 Kurfuersten-Anlage 36
D-69115 Heidelberg D-69115 Heidelberg
Germany Germany
E-Mail: brunner@ccrle.nec.de E-Mail: brunner@ccrle.nec.de
Robert Hancock Robert Hancock
Roke Manor Research Ltd Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN Romsey, Hants, SO51 0ZN
United Kingdom United Kingdom
E-Mail: robert.hancock@roke.co.uk E-Mail: robert.hancock@roke.co.uk
Eleanor Hepworth Eleanor Hepworth
Roke Manor Research Ltd Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN Romsey, Hants, SO51 0ZN
United Kingdom United Kingdom
skipping to change at page 23, line 34 skipping to change at page 21, line 30
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
81739 Munchen 81739 Munchen
Germany Germany
Email: Hannes.Tschofenig@mchp.siemens.de Email: Hannes.Tschofenig@mchp.siemens.de
10 Appendix: Scenarios/Use cases 10 Appendix: Scenarios/Use cases
In the following we describe scenarios, which are important to In the following we describe scenarios, which are important to
cover, and which allow us to discuss various requirements. Some cover, and which allow us to discuss various requirements. Some
regard this as use cases to be covered defining the use of a regard this as use cases to be covered defining the use of a
signaling protocol. 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 10.1 Terminal Mobility
The scenario we are looking at is the case where a mobile terminal The scenario we are looking at is the case where a mobile terminal
(MT) changes from one access point to another access point. The (MT) changes from one access point to another access point. The
access points are located in separate QoS domains. We assume Mobile access points are located in separate QoS domains. We assume Mobile
IP to handle mobility on the network layer in this scenario and IP to handle mobility on the network layer in this scenario and
consider the various extensions (i.e., IETF proposals) to Mobile IP, consider the various extensions (i.e., IETF proposals) to Mobile IP,
in order to provide 'fast handover' for roaming Mobile Terminals. in order to provide 'fast handover' for roaming Mobile Terminals.
The goal to be achieved lies in providing, keeping, and adapting the The goal to be achieved lies in providing, keeping, and adapting the
skipping to change at page 24, line 35 skipping to change at page 22, line 32
the MT is reaching the focus of another base station. However, this the MT is reaching the focus of another base station. However, this
might be detected via measurements of QoS on the physical layer and 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 is therefore out of scope of QoS signaling in IP. Note again that
the MT or the network (see below) might trigger the handoff. the MT or the network (see below) might trigger the handoff.
- This scenario shows that local decisions might not be enough. The - 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 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 considered as well. Hand-off decisions in a QoS domain do not only
depend on the local resource availability, e.g., the wireless part, depend on the local resource availability, e.g., the wireless part,
but involve the rest of the path as well. Additionally, but involve the rest of the path as well. Additionally,
decomposition of an end-to-end reservation might be needed, in order decomposition of an end-to-end signaling might be needed, in order
to change only parts of it. to change only parts of it.
2) Trigger sources 2) Trigger sources
- Mobile terminal: If the end-system QoS management identifies - Mobile terminal: If the end-system QoS management identifies
another (better-suited) access point, it will request the handoff another (better-suited) access point, it will request the handoff
from the terminal itself. This will be especially likely in the case from the terminal itself. This will be especially likely in the case
that two different provider networks are involved. Another important that two different provider networks are involved. Another important
example is when the current access point bearer disappears (e.g. example is when the current access point bearer disappears (e.g.
removing the Ethernet cable). In this case, the NSIS Initiator is removing the Ethernet cable). In this case, the NSIS Initiator is
skipping to change at page 25, line 4 skipping to change at page 22, line 52
removing the Ethernet cable). In this case, the NSIS Initiator is removing the Ethernet cable). In this case, the NSIS Initiator is
basically located on the mobile terminal. basically located on the mobile terminal.
- Network (access network manager): Sometimes, the handoff trigger - Network (access network manager): Sometimes, the handoff trigger
will be issued from the network management to optimize the overall will be issued from the network management to optimize the overall
load situation. Most likely this will result in changing the base- load situation. Most likely this will result in changing the base-
station of a single providers network. Most likely the NSIS station of a single providers network. Most likely the NSIS
Initiator is located on a system within the network. Initiator is located on a system within the network.
3) Integration with other protocols 3) Integration with other protocols
- Interworking with other protocol must be considered in one or the - Interworking with other protocol must be considered in one or the
other form. E.g., it might be worth combining QoS signaling between other form. E.g., it might be worth combining QoS signaling between
different QoS domains with mobility signaling at hand-over. different QoS domains with mobility signaling at hand-over.
4) Handover rates 4) Handover rates
In mobile networks, the admission control process has to cope with In mobile networks, the admission control process has to cope with
far more admission requests than call setups alone would generate. far more admission requests than call setups alone would generate.
For example, in the GSM (Global System for Mobile communications) For example, in the GSM (Global System for Mobile communications)
case, mobility usually generates an average of one to two handovers case, mobility usually generates an average of one to two handovers
per call. For third generation networks (such as UMTS), where it is per call. For third generation networks (such as UMTS), where it is
necessary to keep radio links to several cells simultaneously necessary to keep radio links to several cells simultaneously
(macro-diversity), the handover rate is significantly higher. (macro-diversity), the handover rate is significantly higher.
5) Fast reservations 5) Fast s
Handover can also cause packet losses. This happens when the Handover can also cause packet losses. This happens when the
processing of an admission request causes a delayed handover to the processing of an admission request causes a delayed handover to the
new base station. In this situation, some packets might be new base station. In this situation, some packets might be
discarded, and the overall speech quality might be degraded discarded, and the overall speech quality might be degraded
significantly. Moreover, a delay in handover may cause degradation significantly. Moreover, a delay in handover may cause degradation
for other users. In the worst-case scenario, a delay in handover may 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 cause the connection to be dropped if the handover occurred due to
bad air link quality. Therefore, it is critical that QoS signaling bad air link quality. Therefore, it is critical that QoS signaling
in connection with handover be carried out very quickly. in connection with handover be carried out very quickly.
6) Call blocking in case of overload 6) Call blocking in case of overload
Furthermore, when the network is overloaded, it is preferable to Furthermore, when the network is overloaded, it is preferable to
keep reservations for previously established flows while blocking keep s for previously established flows while blocking new requests.
new requests. Therefore, the resource reservation requests in Therefore, the resource reservation requests in connection with
connection with handover should be given higher priority than new handover should be given higher priority than new requests for
requests for resource reservation. resource reservation.
10.2 Cellular Networks 10.2 3G Wireless Networks
In this scenario, the user is using the packet service of a 3rd In this scenario, the user is using the packet services of a 3rd
generation cellular system, e.g. UMTS. The region between the End generation wireless system (e.g. 3GPP/UMTS, 3GPP2/cdma2000). The
Host and the edge node connecting the cellular network to another region between the End Host and the Edge Node (Edge Router)
QoS domain (e.g. the GGSN in UMTS or the PDSN in 3GPP2) is connecting the wireless network to another QoS domain is considered
considered to be a single QoS domain. to be a single QoS domain.
The issues in such an environment regarding QoS include: The issues in such an environment regarding QoS include:
1) Cellular systems provide their own QoS technology with 1) 3G wireless networks provide their own QoS technology with
specialized parameters to co-ordinate the QoS provided by both the specialized parameters to co-ordinate the QoS provided by both the
radio access and wired access network. For example, in a UMTS radio access and wired access networks. Provisioning of QoS
network, one aspect of GPRS is that it can be considered as a QoS technologies within a 3G wireless network can be described mainly in
technology; provisioning of QoS within GPRS is described mainly in terms of calling bearer classes, service options and service
terms of calling UMTS bearer classes. This QoS technology needs to instances. These QoS technologies need to be invoked with suitable
be invoked with suitable parameters when higher layers trigger a parameters when higher layers trigger a request for QoS. Therefore
request for QoS, and this therefore involves mapping the requested these involve mapping of the requested higher layer QoS parameters
IP QoS onto these UMTS bearer classes. This request for resources onto specific bearer classes or service instances. The request for
might be triggered by IP signaling messages that pass across the allocation of resources might be triggered by signaling at the IP
cellular system, and possibly other QoS domains, to negotiate for level that passes across the wireless system, and possibly other QoS
network resources. Typically, cellular system specific messages domains. Typically, wireless network specific messages are invoked
invoke the underlying cellular system QoS technology in parallel to setup the underlying bearer classes or service instances in
with the IP QoS negotiation, to allocate the resources within the parallel with the IP layer QoS negotiation, to allocate resources
cellular system. within the radio access network.
2) The placement of NSIS Initiators and NSIS Forwarders (terminology
in the framework given here). The NSIS Initiator could be located at
the End Host (triggered by applications), the GGSN/PDSN, or at a
node not directly on the data path, such as a bandwidth broker. In
the second case, the GGSN/PDSN could either be acting as a proxy on
behalf of an End Host with little capabilities, and/or managing
aggregate resources 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 the cellular system.
3) Initiation of IP-level QoS negotiation. IP-level QoS re-
negotiation may be initiated by either the End Host, or by the
network, based on current network loads, which might change
depending on the location of the end host.
4) The networks are designed and mainly used for speech 2) The IP signaling messages are initiated by the NSIS initiator and
communication (at least so far). interpreted by the NSIS Forwarder. The most efficient placement of
the NSIS Initiator and NSIS Forwarder has not been determined in 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 Access Gateway or at a node that is
not directly on the data path, such as a Policy Decision Function.
The Access Gateway could act as a proxy NSIS Initiator on behalf of
the UE/MS or an End Host. The Policy Decision Function that controls
per-flow/aggregate resources with respect to the session within its
QoS domain (e.g. the 3G wireless network) may act as a proxy NSIS
Initiator for the UE/MS or the Access Gateway. Depending on the
placement of the NSIS Initiator, the NSIS Forwarder may be located
at an appropriate point in the 3G wireless network.
Note that in comparison to the previous scenario emphasis is much 3) The need for re-negotiation of resources in a new 3G wireless
less on the mobility aspects, because mobility is mainly handled on domain due to UE/MS mobility. In this case the NSIS Initiator and
the lower layer. the NSIS Forwarder should detect mobility events and autonomously
trigger re-negotiation of resources.
10.3 UMTS access 10.3 An example scenario for 3G wireless networks
The UMTS access scenario is shown in Figure 1. The Proxy-Call State The 3G wireless access scenario is shown in Figure 1. The Proxy-Call
Control Function/Policy Control Function (P-CSCF/PCF) is the State Control Function (P-CSCF) is the outbound SIP proxy (only used
outbound SIP proxy of the visited domain, i.e. the domain where the in IMS). The Access Gateway is the egress router of the 3G wireless
mobile user wants to set-up a call. The Gateway GPRS Support Node domain and it connects the radio access network to the Edge Router
(GGSN) is the egress router of the UMTS domain and connects the UMTS (ER) of the backbone IP network. The Policy Decision Function (PDF)
access network to the Edge Router (ER) of the core IP network. The is an entity responsible for controlling bearer level resource
P-CSCF/PCF communicates with the GGSN via the COPS protocol. The allocations/de-allocations in relation to session level services
User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal e.g. SIP. The Policy Decision Function may also control the Access
Equipment (TE), e.g. a laptop. Gateway to open and close the gates and to configure per-flow
policies, i.e. to authorize or forbid user traffic. The P-CSCF (only
used in IMS) and the Access Gateway communicate with the 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 +--------->| P-CSCF |---------> SIP signaling
/ +--------+ / +--------+
/ SIP : / SIP |
: +--------+ NSIS +----------------+ | |
: | PCF |---------| NSIS Forwarder | | +-----+ +----------------+
: +--------+ +----------------+ | | PDF |<---------->| NSIS Forwarder |<--->
: : | +-----+ +----------------+
: : COPS | | ^
: : | | |
+----+ +--------+ +----+ | | |
| UE |----------| GGSN |------| ER | | |COPS |
+----+ +--------+ +----+ | | |
+------+ +---------+ |
| UE/MS|----------| Access |<-----------+ +----+
+------+ | Gateway |------------------| ER |
+---------+ +----+
Figure 1: UMTS access scenario Figure 1: 3G wireless access scenario
In this scenario the GGSN has the role of Access Gate. According to The PDF has all the required QoS information for per-flow or
3GPP standardization, the PCF is responsible for the policy-based aggregate admission control in 3G wireless networks. It receives
control of the end-user service in the UMTS access network (i.e. resource allocation/de-allocation requests from the P-CSCF and/or
from UE to GGSN). In the current UMTS release R.5, the PCF is part Access Gateway etc. and responds with policy decisions. Hence the
of the P-CSCF, but in UMTS R.6 the interface between P-CSCF and PCF PDF may be a candidate entity to host the functionality of the NSIS
may evolve to an open standardized interface. In any case the PCF Initiator, initiating the "NSIS" QoS signaling towards the backbone
has all required QoS information for per-flow admission control in IP network. On the other hand, the UE/MS may act as the NSIS
the UMTS access network (which it gets from the P-CSCF and/or GGSN). Initiator or the Access Gateway may act as a Proxy NSIS Initiator on
Thus the PCF would be the appropriate entity to host the behalf of the UE/MS. In the former case, the P-CSCF/PDF has to do
functionality of NSIS Initiator, initiating the "NSIS" QoS signaling the mapping from codec types and media descriptors (derived from
towards the core IP network. The PCF/P-CSCF has to do the mapping SIP/SDP signaling) to IP traffic descriptor. In the latter case, the
from codec type (derived from SIP/SDP signaling) to IP traffic UE/MS may use any appropriate QoS signaling mechanism as the NSIS
descriptor. SDP extensions to explicitly signal QoS information are Initiator. If the Access Gateway is acting as the Proxy NSIS
useful to avoid the need to store codec information in the PCF and initiator on behalf of the UE/MS, then it may have to do the mapping
to allow for more flexibility and accurate description of the QoS of parameters from radio access specific QoS to IP QoS traffic
traffic parameters. The PCF also controls the GGSN to open and close parameters before forwarding the request to the NSIS Forwarder.
the gates and to configure per-flow policers, i.e. to authorize or
forbid user traffic.
The NSIS Forwarder is (of course) not part of the standard UMTS The NSIS Forwarder is currently not part of the standard 3G wireless
architecture. However, to achieve end-to-end QoS a NSIS Forwarder is architecture. However, to achieve end-to-end QoS a NSIS Forwarder is
needed such that the PCF can request a QoS connection to the IP needed such that the NSIS Initiators can request a QoS connection to
network. As in the previous example, the NSIS Forwarder could manage the IP network. As in the previous example, the NSIS Forwarder could
a set of pre-provisioned resources in the IP network, i.e. bandwidth manage a set of pre-provisioned resources in the IP network, i.e.
pipes, and the NSIS Forwarder performs per-flow admission control bandwidth pipes, and the NSIS Forwarder performs per-flow admission
into these pipes. In this way, a connection can be made between two control into these pipes. In this way, a connection can be made
UMTS access networks, and hence, end-to-end QoS can be achieved. In between two 3G wireless access networks, and hence, end-to-end QoS
this case the NSIS Initiator and NSIS Forwarder are clearly two can be achieved. In this case the NSIS Initiator and NSIS Forwarder
separate entities. are clearly two separate logical entities. The Access Gateway or/and
This use case clearly illustrates the need for an "NSIS" QoS the Edge Router in Fig.1 may contain the NSIS Forwarder
signaling protocol between NSIS Initiator and NSIS Forwarder. An functionality, depending upon the placement of the NSIS Initiator as
important application of such a protocol may be its use in the discussed in scenario 2 in section 10.2. This use case clearly
inter-connection of UMTS networks over an IP backbone. 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 end-to-end establishment of 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 10.4 Wired part of wireless network
A wireless network, seen from a QoS domain perspective, usually A wireless network, seen from a QoS domain perspective, usually
consists of three parts: a wireless interface part (the "radio consists of three parts: a wireless interface part (the "radio
interface"), a wired part of the wireless network (i.e., Radio interface"), a wired part of the wireless network (i.e., Radio
Access Network) and the backbone of the wireless network, as shown Access Network) and the backbone of the wireless network, as shown
in Figure 2. Note that this figure should not be seen as an in Figure 2. Note that this figure should not be seen as an
architectural overview of wireless networks but rather as showing architectural overview of wireless networks but rather as showing
the conceptual QoS domains in a wireless network. the conceptual QoS domains in a wireless network.
skipping to change at page 29, line 8 skipping to change at page 27, line 26
1. The network supports a high proportion of real-time 1. The network supports a high proportion of real-time
traffic. The majority of the traffic transported in the traffic. The majority of the traffic transported in the
wired part of the wireless network is speech, which is wired part of the wireless network is speech, which is
very sensitive to delays and delay variation (jitter). very sensitive to delays and delay variation (jitter).
2. The network must support mobility. Many wireless 2. The network must support mobility. Many wireless
networks are able to provide a combination of soft networks are able to provide a combination of soft
and hard handover procedures. When handover occurs, and hard handover procedures. When handover occurs,
reservations need to be established on new paths. reservations need to be established on new paths.
The establishment time has to be as short as possible The establishment time has to be as short as possible
since long establishment times for reservations degrade since long establishment times for s degrade
the performance of the wireless network. Moreover, the performance of the wireless network. Moreover,
for maximal utilization of the radio spectrum, frequent for maximal utilization of the radio spectrum, frequent
handover operations are required. handover operations are required.
3. These links are typically rather bandwidth-limited. 3. These links are typically rather bandwidth-limited.
4. The wired transmission in such a network contains a 4. The wired transmission in such a network contains a
relatively high volume of expensive leased lines. relatively high volume of expensive leased lines.
Overprovisioning might therefore be prohibitively Overprovisioning might therefore be prohibitively
expensive. expensive.
skipping to change at page 29, line 53 skipping to change at page 28, line 17
within the session mobility scenario. within the session mobility scenario.
Note that this scenario is different from terminal mobility. Not the Note that this scenario is different from terminal mobility. Not the
terminal (end-system) has moved to a different access point. Both terminal (end-system) has moved to a different access point. Both
terminals are still connected to an IP network at their original terminals are still connected to an IP network at their original
points. points.
The issues include: The issues include:
1) Keeping the QoS guarantees negotiated implies that the end- 1) Keeping the QoS guarantees negotiated implies that the end-
point(s) of communication are changed without changing the point(s) of communication are changed without changing the s.
reservations.
2) The trigger of the session move might be the user or any other 2) The trigger of the session move might be the user or any other
party involved in the session. party involved in the session.
10.6 QoS reservations/negotiation from access to core network 10.6 QoS s/negotiation from access to core network
The scenario includes the signaling between access networks and core The scenario includes the signaling between access networks and core
networks in order to setup and change reservations together with networks in order to setup and change s together with potential
potential negotiation. negotiation.
The issues to be solved in this scenario are different from previous The issues to be solved in this scenario are different from previous
ones. ones.
1) The entity of reservation is most likely an aggregate. 1) The entity of reservation is most likely an aggregate.
2) The time scales of reservations might be different (long living 2) The time scales of s might be different (long living s of
reservations of aggregates, less often re-negotiation). aggregates, less often re-negotiation).
3) The specification of the traffic (amount of traffic), a 3) The specification of the traffic (amount of traffic), a
particular QoS is guaranteed for, needs to be changed. E.g., in case particular QoS is guaranteed for, needs to be changed. E.g., in case
additional flows are added to the aggregate, the traffic additional flows are added to the aggregate, the traffic
specification of the flow needs to be added if it is not already specification of the flow needs to be added if it is not already
included in the aggregates specification. included in the aggregates specification.
4) The flow specification is more complex including network 4) The flow specification is more complex including network
addresses and sets of different address for the source as well as addresses and sets of different address for the source as well as
for the destination of the flow. for the destination of the flow.
10.7 QoS reservation/negotiation over administrative boundaries 10.7 QoS /negotiation over administrative boundaries
Signaling between two or more core networks to provide QoS is Signaling between two or more core networks to provide QoS is
handled in this scenario. This might also include access to core handled in this scenario. This might also include access to core
signaling over administrative boundaries. Compared to the previous signaling over administrative boundaries. Compared to the previous
one it adds the case, where the two networks are not in the same one it adds the case, where the two networks are not in the same
administrative domain. Basically, it is the inter-domain/inter administrative domain. Basically, it is the inter-domain/inter
provider signaling which is handled in here. provider signaling which is handled in here.
The domain boundary is the critical issue to be resolved. Which as The domain boundary is the critical issue to be resolved. Which as
various flavors of issues a QoS signaling protocol has to be various flavors of issues a QoS signaling protocol has to be
skipping to change at line 1855 skipping to change at page 34, line 25
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Notices
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
Director.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/