draft-ietf-nsis-req-05.txt   draft-ietf-nsis-req-06.txt 
Network Working Group M. Brunner (Editor) Network Working Group M. Brunner (Editor)
Internet Draft NEC Internet Draft NEC
Category: Informational November 2002 Category: Informational December 2002
Requirements for Signaling Protocols Requirements for Signaling Protocols
<draft-ietf-nsis-req-05.txt> <draft-ietf-nsis-req-06.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 2, line 16 skipping to change at page 2, line 16
Table of Contents..................................................1 Table of Contents..................................................1
1 Introduction.....................................................2 1 Introduction.....................................................2
2 Terminology......................................................3 2 Terminology......................................................3
3 Problem Statement and Scope......................................5 3 Problem Statement and Scope......................................5
4 Assumptions and Exclusions.......................................6 4 Assumptions and Exclusions.......................................6
4.1 Assumptions and Non-Assumptions................................6 4.1 Assumptions and Non-Assumptions................................6
4.2 Exclusions.....................................................7 4.2 Exclusions.....................................................7
5 Requirements.....................................................9 5 Requirements.....................................................9
5.1 Architecture and Design Goals..................................9 5.1 Architecture and Design Goals..................................9
5.2 Signaling Flows...............................................11 5.2 Signaling Flows...............................................11
5.3 Messaging.....................................................12 5.3 Messaging.....................................................13
5.4 Control Information...........................................14 5.4 Control Information...........................................14
5.5 Performance...................................................15 5.5 Performance...................................................16
5.6 Flexibility...................................................17 5.6 Flexibility...................................................17
5.7 Security......................................................18 5.7 Security......................................................18
5.8 Mobility......................................................20 5.8 Mobility......................................................20
5.9 Interworking with other protocols and techniques..............21 5.9 Interworking with other protocols and techniques..............20
5.10 Operational..................................................21 5.10 Operational..................................................21
6 Security Considerations.........................................22 6 Security Considerations.........................................22
7 References......................................................22 7 Informative References..........................................22
8 Acknowledgments.................................................22 8 Acknowledgments.................................................22
9 Author's Addresses..............................................23 9 Author's Addresses..............................................22
10 Appendix: Scenarios/Use cases..................................23 10 Appendix: Scenarios/Use cases..................................23
10.1 Terminal Mobility............................................24 10.1 Terminal Mobility............................................23
10.2 Cellular Networks............................................26 10.2 Cellular Networks............................................25
10.3 UMTS access..................................................27 10.3 UMTS access..................................................26
10.4 Wired part of wireless network...............................28 10.4 Wired part of wireless network...............................27
10.5 Session Mobility.............................................29 10.5 Session Mobility.............................................29
10.6 QoS reservations/negotiation from access to core network.....30 10.6 QoS reservations/negotiation from access to core network.....30
10.7 QoS reservation/negotiation over administrative boundaries...30 10.7 QoS reservation/negotiation over administrative boundaries...30
10.8 QoS signaling between PSTN gateways and backbone routers.....31 10.8 QoS signaling between PSTN gateways and backbone routers.....31
10.9 PSTN trunking gateway........................................32 10.9 PSTN trunking gateway........................................32
10.10 Application request end-to-end QoS path from the network....34 10.10 Application request end-to-end QoS path from the network....34
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 describe a set of signaling scenarios and use cases in Therefore, we define a conceptual model of signaling on an abstract
the Appendix of that document. These scenarios derive from a variety level. Additionally, we describe the entities involved in signaling
of backgrounds, and help obtain a clearer picture of what is in or and typical signaling paths. In the appendix are a list of use cases
out of scope of the NSIS work. They illustrate the problem of and scenarios where an NSIS protocol could be applied. It is though
signaling from various perspectives (end-system, access network, of helping derive the requirements and to t4est the requirements
core network) and for various areas (fixed line, mobile, wireless against use cases.
environments). Most of them are targeted towards QoS, because that
was the primary target of signaling.
QoS and signaling for QoS is a pretty large field with a lot of QoS and signaling for QoS is a pretty large field with a lot of
interaction with other protocols, mechanisms, applications etc. interaction with other protocols, mechanisms, applications etc.
However, it is not the only field where signaling is used in the However, it is not the only field where signaling is used in the
Internet. Even if this requirement documents mainly used QoS as the Internet. Even if this requirement documents mainly used QoS as the
sample application other application must be possible. sample application other application must be possible and are also
addressed.
There are several areas of the requirements related to networking
aspects which are incomplete, for example, interaction with host and
site multi-homing, use of anycast services, and so on. These issues
should be considered in any future analysis work.
Based on the scenarios, we are able to define the signaling problem There are several areas related to networking aspects which are
on a more abstract level. In Section 3, we thus present a simple incomplete, for example, interaction with host and site multi-
conceptual model of the signaling problem. Additionally, we describe homing, use of anycast services, and so on. These issues should be
the entities involved in signaling and typical signaling paths. In considered in any future analysis work.
Section 4 we list assumptions and exclusions.
2 Terminology 2 Terminology
We try to list the most often used terms in the document. However, We try to list the most often used terms in the document. However,
don't be to religious about it, they are not meant to prescribe any don't be to religious about it, they are not meant to prescribe any
solution in the document. solution in the document. All of them need refined definitions in
follow-up documents.
Resource Management Function (RMF): An abstract concept, Resource Management Function (RMF): An abstract concept,
representing the management of resources in a domain or a node. 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 NSIS Domain (ND): Administrative domain where an NSIS protocol
signals for a resource or set of resources. signals for a resource or set of resources.
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.
NSIS Forwarder (NF): NSIS Entity on the path between a NI and NR, NSIS Forwarder (NF): NSIS Entity on the path between a NI and NR,
which may interact with local resource management function (RMF) for which may interact with local resource management function (RMF) for
this purpose. NSIS Forwarder also propagates NSIS signaling further this purpose. NSIS Forwarder also propagates NSIS signaling further
skipping to change at page 3, line 54 skipping to change at page 3, line 47
NSIS Initiator (NI): NSIS Entity that initiates NSIS signaling for a NSIS Initiator (NI): NSIS Entity that initiates NSIS signaling for a
network resource based on user or application requirements. This can network resource based on user or application requirements. This can
be located in the end system, but may reside elsewhere in network. 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. The flow can be unicast (uni- or bi-directional) or multicast. For
multicast, a flow can diverge into multiple flows as it propagates
toward the receiver. For multi-sender multicast, a flow can also
diverge when viewed in the reverse direction (toward the senders).
Higher Layers: The higher layer (transport protocol and application) Higher Layers: The higher layer (transport protocol and application)
functions that request QoS or any other service from the network functions that request QoS or any other service from the network
layer. The request might be a trigger generated within the end layer. The trigger for the request might be generated within the end
system, or the trigger might be provided by some entity within the system, or the trigger might be provided by some entity within the
network (e.g. application proxy or policy server). network (e.g. application proxy or policy server).
Path: the route across the networks taken by a flow or aggregate, Data Path: the route across the networks taken by a flow or
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
flow or aggregate, i.e. which domains/subdomains it passes through
and the egress/ingress points for each.
Path Segment: The segment of a path within a single Path Segment: The segment of a path within a single
domain/subdomain. domain/subdomain.
Control Information: the information the governs for instance the Control Information: the information the governs for instance the
QoS treatment to be applied to a flow or aggregate, including the QoS treatment to be applied to a flow or aggregate, including the
service class, flow administration, and any associated security or service class, flow administration, and any associated security or
accounting information. accounting information.
Provisioning: the act of actually allocating resources to a flow or Provisioning: the act of actually allocating resources to a flow or
aggregate of flows, may include mechanisms such as LSP initiation aggregate of flows, may include mechanisms such as LSP initiation
for MPLS, packet scheduler configuration within a router, and so on. for MPLS, packet scheduler configuration within a router, and so on.
The mechanisms depend on the overall technology and application The mechanisms depend on the overall technology and application
being used within the domain. being used within the domain, and can be from static to dynamic.
Subdomain: a network within an administrative domain using a uniform Subdomain: a network within an administrative domain using a uniform
technology, e.g., a single QoS provisioning function to provision technology, e.g., a single QoS provisioning function to provision
resources. resources.
QoS Technology: a generic term for a set of protocols, standards and QoS Technology: a generic term for a set of protocols, standards and
mechanisms that can be used within a QoS domain/subdomain to manage mechanisms that can be used within a QoS domain/subdomain to manage
the QoS provided to flows or aggregates that traverse the domain. the QoS provided to flows or aggregates that traverse the domain.
Examples might include MPLS, DiffServ, and so on. A QoS technology Examples might include MPLS, DiffServ, and so on. A QoS technology
is associated with certain QoS provisioning techniques. is associated with certain QoS provisioning techniques.
Resource: something of value in a network infrastructure to which Resource: something of value in a network infrastructure to which
rules or policy criteria are first applied before access is granted. rules or policy criteria are first applied before access is granted.
Examples of resources include the buffers in a router and bandwidth Examples of resources include the buffers in a router and bandwidth
on an interface. on an interface.
Resource Allocation: part of a resource that has been dedicated for Service: something provided by an entity and consumed by another.
the use of a particular traffic type for a period of time through It can be constructed by allocating resources. The network can
the application of policies. provide it to users or a network node can provide it to packets.
Sender-initiated signaling protocol: A sender-initiated signaling Sender-initiated signaling protocol: A sender-initiated signaling
protocol is a protocol where the NI initiates the signaling on protocol is a protocol where the NSIS Initiator initiates the
behalf of the sender of the data. What this means is that admission signaling on behalf of the sender of the data. What this means is
control and resource allocation functions are processed from the that resource management functions are processed from the data
data sender towards the data receiver. However, the triggering sender towards the data receiver. However, the triggering instance
instance is not specified. is not specified.
Receiver-initiated signaling protocol: A receiver-initiated Receiver-initiated signaling protocol: A receiver-initiated protocol
protocol, (see e.g., [RSVP]) is a protocol where the NSIS Responder (e.g., [RSVP]) is a protocol, where the NSIS Responder on behalf of
on behalf of the receiver of the user data initiates the the receiver of the user data initiates the reservation. What this
reservations. What this means is that admission control and resource means is that resource management functions are processed from the
allocation functions are processed from the data receiver back data receiver back towards the data sender. However, the triggering
towards the data sender. However, the triggering instance is not instance is not specified.
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 section. requirement sections.
A basic goal should be to re-use these wherever possible, and to 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 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 solution is needed (e.g. an especially simple one). We also try to
avoid defining requirements related to internal implementation avoid defining requirements related to internal implementation
aspects. 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
skipping to change at page 5, line 42 skipping to change at page 5, line 42
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 resources requested
by them, and also provides feedback information to the higher by them, and also provides feedback information to the higher
layers, which might be used by transport layer rate management or layers, which might be used by transport layer rate management or
adaptive applications. adaptive applications.
2. Something that assists in managing resources further along the 2. Something that assists in managing resources further along the
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 and possibly more NSIS Forwarders interacts with the NSIS Initiator, NSIS Responder, and possibly one
on the path, edge-to-edge or possibly end-to-end. or more NSIS Forwarders on the signaling path, edge-to-edge or end-
to-end.
3. The NSIS Initiator and NSIS Forwarder(s) interact with each 3. Something that terminates the signaling path, the NSIS Responder.
other, path segment by path segment. This interaction involves the
exchange of data (resources control information) over some signaling The NSIS responder might be in an end-system or within other
protocol. equipment. The distinguishing feature of the NSIS Initiator is that
it responds to request at the end of a signaling path.
4. The path segment traverses an underlying network covering one or 4. The path segment traverses an underlying network covering one or
more IP hops. The underlying network might use locally different 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. An NSIS Forwarder maps appropriately for the service requested. In the QoS example, an NSIS
service-specific information to technology-related QoS parameters Forwarder maps service-specific information to technology-related
and receiving indications about success or failure in response. QoS parameters and receiving indications about success or failure in
response.
Now concentrating more on the overall end to end (multiple domain) Now concentrating more on the overall end to end (multiple domain)
aspects, in particular: aspects, in particular:
1. The NSIS Initiator need not be located at an end system, and the 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 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 path. However, they must be able to identify the ingress and egress
points for the flow path as it traverses the domain/subdomain. Any points for the flow's data path as it traverses the NSIS domain. Any
signaling protocol must be able to find the appropriate NSIS signaling protocol must be able to find the appropriate NSIS
Forwarder and carry this ingress/egress point information. Forwarder.
2. We see the network at the level of domains/subdomains rather than 2. We see the network at the level of domains/subdomains rather than
individual routers (except in the special case that the domain 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. to do 3. Any domain may contain Resource Management Function (e.g.
with traffic engineering, admission control, policy and so on). traffic engineering, admission control, policy and so on). These are
These are assumed to interact with the NSIS Initiator and assumed to interact with the NSIS Initiator, Responder, and
Controllers (and end systems) using standard mechanisms. Forwarders using standard mechanisms.
4. The placement of the NSIS Initiators and NSIS Forwarders is not 4. The placement of the NSIS Initiators and NSIS Forwarders is not
fixed. 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
skipping to change at page 7, line 47 skipping to change at page 7, line 51
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. The same applies to application adaptation mechanisms. protocol.
3. Specific mechanisms for provisioning within a domain/subdomain 3. Specific mechanisms for provisioning within a domain/subdomain
are not considered. However, NSIS can be used for signaling within a are not considered. However, NSIS can be used for signaling within a
domain/subdomain performing provisioning. For instance in the QoS domain/subdomain performing provisioning. For instance in the QoS
example, it means that the setting of QoS mechanisms in a domain is example, it means that the setting of QoS mechanisms in a domain is
out of scope, but if we have a tunnels, NSIS could also be used for out of scope, but if we have a tunnel, NSIS could also be used for
tunnel setup with QoS guaranties. It should be possible to exploit tunnel setup with QoS guaranties. It should be possible to exploit
these mechanisms optimally within the end-to-end context. these mechanisms optimally within the end-to-end context.
Consideration of how to do this might generate new requirements for Consideration of how to do this might generate new requirements for
NSIS however. For example, the information needed by a NSIS NSIS however. For example, the information needed by a NSIS
Forwarder to manage a radio subnetwork needs to be provided by the Forwarder to manage a radio subnetwork needs to be provided by the
NSIS solution. 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 capabilities is not
considered. Standard protocols should be used for this (e.g. COPS). considered. Standard protocols might be used for this. This may
This may imply requirements for the sort of information that should imply requirements for the sort of information that should be
be exchanged between the NSIS entities. 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. Protection of non-signaling messages is outside the scope of the
protocol protocol
The protection of non-signaling messages (including data traffic The protection of non-signaling messages (including data traffic
following a reservation) is not directly considered by a signaling following a reservation) is not directly considered by a signaling
protocol. The protection of data messages transmitted along the protocol. The protection of data messages transmitted along the
skipping to change at page 8, line 43 skipping to change at page 8, line 46
state created due to signaling. One example of such an interaction is state created due to signaling. One example of such an interaction is
the different flow identification with and without IPSec protection. the different flow identification with and without IPSec protection.
Many security properties are likely to be application specific and Many security properties are likely to be application specific and
may be provided by the corresponding application layer protocol. may be provided by the corresponding application layer protocol.
8. Service definitions and in particular QoS services and classes 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 handled. service information are addressed.
9. Similarly, specific methods, protocols, and ways to express 9. 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 10. 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).
skipping to change at page 9, line 20 skipping to change at page 9, line 24
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 12. 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, derived from consideration of the use cases/scenarios solution, respecting the framework, scoping assumptions, and
described in the appendix, and respecting the framework, scoping terminology considered earlier. The requirements are in subsections,
assumptions, and terminology considered earlier. The requirements grouped roughly according to general technical aspects: architecture
are in subsections, grouped roughly according to general technical and design goals, topology issues, parameters, performance,
aspects: architecture and design goals, topology issues, parameters, security, information, and flexibility.
performance, 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 requirements in nodes. One approach to this is that the
solution could deal with certain requirements via modular components solution could deal with certain requirements via modular components
or capabilities, which are optional to implement in individual or capabilities, which are optional to implement in individual
nodes. nodes.
In order to prioritize the various requirements we define different In order to prioritize the various requirements we define different
skipping to change at page 10, line 20 skipping to change at page 10, line 23
various technologies. various technologies.
5.1.2 SHOULD provide resource availability information on request 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 resources are
available without performing a reservation. In some scenarios, e.g., available without performing a reservation. In some scenarios, e.g.,
the mobile terminal scenario, it is required to query, whether the mobile terminal scenario, it is required to query, whether
resources are available, without performing a reservation on the resources are available, without performing a reservation on the
resource. resource.
5.1.3 NSIS MUST be designed modular 5.1.3 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 redundant information MUST be supported if necessary.
- Uni- and bi-directional reservations are possible - Uni- and bi-directional reservations are possible
skipping to change at page 10, line 49 skipping to change at page 10, line 52
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 gained flexibility in the information
transported allows for the applicability of the same protocol in transported allows for the applicability of the same protocol in
various scenarios. various scenarios.
However, note that the information carried needs to be the However, note that the information carried needs to be standardized;
standardized; otherwise interoperability is difficult to achieve. otherwise interoperability is difficult to achieve.
5.1.5 NSIS MUST reuse existing provisioning 5.1.5 NSIS MUST reuse existing provisioning
Reuse existing functions and protocols for provisioning within a Reuse existing functions and protocols for provisioning within a
domain/subdomain unchanged. (Motivation: 'Don't re-invent the domain/subdomain unchanged. (Motivation: 'Don't re-invent the
wheel'.) wheel'.)
5.1.6 Independence of signaling and provisioning paradigm 5.1.6 NSIS MUST support independence of signaling and provisioning
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 provisioning. 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 Application independence 5.1.7 NSIS MUST be application independent
The signaling protocol MUST be independent of the application. The The signaling protocol MUST be independent of the application. The
control information SHOULD be application independent, because we control information SHOULD be application independent, because we
look into network level signaling. look into network level signaling.
The requirement relates to the way the signaling interacts with The requirement relates to the way the signaling interacts with
upper layer functions (users, applications, and QoS administration), upper layer functions (users, applications, and QoS administration),
and lower layer technologies. and lower layer technologies.
Opaque application information MAY get transported in the signaling Opaque application information MAY get transported in the signaling
skipping to change at page 11, line 35 skipping to change at page 11, line 39
deployment of new applications SHOULD be possible without impacting deployment of new applications SHOULD be possible without impacting
the network infrastructure. 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 Free placement of NSIS Initiator, Forwarder, Responder 5.2.1 The placement of NSIS Initiator, Forwarder, Responder MUST be
free
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 providers 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 of the signaling and NSIS Forwarders to be in the 5.2.2 No constraint MUST be posed the signaling and NSIS Forwarders to
data path. be in the data path.
There is a set of scenarios, where signaling is not on the data 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 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 and useful in many cases. Therefore the case of having NSIS entities
on the data path only MUST be allowed. on the data path only MUST be supported.
There are going to be cases where a centralized entity will take a 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 decision about service requests. In this case, there is no need to
have the data follow the signaling path. 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 There are going to be cases without a centralized entity managing
resources and the signaling will be used as a tool for resource resources and the signaling will be used as a tool for resource
management. For various reasons (such as efficient use of expensive management. For various reasons (such as efficient use of expensive
bandwidth), one will want to have fine-grained, fast, and very bandwidth), one will want to have fine-grained, fast, and very
dynamic control of the resources in the network. dynamic control of the resources in the network.
There are going to be cases where there will be neither signaling There are going to be cases where there will be neither signaling
nor a centralized entity (over-provisioning). Nothing has to be done nor a centralized entity (over-provisioning). Nothing has to be done
anyway. anyway.
skipping to change at page 12, line 30 skipping to change at page 12, line 37
Routing the signaling protocol along an independent path is desired Routing the signaling protocol along an independent path is desired
by network operators/designers. Ideally, the capability to route the by network operators/designers. Ideally, the capability to route the
protocol along an independent path would give the network protocol along an independent path would give the network
designer/operator the option to manage bandwidth utilization through designer/operator the option to manage bandwidth utilization through
the topology. the topology.
There are other possibilities as well. An NSIS protocol MUST accept There are other possibilities as well. An NSIS protocol MUST accept
all of these possibilities with a strong focus on the on-path all of these possibilities with a strong focus on the on-path
signaling. signaling.
5.2.3 Concealment of topology and technology information 5.2.3 Concealment of topology and technology information SHOULD be
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 Transparency of signaling to network 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 traverse
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 flow-related
signaling passing transparently through it. signaling 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 5.3.1 Explicit release of resources MUST be possible
When a resource reservation is no longer necessary, e.g. because the When a resource reservation 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 explicitly release resources. In general
explicit release enhances the overall network utilization. explicit release enhances the overall network utilization.
5.3.2 Possibility for automatic release of resources after failure 5.3.2 Automatic release of resources after failure SHOULD be possible
When the NSIS Initiator goes down, the resources it requested in the When the NSIS Initiator goes down, the resources it requested in the
network SHOULD be released, since they will no longer be necessary. network SHOULD be released, since they 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 a reservation it is
involved in. For example, this may require signaling of the "Release involved in. For example, this may require signaling of the "Release
after Failure" message upstream as well as downstream, or soft state after Failure" message upstream as well as downstream, or soft state
timing out of reservations. timing out of reservations.
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 Notifications sent upstream 5.3.3 NSIS SHOULD allow for sending notifications upstream
NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS
Forwarder upstream, if there is a state change inside the network. Forwarder upstream, if there is a state change inside the network.
There are various types of network changes for instance among them: There are various types of network changes for instance among them:
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.
skipping to change at page 14, line 21 skipping to change at page 14, line 28
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. E.g., if it gets an error notification it might
teardown the reservation, even if everything is ok. So the teardown the reservation, even if everything is ok. So the
notification might depend on security associations between the notification might depend on security associations between the
sender of the notification and its receiver. If a hop-by-hop sender of the notification and its receiver. If a hop-by-hop
security mechanism is chosen, this implies also that notifications security mechanism is chosen, this implies also that notifications
need to be sent on the reverse path. need to be sent on the reverse path.
5.3.4 Feedback about success of service request 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. A request for service MUST be answered at least with yes or no.
However, it may be useful in case of a negative answer to also get a However, it may be useful in case of a negative answer to also get a
description of what amount of resources a request is possible. So an description of what amount of resources a request is possible. So an
opaque element MAY be included into the answer. The element heavily opaque element MAY be included into the answer. The element heavily
depends on the service requested. depends on the service requested.
5.3.5 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. Local information might, for example, be IP addresses, domain. The local information exchange is performed by a number of
severe congestion notification, notification of successful or separate messages not belonging to an end-to-end signaling process.
erroneous processing of signaling messages. Local information might, for example, be IP addresses, severe
congestion notification, notification of successful or erroneous
processing of signaling messages.
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
information that needs to be exchanged. information that needs to be exchanged.
5.4.1 Mutability information on parameters 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 from being
changed in a non-recoverable way. The NSIS initiator SHOULD be able changed in a non-recoverable way. The NSIS initiator SHOULD be able
to control what is requested end to end, without the request being to control what is requested end to end, without the request being
gradually mutated as it passes through a sequence of domains. This gradually mutated as it passes through a sequence of domains. This
implies that in case of changes made on the parameters, the original implies that in case of changes made on the parameters, the original
requested ones must still be available. 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 a provider or that particular services
requested, can still influence the provisioning but in the signaling requested, 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 Possibility to add and remove local domain information 5.4.2 SHOULD possible to add and remove local domain information
It SHOULD be possible for the Resource Management Function to add It SHOULD be possible for the Resource Management Function to add
and remove local scope elements. E.g., at the entrance to a domain and remove local scope elements. Compared to Requirement 5.3.5 this
domain-specific information is added, which is used in this domain requirement does use the normal signaling process and message
only, and the information is removed again when a signaling message exchange for transporting local information. E.g., at the entrance
leaves the domain. The motivation is in the economy of re-use the to a domain domain-specific information is added, which is used in
protocol for domain internal signaling of various information this domain only, and the information is removed again when a
pieces. Where additional information is needed within a particular signaling message leaves the domain. The motivation is in the
domain, it should be possible to carry this at the same time as the economy of re-use the protocol for domain internal signaling of
end-to-end information. various information pieces. Where additional information is needed
within a particular domain, it should be possible to carry this at
the same time as the end-to-end information.
5.4.3 Independence of reservation identifier 5.4.3 State MUST be addressed independent of flow identification
A reservation identifier MUST be independent of the flow identifier Addressing or identifying state MUST be independent of the flow
(flow end-points). Various scenarios in the mobility area require identifier (flow end-points, topological addresses). Various
this independence because flows resulting from handoff might have scenarios in the mobility area require this independence because
changed end-points etc. but still have the same service requirement. flows resulting from handoff might have changed end-points etc. but
Also several proxy-based signaling methods profit from such as still have the same service requirement. Also several proxy-based
independence. signaling methods profit from such independence.
5.4.4 Seamless modification of already reserved resources 5.4.4 Modification of already reserved resources SHOULD be seamless
In many case, the reservation needs to be updated (up or downgrade). In many case, the reservation needs to be updated (up or downgrade).
This SHOULD happen seamlessly without service interruption. At least This SHOULD happen seamlessly without service interruption. At least
the signaling protocol should allow for it, even if some data path the signaling protocol should allow for it, even if some data path
elements might not be capable of doing so. elements might not be capable of doing so.
5.4.5 Grouping of signaling for several micro-flows 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 of grouping. of a soft state solution) might profit from grouping.
However, the network MUST NOT know that a relationship between the However, the network MUST 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 and each reservation MUST be handled separately from each
other. other.
5.5 Performance 5.5 Performance
This section discusses performance requirements and evaluation This section discusses performance requirements and evaluation
skipping to change at page 16, line 38 skipping to change at page 16, line 50
reservations. Some servers might be expected to setup a large number reservations. Some servers might be expected to setup a large number
of reservations. of reservations.
Scalability in the number of state per entity MUST be achieved for Scalability in the number 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 And Scalability in CPU use MUST be achieved on end terminals in case
of many reservations at the same time and intermediate nodes mainly of many reservations at the same time and intermediate nodes mainly
in the core. in the core.
5.5.2 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 reservations. This is
only needed in scenarios, where reservations are in a short time only needed in scenarios, where reservations are in 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 Allow for low bandwidth consumption for signaling protocol 5.5.3 NSIS MUST allow for low bandwidth consumption for signaling
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 Ability 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, and this
are only examples, include message aggregation, by ignoring are only examples, include message aggregation, by ignoring
signaling message, header compression, or minimizing functionality. signaling message, header compression, or minimizing functionality.
The framework may choose any method as long as the requirement is The framework may choose any method as long as the requirement is
met. met.
5.5.5 Highest possible network utilization 5.5.5 NSIS SHOULD target highest possible network utilization
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 is of
critical financial importance. On the other hand there are other critical financial importance. On the other hand there are other
parts of the network where high utilization is not required. parts of the network where high utilization is not required.
skipping to change at page 17, line 39 skipping to change at page 17, line 52
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
NSIS MUST be flexible in placing an NSIS Initiator. The NSIS NSIS MUST be flexible in placing an NSIS Initiator. The NSIS
Initiator might be the sender or the receiver of content. But also Initiator might be the sender or the receiver of content. But also
network-initiated reservations MUST be available in various network-initiated reservations MUST be allowed in various scenarios
scenarios such as PSTN gateways, some VPNs, and mobility. such as PSTN gateways, some VPNs, and mobility.
5.6.3 Flexibility in the initiation of re-negotiation 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 re-negotiation or change the reservation due to various reasons,
such as local resource shortage (CPU, memory on end-system) or a such as local resource shortage (CPU, memory on end-system) or a
user changed application preference/profiles. user changed application preference/profiles.
5.6.4 SOULD support network-initiated re-negotiation 5.6.4 SOULD support network-initiated re-negotiation
NSIS SHOULD support network-initiated re-negotiation. This is used NSIS SHOULD support network-initiated re-negotiation. This is used
in cases, where the network is not able to further guarantee in cases, where the network is not able to further guarantee
resources and want to e.g. downgrade a reservation. resources and want to e.g. downgrade a reservation.
skipping to change at page 19, line 31 skipping to change at page 19, line 44
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 Location privacy MAY be supported. It is an issue for the initiator
who triggers the signaling protocol. In some scenarios the initiator who triggers the signaling protocol. In some scenarios the initiator
may not be willing to reveal location information to the responder as may not be willing to reveal location information to the responder as
part the signaling procedure. 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 low computation complexity to verify a resource 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 (for example main memory or other additional
message exchanges) before a successful authentication was done. message exchanges) before a successful authentication was 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
skipping to change at page 20, line 4 skipping to change at page 20, line 18
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 a reservation
When existing reservations have to be modified then there is a need When existing reservations have to be modified then there is a need
to use a reservation identifier to uniquely identify the established to use a reservation identifier to uniquely identify the established
state. A signaling protocol MUST provide the appropriate security state. A signaling protocol MUST provide the appropriate security
protection to prevent other entities to modify state without having protection to prevent other entities to modify state without having
the proper ownership. the proper ownership.
5.7.10 Hooks with Authentication and Key Agreement protocols
This requirement covers two subsequent steps before a signaling
protocol is executed and the required hooks. First there is a need to
agree on a specific authentication protocol. Later this protocol is
executed and provides authentication and establishes the desired
security associations. Using these security associations it is then
possible to exchange secured signaling messages.
The signaling protocol implementation SHOULD provide hooks to
interact with protocols that allow the negotiation of authentication
and key agreement protocols. Although the negotiation of an
authentication and key management protocol within the signaling
protocol may be outside the scope it is still required to trigger
this exchange in case that no such security association is available.
This requirement originates from the fact that more than one key
management protocol may be used to provide a security association for
the signaling protocol. Hence the communicating entities must be
capable to agree on a specific authentication. The selected
authentication and key agreement protocol must however be able to
create a security association that can be used within the signaling
protocol.
Key management protocols typically require a larger number of
messages to be transmitted to allow a session key and the
corresponding security association to be derived. To avoid the
complex issue of embedding individual authentication and key
agreement protocols into a specific signaling protocol it is required
that most of these protocols are executed independently (prior to the
signaling protocol) and although the key management protocol may be
independent there must be a way for the signaling protocol to access
and use available (i.e. already established) security associations to
avoid executing a separate key management protocol (or instance of
the same protocol) for protocols that closely operate together. If no
such security association exists then there SHOULD be means for the
signaling protocol to dynamically trigger such a protocol.
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 reservation 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-
skipping to change at page 22, line 33 skipping to change at page 22, line 10
NSIS peers SHOULD be able to detect the malfunctioning peer. It may NSIS peers SHOULD be able to detect the 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. A separate document describes security of a signaling protocol.
threats for NSIS signaling [SEC-THR].
7 References
[SEC-THR] Tschofenig, H., "NSIS Threats", Internet Draft <draft- 7 Informative References
ietf-nsis-threats-00.txt>, October 2002.
[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 ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", 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.
8 Acknowledgments 8 Acknowledgments
skipping to change at page 23, line 20 skipping to change at page 22, line 47
Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis
(Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University
of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars of Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have Westberg (Ericsson), Haihong Zheng (Nokia). Some of those have
actively contributed new text to this document as well. actively contributed new text to this document as well.
Another Internet Draft impacting this document has been written by Another Internet Draft impacting this document has been written by
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.
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 34
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 27, line 7 skipping to change at page 26, line 35
4) The networks are designed and mainly used for speech 4) The networks are designed and mainly used for speech
communication (at least so far). communication (at least so far).
Note that in comparison to the previous scenario emphasis is much Note that in comparison to the previous scenario emphasis is much
less on the mobility aspects, because mobility is mainly handled on less on the mobility aspects, because mobility is mainly handled on
the lower layer. the lower layer.
10.3 UMTS access 10.3 UMTS access
The UMTS access scenario is shown in figure 3. The Proxy-Call State The UMTS access scenario is shown in Figure 1. The Proxy-Call State
Control Function/Policy Control Function (P-CSCF/PCF) is the Control Function/Policy Control Function (P-CSCF/PCF) is the
outbound SIP proxy of the visited domain, i.e. the domain where the outbound SIP proxy of the visited domain, i.e. the domain where the
mobile user wants to set-up a call. The Gateway GPRS Support Node mobile user wants to set-up a call. The Gateway GPRS Support Node
(GGSN) is the egress router of the UMTS domain and connects the UMTS (GGSN) is the egress router of the UMTS domain and connects the UMTS
access network to the Edge Router (ER) of the core IP network. The access network to the Edge Router (ER) of the core IP network. The
P-CSCF/PCF communicates with the GGSN via the COPS protocol. The P-CSCF/PCF communicates with the GGSN via the COPS protocol. The
User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal User Equipment (UE) consists of a Mobile Terminal (MT) and Terminal
Equipment (TE), e.g. a laptop. Equipment (TE), e.g. a laptop.
+--------+ +--------+
skipping to change at page 33, line 28 skipping to change at page 33, line 5
Forwarder (which may be integrated in the MGC) triggers the Forwarder (which may be integrated in the MGC) triggers the
NSIS Forwarder of the next domain. NSIS Forwarder of the next domain.
When the out-of-band QoS signaling is used the Media Gateway When the out-of-band QoS signaling is used the Media Gateway
Controller (MGC) will be acting as the NSIS Initiator. Controller (MGC) will be acting as the NSIS Initiator.
In the second scenario the voice provider manages a set of traffic In the second scenario the voice provider manages a set of traffic
trunks that are leased from a network provider. The MGC does the trunks that are leased from a network provider. The MGC does the
admission control in this case. Since the NSIS Forwarder acts both admission control in this case. Since the NSIS Forwarder acts both
as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is
required. This scenario is shown in figure 1. required. This scenario is shown in Figure 3.
+-------------+ ISUP/SIGTRAN +-----+ +-----+ +-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 | | SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+ +-------------+ +-------+-----+---------+ +-----+
: / : \ : / : \
: / : \ : / : \
: / +--------:----------+ \ : / +--------:----------+ \
: MEGACO / / : \ \ : MEGACO / / : \ \
: / / +-----+ \ \ : / / +-----+ \ \
: / / | NMS | \ \ : / / | NMS | \ \
: / | +-----+ | \ : / | +-----+ | \
: : | | : : : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+ +--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |-- | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+ +--------------+ +----+ \ / +----+
\ QoS network / \ QoS network /
+-------------------+ +-------------------+
Figure 1: PSTN trunking gateway scenario Figure 3: PSTN trunking gateway scenario
In the third scenario, the voice provider does not lease traffic In the third scenario, the voice provider does not lease traffic
trunks in the network. Another entity may lease traffic trunks and trunks in the network. Another entity may lease traffic trunks and
may use a NSIS Forwarder to do per-flow admission control. In this may use a NSIS Forwarder to do per-flow admission control. In this
case the NSIS signaling is used between the MGC and the NSIS case the NSIS signaling is used between the MGC and the NSIS
Forwarder, which is a separate box here. Hence, the MGC acts only as Forwarder, which is a separate box here. Hence, the MGC acts only as
a NSIS Initiator. This scenario is depicted in figure 2. a NSIS Initiator. This scenario is depicted in Figure 4.
+-------------+ ISUP/SIGTRAN +-----+ +-----+ +-------------+ ISUP/SIGTRAN +-----+ +-----+
| SS7 network |---------------------| MGC |--------------| SS7 | | SS7 network |---------------------| MGC |--------------| SS7 |
+-------------+ +-------+-----+---------+ +-----+ +-------------+ +-------+-----+---------+ +-----+
: / : \ : / : \
: / +-----+ \ : / +-----+ \
: / | NF | \ : / | NF | \
: / +-----+ \ : / +-----+ \
: / : \ : / : \
: / +--------:----------+ \ : / +--------:----------+ \
skipping to change at page 34, line 25 skipping to change at page 33, line 53
: : / +-----+ \ : : : / +-----+ \ :
: : / | NMS | \ : : : / | NMS | \ :
: : | +-----+ | : : : | +-----+ | :
: : | | : : : | | :
+--------------+ +----+ | bandwidth pipe (SLS) | +----+ +--------------+ +----+ | bandwidth pipe (SLS) | +----+
| PSTN network |--| MG |--|ER|======================|ER|-| MG |-- | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
+--------------+ +----+ \ / +----+ +--------------+ +----+ \ / +----+
\ QoS network / \ QoS network /
+-------------------+ +-------------------+
Figure 2: PSTN trunking gateway scenario Figure 4: PSTN trunking gateway scenario
In the fourth scenario multiple transport domains are involved. In In the fourth scenario multiple transport domains are involved. In
the originating network either the MGC may have an overview on the the originating network either the MGC may have an overview on the
resources of the overlay network or a separate NSIS Forwarder will resources of the overlay network or a separate NSIS Forwarder will
have the overview. Hence, depending on this either the MGC or the have the overview. Hence, depending on this either the MGC or the
NSIS Forwarder of the originating domain will contact the NSIS NSIS Forwarder of the originating domain will contact the NSIS
Forwarder of the next domain. The MGC always acts as a NSIS Forwarder of the next domain. The MGC always acts as a NSIS
Initiator and may also be acting as a NSIS Forwarder in the first Initiator and may also be acting as a NSIS Forwarder in the first
domain. domain.
10.10 Application request end-to-end QoS path from the network 10.10 Application request end-to-end QoS path from the network
 End of changes. 

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